Наша команда больше двух лет занимается автоматизацией клиентского сервиса. Недавно мы поняли, что подключение чат-ботов и виртуальных ассистентов не всегда идёт на пользу бизнесу.
Чтобы это увидеть, представьте такую ситуацию: вы менеджер в крупном банке, где клиентам сложно зайти в мобильное приложение — на этапе входа ломается каждый второй, потому что авторизироваться так же трудно, как осилить великую теорему Ферма. У вас есть два варианта:
Автоматизировать саппорт и нанять на работу робота как правило дешевле, чем доводить до ума процессы в приложении. Поэтому теперь недальновидные менеджеры выбирают второй вариант — делают ставку на первую линию поддержки, чтобы с её помощью закрыть дыры в продуктах.
Особенно это касается бизнесов-инноваторов (финтех, тревел, телеком, е-коммерс) — они уже успешно внедрили виртуальных ассистентов и получили возможность перекинуть на них большинство проблем. В итоге поддержка иногда работает как затычка, закрывающая пробоины в лодке.
Кейс. Банк хотел, чтобы наш виртуальный ассистент согласовывал доставку карт с клиентами. В ходе автоматизации сценария выяснилось, что сам процесс построен неправильно: пользователь сначала выбирает регион, затем карту привозят в нужный город и только потом согласовывают адрес доставки.
Такой подход приводит к куче проблем с теми, кто не обратил внимание на пункт про город — он предзаполнен как «Москва» и многие его просто не замечают. В итоге робот звонит клиенту и говорит: «Привет, ваша карта в Москве, когда удобно доставить?», а клиент отвечает: «Бл**ь, я в Новосибе, вы там как вообще?»
Исправить такой процесс несложно: нужно просто понятно спросить в приложении, куда везти карту. Но нам пришлось учить робота правильно реагировать на косяк и отправлять карты в другие регионы.
В итоге банк терял деньги на доставке и закрывал баг с помощью саппорта, хотя стоило докрутить оформление заявки — проблем бы не было.
Это не единичный случай. Мы проанализировали обращения 6 млн пользователей и увидели, что самая частая боль — это банальные косяки в продукте.
Но вопрос в том, как продуктовая команда узнает, что нужно доработать?
Боты могут подсказать ответ. Наши нейронные сети кластеризуют обращения пользователей и объединяют однотипные сообщения в группы (кластера): чем больше группа — тем острее и популярнее проблема. Если посмотреть на кластера, можно понять, что стоит исправить, чтобы облегчить жизнь пользователей.
За последний год работы с подобными кейсами мы сделали вывод, что автоматизация саппорта это не всегда благо, если забывать о решении продуктовых вопросов: менять процессы и дизайн, выстраивать правильную коммуникацию. Но пока поддержка справляется и учит клиентов пользоваться тем, что есть, мало кто занимается этим всерьёз.
И ассистенты отчасти в этом виноваты.
Попытка закрыть с помощью робота все дыры в продукте — не единственная проблема, которую виртуальные ассистенты создают бизнесу.
С появлением автоматизации на первых линиях поддержки все забыли о том, чтобы доносить до компании информацию о сбоях в системе и болях пользователей. Мы сосредоточились на максимально сервисной поддержке, но не думали, как наладить коммуникацию с продакт-менеджерами.
Поэтому однажды наши коллеги из Украины напоролись на такую ситуацию: запустили ассистента в одном крупном банке и не совсем корректно настроили алгоритм переключения на оператора. Когда случился сбой базовой платёжной функциональности и посыпались обращения от клиентов, робот тупил, просил переформулировать вопрос или отмазывался: «Да-да, скоро починим».
Шёл второй день, ассистент продолжал утешать пользователей, а внутри банка никто не знал об инциденте. На аналитике это было трудно заметить — функциональность легла не везде, а только на небольшом сегменте.
Хорошо, нашлись злые клиенты, которые обошли робота: кто-то ломал его через матерные слова, которые заставляли переключиться на оператора, кто-то дозвонился менеджерам и сообщил о поломке. Банк наконец понял, что пошло не так и исправил проблему только на вторые сутки.
Это был классный кейс, который показал баг в коммуникации робот→ менеджер. Мы поняли, что нужно создать модель и наладить emergency-связь между ассистентами и продактами.
В первую очередь нам нужно было понять, о чём сообщать продактам — иными словами, что считать инцидентом, а что нет.
Чтобы робот научился понимать параметры объема запросов и отличать массовые ошибки от мелких, мы обучили его определять инцидент по нескольким критериям:
Алгоритм кластеризации выделяет группы похожих обращений вне зависимости от того, есть ли они в разметке или нет. Если в поддержку массово обращаются пользователи и динамика сообщений растёт за последние несколько минут/часов/дней — это инцидент.
Пока не идеально, но мы научились решать проблему коммуникации с сотрудниками компании. Если ассистент понимает, что случилась проблема, он действует по такому алгоритму:
Когда ассистент начал сообщать о массовых сбоях, мы увидели, что многие ошибки были связаны с техническими проблемами. И научились быстро на них реагировать.
Например, когда у нас полетела логика бюджетных платежей и пользователи не могли заплатить налоги, робот прислал рапорт об ошибке уже через час. Команда быстро откатила версию обратно и оперативно решила вопрос.
Это гораздо лучше, чем писать: «Да-да, скоро всё будет хорошо». И честнее по отношению к пользователям.
Обычно все, кто занимается автоматизацией саппорта, фокусируются на том, чтобы научить роботов отвечать быстро, качественно и дешево. Но упускают важный момент: задачи менеджера поддержки шире, чем просто написать ответ.
Когда мы стали глубоко изучать все функции роли, которые пытаемся автоматизировать, то увидели, что хороший клиентский сервис — это когда саппорт связывается с командой и рассказывает им о болях пользователей, а компания дорабатывает свой продукт.
В противном случае поддержка превращается в постоянный костыль для бизнеса: закрывает дыры и отмазывается до последнего вместо того, чтобы решать проблемы.
Чтобы это увидеть, представьте такую ситуацию: вы менеджер в крупном банке, где клиентам сложно зайти в мобильное приложение — на этапе входа ломается каждый второй, потому что авторизироваться так же трудно, как осилить великую теорему Ферма. У вас есть два варианта:
- Исправить процесс авторизации — нормально спроектировать экраны и положить мучениям пользователей конец. Это будет стоить от NNN рублей.
- Автоматизировать саппорт — подключить виртуального ассистента, который научит клиентов пользоваться приложением. Это будет стоить от NN рублей.
Автоматизировать саппорт и нанять на работу робота как правило дешевле, чем доводить до ума процессы в приложении. Поэтому теперь недальновидные менеджеры выбирают второй вариант — делают ставку на первую линию поддержки, чтобы с её помощью закрыть дыры в продуктах.
Особенно это касается бизнесов-инноваторов (финтех, тревел, телеком, е-коммерс) — они уже успешно внедрили виртуальных ассистентов и получили возможность перекинуть на них большинство проблем. В итоге поддержка иногда работает как затычка, закрывающая пробоины в лодке.
Кейс. Банк хотел, чтобы наш виртуальный ассистент согласовывал доставку карт с клиентами. В ходе автоматизации сценария выяснилось, что сам процесс построен неправильно: пользователь сначала выбирает регион, затем карту привозят в нужный город и только потом согласовывают адрес доставки.
Такой подход приводит к куче проблем с теми, кто не обратил внимание на пункт про город — он предзаполнен как «Москва» и многие его просто не замечают. В итоге робот звонит клиенту и говорит: «Привет, ваша карта в Москве, когда удобно доставить?», а клиент отвечает: «Бл**ь, я в Новосибе, вы там как вообще?»
Исправить такой процесс несложно: нужно просто понятно спросить в приложении, куда везти карту. Но нам пришлось учить робота правильно реагировать на косяк и отправлять карты в другие регионы.
В итоге банк терял деньги на доставке и закрывал баг с помощью саппорта, хотя стоило докрутить оформление заявки — проблем бы не было.
Это не единичный случай. Мы проанализировали обращения 6 млн пользователей и увидели, что самая частая боль — это банальные косяки в продукте.
5 из 10 самых высокочастотных сценариев (в финтехе, ритейле, телекоме) можно закрыть, если доработать бизнес-процессы или поменять UX-дизайн.
Но вопрос в том, как продуктовая команда узнает, что нужно доработать?
Боты могут подсказать ответ. Наши нейронные сети кластеризуют обращения пользователей и объединяют однотипные сообщения в группы (кластера): чем больше группа — тем острее и популярнее проблема. Если посмотреть на кластера, можно понять, что стоит исправить, чтобы облегчить жизнь пользователей.
За последний год работы с подобными кейсами мы сделали вывод, что автоматизация саппорта это не всегда благо, если забывать о решении продуктовых вопросов: менять процессы и дизайн, выстраивать правильную коммуникацию. Но пока поддержка справляется и учит клиентов пользоваться тем, что есть, мало кто занимается этим всерьёз.
И ассистенты отчасти в этом виноваты.
Забытая функция: коммуникация
Попытка закрыть с помощью робота все дыры в продукте — не единственная проблема, которую виртуальные ассистенты создают бизнесу.
С появлением автоматизации на первых линиях поддержки все забыли о том, чтобы доносить до компании информацию о сбоях в системе и болях пользователей. Мы сосредоточились на максимально сервисной поддержке, но не думали, как наладить коммуникацию с продакт-менеджерами.
Поэтому однажды наши коллеги из Украины напоролись на такую ситуацию: запустили ассистента в одном крупном банке и не совсем корректно настроили алгоритм переключения на оператора. Когда случился сбой базовой платёжной функциональности и посыпались обращения от клиентов, робот тупил, просил переформулировать вопрос или отмазывался: «Да-да, скоро починим».
Шёл второй день, ассистент продолжал утешать пользователей, а внутри банка никто не знал об инциденте. На аналитике это было трудно заметить — функциональность легла не везде, а только на небольшом сегменте.
Хорошо, нашлись злые клиенты, которые обошли робота: кто-то ломал его через матерные слова, которые заставляли переключиться на оператора, кто-то дозвонился менеджерам и сообщил о поломке. Банк наконец понял, что пошло не так и исправил проблему только на вторые сутки.
Это был классный кейс, который показал баг в коммуникации робот→ менеджер. Мы поняли, что нужно создать модель и наладить emergency-связь между ассистентами и продактами.
Как мы научили ассистентов говорить о проблемах
В первую очередь нам нужно было понять, о чём сообщать продактам — иными словами, что считать инцидентом, а что нет.
Чтобы робот научился понимать параметры объема запросов и отличать массовые ошибки от мелких, мы обучили его определять инцидент по нескольким критериям:
- Число пользователей — по истории сообщений клиента робот узнает примерное количество активных пользователей и определяет, какой процент обращений можно считать критическим.
- Отрезок времени, за который приходят сообщения о проблеме — когда робот видит резкий всплеск одинаковых обращений, он соотносит его с числом клиентов: если ошибка массовая, заводит инцидент (одинаковость определяется нашей базовой нейросетью, которая распознает смысл обращений по тексту).
Алгоритм кластеризации выделяет группы похожих обращений вне зависимости от того, есть ли они в разметке или нет. Если в поддержку массово обращаются пользователи и динамика сообщений растёт за последние несколько минут/часов/дней — это инцидент.
Пока не идеально, но мы научились решать проблему коммуникации с сотрудниками компании. Если ассистент понимает, что случилась проблема, он действует по такому алгоритму:
- Заводит инцидент и высылает уведомления ответственным сотрудникам по заранее указанным телефонам/e-mail.
- Просит написать сообщение, которое будет приходить пользователям в ответ: например, «починка займет два часа, приносим свои извинения».
- После исправления бага ассистент закрывает тикет и может написать всем пострадавшим: «ура, мы все починили». Это удобно, так как не приходится рассылать ответ по всей базе — робот запоминает только тех, кого коснулась проблема.
Когда ассистент начал сообщать о массовых сбоях, мы увидели, что многие ошибки были связаны с техническими проблемами. И научились быстро на них реагировать.
Например, когда у нас полетела логика бюджетных платежей и пользователи не могли заплатить налоги, робот прислал рапорт об ошибке уже через час. Команда быстро откатила версию обратно и оперативно решила вопрос.
Это гораздо лучше, чем писать: «Да-да, скоро всё будет хорошо». И честнее по отношению к пользователям.
Обычно все, кто занимается автоматизацией саппорта, фокусируются на том, чтобы научить роботов отвечать быстро, качественно и дешево. Но упускают важный момент: задачи менеджера поддержки шире, чем просто написать ответ.
Когда мы стали глубоко изучать все функции роли, которые пытаемся автоматизировать, то увидели, что хороший клиентский сервис — это когда саппорт связывается с командой и рассказывает им о болях пользователей, а компания дорабатывает свой продукт.
В противном случае поддержка превращается в постоянный костыль для бизнеса: закрывает дыры и отмазывается до последнего вместо того, чтобы решать проблемы.
