Короткий ответ
Чат-бот должен звать человека по явной просьбе клиента, при повторном непонимании, отсутствии подтверждённого источника, риске ошибочного обещания и в ситуациях, где решение требует полномочий сотрудника. Передача сопровождается причиной, приоритетом, кратким контекстом и паузой автоматических сообщений. Число эскалаций нельзя снижать любой ценой: важнее доля своевременно и правильно переданных обращений.
Эскалация — признак хорошего сценария
Бот не обязан отвечать на всё. Нестандартная цена, доступ к персональным данным, конфликтная ситуация и два неудачных уточнения — это не ошибка клиента, а заранее известный момент подключения специалиста.
Что сказать клиенту при передаче
Подтвердите, что уже поняли, назовите следующий шаг и не обещайте срок, который команда не выдержит. Формула проста: «Запрос передан специалисту; он видит детали; ответим здесь до …». Она снимает тревогу лучше абстрактного «ожидайте».
Матрица причин для эскалации
| Сигнал | Действие бота | Что увидит оператор |
|---|---|---|
| Просьба о человеке | Передать сразу без отговаривания | Последняя задача и собранные поля |
| Два непонимания подряд | Признать ограничение и передать | Фразы, которые не удалось распознать |
| Цена, возврат, исключение | Не обещать решение | Причина и нужная компетенция |
| Негатив или риск | Сократить автоматический ответ | Приоритет и исходный текст клиента |
Назначение оператора и пауза автоматизации
После передачи у диалога должен появиться владелец. В botodel назначения, упоминания и непрочитанные сообщения помогают доставить обращение конкретному человеку, а режим оператора временно останавливает автоматизацию. Без владельца эскалация остаётся красивой кнопкой без результата.
Когда возвращать бота в разговор
Не включайте сценарий сразу после любого ответа оператора. Возврат уместен после закрытия вопроса, истечения согласованной паузы или нового явного события. Клиент должен понимать, кто отвечает сейчас: человек, автоматизация или оба последовательно.
Мне нужна нестандартная скидка для филиалов.
Такие условия согласует менеджер. Передам ему запрос и уже указанные данные.
Подключился. Вижу, что речь о нескольких филиалах. Уточню количество и подготовлю варианты.
Бот не придумывает условия и не заставляет клиента повторять исходную задачу.
Не все передачи имеют одинаковый приоритет
| Категория | Пример | Правило обработки |
|---|---|---|
| Критично | Оплата списана, доступ не появился | Немедленное назначение и уведомление ответственного |
| Высокий | Сервис недоступен в рабочем процессе | Передача с диагностикой и ближайшим сроком ответа |
| Обычный | Нужна настройка или пояснение | Очередь по стандартному регламенту |
| Низкий | Идея или пожелание | Сохранить контекст и сообщить, как будет рассмотрено |
Приоритет нельзя определять только по эмоциональности сообщения. Свяжите его с влиянием на клиента: потеря денег, остановка работы, нарушение доступа, риск для данных. Бот может распознать сигнал и собрать диагностику, но спорный случай лучше повысить, чем уверенно отправить в медленную очередь.
Разбор эскалаций превращает поддержку в источник знаний
- 01
Отберите повторения
Найдите причины, которые чаще всего приводили к человеку за неделю.
- 02
Проверьте необходимость
Отделите реальные исключения от вопросов, на которые не хватило понятного источника.
- 03
Исправьте один слой
Обновите базу, текст сценария или правило маршрутизации — в зависимости от причины.
- 04
Повторите тест
Пройдите исходные формулировки и убедитесь, что граница безопасности не исчезла.
Контекст для оператора собирается до передачи
Что положить во внутреннюю заметку
- исходный вопрос клиента без «улучшения» формулировки;
- что бот уже проверил и какие ответы получил;
- конкретный сигнал эскалации: просьба, риск, конфликт или повторное непонимание;
- приоритет и команда, которая может принять решение;
- что уже пообещали клиенту и когда он ожидает продолжение.
Если причина передачи техническая, сохраняйте полезную диагностику: канал, время, идентификатор заказа или шага сценария, но не просите клиента добывать внутренние данные системы. Оператору нужна возможность увидеть полную историю и оставить внутренний комментарий для коллег, не отправляя служебный текст наружу.
Для чувствительных тем заранее определите, какие данные нельзя повторять в уведомлениях и внутренних сводках. Эскалация не должна размножать персональную информацию по чатам команды. Достаточно идентификатора обращения и ссылки на защищённую карточку, где доступ ограничен ролью оператора.
- Есть явная кнопка человека.
- Два непонимания ведут к передаче.
- Оператор видит причину эскалации.
- У переданного диалога есть конкретный владелец.
- Возврат автоматизации происходит по понятному правилу.
Качество эскалации измеряется после передачи
Сам факт передачи ещё не помогает клиенту. Проверьте время до первого ответа, долю обращений, где оператору пришлось заново задавать уже отвеченный вопрос, и повторные передачи между сотрудниками. Если бот правильно распознал границу, но диалог лежит без владельца, исправлять нужно очередь команды, а не AI или текст сценария.
| Метрика | Что показывает | Тревожный сигнал |
|---|---|---|
| Время до ответа человека | Работает ли обещанный уровень сервиса | Клиент ждёт дольше названного срока |
| Повторный сбор данных | Сохранился ли контекст | Оператор снова спрашивает цель и контакт |
| Повторная передача | Правильно ли выбран владелец | Диалог гуляет между командами |
| Возврат с тем же вопросом | Был ли вопрос решён | Формальное закрытие без результата |
Источники и документация
Как это работает в продукте
Правило эскалации стоит хранить рядом со сценарием: например, после двух непонятых ответов или при выборе «нужен менеджер». Тогда оно одинаково работает во всех подключённых каналах, а не зависит от памяти оператора.
В inbox полезно оставить внутреннюю заметку с причиной передачи. Клиент её не видит, зато команда понимает, был ли это сложный вопрос, техническая ошибка или осознанный выбор человека.
Частые вопросы
- В каких случаях бот поддержки обязан позвать человека?
- При прямой просьбе клиента, повторной неудаче, конфликтующих данных, жалобе, вопросах об оплате или обещаниях, которых нет в подтверждённой базе. Эти условия лучше хранить как явные правила сценария, а не надеяться, что модель сама угадает риск.
- Что должен увидеть оператор после эскалации?
- Полную историю переписки, краткую причину передачи, уже выполненные проверки и ожидаемый следующий шаг. Внутренняя заметка должна помогать продолжить разговор с места остановки, а не пересказывать весь чат другими словами.
- Когда можно вернуть диалог боту?
- После того как оператор решил нестандартную часть вопроса и явно указал, какой автоматический маршрут можно продолжить. Самопроизвольный возврат по таймеру опасен: клиент может снова получать подсказки, пока человек ещё разбирается с обращением.