Тупой робот: кейс провайдера с 588 звонками за день

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

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

Очевидно, что имеющиеся люди-операторы физически не могли бы обработать такой объем без очередей, сбросов и роста недовольства.

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

Почему робот стал «тупым»

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

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

Со стороны абонента это выглядит как «тупой робот», что естественно сильно злит людей.

Что показали данные

За день было зафиксировано 588 звонков от 273 уникальных номеров. Главную нагрузку создали не просто отдельные обращения, а повторные звонки одних и тех же абонентов.

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

588всего звонков
273уникальных номера
127номеров с 2+ звонками
442звонка повторников
146звонков неповторников
75,2%звонков от повторников
Три четверти всех звонков пришлись на абонентов, которые обращались повторно. Проблема была не только в самой аварии, а в том, что сценарий взаимодействия не снижал напряжение, а провоцировал новые звонки.

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

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

Большая часть повторных обращений — это 2-3 звонка. Но были и абоненты, которые звонили 7, 8, 10, 12 и даже 17 раз за день.

Количество звонков с номера Количество номеров
2 звонка 55
3 звонка 33
4 звонка 15
5 звонков 6
6 звонков 6
7 звонков 4
8 звонков 5
10 звонков 1
12 звонков 1
17 звонков 1

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

Самые часто звонившие номера

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

Номер Количество звонков
********800 17
********348 12
********016 10
********725 8
********644 8
********024 8
********652 8
********308 8
********703 7
********607 7
********988 7
********537 7
Именно на таких абонентах особенно хорошо видно, что робот не закрывал ситуацию. Он принимал звонок, но не давал нужного ответа в нужном контексте. В результате клиент возвращался в канал снова и снова.

Если рассудить здраво, робот тут ни при чем

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

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

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

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

Технология хорошая, но исполнение решает

Этот кейс — классическая история про хорошую технологию и качество исполнения. Ошибка оператора влияет на один разговор. Ошибка в управлении роботом масштабируется сразу на сотни звонков.

Поэтому внедрение голосового робота — это не только про сценарии и интеграции. Это еще и про процессы внутри компании:

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