Чат-бот обратной связи: опрос после услуги и передача проблемы

Чат-бот обратной связи полезен, если он не просто собирает оценки, а помогает заметить проблему и передать её человеку. Для этого руководителю сервиса нужно определить событие запуска, задать два-три нейтральных вопроса, предусмотреть отказ и описать маршрут критичного ответа.

Эта статья посвящена обратной связи клиента после конкретной услуги. Это не опрос сотрудников и не подготовка ответа на уже опубликованный отзыв. Полученная в личном диалоге оценка остаётся частью сервисного процесса, пока клиент отдельно не согласился на её публикацию.

Когда запрашивать обратную связь после услуги

Запускайте опрос после подтверждённого завершения услуги. Само по себе сообщение исполнителя «готово» может быть недостаточным: в одном процессе завершением считается выдача результата, в другом — приёмка клиентом, закрытие заказа или изменение согласованного статуса в рабочей системе.

До настройки бота запишите три условия события:

1. Какой статус подтверждает завершение услуги.
2. Кто или какая система меняет этот статус.
3. Какие события отменяют или откладывают отправку.

Например, заказ не стоит считать завершённым, если мастер закончил работу, но клиент ещё не получил оборудование. Иначе опрос придёт раньше результата, который предлагается оценить.

После события система проверяет канал. Telegram-бот не может первым начать личный разговор с произвольным пользователем: человек должен прежде сам отправить ему сообщение или запустить диалог. Поэтому одного номера телефона или имени клиента недостаточно. Для Telegram нужен ранее начатый диалог и сохранённая связь между ним и заказом.

Если такого диалога нет, не пытайтесь обходить ограничение. Предусмотрите другой заранее согласованный канал или не отправляйте опрос. Возможность технически доставить сообщение сама по себе не определяет, допустимо ли использовать канал: правила контакта и обработки данных утверждает специалист заказчика.

Полезно разделить три разных действия:

• запросить у клиента оценку завершённой услуги;
• передать просьбу о помощи ответственному сотруднику;
• опубликовать отзыв или ответить на уже опубликованный материал.

Первое не даёт автоматического разрешения на третье. Личная обратная связь нужна для работы с услугой, а публикация требует отдельного основания.

Как составить короткие понятные вопросы

Свяжите вопрос с конкретной услугой, чтобы клиент понимал, что именно оценивает. Вместо «Вам всё понравилось?» спросите: «Как вы оцените ремонт заказа R-1042 по шкале от 1 до 5?» Такая формулировка не подсказывает желательный ответ и отделяет этот ремонт от других обращений клиента.

После оценки дайте свободное уточнение: «Что повлияло на оценку?» Оно помогает увидеть обстоятельство, которого нет в готовом списке. Если сервис должен быстро принимать просьбы о помощи, добавьте отдельный вопрос: «Нужна помощь сотрудника?»

Короткий сценарий выглядит так:

1. Оценка конкретной услуги по понятной шкале.
2. Свободный комментарий о причине оценки.
3. Отдельный запрос помощи, если он нужен процессу.
4. Возможность отказаться от последующих опросов.

Не заменяйте нейтральную оценку вопросом «Насколько превосходно мы справились?» и не просите клиента исправить низкий балл. Бот собирает сигнал, а не добивается комплимента.

Молчание также не является положительной оценкой. Если клиент не ответил, сохраните состояние «ответ не получен». Не подставляйте вместо него максимальный балл и не включайте такое событие в среднюю оценку.

Заранее решите, связываются ли ответы с идентификатором диалога, заказом и контактом клиента. Если такая связь сохраняется, не называйте весь опрос анонимным. В системах опросов анонимность может быть отдельной настройкой, но она не делает анонимной всю цепочку бота, если другая её часть хранит идентификатор пользователя. Клиенту лучше прямо объяснить, какие сведения нужны для обработки ответа.

Как подключить бот и право на сообщение

Сначала определите не платформу, а операцию: какое событие запускает опрос, кому можно написать, куда записывается ответ и кто получает просьбу о помощи. После этого можно выбирать конструктор или собственную разработку.

Это критерии выбора, а не обещание совместимости. Возможности, тариф, права и доступность API проверяют отдельно для выбранной платформы и системы заказчика.

Официальная документация Telegram подтверждает первые шаги: бота регистрируют через BotFather, полученный токен хранят как секрет, а обработку сообщений выполняет подключённый сервер. Полная учебная последовательность для этого сценария выглядит так:

1. Обратиться к BotFather и зарегистрировать бота.
2. Получить токен аутентификации.
3. Сохранить токен как секрет и открыть доступ только тем, кому он нужен.
4. Подключить к боту сервер или выбранную платформу обработки сообщений.
5. Настроить связь между завершением услуги, вопросами и маршрутом обращения.
6. Провести пробный диалог с тестовой учётной записью, которая сама начала разговор с ботом.

Это учебная последовательность на основе документации и требований описанного процесса, а не отчёт о выполненной настройке. Конкретные элементы интерфейса и доступные команды нужно сверить в Telegram и выбранном средстве разработки перед работой.

Токен даёт контроль над ботом. Не вставляйте его в текст сценария, публичную инструкцию или репозиторий. Используйте принятое в компании хранилище секретов, ограничьте доступ и предусмотрите замену токена при утечке. Рекомендации OWASP помогают сформировать общий порядок управления секретами, но не доказывают, что он уже внедрён в конкретной компании.

Перед первым вопросом объясните назначение диалога простыми словами. Например: «Зададим три вопроса о ремонте заказа R-1042. Ответы свяжем с заказом, чтобы сервис мог разобраться в проблеме. От последующих опросов можно отказаться».

Не копируйте этот текст как юридическую формулу. Состав данных, основание обработки и окончательный текст уведомления определяет специалист заказчика. Отказ должен прекращать последующие опросы по согласованному правилу, но не отменять оказанную услугу и не мешать клиенту попросить о помощи.

Как передавать негатив и просьбу о помощи

Задайте признаки, при которых ответ перестаёт быть только строкой в отчёте. Критичным сигналом могут быть:

• оценка в заранее согласованном низком диапазоне;
• явная просьба связаться с сотрудником;
• сообщение о повторной неисправности;
• описание риска или незавершённой услуги.

Сигнал должен создавать обращение, а не исчезать из-за неудобной формулировки. Передайте в него номер услуги, оценку, комментарий, время ответа, признак запроса помощи и доступный контактный контекст. Затем назначьте ответственного и правило контроля статуса.

Бот не должен ставить диагноз. По фразе «Неисправность повторилась» нельзя заключить, что мастер ошибся или сломалась определённая деталь. Безопасный ответ сообщает организационный шаг: «Создали обращение и передали описание ответственному сотруднику. Он проверит ситуацию по правилам сервиса».

Статусы полезно развести так:

• «создано» — обращение записано;
• «назначено» — указан ответственный;
• «в работе» — сотрудник принял задачу;
• «решено» — выполнено согласованное условие закрытия;
• «закрыто без решения» — зафиксирована отдельная допустимая причина.

Назначение сотрудника ещё не означает решения. Условием закрытия может быть подтверждённый следующий шаг, повторная услуга или другое действие, которое владелец процесса заранее определил в регламенте.

Не удаляйте негатив ради красивой статистики и не публикуйте переписку как отзыв. Для анализа публичных отзывов предназначен отдельный процесс — разбор отзывов и обратной связи. Здесь задача состоит в том, чтобы помочь клиенту и сохранить контекст для сотрудника.

Как хранить результаты и считать показатели

Разведите события, которые часто ошибочно объединяют словом «опрос»:

• отправлено — система сформировала и передала сообщение в канал;
• доставлено — канал подтвердил доставку, если такой статус доступен;
• отвечено — клиент отправил хотя бы предусмотренный ответ;
• создано обращение — критичный сигнал прошёл правило маршрутизации;
• решено — обращение достигло согласованного результата закрытия.

Если канал не предоставляет надёжного статуса доставки, не называйте отправленное сообщение доставленным. Храните доступный технический статус и ограничение данных.

Рассмотрим синтетический набор за один период: отправлено 120 опросов, доставлено 114, получено 18 ответов. В пяти ответах клиенты поставили 1–2 балла. Три из этих пяти клиентов попросили помощь, поэтому система создала три обращения. Два обращения решены, одно остаётся открытым.

Шесть недоставленных сообщений и 96 доставленных опросов без ответа не являются хорошими оценками. Их нельзя добавлять к положительным ответам. Показатель решения также считают как 2 из 3 обращений, а не как 2 из 5 низких оценок: два клиента с низкой оценкой не попросили помощи и по заданному правилу не образовали обращения.

Такая выборка не подтверждает вывод обо всех клиентах. Восемнадцати ответов недостаточно, чтобы уверенно описать мнение всех 114 получателей, а три обращения — слишком малая база для устойчивой оценки доли решений. Эти числа помогают проверить арифметику и состояния процесса, но не обещают рост рейтинга.

Для сравнения периодов фиксируйте одинаковые канал, момент отправки, вопросы и знаменатель. Если один месяц считать ответы от доставленных, а другой — от отправленных, изменение показателя может появиться только из-за метода расчёта.

Учебный пример опроса после ремонта

Ниже — синтетический пример для проектирования сценария. Заказ R-1042 и обращение A-207 вымышлены; это не клиентский кейс и не результат внедрения Switch On AI.

Заказ R-1042 получил подтверждённый статус завершения. Клиент ранее сам начал диалог с Telegram-ботом, поэтому система может продолжить разговор в этом чате. Бот спрашивает: «Как вы оцените ремонт заказа R-1042 по шкале от 1 до 5?» Клиент выбирает 2 и пишет: «Неисправность повторилась». На вопрос о помощи он отвечает утвердительно.

Система не публикует ответ и не пытается определить причину неисправности. Она создаёт обращение A-207, передаёт контекст диспетчеру, назначает ответственного по правилам сервиса и сообщает клиенту дальнейший организационный шаг. Отдельно остаётся возможность отказаться от будущих опросов.

Этот ответ не является внешним отзывом. Клиент отправил его в сервисный диалог для разбора конкретного ремонта. Чтобы разместить текст публично, нужен отдельный процесс и соответствующее основание; сам факт получения оценки такого права не создаёт.

Пример показывает важное исключение: низкий балл сам по себе ещё не решает проблему. Ценность сценария появляется, когда комментарий и просьба о помощи доходят до ответственного, а обращение остаётся открытым до подтверждённого результата.

Как проверить опрос и запустить его с командой

До пилота подготовьте таблицу проверок: исходное событие, ожидаемое действие, фактический результат и ответственный за расхождение. Одного удачного диалога недостаточно. Команда должна пройти как минимум следующие ситуации:

Назначьте владельцев правил до запуска: руководитель сервиса определяет событие завершения и маршрут; специалист заказчика утверждает обработку данных и уведомление; техническая команда проверяет подключение, повторы, ошибки и доступы; сотрудники сервиса подтверждают условия закрытия обращения.

Для пилота выберите одну услугу, один канал и небольшой контролируемый сценарий. Не подключайте сразу все типы заказов: так легче увидеть, где теряется статус, дублируется опрос или остаётся без владельца обращение.

Switch On AI может помочь описать эту операцию, подготовить прототип бота или интеграции и согласовать проверочные сценарии. Возможность подключения подтверждается после проверки данных, API и прав. Прототип показывает согласованный фрагмент процесса и не означает полноценного внедрения.

На странице разработки чат-ботов можно сравнить меню, свободный диалог и передачу обращения сотруднику. Чтобы обсудить задачу, опишите процесс и выбранный канал: разберём завершение одной услуги, маршрут обратной связи и критерии прототипа без обещания заранее заданного эффекта.