Когда чатботу пора передать диалог человеку
Передача нужна не по таймеру и не после условного числа сообщений, а когда следующий шаг выходит за пределы заранее описанного сценария. Например, собеседник просит индивидуальное условие, которого нет в базе ответов, или сообщает сведения, не позволяющие определить запрос. В такой ситуации продолжение автоматических уточнений может лишь затянуть разговор.
В правилах можно задать события передачи: запрос исключения, противоречивые ответы, нехватка обязательных данных или прямое желание поговорить с сотрудником. Затем определить маршрут: кто принимает обращение, в какой очереди оно появляется и что происходит вне рабочего времени. ИИ-автоматизация маркетинга связана с тем, как согласовать такие правила с остальными этапами коммуникации.
Условия должны быть наблюдаемыми, а не расплывчатыми. Вместо формулировки «сложный запрос» укажите, какие поля обязательны, какие ответы считаются противоречивыми и какие темы требуют сотрудника. Для каждого события определите адресата и минимальный набор сведений. Тогда команда сможет менять правило на конкретных примерах, а не спорить о значении слова «сложность».
Что показывает пример Siemens и Salesforce
В публикации Salesforce от 15 сентября 2026 года сообщается, что ИИ-квалификация охватывает 100% рассматриваемых входящих лидов Siemens в 132 странах. В описании агент использует CRM-контекст, уточняет сведения и сохраняет ответы, в том числе о бюджете и сроках.
Это охват описанного входящего потока в клиентском кейсе поставщика, а не конверсия, точность, рост выручки или результат независимого аудита. Пример показывает масштаб применения в конкретном контексте, но не задаёт универсальный порог передачи: он зависит от задачи, правил компании и решений, для которых нужен сотрудник.
Условный пример: запрос выходит за рамки сценария
Представим, что посетитель спрашивает о сроке запуска услуги, а затем — можно ли объединить её с нестандартным набором работ. Чатбот по сценарию может собрать тип проекта и желаемую дату. Но если комбинация не описана в правилах, он передаёт разговор сотруднику, а не угадывает ответ.
В карточке передачи можно кратко указать исходный вопрос, уже полученные сведения, чего не хватает и почему сработало правило. Сотруднику достаётся не просто длинная переписка, а контекст следующего решения. Это условная иллюстрация организации процесса.
Чтобы резюме помогало продолжить разговор, сохраняйте последовательность: исходный запрос, уточнения, затем причина маршрутизации. Если собеседник называл данные своими словами, резюме должно передавать их смысл без превращения предположения системы в установленный факт. Тогда сотрудник сможет задать только недостающий вопрос, а не начинать беседу заново.
Для передачи полезно отделять сообщённое человеком от вывода чатбота. Например, «назвал дату 12 мая» — это содержание диалога, а «готов к запуску» — уже интерпретация, если собеседник этого не говорил. Такое разделение помогает сотруднику проверить резюме и не принять предположение за согласованное условие.
Ошибка: считать продолжение диалога успешной квалификацией
| Вариант | Что получает сотрудник | Практическое следствие |
|---|---|---|
| Только текст переписки | Полный разговор без выделенной причины | Нужно самому искать вопрос и важные детали |
| Тема и контакт | Краткая метка и данные для связи | Неясно, почему передали обращение и чего не хватает |
| Резюме и причина маршрута | Вопрос, собранные сведения и условие передачи | Понятно, с чего продолжить разговор |
Как проверить качество передачи и дальнейший путь
После настройки разбирайте выборку переданных диалогов рядом с исходными переписками. Для каждого случая отметьте, понятна ли причина, получил ли сотрудник нужный контекст и пришлось ли повторно спрашивать уже сообщённое. Отдельно фиксируйте случаи, когда правило отправило разговор человеку раньше необходимого или оставило его в автоматическом сценарии.
Сравнивайте одинаковые типы обращений в разные периоды — например, до изменения правила и после. Можно смотреть, изменилось ли число повторных вопросов и распределение причин передачи. Если результат сдвинулся, изучите примеры: это поможет понять, какое условие повлияло на работу маршрута.
Затем сопоставьте эти наблюдения с дальнейшим статусом обращения: принято ли оно в работу, перешло ли на следующий этап и где возникла задержка. Так оценка не ограничивается количеством диалогов, обработанных ботом. О том, как проверить передачу обращения между этапами продаж, рассказано в связанном материале.
Для сопоставимости используйте одинаковый период просмотра и единые категории причин. Если коллеги трактуют одну категорию по-разному, сначала согласуйте её описание; иначе изменение статистики может отражать разницу в разметке. Решение по спорному примеру затем можно внести в правило или подсказку сотруднику.
Полезно различать скорость реакции и качество дальнейшей обработки. Если обращения быстрее попадают к нужному сотруднику, но тот всё равно запрашивает сведения заново, в процессе остаётся пробел. Поэтому при разборе отмечают не только момент передачи, но и следующий требуемый шаг: уточнение, назначение ответственного или переход к работе с запросом.