Автоматизация обработки заявок: AI-маршрутизация для поддержки

AI маршрутизация заявок: где ломается ручная сортировка

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

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

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

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

Что даёт переход на автоматическую обработку обращений

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

Доля автораспределения — первая метрика, которую мы замеряем до и после. На старте это обычно 40–60%: автоматически расходится то, что однозначно читается по теме. После дообучения на накопленной разметке показатель доходит до 75–85%, и упирается он не в модель, а в качество рубрикатора — очередей, по которым обращения действительно расходятся.

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

Ошибочная маршрутизация уходит как класс: раньше заявка могла лежать в чужой очереди, пока адресат её не заметит. Каждое исправление очереди мы возвращаем в разметку, поэтому следующий похожий случай распределяется верно. В связке с Jira Service Management видно и основание решения: по какому признаку заявка попала к исполнителю и где правило сработало не так.

Способы маршрутизации: правила, модель, гибридная схема

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

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

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

Порядок внедрения: от разбора потока до передачи в поддержку

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

1. Аудит потока обращений — разбираем, откуда приходят заявки, сколько их по типам и как они распределяются сейчас; фиксируем, где копится очередь и какие обращения уходят не туда.
2. Проектирование схемы маршрутизации — описываем категории, правила эскалации и порог уверенности, ниже которого заявку обязательно смотрит человек.
3. Разметка исторических данных — на выборке прошлых обращений проставляем эталонные категории и приоритеты. Это база, на которой схему можно измерить, а не показать на демонстрационных примерах.
4. Настройка и проверка на истории — прогоняем маршрутизацию по размеченному набору и смотрим матрицу ошибок: где путаются соседние категории, правим признаки и пороги до приемлемой точности.
5. Опытная эксплуатация — включаем режим, где система предлагает маршрут, а решение принимает оператор; расхождения разбираем ежедневно и возвращаем в дообучение.
6. Передача в поддержку — отдаём регламент категорий, порядок разбора спорных заявок, обучаем команду и остаёмся на сопровождении после запуска.

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

Что остаётся у заказчика: правила, модели, регламенты

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

• Карта маршрутизации — какие категории обращений выделены, за какими очередями и исполнителями они закреплены и в какую сторону уходит заявка, если модель не уверена в разборе.
• Правила приоритета обращений — признаки, поднимающие заявку в начало очереди: повторное обращение, срок по договору, статус клиента; отдельно описан порядок, когда срабатывает несколько правил сразу.
• Роли и права доступа — кто только просматривает отчёты, кто меняет правила, кто утверждает новые категории; разграничение по подразделениям и по объёму видимых данных.
• Регламент эскалации — по каким условиям заявка уходит на оператора, сколько ждёт ответа и кто подхватывает её при недоступности первой линии.
• Инструкции для операторов — что делать с обращением, отнесённым к категории с низкой уверенностью, как пометить ошибку разбора, чтобы она попала в дообучение.
• Порядок переобучения модели — как накапливается и утверждается разметка, на каком наборе примеров проверяется новая версия и как вернуться к предыдущей, если качество просело.
• Журнал решений и выгрузки — по каким признакам заявка попала в очередь, с какой уверенностью и что именно было передано оператору.

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

Кейс: распределение заявок без ручной сортировки

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

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

Что изменили

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

Метрики до и после

• Доля автораспределения: от нуля до 87% обращений, ручная разметка осталась только на спорных случаях.
• Время до первого ответа: с нескольких часов в пике до 30-40 минут, включая ночные смены.
• Повторные обращения: минус треть — клиент реже писал повторно в другой канал.
• Нагрузка на операторов первой линии: сортировка перестала быть основной задачей, освободившееся время ушло на сложные обращения.

Каждое решение модели логируется вместе с признаками, а переотнесение заявки оператором уходит в разметку для дообучения — качество маршрутизации растёт без переписывания правил вручную.

Чем отличается сортировка по правилам от обученной модели?

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

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

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

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

Технические сомнения перед стартом работы

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

Можно ли менять правила на ходу?

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

Сколько нужно исторических данных?

Для старта достаточно нескольких тысяч размеченных обращений; без разметки маршруты восстанавливаются по журналам переписок. На малом объёме больше решают правила, модель дообучается на живом потоке.

Как проверяется качество маршрутизации?

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

Как откатываются изменения?

Версии правил и модели хранятся с датой и автором, поэтому откат — возврат предыдущей версии, а не срочная правка кода. Прежнее поведение восстанавливается за минуты, поток заявок при этом не останавливается.

Обсудим задачу и вернёмся с планом работ

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

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

• Разбираем каналы: почта, формы, чат, звонки — где теряются заявки и какой поток разбирается вручную.
• Смотрим выборку обращений: какие типы повторяются и по каким признакам их можно разделять автоматически.
• Уточняем правила: кому и по какому признаку уходит заявка, что делать с неоднозначными случаями, кто принимает финальное решение.
• Фиксируем показатели: время первого ответа, доля обращений, закрытых без оператора, число переадресаций.
• Согласуем доступы и ограничения: какие системы подключаем, какие данные нельзя выносить за контур.
• Оцениваем состав работ: нужна ли разметка истории, сколько сценариев закрываем на первом этапе, что переносим на следующий.
• Прописываем сроки этапов, точки проверки результата и порядок отката к ручной обработке.

Опишите задачу так, как она выглядит у вас — вернёмся с оценкой и планом работ.