Когда передавать диалог от чат-бота оператору

Согласуйте причины передачи до настройки бота

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

• Прямая просьба о человеке. Дайте доступный способ вызвать оператора. Не заставляйте клиента сначала пройти ещё один круг автоматических подсказок.
• Недостаточно оснований для ответа. Нет подходящего утверждённого источника, источники противоречат друг другу или клиент уже сообщил, что ответ не помог. Допустимое число уточнений задайте до запуска.
• Не хватает полномочий. Например, решение об исключении из правил возврата или изменении условий заказа принимает сотрудник. Бот может собрать контекст, но не должен обещать одобрение.
• Не удалось выполнить действие. Система заказов недоступна, запись не подтверждена или идентификатор обращения не получен. Нужен отдельный маршрут сбоя, чтобы бот не объявлял успех.

Это рекомендуемая схема приёмки Dev Crabs, а не универсальный регламент. Для срочных и чувствительных обращений владелец процесса отдельно определяет группу и время реакции. Числовую «уверенность» модели нельзя без проверки на своих примерах считать вероятностью правильного ответа.

Передайте контекст, с которого можно продолжить

Проверьте карточку глазами принимающего сотрудника. В ней должны быть причина передачи, запрос клиента, история уже предложенных решений, результат выполненных действий и следующий шаг. Добавьте ID обращения, время запроса человека, очередь и текущего ответственного. Ссылки на заказ и вложения передавайте только в пределах прав получателя.

Краткое резюме полезно для начала работы, но оно может потерять условие или неверно пересказать отказ клиента. Оставьте доступ к исходным сообщениям в разрешённой системе. В резюме отделяйте слова клиента от предположений бота: «клиент сообщает о повторном списании» не равнозначно подтверждённому повторному платежу.

Универсального поля «передать всё» нет. В документации Just AI действие TransferToOperator требует подключённого операторского канала. Параметры истории настраиваются отдельно; prechatAttributes поддерживается для Aimychat и LiveTex, а destination — для Aimychat и Operator API. Совместимость полей с вашей системой нужно проверить на конкретном подключении.

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

Одна переписка, три состояния смены

Учебный пример. Клиент: «Хочу вернуть заказ. Бот уже прислал инструкцию, но мой случай в ней не описан. Позовите сотрудника». Карточка R-104: причина — запрос человека; тема — возврат; действие бота — показана инструкция; решения о возврате ещё нет. Идентификатор и расписание ниже вымышлены; это иллюстрация для проверки, не подключение к helpdesk и не клиентский кейс.

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

Если канал закрывается вместе с сессией, фраза «ответим в этот чат» не подходит. Заранее определите разрешённый способ продолжения связи и объясните его клиенту. При сбое сохранения нельзя показывать номер, которого ещё нет в системе: сообщите об ошибке и предложите действующий резервный канал.

Разделите сохранение, ожидание и приём человеком

Для контроля достаточно понятных состояний: «запрошен человек» → «сохранено» → «ожидает в очереди» → «принято сотрудником». Ответ клиенту и решение вопроса отмечайте отдельно. Принятое обращение ещё не означает решённую проблему.

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

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

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

Прогоните маршрут до включения на клиентах

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

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

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

Проверяйте изменения правил как отдельный выпуск

5 ноября 2026 года Intercom сообщил о Releases для Fin: изменения контента, инструкций, правил эскалации и процедур можно объединять, проверять и включать постепенно. FAQ поставщика датирует общую доступность тем же днём. Это состоявшийся выпуск функции конкретного продукта; он не доказывает рост внедрений или качество передачи в вашей поддержке.

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

Считайте принятые обращения и незавершённое ожидание

Выберите период по моменту запроса человека и задайте окно наблюдения. Для этой группы отдельно посчитайте сохранённые обращения, принятые сотрудником, ожидающие и потерянные при передаче. Доля принятых — число обращений с подтверждением приёма, делённое на число обращений, которым по правилам требовался человек. Запросы, которые бот не распознал, тоже входят в знаменатель после проверки выборки.

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

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

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

Частые вопросы