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