Почему автоматизация поддержки вредит бизнесу

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

Чтобы это увидеть, представьте такую ситуацию: вы менеджер в крупном банке, где клиентам сложно зайти в мобильное приложение — на этапе входа ломается каждый второй, потому что авторизироваться так же трудно, как осилить великую теорему Ферма. У вас есть два варианта:

1. Исправить процесс авторизации — нормально спроектировать экраны и положить мучениям пользователей конец. Это будет стоить от NNN рублей.
2. Автоматизировать саппорт — подключить виртуального ассистента, который научит клиентов пользоваться приложением. Это будет стоить от NN рублей.

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

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

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

Такой подход приводит к куче проблем с теми, кто не обратил внимание на пункт про город — он предзаполнен как «Москва» и многие его просто не замечают. В итоге робот звонит клиенту и говорит: «Привет, ваша карта в Москве, когда удобно доставить?», а клиент отвечает: «Бл**ь, я в Новосибе, вы там как вообще?»

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

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

Это не единичный случай. Мы проанализировали обращения 6 млн пользователей и увидели, что самая частая боль — это банальные косяки в продукте.

5 из 10 самых высокочастотных сценариев (в финтехе, ритейле, телекоме) можно закрыть, если доработать бизнес-процессы или поменять UX-дизайн.

Но вопрос в том, как продуктовая команда узнает, что нужно доработать?

Боты могут подсказать ответ. Наши нейронные сети кластеризуют обращения пользователей и объединяют однотипные сообщения в группы (кластера): чем больше группа — тем острее и популярнее проблема. Если посмотреть на кластера, можно понять, что стоит исправить, чтобы облегчить жизнь пользователей.

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

И ассистенты отчасти в этом виноваты.

Забытая функция: коммуникация

Попытка закрыть с помощью робота все дыры в продукте — не единственная проблема, которую виртуальные ассистенты создают бизнесу.

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

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

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

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

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

Как мы научили ассистентов говорить о проблемах

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

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

• Число пользователей — по истории сообщений клиента робот узнает примерное количество активных пользователей и определяет, какой процент обращений можно считать критическим.
• Отрезок времени, за который приходят сообщения о проблеме — когда робот видит резкий всплеск одинаковых обращений, он соотносит его с числом клиентов: если ошибка массовая, заводит инцидент (одинаковость определяется нашей базовой нейросетью, которая распознает смысл обращений по тексту).

Алгоритм кластеризации выделяет группы похожих обращений вне зависимости от того, есть ли они в разметке или нет. Если в поддержку массово обращаются пользователи и динамика сообщений растёт за последние несколько минут/часов/дней — это инцидент.

Пока не идеально, но мы научились решать проблему коммуникации с сотрудниками компании. Если ассистент понимает, что случилась проблема, он действует по такому алгоритму:

• Заводит инцидент и высылает уведомления ответственным сотрудникам по заранее указанным телефонам/e-mail.
• Просит написать сообщение, которое будет приходить пользователям в ответ: например, «починка займет два часа, приносим свои извинения».
• После исправления бага ассистент закрывает тикет и может написать всем пострадавшим: «ура, мы все починили». Это удобно, так как не приходится рассылать ответ по всей базе — робот запоминает только тех, кого коснулась проблема.

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

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

Это гораздо лучше, чем писать: «Да-да, скоро всё будет хорошо». И честнее по отношению к пользователям.

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

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

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