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