Skip to main content
ИИ
Блог

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

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

16 сентября 20267 мин чтения

Почему передача решает вердикт

Мнение о чат-боте почти никогда не складывается по его лучшему ответу. Оно складывается по худшему моменту, а худший момент — почти всегда передача: клиент просит помощи, а система либо сопротивляется, либо отдаёт его тому, кто ничего не знает.

Это выглядит технической задачей, но на деле это три отдельных решения: когда бот должен остановиться, что уходит вместе с разговором и кто находится с той стороны. Большинство проектов отвечает на первый вопрос и оставляет остальные два на усмотрение настроек — а потом удивляется, почему передача ощущается плохо.

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

Пять триггеров остановки

  1. Прямая просьбаЕсли клиент говорит «оператор» или «живой человек» — немедленно. Без вопроса «почему», без встречного предложения, без «может, я помогу». Попытка отговорить — самое жалобогенное поведение из возможных, и она обесценивает все хорошие ответы, данные до этого.
  2. Пробел в знанияхЕсли материал не покрывает вопрос, бот должен честно сказать об этом и предложить человека. Правдоподобный выдуманный ответ всегда дороже медленного — особенно в вопросах цены, права и соответствия требованиям.
  3. Повторяющаяся неудачаЕсли клиент третий раз спрашивает то же самое другими словами, бот провалился, что бы он сам ни считал ответом. Счётчик повторов — простой и на удивление действенный триггер.
  4. Эмоциональный сигналЖалоба, заметное раздражение, открытое недовольство. Здесь скорость важнее точности: третий уточняющий вопрос раздражённому клиенту ситуацию не улучшает.
  5. Коммерческая или рисковая территорияПереговоры о скидке, условия договора, юридическая угроза, вопрос безопасности. Это требует полномочий, а не компетентности, а полномочий у бота нет.

Какой контекст должен уйти вместе

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

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

Без первого пункта остальные почти не имеют значения. Непереданная переписка — самый частый и самый дорогой дефект в дизайне передачи.

Очередь, часы работы и ожидание

Передача сработала — а дальше что? Если у этого вопроса нет записанного ответа, для клиента ответом будет «ничего».

  • В рабочие часы: честное указание времени ожидания. Сказать «пара минут» и продержать пятнадцать хуже, чем не сказать ничего.
  • Вне рабочих часов: бот должен прямо об этом сказать и предложить конкретную альтернативу — утренний звонок, оставить сообщение или названный срок ответа. «Операторы недоступны» альтернативой не является.
  • Никто не взял: таймаут и второе назначение. Без них разговор лежит непрочитанным, и этого никто не замечает, потому что ничего не сломалось.
  • Клиент ушёл, не дождавшись: разговор не должен испариться. Его нужно перевести в канал, который до клиента дойдёт, — почта, WhatsApp, обратный звонок.
  • Как только оператор принял разговор, бот обязан замолчать. Двое, отвечающие одновременно, — самый сбивающий с толку исход для клиента.

Возврат: от оператора к боту

Это направление обсуждают гораздо реже, а значит оно почти столь же важно. Когда бот возвращается после того, как оператор закончил?

Практический ответ: не сразу. В течение заданного периода после ответа оператора — полчаса как разумное значение по умолчанию — бот не должен вмешиваться в этот разговор, потому что клиент почти наверняка считает, что говорит с человеком. Без такой паузы оператор пишет одну фразу, а бот отвечает поверх него, и разговор становится неуправляемым.

После паузы возвращение бота нормально и полезно, особенно ночью. Важно лишь, чтобы это управлялось правилом, а не случайностью.

Что измерять

  1. Доля передач в разбивке по триггерамКакая часть диалогов доходит до оператора и по какому триггеру. Без разбивки цифра не говорит ничего: передачи из-за пробелов в знаниях означают, что материал нужно дорабатывать, а прямые просьбы — совсем другое.
  2. Время от передачи до первого ответа человекаТо ожидание, которое клиент реально переживает. Сводное время ответа его прячет, потому что считает и реплики бота.
  3. Доля повторных объясненийКак часто клиенту приходится повторять сказанное после передачи. Найти это можно только чтением расшифровок, и это настоящий экзамен вашего дизайна передачи.
  4. Доля решений после передачиКакая часть эскалированных разговоров решается там же. Низкая цифра означает, что передача идёт не в то назначение.

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

Частые ошибки

  • Отказывать в просьбе о человеке или тянуть с ней — самая дорогая ошибка в списке.
  • Не передавать переписку, вынуждая клиента начинать заново.
  • Врать про время ожидания или вовсе о нём молчать.
  • Не задать альтернативный путь вне рабочих часов.
  • Не глушить бота после того, как ответил оператор.
  • Не фиксировать причину передачи, из-за чего оператор слеп, а метрики бессмысленны.
  • Считать любую передачу провалом. Некоторые — корпоративный запрос, VIP-клиент — это запланированный и правильный исход.

Как передача устроена в Vexvon

В Vexvon есть три явных пути к человеку, и все три пишутся в журнал. Когда клиент просит оператора, движок это распознаёт и поднимает уведомление. Когда агент вводит в диалог стоп-символ — по умолчанию точку, — ИИ встаёт на паузу в этом разговоре на тридцать минут, так что оператор принимает его чисто и бот не пишет поверх. ИИ можно также полностью отключить для конкретного диалога.

ИИ останавливает себя и сам: нецензурная лексика работает как стоп-условие, а фразы с просьбой об операторе поднимают уведомление. Это покрывает два из пяти триггеров выше поведением, которое уже существует.

Со стороны контекста память диалога охватывает последние пятнадцать сообщений, и все каналы пишут в одну карточку клиента — человек, написавший в Instagram, затем в WhatsApp и потом позвонивший, это одна карточка, а не три. В карточке лежат расшифровка, извлечённые поля и резюме одним предложением, а единая лента собирает хронологию из десяти источников — именно это позволяет оператору сориентироваться за тридцать секунд.

Прозрачность ответа помогает и здесь: система фиксирует, какой фрагмент знаний породил конкретный ответ, так что при разборе передачи из-за пробела видно, на чём бот основывался, и материал правится один раз.

5Триггеров остановки бота
30Минут паузы оператора
15Сообщений памяти диалога

Частые вопросы

  1. Что такое передача от чат-бота оператору?Это перевод разговора из автоматического ответа к живому человеку вместе с расшифровкой, карточкой клиента и причиной перевода. Если контекст не уходит, это не передача, а смена очереди.
  2. Какие данные и интеграции нужны?Полная переписка, карточка клиента, сопоставленная по телефону или почте, извлечённые поля и резюме, причина передачи и очередь или ящик, в котором оператор действительно работает.
  3. Когда бот должен выполнить просьбу о человеке?Немедленно и безусловно. Спрашивать зачем, делать встречное предложение или говорить «давайте я сначала попробую» — самое жалобогенное поведение во всём сценарии.
  4. Что должно происходить вне рабочих часов?Бот должен прямо об этом сказать и дать конкретную альтернативу: утренний звонок, оставить сообщение или названный срок ответа. «Операторов нет» альтернативой не считается.
  5. Какими метриками мерить качество передачи?Доля передач по триггерам, время от передачи до первого ответа человека, доля повторных объяснений и доля решений после передачи.
  6. Когда бот должен вернуться после оператора?Не сразу. После ответа оператора нужна пауза — тридцать минут как разумное значение, — иначе бот напишет поверх человека.

Прочитайте свои передачи

Быстрее всего улучшить дизайн передачи можно, прочитав эскалированные разговоры за прошлый месяц. Ищите в каждом две вещи: пришлось ли клиенту повторять уже сказанное и сколько прошло до первого ответа оператора. Эти две цифры почти всегда точно указывают на проблему.

Live demo

Ready? Let's start

See Vexvon live in a 10-minute demo.

  • A scenario built for your business
  • A live sample call
  • A tour of the platform
Get a demo

Your details are used only for the demo and to get in touch.

Book a Meeting with Vexvon

Pick a time that suits you in our calendar.