Когда ИИ-агент должен передавать диалог человеку

Задайте причины передачи до запуска

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

Разделите отсутствие знаний и отсутствие полномочий. Агент может знать стандартные условия, но не иметь права менять их. Например, индивидуальную скидку согласует ответственный сотрудник, даже если клиент подробно объяснил ситуацию. Не стоит сводить все случаи к абстрактной «уверенности модели». Границы задач и разрешённые действия можно проверять по явным правилам и тестовым обращениям.

Сделайте простую матрицу решений

Ниже — условный образец для обсуждения с командой. Он не описывает готовую настройку ЛидПотока: роли и порядок действий нужно адаптировать к вашей работе.

Таблицу можно прокрутить по горизонтали.

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

Передайте причину, договорённости и историю

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

Сохраните доступ к полной истории в рабочем инструменте, если выбранная интеграция это поддерживает. Например, документация Microsoft Copilot Studio описывает передачу истории и переменных в подключённый сервис обслуживания. Это пример возможностей конкретной платформы, а не универсальная функция любого бота. Для вашей системы нужно проверить, какие данные и через какое подключение увидит сотрудник. Не включайте в уведомление сведения, которые получателю не нужны для решения задачи.

Различайте запрос, уведомление и принятый диалог

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

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

Продумайте ожидание и нерабочее время

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

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

Проверьте передачу с обеих сторон

Тест считается законченным, когда понятен результат для клиента и сотрудника. Начните с обычной просьбы о человеке, затем добавьте вопрос вне материалов, конфликтующую информацию, недоступность CRM и отсутствие ответственного. Проверьте также повторное сообщение клиента, пока он ждёт: агент должен учитывать уже начатую передачу.

1. Причина передачи определена по согласованным правилам.
2. Клиент получил понятное сообщение без неподтверждённых обещаний.
3. Уведомление пришло нужной роли или очереди.
4. Сотрудник видит историю и следующий шаг.
5. После принятия нет одновременных ответов агента.
6. Неудавшаяся передача видна и может быть восстановлена.

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

Используйте передачи для улучшения системы

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

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

Отличайте возражение от решения, которое принимает человек

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

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

Заполненная сводка и восстановление передачи

Учебная сводка: «Запрос: кухня; размеры 3 × 2 м; срок — декабрь; бюджет не указан; причина передачи — запрос нестандартной рассрочки; обещания не даны; следующий шаг — согласовать условия с менеджером». В журнале 18:05 — handoff_requested, 18:05 — очередь недоступна, 18:06 — повтор поставлен в резервную очередь, 09:10 — сотрудник принял. До последнего события статус «ожидает принятия».

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