Служба заботы Skillbox: как ChatGPT-бот забрал 25% обращений и позволил нам уделять больше внимания сложным запросам

Сегодня хочу рассказать, как мы ввели чат-бота на основе ChatGPT, который отвечает студентам по нашей базе знаний и забирает 25% обращений на себя. Описала весь путь: как продумали логику его работы и встроили в обработку обращений без страданий для пользователя, какие выбрали показатели и цели, как их отслеживаем, про ошибки, радости и счастливый финал 🙂

Меня зовут Снежана Майская, я руковожу Службой заботы в Skillbox. Это третья статьи в серии, здесь я писала про то, как росла и менялась поддержка, а тут — про то, как мы ведем базу знаний.

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

Выбрали бот

Интегрировали с хелпдеском

Продумали логику работы бота

Прописали шаблоны бота

Встретили приколы бота (и проводили)

Ввели показатели для отслеживания успеха бота

Выделили ИИ-менеджера

Поставили цели для бота

Проблемы: бот не работает?

Ввели теги для автоматического подсчета показателей

Как изменился бот спустя 6 месяцев работы

Результаты бота: что сейчас

Cколько экономит нам бот

Готовы ли вы к ИИ-боту в службе поддержки

Чек-лист: как внедрить ИИ-бот в службу поддержки

Или бот выбрал нас. Команда Wikibot предложила проиндексировать наш существующий FAQ для пользователей в Notion и посмотреть, как работает ИИ-бот. Он выдавал ответы по теме, хоть пока и далеко от идеала — решили пробовать.

Сейчас бот, используя ChatGPT, работает на основе нашей новой открытой базы знаний для пользователей: zabota.skillbox.ru.

Платим по тарифу за пакет «кредитов». Кредит — это стоимость обращения к боту. Основные вопросы стоят 1 кредит, первая линия* — 0,5 кредита, приветствия и благодарности — 0,2 кредита.

*Первая линия — это вопросы, на которые бот не обращается в базу знаний, а дает один заготовленный и фиксированный ответ или переводит на оператора.

От подписания договора до интеграции с Юздеск и запуска бота прошло 2 дня.

Мы решили начать с канала Telegram, так как там поступает меньше всего обращений. Каких-то особых проблем в подключении не было, по крайней мере для нас 🙂

С этого момента мы начали совместную непрерывную работу над совершенствованием нашего бота и продукта в целом, потому что Wikibot — это стартап, у которых мы одни из первых клиентов.

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

Сначала бот обрабатывал первое и каждое следующее сообщение, пока студент не позовет оператора.

Минусы:

• не все дочитывали до конца, что нужно назвать волшебное слово и просто продолжали писать и задавать вопросы — так может продолжаться вечно и мы не узнаем, если специально не следим;
• каждый запрос стоит денег, бесконечные диалоги съедят запас «кредитов».

Плюсы:

• студент мог получить правильный ответ бота на каждое сообщение;
• в конце боту говорили «спасибо» и иногда даже не замечали, что с ними говорит ИИ :)

Поэтому оставили обработку только первого сообщения.

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

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

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

Еще важно составить список слов, которыми пользователь захочет позвать агента — диапазон примерно от «позовите человека» до «император».

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

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

Позже добавили и другие реакции бота на разные случаи:

• Исключение, если в сообщении только приветствие без вопроса, чтобы он не пытался найти ответ и не отвечал «у меня нет ответа на этот вопрос». Сделали к таким случаям отдельный шаблонный ответ, чтобы бот просто здоровался: «Здравствуйте! Чем могу помочь?».
• То же самое проделали со «спасибо» и добавили отдельный ответ: «Рад помочь! Пишите, если будут вопросы».
• Добавили еще одно сообщение, когда студент вызывает оператора: «Хорошо, передал ваше обращение в работу — скоро вернёмся с ответом».
• И сделали специальные автоответы в зависимости от времени дня. Если это нерабочее время, то бот отвечал, что сейчас Служба заботы отдыхает, но он постарается помочь. И дальше сгенерированный ответ бота.

Получились такие шаблоны:

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

Поделюсь, с чем мы работали и с чего начинали.

Не нравилось, что поначалу он отвечал, будто не имеет отношения к Skillbox: «в данной документации не указано» или «документация предоставляет несколько вариантов». Однажды так и сказал: «Я не являюсь представителем Skillbox и не имею доступа к их политике обучения. Рекомендую вам обратиться в их службу поддержки». Что в этот момент думал про нас студент, остается только догадываться 🙂

Или отфутболивал в поддержку, хотя студент уже в одном из наших каналов: «напишите в Службу заботы Skillbox на [email protected], через виджет чата на платформе или же в Telegram — @Skillbox_support_bot». Так получалось, потому что в статьях нашей базы знаний мы писали, куда обращаться, если не нашли ответ.

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

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

Первый раз мы проверили ответы бота спустя неделю его работы.

В первой выгрузке я ввела такие столбцы:

• Верно или нет.
• Какая ошибка:
• отправил к нам же;ответ неверно сформулирован;придумал от себя;нужно было передать оператору;ответ не по делу;неполный ответ.
• Недочеты:
• слеши;опечатка;странная формулировка;кавычки.
• Как надо? Как лучше? — здесь пишем словами, что должен был ответить бот.

Первые результаты были такие:

• От общего числа тикетов, прошедших через бота, верных ответов или переводов на оператора — 28%, можно лучше — 20%, неверно — 52%.
• Среди запросов, где бот совершал попытку ответить, верно — 23%, можно лучше — 22%, неверно — 55%.
• Из общего числа ошибок нужно было передать оператору в 43% случаев. Отправил писать к нам же в поддержку — 24%.

Сначала получились такие два показателя, которые мы стали отслеживать:

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

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

Окей, столько он правильно переводит, столько дает правильных ответов. А польза есть?

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

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

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

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

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

Откуда взяли целевые значения:

— ориентировались на текущие значения и прикидывали, на сколько еще это может вырасти в реалистичном и оптимистичном сценарии;

— заложили свои надежды и желания, потому что ниже нам неинтересно и не надо.

Цели получились такие:

• Верных срабатываний из всех тикетов — 95%.
• Верно отвеченных из всех тикетов — 50%.
• Верно отвеченных из попыток ответить — 97%.
• Успешно закрытых полностью ботом из всех тикетов — 30%.

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

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

Идея мне понравилась — мы начнем больше тикетов обрабатывать верно.

Когда мы начали прорабатывать вопрос-ответ в табличке, быстро пришло понимание, что мы скатываемся в тот бот, что у нас раньше был в Юздеске. Так как оказалось, что надо добавлять разные вариации запросов для одного ответа: «ошибка отправки», «ошибка при отправке сообщения» и так далее.

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

Позже команда Wikibot признала, что файл QA в гугл-таблице спутал им поиск, и вдобавок они превратили свой продукт в сценарного бота.

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

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

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

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

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

Wikibot сделали «первую линию поддержки», где можно указать вопросы, на которые нужно дать фиксированный ответ или передать оператору.

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

Добавили в исключения на почтовом канале список спамеров и формулировки автоответов студентов типа «я в отпуске», чтобы не тратить кредиты.

Wikibot ввели возможность выставлять тему обращения, соответствующую статье в базе знаний, где боту удалось найти ответ. Ура!

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

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

Еще можем вот так показать:

Ответы бота сегодня выглядят так:

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

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

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

Нужен ли вам ИИ-бот:

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

2. Если у вас меньше 500 тикетов в месяц, также не торопитесь с ботом.

Бот своими силами или готовое решение:

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

К чему нужно быть готовым:

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

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

1. Собрать открытую базу знаний
2. Интегрировать бот в хелпдеск
3. Продумать схему обработки обращения
4. Настроить правила и триггеры в хелпдеске
5. Написать шаблонные части ответа бота
6. Выделить ИИ-менеджера для совместной работы с командой бота
7. Продумать показатели для отслеживания работы бота
8. Продумать целевые показатели успеха мероприятия
9. Ввести теги для автоматического подсчета показателей
10. Продумать вопросы-исключения и L1 бота
11. Проиндексировать базу знаний
12. Запустить бота
13. Непрерывно улучшать базу знаний и алгоритмы