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

Какие триггеры требуют передачи

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

• прямая просьба клиента поговорить с человеком;
• ответ отсутствует в опубликованной базе знаний;
• источники противоречат друг другу;
• цена, гарантия или срок выходят за утверждённые правила;
• сообщение содержит жалобу, конфликт или чувствительную ситуацию.

Что входит в пакет передачи

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

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

Сообщение клиенту «передаю специалисту» ещё не является handoff. В системе должно появиться обращение со статусом, временем создания и ответственным местом обработки, например Inbox или очередь поддержки.

Кто задаёт срок ответа клиенту

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

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

Какие отрицательные сценарии проверить

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

Как исправлять ошибки маршрута

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

NIST рекомендует заранее определять роли людей и процессы контроля, а OWASP советует требовать подтверждение значимых действий. В продажах и поддержке это означает простую границу: ИИ собирает и объясняет, человек принимает решение с ценой ошибки.

Что смотреть в кабинете

До подключения клиентов откройте правила передачи, проведите три рискованных диалога в Test Room и убедитесь, что каждый появился в Inbox с правильной причиной. Затем перезапустите приложение и проверьте, что очередь, история и уже собранные поля сохранились.

Настройте, когда заявка действительно готова

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

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

Проверенные границы: VPS на Linux с архитектурой amd64. Минимум 2 CPU. Тариф с 4 ГБ RAM или больше. Диск от 40 ГБ и не меньше 12 ГБ свободного места. Домен или явно выбранный временный адрес. Codex Desktop или Claude Code для самостоятельной установки. Собственный model API key и баланс у провайдера. Собственные материалы, цены и правила; владелец проверяет ответы и публикует сотрудника.