Начать с разговора, который не помещается в меню
Возьмём условный сервис ремонта. Клиент пишет: «Курьер забрал устройство, но статус не изменился. Завтра я уезжаю». Формально тема — статус заказа. По смыслу человеку нужно ещё понять, успеет ли он получить устройство, и договориться о дальнейших действиях.
Ответ из справки может объяснить, когда обновляются статусы. Для решения конкретной ситуации потребуются данные заказа и сотрудник с нужными полномочиями. Если бот продолжит выдавать общие инструкции, он правильно распознает тему, но не поможет человеку.
До разработки стоит собрать несколько характерных разговоров, обезличить их и отметить момент, когда справки становится недостаточно. Так появляется граница ответственности: какие вопросы бот закрывает сам, какие уточняет, какие сразу передаёт команде. Граница полезнее длинного перечня команд.
У каждого вопроса должна быть работа
Чтобы проверить заказ, может понадобиться его номер. Чтобы выбрать сервисную команду — город или подразделение. Если ответ не влияет ни на маршрут обращения, ни на решение, его сбор стоит отложить. Анкета из десяти обязательных полей может выглядеть организованной, оставляя человека без помощи на первом экране.
Заранее предусмотрите ответ «Не знаю номер». Покажите, где его найти, или предложите допустимый альтернативный способ обращения. Если для доступа к сведениям нужна проверка личности, проектируйте её отдельно. Сам факт переписки с ботом не даёт права раскрывать данные по любому введённому номеру.
После уточнений полезно коротко подтвердить смысл: «Передам сотруднику, что вы уезжаете завтра и хотите уточнить, когда сможете получить устройство». Человек должен иметь возможность исправить неверно понятый запрос. При этом не нужно повторять в общем чате чувствительные сведения или просить документы, которые не требуются для текущего шага.
Передать человеку — значит передать и контекст
Надпись «Оператор скоро ответит» не создаёт рабочую очередь. На стороне компании нужны само обращение, ответственный, состояние обработки и способ заметить, что никто не подключился. Если два сотрудника могут одновременно взять один разговор, нужно заранее определить, как они увидят действия друг друга.
Сотруднику стоит передать тему, уже полученные необходимые сведения, последние сообщения и причину перехода от бота. Клиенту — сообщить, что именно произошло: запрос зарегистрирован или конкретный специалист уже подключился. Обещать короткое время ответа можно лишь тогда, когда команда способна его выдержать.
Когда сотрудник вступил в разговор, автоматические ответы не должны спорить с ним или заново запускать анкету. Практическая схема состояний может быть простой: «уточняем вопрос», «ожидаем сотрудника», «сотрудник отвечает», «обращение завершено». Важно определить, какие события переводят разговор между состояниями.
Нужен и порядок на нерабочее время. Человек может оставить описание, узнать часы ответа и воспользоваться другим доступным каналом, если ситуация не терпит ожидания. Бот не должен создавать впечатление круглосуточной службы только потому, что сам доступен круглые сутки.
Клиенты не обязаны идти по сценарию
После передачи оператору человек может дописать важную подробность, прислать фото или нажать старую кнопку в истории. Каждое такое действие должно иметь понятный результат. Дополнение обычно нужно связать с текущим обращением; устаревшую кнопку — объяснить или заменить актуальным действием.
Отдельно разберите повторную доставку событий и ошибки отправки сообщений. Они не должны создавать несколько одинаковых задач или скрывать тот факт, что ответ не ушёл. В документации Telegram описаны подтверждение полученных обновлений и ограничения частоты отправки. Эти особенности требуют обработки в приложении; пользователю незачем разбираться в технических повторах.
Если вложения не поддерживаются, сообщите об этом до того, как человек потратит время. Если поддерживаются — определите, какие файлы допустимы, кто получит доступ и как долго они понадобятся. Передача файлов в привычный мессенджер не избавляет компанию от необходимости продумать обращение с данными.
Приёмка с двух сторон разговора
Проверяйте бота вдвоём: один человек играет клиента, другой работает в интерфейсе сотрудника. Пройдите обычный вопрос, отсутствие номера заказа, просьбу сразу связаться с человеком, дополнение к обращению и сообщение после завершения. Для каждого эпизода проверьте, что видят обе стороны.
Затем внесите помеху в тестовом окружении: сотрудник недоступен, внешняя система не отвечает, одно событие приходит повторно. Зафиксируйте ожидаемое сообщение клиенту и действие команды. Если после ошибки всем приходится смотреть в серверный журнал, операционный сценарий пока не закончен.
После запуска смотрите на завершённые задачи, повторные обращения по той же теме и время до содержательного ответа. Доля разговоров без оператора сама по себе двусмысленна: часть клиентов получила помощь, часть могла просто уйти. Разбирайте несколько цепочек целиком. Бот полезен тогда, когда понятна судьба обращения — даже если в нужный момент он уступил место человеку.