Как мы меняем клиентский сервис с помощью AI. Часть 1

Кажется, что большие языковые модели просто созданы для того, чтобы работать в клиентском сервисе. Они умеют анализировать запрос, генерировать короткие и подробные ответы, структурировать и объяснять. Но в большинстве случаев мы все равно недовольны ответами чат-ботов и просим быстрее «перевести на оператора». Почему?

Я — Максим Михайлов из Cloud.ru ^[1]. В серии статей попробую ответить на этот вопрос. А еще расскажу, как мы внедряем AI в клиентский сервис так, чтобы сотрудники и технологии работали в симбиозе, ответы сохраняли дружелюбие, клиенты максимально эффективно решали свои задачи и уровень удовлетворенности услугами и сервисами только возрастал.

Почему многих не устраивают ответы AI в поддержке

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

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

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

Часто компании используют классические сценарии автоматизации, которые работают примерно таким образом:

1. Пользователь пишет запрос.

2. Этот запрос попадает в какой-то препроцессинг на скриптах, который думает примерно так: «вроде бы здесь есть слово “здравствуйте”, давайте запустим сценарий “здравствуйте”».

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

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

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

Поэтому мы не пытались расписать все сценарии и полностью заместить специалиста поддержки искусственным интеллектом ^[3]. Вместо этого мы постарались создать удобный инструмент на базе AI, с помощью которого любой специалист сможет быстро разобраться в проблеме и помочь клиенту. При этом не терять человечность ответов и делать их даже более дружелюбными.

Как мы внедряли AI в поддержку: 2 этапа

Перед командой стояло несколько целей:

1. Сократить время, которое задача находится в работе у инженера (Average Handling Time, AHT).

2. Сделать ответы дружелюбнее.

3. Создать AI-агента, чтобы автоматизировать ответы на простые вопросы.

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

Этап 1. Сократить АНТ

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

Собрать генеративные подсказки — не такая уж и простая задача. Для этого мы:

1. Вычитали большой пласт обращений. Потратили на это месяц, разбирались, какие вообще есть типы обращений, что интересует клиентов, как можно классифицировать эти обращения.

2. Кластеризовали данные с помощью машинного обучения ^[4].

3. Обучили модели классификации, чтобы понять, какие у нас есть тематики.

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

5. Собрали базу знаний для модели, которую непрерывно обновляем и пополняем.

6. Дальше много промптили, подбирали модели. Для этого у нас есть Evolution AI Factory ^[5] — облачная среда с AI- и ML-инструментами. Например, с помощью Evolution Foundation Models вы можете выбрать готовые LLM- и AI-модели и адаптировать их под свои задачи.

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

• лампочка хранит сгенерированные подсказки;

• карандаш исправляет орфографические и пунктуационные ошибки ^[6];

• молния улучшает тон всего ответа (о ней расскажу дальше);

• лист копирует подсказку в рабочую зону.

Что нам дали генеративные подсказки:

• АНТ сократилось на 25 минут. Это влияет и на все прочие метрики поддержки: SLA на ответ, количество отработанных тикетов.

• Покрыли 62% входящего потока обращений.

• Получили фундамент для дальнейшей автоматизации.

Этап 2. Сделать ответы дружелюбными

В своем выступлении на GoCloud ^[7] я спрашивал у аудитории, как она понимает, что такое дружелюбие. Кто-то ответил, что текст без ошибок это и есть уважительное обращение, кто-то, что должно быть коротко и ясно, а кто-то написал, что дружелюбие — это когда тебе в целом отвечают.

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

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

1. Адаптировали Tone of voice (голос бренда), который ранее был разработан департаментом бренд-маркетинга и коммуникаций, для инженеров поддержки и провели обучение инженеров по Tone of voice.

2. Создали чек-лист для LLM. Чтобы замерить прогресс и оценить, стали ли инженеры отвечать дружелюбнее, сделали объективную метрику: разложили ToV на чек-лист из 10 простых вопросов, на которые можно ответить «да» или «нет». Например, есть ли в тексте канцеляризмы, которые усложняют ответ инженера и добавляют лишний официоз. Модель проходит по чек-листу и анализирует каждый ответ, который уходит клиенту. Благодаря этому у нас появилась метрика, которая оценивает дружелюбие ответа и соответствие Tone of voice в целом.

3. Добавили в рабочее место инженера ту самую молнию, которую показывал на скрине выше. Этот инструмент учитывает Tone of voice, добавляет в текст структуру и выдает ответ в нужном формате. Работает так: инженер пишет ответ, нажимает на одну кнопку и получает текст, который разбит на абзацы, в нем нет ошибок, ссылки вставлены правильно, а сложные предложения стали простыми и читаемыми.

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

Что в результате

Один из важных показателей для нашей компании — уровень удовлетворенности клиентов (NPS). За год этот показатель вырос на 17 пунктов, и многие клиенты отметили рост качества и скорости работы технической поддержки.

Если посмотреть на фактическое использование LLM сотрудниками, то статистика такова: 47% ответов были даны с использованием генеративного AI. Это могла быть генеративная подсказка, улучшение текста или исправление ошибок. Замечу, что у инженеров нет KPI на создание ответов с AI — каждый сам решает, когда стоит обратиться к этим инструментам.

Дальше мы перешли к работе над AI-агентом, который уже отвечает на 10% запросов наших клиентов, а к концу года в наших планах доверить ему до 70%.

О том, как мы создавали агента, какие результаты получили и как AI будет менять работу поддержки дальше — расскажу во второй части. А пока делитесь в комментариях — какие инструменты или сервисы на базе AI используете вы? И для каких задач?