Привет! Мы в Chatme.ai автоматизируем коммуникационные процессы бизнес-заказчиков в мессенджерах и соцсетях – добиваемся снижения затрат на операторов, роста NPS, лояльности, выручки и улучшения других метрик, важных клиентам. В основе наших решений – чат-боты, их мы создаем на собственной low-code платформе.

Успешные компании, кратно снизившие издержки с помощью ботов, доказали эффективность чатботов. Но их нужно правильно «готовить», что умеют далеко не многие. Поэтому в Интернете нам часто отвечают «глупые» и «бесящие» боты. И поэтому бизнес все еще с недоверием относится к ним – не верит, что боты могут качественно решать задачи, не хочет выглядеть глупо и раздражать клиентов. Но, когда в результате работы бота метрики растут  – мнение меняется.

Наша задача в каждом проекте – не просто сделать эффективного бота, а дать полноценное решение, улучшающее метрики. А это больше, чем просто реализовать ТЗ.

О проекте

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

Входные данные:

• Размер контакт-центра: 12 операторов, ежеквартальный прирост
• Нагрузка на контакт центр: 49-67 тыс. обращений в месяц 24/7
• Распределение трафика: виджет на сайте – 95%, ВК – 5%
• Количество тематик вопросов (интентов): более 60 и постоянно увеличивается
• Софт операторов: Jivo 
   

Ожидания заказчика: 

• разгрузить операторов минимум на 50% – не меньше половины обращений должен самостоятельно закрывать чат-бот
• прирост средней конверсии в займ – тут без конкретики, даже +0,1% считаем за успех

Проблема заказчика (стандартная для онлайн): клиенты в 10 часовых поясах, они пишут круглосуточно и оставляют 60 тысяч обращений в месяц. Штат из 12 операторов уже не мог оперативно обрабатывать такой объем, метрики падали, а постоянно нанимать дополнительных операторов бизнес не хотел, что естественно. Контакт-центр становился блокером для масштабирования.
 

Решение: чат бот с искусственным интеллектом на платформе chatme.ai 

Результаты проекта: 

• бот забирает на себя 100% обращений – это 49-67 тыс. в месяц
• бот самостоятельно решает 70-72% обращений клиентов
• не более 6% обращений переводятся на оператора из-за проблем с распознаванием, остальные переводы на оператора – по сценарию (пользователь сайта явно позвал оператора, ненормативная лексика и стоп-слова, специальные вопросы, которые должен решать только оператор)
• 76% опрошенных клиентов положительно оценивают работу бота
• Клиент доволен, начал активно растить траффик, а текущего штата операторов хватит еще надолго)

Длительность: 

• 1 месяц – подготовка данных и создание бота
• 1 месяц – внутреннее тестирование
• 2 недели – улучшение бота до желаемого результата на полном реальном трафике
• Еще за 2 недели «шлифовки» бота превзошли желаемый результат

Стоимость работ: 80 тыс. руб.

Особые требования: 

• Выделить отдельный инстанс нашей платформы в облаке для частного использования клиентом в этом проекте (это отдельная история про devops, не в этой статье)

Как делали проект, детали

Сделка

Клиент пришел к нам с вышеописанной проблемой, запросом вида «сделайте чат-бота с распознаванием речи (NLU) на питоне, чтобы выдержал тысячи обращений в день» и желаемыми KPI. Порадовало, что не требовалось сделать бота неотличимым от человека, главное – разгрузить операторов без потери качества. 

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

Запрос был для нас типовой с точки зрения создания бота, и мы предложили альтернативное «боту на питоне» решение – собрать бота на нашей платформе. Это намного быстрее, дешевле, и клиент может сам поддерживать бота. Кроме того, у заказчика была накоплена история общения в Jivo, и ее можно было использовать для быстрого создания бота с помощью нашего Автосборщика. 

Автосборщик – инструмент для автоматического создания ботов (из подготовленных данных экселе), способных распознавать смысл фраз и отвечать на них должным образом. 

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

Клиент хотел работать без ТЗ, чтобы не тратить время на аналитику и его написание, но и на почасовку по agile не был согласен – типично). Договорились: 

1. клиент самостоятельно «закрывает» подготовку обучающих данных для бота в нужном формате и его тестирование
2. мы предоставляем консультации, собираем бота нашим Автосборщиком, а полноценно подключаемся только на первый месяц его эксплуатации для улучшения «на ходу»
3. дальше проект переходит на поддержку

Создание силами заказчика

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

У нас такой этап обычно занимает неделю-две, в зависимости от объема данных, так как есть внутренние инструменты полуавтоматического анализа и кластериазции истории диалогов, мы пока не упаковали их в самостоятельный продукт, в отличие от Платформы.

Получив данные, с помощью Автосборщика мы собрали бота за 2 минуты и вывели его в закрытый телеграм канал для тестирования. Но потом не все пошло так гладко)) 

Тестирование перед запуском. Скрытая угроза

Три недели длилось тестирование и отладка бота сотрудниками клиента: две – в телеграме, затем еще неделю на ограниченном реальном трафике (<5%) – в группе в ВК. Конечно, мы предоставили рекомендации и инструкции, но в подготовке и тестировании бота важен опыт, которого не было у клиента к тому моменту (обучение не вошло в скоуп проекта), это сильно повлияло на результат.

Заказчик думал, что улучшает распознавание, когда увеличивал количество вопросов, разделяя один общий на несколько частных, но на деле, это только запутало бота. В нем оказалось очень много «близких» интентов с пересекающимися обучающими выборками. Такими интентами были, например: «Когда можно продлить займ», «Оформить продление займа» и «Как оформить продление займа». Это плохо для распознавания.

Интент – намерение клиента / собеседника бота, которое бот должен распознать, суть вопроса. Например, у фраз «как вас найти?», «где вы находитесь?», «скажите адрес пож» – один смысл: клиент хочет узнать адрес. То есть эти фразы принадлежат одному интенту.
Обучающая выборка – набор фраз-примеров для каждого интента (в примерах выше: «как вас найти?», «где вы находитесь?», «скажите адрес пож»). 

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

Для хорошего результата обучающие данные должны быть качественно подготовлены, например, выборки должны иметь оптимальное количество примеров и не должны «пересекаться» – одна и та же фраза не должна быть в выборках разных интентов.

Искусственный тестовый трафик в Телеграме не вскрыл проблему, т.к специалисты заказчика были «в контексте» – знали, какие вопросы они заложили в бота, и неосознанно пытались «попасть» в них, вместо того чтобы брать «сырые» фразы из истории диалогов (это довольно частая ошибка у тех, кто впервые сам создает умного бота).

Да, мы могли бы выявить проблему, но тестирование было целиком за заказчиком. Заказчик тестировал и говорил, что с распознаванием все отлично (а это ли не главное?), и этого всем казалось достаточно.

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

В общем, казалось, все хорошо. Пошли в прод!

Запуск на 100% трафика: проблемы и улучшение в 3 раза за месяц

Проблему с распознаванием мы увидели 1 июля, когда вывели бота на весь трафик ВК и виджет на сайте, а это 1500-2000 обращений в день. В тот день, как и при тестировании, бот «распознавал» 90% фраз, но, как оказалось, почти все – неправильно. Вследствие этого 80% всех обращений были переведены на оператора, в основном по причине «бот не понял / запутался». Реальная же корректность распознавания составила 25.9%. 

Такой результат никого не устроил. Но проблему решили быстро.

За второй день мы пересобрали бота целиком: сделали полное ревью, избавились почти от 20 «близких» интентов, где-то подключили распознавание по регулярным выражениям, где-то добавили кнопки, оптимизировали обучающие выборки. Реинжиниринг повысил качество работы бота более чем в 2 раза, но на этом мы не остановились, потенциал проекта еще не был исчерпан.

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

За этот месяц мы увеличили долю полностью решенных ботом обращений до 72% – это стало ключевой метрикой эффективности проекта. А доля переведенных на операторов обращений по причине «бот не понял / запутался» снизилась до 5-6%, остальные переводы на оператора – запланированные в сценарии (определенные вопросы решает только оператор). Ресурс операторов высвободился, они смогли оперативнее подключаться в важным и уникальным обращениями.

Далее проект перешел на поддержку, мы продолжали с заказчиком смотреть аналитику работы бота и дообучать его, но уже всего один раз в неделю, т.к. проблем стало мало. Мы и сейчас это продолжаем делать, поэтому доля решенных ботом обращений держится на уровне 70-73% ежемесячно, несмотря на рост трафика и тематик обращений. 

В в августе прикрутили к сценарию бота сбор обратной связи после ответа на вопросы. Интересно, что этот показатель стабилен – и в первую неделю, и сегодня положительно качество обслуживания оценивают 74-75% респондентов.

Итоги

В целом проект был не сложный с точки зрения создания и улучшения бота, но особенный в том, что клиент захотел много сам сделать. Для нас бОльшим вызовом была инфраструктурная задача – начать тиражировать Платформу в отдельных инстансах под клиентов на собственном облаке. Проблем с распознаванием при запуске бота можно было бы избежать, если бы аналитика нашими силами и/или ТЗ вошли в скоуп проекта, либо если бы заказчик прошел обучение, но случился Agile - с MVP и итеративным улучшением;)