Что будет, если IT-компания внедрит ИИ во внутренние бизнес-процессы? Об этом и поговорим.
Привет, Хабр! Меня зовут Оксана Романенкова, я директор Департамента клиентского сервиса (ДКС) СберКорус, а мой коллега — Алексей Кудрявцев, руководитель Группы аналитической отчётности Департамента анализа и обработки данных СберКорус. Сегодня мы хотим поделиться историей о том, как решили привлечь к работе техподдержки искусственный интеллект и что из этого вышло.
337 200 заявок в год
Это сегодня Департамент клиентского сервиса — большая структура, объединяющая в себе кол-центр, техподдержку, отдел контроля качества и отдел обучения клиентов. Ребята в нем работают выделенными линиями техподдержки первой, полуторной, второй и экспертной третьей линии. Первая и полуторная линии решают типовые проблемы обратившихся, а уже вторая и третья предоставляют узкоспециализированные консультации.
Но так было не всегда. Ещё недавно мы назывались Единый центр обслуживания (ЕЦО), где трудились 15 сотрудников, которым в год нужно было обрабатывать почти 350 000 заявок. Им приходилось принимать звонки, обрабатывать письменные запросы, отвечать клиентам в чате. Количество клиентов увеличивалось, нагрузка тоже стабильно роста, и справляться с ней становилось все сложнее.
Казалось бы, очевидное решение — увеличить количество сотрудников. Но увеличение ФОТ помогает только в тех случаях, когда количество задач — единственная проблема, а наши сложности были не только в этом. Судите сами:
В техподдержку обращались не только для решения каких-то инцидентов. Мог прийти запрос, например, с просьбой выслать инструкцию к сервису. И его приходилось обрабатывать в порядке общей очереди. наряду с инцидентами.
Мы работаем в Jira, где завели для себя проект Helpdesk, но далеко не все заявки отправлялись именно туда. Порой их удавалось обнаружить в других проектах — например, в проекте конкретного продукта, если проблема была связана с его работой. Как итог — пропущенные заявки и снижение индекса удовлетворённости клиентов (CSI), несмотря на все попытки сотрудников отловить новый запрос как можно скорее.
Распределением клиентских запросов в ЕЦО занимались всего 2 сотрудника. А когда происходил массовый инцидент — приходилось на разбор заявок выделять дополнительные ресурсы. Итого, еще как минимум двое уходили на разбор завалов из заявок, а оставшиеся закрывали все запросы от клиентов.
Конечно, нельзя было забывать о трех волшебных буквах — SLA. Нечего и говорить, что соблюдать соглашение об уровне сервиса с клиентам было задачей непростой.
Определённо пора было что-то менять.
Как я уже сказала, первая очевидная идея — расширить ФОТ, нанять много людей. Но мне не давала покоя мысль, что я работаю в IT-компании, продукты которой призваны упростить бизнес-процессы клиентов. Неужели мы не сможем придумать что-то подобное для себя?
В итоге мы с коллегами пришли к решению, что можно попробовать внедрить Machine Learning в систему обработки заявок. Инициативу одобрил наш операционный директор Юрий Чекунов. И закипела работа.
Чем нам должен помочь ИИ?
Теперь объясню, какие задачи мы поставили перед ИТ-специалистами для разработки и последующей реализации проекта Jira ML:
Ранжирование обращений. Это помогло бы нам быстрее реагировать на инциденты, а запросы на обслуживание выполнять в обычном режиме. Если у пользователя возникала проблема с эксплуатацией наших сервисов, мы должны устранять её в первую очередь.
Фильтрация спама. Нам хотелось, чтобы ИИ распознавал спам, обработка которого тоже отнимала массу ресурсов.
Классификация обращений, чтобы быстрее реагировать на заявки клиентов, повышать CSI и полностью выполнять условия договоров SLA.
Когда мы составляли техническое задание, договорились о том, что будет здорово, если ИИ на первом этапе возьмёт на себя обработку хотя бы 50 % заявок. Например, если в техподдержку поступит 10 запросов, то 5 из них должен распределить ИИ, а остальные 5 — сотрудник техподдержки.
Начинаем внедрять ИИ в техподдержку
Подготовка началась с рутинных больших задач: нужно было описать все, что происходит в ЕЦО, привести примеры, показать, как мы классифицируем запросы.
Сначала понадобилось описать, как создаётся тикет в Jira, в чём разница между заявкой на обслуживание и уведомлением об инциденте. Мы приводили примеры описаний задач, чтобы машинная модель училась транскрибировать и классифицировать их.
Много времени потратили на описание того, как задачи могли «прыгать» из проекта в проект, пока не оказывались у техподдержки, указали признаки, по которым можно было сформировать очередь рассмотрения запросов по приоритетности.
Перед командой разработки стояло три главные задачи — маршрутизация заявок, их ранжирование, фильтрация спама. Чтобы корректно обучить модель, нужно было позаботиться о чистоте данных. Поэтому:
Мы искали аномалии в данных, чтобы удалить их. Среди них — заявки без указанных e-mail, со сломанной кодировкой, где были только цифры, составленные на иностранных языках или вовсе без описания.
Приводили текст к нормальному виду. Например, обозначили более десятка способов указать ИНН организации или слова «Здравствуйте» в начале обращения.
Убирали незначительную информацию, чтобы не засорять ИИ. Например, CSS и XML-разметки, вложения файлов и подписи к письмам, приветствий, уведомлений о конфиденциальности.
ИИ обучался на данных с глубиной выгрузки в 8 месяцев — с IV квартала 2021 года по II квартал 2022 года. Объём данных составил 1,81 Гб. Всего в выгрузке за 8 месяцев было 249 377 заявок, это тикеты от внешних клиентов и внутренних служб. Но модель мы обучали только на заявках от внешних пользователей. Разработка велась ресурсами СберКорус, приглашать сторонних вендоров не потребовалось.
Изначально проект планировалось реализовать за 5 месяцев, но сроки пришлось увеличить до 6,5 месяцев. Причина — изменение бизнес-процессов в ДКС, из-за чего пришлось переобучать модели.
Первые 3 месяца ИИ обучался на уже существующих тикетах, а затем мы внедрили его в полевые условия — подключили к работе техподдержки и смотрели, как работает система. Оставшиеся 3,5 месяца модель распределяла запросы уже в режиме реального времени, а команда разработки дообучала модель по фидбэку от коллег.
Jira ML — не самообучающаяся модель. Если произойдут какие-то изменения в структуре ДКС или его бизнес-процессах, Jira ML придётся обучать заново вручную.
Однако этот процесс запустить довольно просто — все скрипты сохранились, нужно будет лишь вводить новые данные. Переобучение возможно на объединённых данных (старые и новые) или только на новых данных. Модели, которые покажут лучшие результаты работы, и будет в дальнейшем помогать техподдержке.
— «Иногда обучать модель на данных, например, пятилетней давности нет смысла. Бизнес-процессы могли так сильно поменяться, что знакомить ИИ со старыми регламентами работ попросту нет необходимости. Потому берём в работу только актуальную информацию, чтобы Jira ML работала без ошибок».
Алексей Кудрявцев, руководитель Группы аналитической отчётности Департамента анализа и обработки данных СберКорус
Что в итоге получилось
Сразу хочу сказать, что проект Jira ML превзошёл мои ожидания. Но давайте пройдемся по результатам более детально:
Благодаря быстрой маршрутизации запросов с помощью ML мы теперь закрываем до 86 % поступающих запросов в день. Ещё 2,5 года назад я и подумать о таком не могла.
Машинная модель самостоятельно обрабатывает не 50 % заявок, как изначально указывалось в ТЗ, а 70 %. Вручную специалист распределяет только 30 % запросов. Благодаря этому на ручной обработке заявок у нас остался только 1 специалист, когда раньше для работы с массовыми инцидентами нужно было не менее 4 сотрудников.
ИИ качественно определяет спам и освобождает время сотрудников для других задач.
Сама система поставлена на мониторинг, и если с ней что-то происходит, это регистрируется как массовый инцидент, и специалисты быстро чинят её.
А ещё мы перевыполнили KPI по CSI :)
Планы на будущее
Нет предела совершенству, и мы также планируем улучшать нашу ИИ-модель в следующих направлениях:
Мы хотим добиться 100 % автоматизации обработки заявок в техподдержку.
Предстоит решить проблему при возобновлении заявок. Если техподдержка и пользователь пришли к выводу, что некая проблема решена, тикет закрывается. Однако позднее пользователь вновь может обнаружить недочёты и восстановить запрос. Нужно научить Jira ML работать с такими заявками, классифицировать их и отправлять в работу техподдержке.
Отдельная работа предстоит с дубликатами заявок. Случается, что клиент начинает сообщать о своей проблеме сразу по нескольким каналам техподдержки — по телефону, электронной почте или через форму на сайте. В итоге получается так, что по одной задаче сформировано несколько одинаковых тикетов. Потому нужно научить ИИ находить такие заявки и объединять их в одну.
Особая задача — научить ИИ работать с типовыми запросами пользователей. Допустим, если клиент запрашивает инструкцию к сервису, Jira ML могла бы самостоятельно направить ответ ему с прикреплённым файлом.
Самое главное для нас уже случилось — работа над заявками стала прозрачнее и эффективнее. И я уверена, что работа ДКС с полным внедрением ML станет только проще, а клиенты всегда будут своевременно получать от нас помощь.