Чат-бот плюс живой менеджер. Как разделить работу и не потерять клиента на передаче

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

Главное из статьи:

• Вопрос отдают боту, если у него есть единственный правильный ответ, известный заранее

• Кнопка вызова человека присутствует в первом же сообщении, и это снижает частоту её использования, а не повышает

• Передача считается успешной, только когда менеджер видит предысторию и клиенту не приходится повторять

• Ночной бот окупается быстрее дневного, потому что ночью альтернатива не менеджер, а тишина

• Доля автоматически закрытых обращений растёт и при плохом сценарии, поэтому оценивать по ней опасно

• Сценарий, написанный из головы, застревает на распознавании 40% обращений

Критерий разделения вопросов между ботом и человеком

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

Проверяется просто. Возьмите 200 последних обращений и рассортируйте по этому признаку. Обычно от 40 до 60% попадают в первую категорию, и это тот объём, который снимается с менеджеров.

Таблица зон ответственности

Составлена нами по итогам разбора типовых потоков обращений в рознице и сервисе.

Второй критерий отсекает вопросы с дорогой ошибкой

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

Здесь автоматика допустима в информационном виде со ссылкой на специалиста, но не как окончательный ответ.

Бот квалифицирует, но не продаёт

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

Разумная граница проходит на моменте, когда клиент назвал потребность. Дальше диалог уходит человеку, а бот к этому моменту уже собрал контекст.

Точка передачи диалога человеку

Введём рабочее понятие. Точка передачи — это момент, в который бот прекращает обработку и диалог уходит человеку вместе со всей собранной предысторией. Качество схемы определяется не сценарием бота, а тем, как устроена эта точка.

4 триггера, по которым бот обязан отдать диалог

Клиент попросил напрямую. Бот 2 раза подряд не понял вопрос. В сообщении есть признаки недовольства. Тема относится к деньгам или к жалобе.

Два раза, а не три и не пять. Каждая следующая неудачная попытка уменьшает шанс, что клиент дождётся человека.

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

Менеджер получает диалог вместе с предысторией или схема не работает

Здесь проходит граница между рабочей и нерабочей схемой. Если менеджер начинает с «расскажите, что у вас случилось», вся экономия времени обнуляется, а клиент злится.

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

Именно поэтому связка бота с CRM важнее выбора самого бота. Подключённый к системе номер мессенджера обеспечивает единую ленту диалога независимо от того, кто отвечал в конкретный момент.

Обратная передача требует отдельного правила

Сценарий, о котором забывают. Менеджер решил вопрос, диалог закрыт, но через 2 дня клиент пишет снова по другому поводу.

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

Экспертная врезка

Самая устойчивая ошибка при внедрении — сценарий пишут исходя из того, как компания представляет себе вопросы клиентов, а не из того, как эти вопросы задаются в реальности. Люди пишут «а когда приедет», а не «уточните статус доставки заказа». Единственный надёжный способ построить работающий сценарий — взять выгрузку из 300 реальных диалогов и собрать формулировки оттуда дословно, включая опечатки и сокращения. Компании, делающие этот шаг, получают долю распознанных обращений выше 80% с первой версии. Компании, пишущие сценарий из головы, застревают на 40% и потом полгода правят его по жалобам.

Ночь, выходные и пиковые периоды

Ночной бот окупается быстрее дневного

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

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

Отвечать по существу он не обязан. Достаточно 3 функций — принять обращение, зафиксировать его в CRM, назвать конкретное время ответа утром.

Пиковую нагрузку готовят за месяц, а не в сезон

В сезон поток обращений вырастает в разы, и бот работает как буфер. Он снимает справочные вопросы, из-за которых менеджеры не успевают отвечать готовым купить.

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

На праздниках бот заменяет объявление на двери

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

Клиенту здесь не нужен диалог, ему нужна определённость. Одно точное сообщение работает лучше сложного сценария.

Ограничение для сфер с круглосуточными обязательствами

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

Оценка качества сценария

4 показателя, которые снимают вместе

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

Доля клиентов, обратившихся повторно по тому же вопросу. Именно она показывает, был ли вопрос решён или клиент сдался.

Время до передачи человеку. Свыше 3 минут означает перегруженный сценарий.

Оценка после диалогов с передачей в сравнении с оценкой диалогов без бота. Отрицательная разница указывает на проблему в точке передачи, а не в самом боте.

Доля автоматизации растёт и при плохом сценарии

Показатель увеличивается в 2 разных случаях. Когда бот хорошо решает вопросы и когда клиенты перестают ждать и уходят.

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

Сценарий пересматривают раз в месяц

Просматривайте диалоги, где бот не понял вопрос. Каждый такой случай — либо новая формулировка, либо новая ветка.

За полгода сценарий обычно вырастает вдвое, а доля непонятых обращений падает до единиц процентов. Без пересмотра происходит обратное — язык клиентов меняется, а бот остаётся прежним.

Когда бот не нужен

Экономия на операторах не наступает при малом потоке

Тезис привычен — бот снимает нагрузку с поддержки. Контртезис такой. Сценарий нужно написать, проверить и потом ежемесячно править, и эта работа не исчезает после запуска.

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

Однородный сложный продукт плохо ложится на сценарий

Если 80% обращений требуют расчёта, подбора или консультации, автоматизировать нечего. Бот в такой нише выполнит только идентификацию, и его ценность сводится к экономии 30 секунд.

Здесь разумнее вложиться в шаблоны ответов для менеджеров и в скорость распределения входящих.

Чего мы не измеряли

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

Также мы не разбираем сценарии с генеративными моделями, где ответ формируется на лету. Их поведение при нестандартных обращениях требует отдельной проверки, и переносить на них правила из этой статьи преждевременно.

Чаво:

Вопрос: Обязательно ли предупреждать клиента, что он общается с ботом

Ответ: Да, и это в интересах компании. Клиент, узнавший об этом в середине разговора, чувствует себя обманутым. Одна фраза в начале снимает вопрос, а на готовность общаться почти не влияет

Вопрос: Можно ли использовать бота на том же номере, где работают менеджеры

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

Вопрос: Что делать, если бот дал клиенту неверную информацию

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

Вопрос: Нужен ли бот компании с потоком менее 30 обращений в день

Ответ: Полноценный сценарий не окупится, а ночной автоответ с фиксацией заявки вполне. Начинать стоит с него

Вопрос: Как бот влияет на ограничения мессенджеров

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