Красный SLA: кто виноват?

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

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

Куда уходит время, пока заявка ищет адрес

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

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

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

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

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

Пусть люди перестанут угадывать

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

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

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

Так заявка с первого раза попадает в нужную группу. Например, в кейсе ITG Corporation — компании с сервисным контуром в 10 странах и больше чем 50 продуктовых направлениях — доля ошибок классификации обращений после внедрения ИИ снизилась с 30% до 5%. SLA перестает гореть, даже не успев толком загореться.

Как ИИ определяет услугу и категорию — и почему это не поиск по ключевым словам

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

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

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

У этого механизма есть операционная цена, которую стоит проговорить отдельно. В компании с несколькими юридическими лицами или регионами каталог услуг обычно не один — по каждому лицу или подразделению свой, да еще и на разных языках; классификатору приходится сопоставлять смысл обращения именно с тем каталогом, который актуален для конкретного юрлица и региона. Отдельный вопрос — кто отвечает за качество классификации, когда обращение все же ушло не туда. Об этом мы уже рассказывали в другой нашей статье: у ИИ-сервиса должен быть свой владелец, который отвечает за актуальность данных, сценарии эскалации и мониторинг качества решений, а не только за то, что система технически работает. Применительно к классификации это значит конкретное действие на самой заявке — кнопка «Переклассифицировать» рядом с полем «услуга/категория»: агент выбирает верную пару вручную, а система фиксирует это отдельно от обычных переназначений между отделами. Тогда видно не просто, что заявку перекинули, а где именно и как часто ошибается классификатор, — и это исправление можно использовать, чтобы то же обращение в следующий раз распозналось верно. 

Точку входа для ИИ можно сдвинуть еще раньше. В SimpleOne ITSM для этого есть ИИ гид-помощник: сотрудник описывает проблему свободным текстом в чате, а гид по ходу диалога находит подходящую услугу, статью базы знаний или уже известную ошибку и сразу предлагает готовый ответ — часть обращений вообще не доходит до создания заявки. Там, где заявка всё же нужна, гид сам уточняет срочность, шаги воспроизведения и другие обязательные поля и передает специалисту уже заполненную форму — с корректно определёнными услугой и категорией, а не голым текстом, который агенту пришлось бы разбирать с нуля.  

Подробнее ознакомиться с функциональностью ИИ гида-помощника можно посмотрев наш видео-обзор.

Резюме

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

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