AI-система маршрутизации обращений в отделы

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

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

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

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

Классификация, приоритеты и сроки ответа в одной системе

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

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

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

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

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

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

Как выбрать схему под свой поток обращений

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

Как мы строим систему распределения запросов: этапы работ

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

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

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

Конфигурация системы, схемы потоков и регламенты

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

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

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

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

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

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

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

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

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

Что делать, если правила настроены, но не работают

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

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

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

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

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

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

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

Останется ли человек в контуре решения?

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

Что делать с нестандартными вложениями и голосовыми?

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

Как контролируется качество модели после запуска?

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

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

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

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

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