Чтобы проверить передачу диалога от бота оператору, откройте учебную переписку со стороны клиента и сотрудника. Найдите обращение в принимающей системе, проверьте назначение, исходную историю и ответ человека в том же чате. До проверки договоритесь о времени ожидания, о том, когда бот перестаёт отвечать, и как снова получает управление.
Ниже предложен лист приёмки для вашей команды и подрядчика. Проверка документации проведена 14 октября 2026 года. Учебные сообщения и ожидаемые результаты вымышлены; испытания передачи в этих сервисах не проводились.
Разборы применения ИИ в работе компании можно читать в канале автора.
Что считать передачей диалога оператору?
Сначала определите, что вы покупаете: продолжение разговора человеком в том же чате или создание обращения с отложенным ответом. Оба варианта можно использовать, если клиент понимает, что произойдёт дальше. Ссылка на контакт сотрудника сама по себе не переносит текущую переписку.
| Наблюдение | Что оно подтверждает | Что проверить дальше |
|---|---|---|
| Бот сообщил о передаче | Клиент увидел сообщение | Появилось ли обращение у команды |
| Обращение видно в очереди | Принимающая система сохранила его | Кто назначен и доступна ли история |
| Указан назначенный сотрудник | У обращения есть ответственный в системе | Принял ли он разговор и что видит |
| Ответ сотрудника виден клиенту | Обратный путь сработал в этом случае | Верно ли продолжен разговор и кто отвечает дальше |
Это предлагаемые ступени проверки, названия статусов в вашем продукте могут отличаться. В справке Microsoft Copilot Studio описан вариант работы агента standard harness; перед настройкой проверьте, применим ли этот раздел к вашей конфигурации. В нём показана похожая граница: системный сценарий Escalate может лишь вывести сообщение о помощи человека. У агента, созданного непосредственно в Copilot Studio, в этом сценарии по умолчанию нет шага Transfer conversation, который передаёт разговор. Для работы с операторами настраивают подключение к их системе обслуживания.
Если у вас пока справочный помощник с контактом поддержки, сначала прочитайте инструкцию по запуску ИИ-бота в Telegram. Автоматический перенос диалога и истории там выделен как отдельная задача.
Что согласовать до проверки?
Начните с прямой просьбы о человеке, вопроса без ответа в разрешённых источниках и отказа клиента от предложенного решения. Дополните список темами, которые ваша компания поручает только сотруднику. Не задавайте выдуманный универсальный порог уверенности модели или число неудачных попыток: правило нужно согласовать для вашей поддержки и проверить на разных формулировках.
Например, в модуле Ai-бот Carrot quest предусмотрены стоп-фразы и отдельные ответы при переводе в рабочее и нерабочее время. В настройках раздела «Перевод диалогов на оператора» фразу вводят в поле и нажимают Enter. Но справка по оптимизации предупреждает о неточном распознавании стоп-слов в неожиданном контексте. Она предлагает добавлять другие формы слова или целые фразы. Поэтому проверьте «оператор», «хочу поговорить с человеком» и фразу, где это слово относится к другому предмету.
Очередь должна вести к команде, которая действительно обрабатывает такие вопросы. В Открытых линиях Битрикс24 результат назначения зависит в том числе от настройки проверки доступности сотрудника. Если никто не принял диалог, система снова ищет оператора. Справка описывает, что происходит при этом поиске, если операторов нет:
«Если операторов нет, диалог останется в очереди.»
Для вашей системы отдельно выясните, кто увидит ночное обращение, как сохранится уточнение клиента и как команда узнает о нём после начала работы. Не обещайте подключение сотрудника, если подтверждена только постановка в очередь. Если запись не удалась или её состояние неизвестно, клиенту нужен согласованный запасной путь, а проверяющему нужно отметить сбой.
Обсудить организацию передачи диалогов можно через форму ниже. Для разговора подготовьте канал общения и рабочее место сотрудников.
Консультация
Заявка на консультацию по внедрению ИИ
Оставьте контакт: свяжемся и обсудим, какие задачи вашей компании имеет смысл передать искусственному интеллекту.
Как проверить историю на стороне оператора?
Используйте вымышленные данные и согласованную тестовую среду. Не передавайте в модель реальные клиентские контакты и закрытую переписку ради этого упражнения. Допустимые данные и доступы команды можно закрепить по политике использования ИИ в компании.
Ниже отдельный учебный разговор D05. Номера M01 и дальше обозначают сообщения; X01 обозначает подтверждение действия в условной системе. Все строки придуманы для проверки, это не журнал работы настоящего бота.
D05 / M01 / клиент: Раздел пустой, но вчера работал.
D05 / M02 / бот: Откройте экран заново.
D05 / M03 / клиент: Открыл. Не помогло.
D05 / X01 / система: Учебная отметка диагностики сохранена.
D05 / M04 / клиент: Передайте оператору; повторять всё не хочу.Для этого упражнения оператор должен увидеть все пять строк в указанном порядке. Попытка открыть экран известна со слов клиента; сохранение отметки подтверждается X01. Просьба бота выполнить действие не считается подтверждением его выполнения. Если сводка сообщает «вопрос решён», она противоречит M03. Если в ней осталось только M01, сотрудник не увидит уже предпринятую попытку.
Попросите сотрудника продолжить именно этот разговор. Его ответ должен учитывать, что клиент уже открыл экран заново и это не помогло; сообщение сотрудника должно появиться у клиента в том же диалоге. Первый ответ человека ещё не подтверждает решение проблемы.
Если для работы нужны вложения, добавьте отдельный искусственный файл и проверьте, может ли оператор его открыть. Проверка текстовой истории не подтверждает доставку файла. Поддержку форматов и способ доступа согласуйте с исполнителем; отсутствие нужного вложения запишите как ограничение.
Какие сценарии прогнать перед запуском?
Таблица задаёт восемь учебных сценариев. Это ручные эталоны предлагаемой приёмки, фактические результаты пока не получены. Перед каждым сценарием берите отдельный тестовый разговор, чтобы результат предыдущего не менял начальные условия. Для вашей системы сначала подтвердите, какие механизмы поддерживаются.
| Сценарий | Учебное условие | Ожидаемый результат по согласованным правилам |
|---|---|---|
| D01: просьба о человеке | «Позовите оператора, пожалуйста» | Передача запускается без обязательного повторного объяснения; обращение видно команде |
| D02: нет ответа в базе | Вопрос о режиме Z, которого нет в учебной справке | Отсутствие ответа обозначено, вопрос передан без выдуманного объяснения режима |
| D03: решение не помогло | Клиент уже открыл экран заново и сообщает, что это не помогло | История сохраняет попытку; бот не повторяет совет бесконечно |
| D04: ожидание | Все сотрудники заняты либо обращение пришло вне согласованных часов | Обращение сохранено; клиент видит сообщение об ожидании без обещания подключения сотрудника; назначение и ответ отмечаются позже |
| D05: история | Пять строк D05: жалоба, совет, неудачная попытка, отметка X01 и просьба об операторе | Оператор видит исходные строки, порядок, авторство и подтверждение X01 |
| D06: повтор события | Одна просьба доставлена дважды с одним номером события | В очереди остаётся одно обращение по этой просьбе; отдельная новая реплика сохраняется |
| D07: человек принял разговор | Клиент задаёт новый вопрос после подключения сотрудника | В выбранном режиме полного перехода бот не отвечает клиенту параллельно человеку |
| D08: возврат боту | Сотрудник выполняет заранее согласованное действие возврата | До подтверждения возврата отвечает человек; после действует выбранное правило бота |
Для D02 заранее подготовьте учебную справку, в которой есть только совет открыть экран заново и нет режима Z. В D04 прогоните обе ветви: очередь в рабочие часы и обращение вне графика. Это разные начальные условия одного сценария.
Обращение в очередь и первый ответ человека фиксируйте раздельно. Если сотрудников сейчас нет, можно подтвердить сохранение истории и ожидание, но проверка продолжения разговора остаётся незавершённой до ответа сотрудника.
Что делать с повторами и возвращением к боту?
В сценарии D06 при повторной доставке события попросите исполнителя дважды доставить одну учебную просьбу с тем же идентификатором, то есть номером события, затем отправьте такую же фразу как новое сообщение с новым номером. По предложенным правилам проверки в первом случае в очереди должно остаться одно обращение по этой просьбе; во втором оператор должен получить новую реплику. Так вы проверите, что система различает сообщения по номеру события.
Срок хранения номеров событий и обработку поздних повторов согласуйте отдельно. Если канал не предоставляет устойчивые идентификаторы, исполнитель должен объяснить поддерживаемый способ проверки. Нельзя обещать отсутствие дублей только по названию конструктора.
В сценарии D07, после принятия разговора человеком, добавьте вопрос, на который бот умеет отвечать. Проверьте обе стороны: вопрос дошёл оператору, а клиент не получил конкурирующий содержательный ответ бота. Отдельно разберите ответ модели, который начал готовиться до переключения и отправляется позже: способ остановки или отклонения такого ответа зависит от реализации.
Правила возврата действительно различаются. В Zendesk messaging описано возвращение после перехода связанного обращения из Solved, «решено», в Closed, «закрыто». Новое сообщение клиента после этого перехода начинает новый разговор, в котором бот снова становится первым отвечающим. Одна отметка «решено» не означает, что такой переход уже произошёл. Это поведение Zendesk messaging, его нельзя подставить как правило вашего другого сервиса.
В сценарии D08, при возврате управления боту, предлагается правило упражнения: сотрудник явно завершает передачу и подтверждает возвращение управления боту. Это не обещание одноимённой кнопки в любом продукте. Если вашей системе подходит другой механизм, замените условие и ожидаемый результат до теста, сохранив проверку того, кто отвечает после перехода.
Как принять результат и найти место сбоя?
Для каждого сценария заполните запись. Номер диалога должен позволять найти тот же разговор и у клиента, и в системе поддержки; способ связывания согласуйте с исполнителем.
Сценарий и версия правил:
Канал и номер учебного диалога:
Исходное условие:
Ожидаемый результат:
Сообщение бота о передаче:
Где видно принятое обращение:
Назначенный сотрудник или состояние очереди:
Исходная история и подтверждения действий:
Ответ сотрудника, увиденный клиентом:
Кто отвечает после переключения:
Фактический результат и ссылки на доказательства:
Итог: соответствует / не соответствует / не провереноПорядок приёмки:
- Согласуйте маршрут, правила переключения и ожидаемые результаты.
- Выполните учебные сценарии со стороны клиента и оператора.
- Сверьте историю и подтверждения действий, затем обратный ответ.
- Разберите повторные события, нерабочие часы и возвращение боту.
- Исправьте несоответствия и повторите затронутые проверки.
Если запись не появилась, разбирайте переход в принимающую систему. Если запись есть без ответственного, проверяйте очередь и назначение. Если сотрудник ответил, но клиент не увидел сообщения, проверяйте обратный путь. Для потерянной реплики отдельно сверяйте передачу истории и права доступа оператора. Скриншот настроек показывает настройки; доставку подтверждает наблюдение у получателя.
Восемь учебных сценариев не измеряют качество ответов на всём потоке, нагрузку, сохранность данных и скорость восстановления после отказа. Дополнительные проверки согласуйте по последствиям ошибки в вашей компании. Для общего выбора продукта полезны вопросы продавцу ИИ-сотрудника; здесь принимается один конкретный переход диалога.
Для обсуждения подготовьте канал, рабочее место операторов и примеры найденных несоответствий без клиентских данных. В форме ниже укажите контакт и сайт компании, чтобы обсудить организацию передачи диалогов.
Источники
- Carrot quest: Ai-бот.
- Carrot quest: Оптимизация работы с AI-ботом.
- Битрикс24: Как настроить очередь сотрудников в открытых линиях.
- Microsoft Learn: Hand off to a live agent.
- Zendesk: Managing conversation handoff and handback.