Маршрутизация обращений ИИ: как настроить автоматическое распределение тикетов

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

Что такое ИИ-маршрутизация и чем она не является

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

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

Три вопроса, которые ИИ решает по каждому обращению

Первый — тип и тема. «Не работает доступ к 1С», «не пришёл счёт», «сломался принтер в офисе на Ленина» — это разные потоки, и раньше их различал человек по заголовку письма.

Второй — срочность и приоритет. Модель смотрит на формулировки, наличие слов-маркеров сбоя, тональность и историю клиента: обращение от ключевого заказчика с упоминанием простоя весит иначе, чем уточнение по инструкции.

Третий — исполнитель и момент эскалации. Кому отдать, есть ли у него компетенция, не превышен ли лимит активных тикетов, и когда пора звать руководителя, если реакции нет.

Как устроен контур ИИ-маршрутизации

Шаг 1. Приём и нормализация

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

Шаг 2. Классификация и извлечение сущностей

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

Категории не должны быть абстрактными. Если в 1С:Документообороте или Битрикс24 у вас уже есть дерево услуг, классификатор обучают именно на нём, иначе маршрутизация будет уводить тикеты «в никуда».

Шаг 3. Обогащение данными из учётных систем

Голый текст даёт мало. Реальную ценность добавляет контекст: тариф и уровень сервиса из CRM, открытые сделки, прошлые обращения, наличие гарантии на оборудование, статус лицензии в 1С. Именно этот шаг превращает классификатор в полноценного диспетчера.

Интеграция делается через API или промежуточный слой, который забирает данные из 1С, amoCRM, Битрикс24 и отдаёт их модели в обезличенном виде. Никакой персональной информации в промпт уходить не должно.

Шаг 4. Правила приоритета и SLA

Дальше в дело вступает детерминированная логика — её не стоит отдавать нейросети. Матрица «категория × уровень клиента × канал» определяет приоритет и нормативный срок. Модель лишь поставляет признаки, решение принимает правило, и это решение воспроизводимо и объяснимо.

Шаг 5. Назначение, эскалация, обратная связь

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

Обратная связь обязательна. Когда оператор вручную меняет очередь или категорию, это сигнал для дообучения. Без такого цикла качество модели деградирует за пару месяцев.

Приватная LLM или облачный API

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

Практичный вариант — приватная LLM на собственном сервере с GPU. Для классификации и извлечения сущностей хватает моделей среднего размера, они уверенно работают на одной-двух картах и не требуют дата-центра. Если нагрузки небольшие, разумна гибридная схема: локальная модель для чувствительных потоков, внешняя — для обезличенной аналитики.

Зачем маршрутизатору RAG

Классификатор, который знает только общие слова, будет путать «не работает VPN» и «не работает 1С». Решение — RAG-контур поверх корпоративной базы знаний: регламентов, инструкций, истории закрытых тикетов, описаний услуг.

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

Примеры из российской практики

Промышленное предприятие с парком заявок в 1С:Документооборот: маршрутизация по 40 категориям, приоритет определяется по признакам простоя, эскалация через 30 минут. Доля тикетов, попавших к нужному исполнителю с первого раза, выросла с 60 до 90 процентов.

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

ИТ-подразделение холдинга: приватная LLM на локальном сервере, RAG по внутренним регламентам, полный аудит решений. Юридически значимые обращения остаются в контуре компании.

Метрики, по которым видно эффект

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

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

Типичные ошибки внедрения

Первая — отдать нейросети всё, включая приоритеты и сроки. Правила должны остаться в коде, модель — только поставщик признаков.

Вторая — запуск без логов и разметки. Если нельзя объяснить, почему тикет ушёл именно этому сотруднику, систему не примут ни поддержка, ни аудит.

Третья — категории, придуманные под модель, а не под реальные процессы. Справочник услуг должен совпадать с тем, что уже живёт в 1С и CRM.

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

С чего начать

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

В студии АПС мы внедряем такие системы под ключ: приватные LLM на серверах заказчика, RAG по корпоративным данным, ИИ-агентов и интеграции с 1С и CRM. Начинаем с аудита потока обращений и расчёта, где автоматизация окупится быстрее всего.