ИИ для сортировки обращений и маршрутизации заявок в 2026
Практическая схема классификации писем, заявок и сообщений по теме, приоритету и ответственному сотруднику.
Когда входящие приходят из почты, формы на сайте и мессенджеров, ручная сортировка быстро превращается в отдельную смену. Я рассматриваю такую задачу как конвейер из пяти этапов: получить сообщение, определить его тему, оценить срочность, извлечь данные и выбрать маршрут. Нейросеть здесь не заменяет регламент, а помогает применять его к большому потоку.
Сам принцип обмена письмами появился задолго до современных языковых моделей: первую сетевую электронную почту отправили в 1971 году, а формат интернет-сообщений RFC 5322 опубликован в 2008 году. Сегодня к письму добавились вложения, формы, номера заказов и сообщения из каналов с разной структурой. Поэтому качество сортировки зависит от того, насколько аккуратно описаны входные поля и правила передачи обращения.
Как устроена автоматическая сортировка обращений
ИИ сортирует обращение в два прохода: сначала выделяет признаки из текста, затем принимает решение по маршруту. В рабочей схеме достаточно 4 групп данных: источник, содержание, срочность и найденные сущности.
На первом проходе система смотрит на тему письма, первые строки, основной текст, подпись и технические поля. Для заявки из формы полезны дата, город, номер заказа и выбранная категория. В сообщении из мессенджера часть этих сведений может отсутствовать, поэтому классификатор должен уметь работать с неполным набором признаков.
На втором проходе формируется карточка решения. Обычно в ней есть 5 полей:
- категория обращения, например оплата, доставка, возврат или техническая проблема;
- приоритет от P1 до P4;
- рекомендуемый отдел или роль сотрудника;
- найденные данные, номер заказа, дата, сумма, название услуги;
- уверенность модели в решении, от 0 до 1.
Такой формат удобнее свободного ответа. Его можно проверить по отдельным полям, передать в рабочую систему и отправить на ручной контроль, если уверенность ниже установленного порога. Подробнее о проверке результата генерации можно прочитать в статье о задачах и проверке текста нейросетью.
Какие признаки нужны для определения темы и приоритета
Для базовой классификации достаточно 4 признаков, а приоритет лучше вычислять по сочетанию срочности, ущерба и срока реакции. Одного слова «срочно» в теме письма мало: его часто используют для обычного запроса.
Тему определяют по смыслу всего сообщения, а не по одному ключевому слову. Фраза «не проходит оплата» может относиться к ошибке карты, возврату или вопросу о комиссии. Разница проявится в соседних предложениях, номере операции и описании результата.
Модельный кейс: в обращении «Не пришёл акт за заказ 4821, закрывающие документы нужны сегодня» одновременно находятся тема документов, номер заказа 4821 и временной маркер «сегодня». Для маршрута это полезнее, чем простая метка «документы».
Я рекомендую разделять четыре уровня приоритета:
- P1, остановлена критичная операция, нужен быстрый просмотр по внутреннему регламенту, например в течение 15 минут;
- P2, клиент не может завершить важное действие, но есть временный обходной путь;
- P3, стандартный вопрос без признаков немедленного ущерба;
- P4, предложение, отзыв, справочный запрос или обращение без срока реакции.
Эти интервалы не являются отраслевым законом. Их задают в SLA, то есть в соглашении о времени реакции, и проверяют на собственной статистике. В поле уверенности я использую рабочие пороги: выше 0,85 можно направлять автоматически, от 0,60 до 0,85 отправлять на выборочную проверку, ниже 0,60 оставлять оператору. Порог меняется после тестирования, а не выбирается раз и навсегда.
Как построить маршрут до нужного сотрудника
Маршрут лучше описывать через 5 последовательных действий: нормализация, классификация, приоритизация, извлечение сущностей и назначение ответственного. Такая цепочка помогает найти ошибку, если обращение попало не в тот отдел.
Сначала приводят входные данные к единому виду. Убирают повторяющиеся подписи, технические цитаты, лишние пробелы и служебные уведомления. Длинную переписку полезно разделить на последнее сообщение и историю, иначе старый вопрос может перетянуть классификацию на себя.
Затем задают справочник категорий. Для небольшого отдела я начинаю с 8–12 классов, а не с 50 размытых вариантов. Например, «оплата», «доставка», «возврат», «документы», «доступ», «ошибка сервиса», «жалоба» и «прочее». Категория «прочее» нужна как предохранитель, но её доля должна отслеживаться отдельно.
После этого извлекаются сущности. Для интернет-магазина это номер заказа, дата покупки, сумма и город. Для сервиса подписки, идентификатор аккаунта, дата списания и название тарифа. Не вся найденная информация достоверна: номер из подписи может относиться к старому заказу, поэтому автоматическое назначение должно учитывать контекст.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 1000 обращений в сутки из трёх каналов. Для неё разумно начать с 8 категорий, двух уровней ручной проверки и отдельной очереди для сообщений с отсутствующим номером заявки. Такой сценарий иллюстрирует методику, а не описывает реального клиента.
Финальное назначение можно строить по роли, региону, продукту или загрузке. Если в отделе 6 специалистов, маршрутизатор должен знать их рабочие зоны и часы доступности. Без этих данных нейросеть определит тему, но не сможет надёжно решить, кому именно передать сообщение.
Что выбрать: правила, нейросеть или гибрид
Для стабильных формулировок подходят правила, для разнообразного языка нужна нейросеть, а при высокой цене ошибки я выбираю гибрид. В нём простые случаи проходят автоматически, сомнительные обращения проверяет человек.
| Подход | Когда применять | Преимущество | Ограничение |
|---|---|---|---|
| Правила по словам и полям | Есть 8–12 устойчивых категорий и фиксированные формы | Легко объяснить решение, быстро изменить условие | Плохо работает с синонимами, опечатками и длинным контекстом |
| Нейросетевой классификатор | Формулировки клиентов сильно различаются | Учитывает смысл сообщения и соседние фразы | Может ошибиться на редком или двусмысленном запросе |
| Гибридная схема | Есть регламент, SLA и риск ошибочного маршрута | Правила закрывают очевидные случаи, модель разбирает вариативный текст | Нужно поддерживать справочник и набор тестовых примеров |
Я не советую начинать с полной автоматической передачи. Сначала фиксирую решение модели и решение оператора, не меняя очередь. Через 200–500 проверенных сообщений уже видны повторяющиеся ошибки: путаница между возвратом и отменой, неверная трактовка слова «срочно», потеря номера заказа в длинной переписке.
Для подготовки инструкции полезен разбор основ правильной формулировки запросов к нейросети. В классификации особенно полезны явные границы классов, 2–3 положительных примера и 2 отрицательных примера для каждой спорной категории.
Как измерить качество сортировки
Я измеряю качество по 4 показателям: точность категории, полнота обнаружения нужных обращений, точность назначения и соблюдение SLA. Одна общая цифра скрывает причину ошибки, поэтому её недостаточно.
Точность категории показывает долю верных решений среди всех автоматически классифицированных сообщений. Полнота отвечает на другой вопрос: сколько обращений нужного класса система вообще нашла. Если фильтр жалоб обнаружил 90 из 100 сообщений, полнота равна 90%, даже если часть найденных писем оказалась ошибочной.
Точность назначения измеряется отдельно. Модель может правильно определить «возврат», но передать письмо в отдел оплаты, если справочник ролей составлен неясно. Для контроля я записываю исходную категорию, предсказание, уверенность и итог оператора в одной таблице.
Для примера: из 300 проверенных обращений 240 можно оставить в автоматическом маршруте при точности 92%, а 60 отправить на ручной контроль. Это не готовая норма, а способ посчитать границу автономной работы. Если среди 60 сообщений много P1, порог уверенности нужно поднять, даже при высокой средней точности.
Проверять следует отдельные срезы: новые темы, короткие сообщения до 20 слов, письма с вложениями, смешение русского и профессиональных сокращений, повторные обращения. Минимальный тестовый набор я делю по каналам и классам, чтобы 1 крупная категория не замаскировала провал в редкой, но опасной очереди.
Как провести пилот без потери контроля
Пилот можно организовать за 10 рабочих дней, если заранее определить 8–12 категорий, 2 уровня ручной проверки и набор контрольных сообщений. Цель пилота, сравнить решения модели с решениями сотрудников, а не сразу убрать человека из процесса.
В первые 2 дня я собираю обезличенные примеры и объединяю дублирующиеся темы. На 3–4-й день описываю классы и приоритеты, затем готовлю тест из 100–300 сообщений. На 5–6-й день проверяю, одинаково ли модель понимает короткий вопрос, длинную переписку и сообщение с несколькими проблемами.
Вторую половину пилота лучше посвятить теневому режиму. Система предлагает категорию и маршрут, а сотрудник принимает решение по старому процессу. В журнале остаются 5 значений: исходный текст, прогноз, уверенность, решение человека и причина расхождения. Уже после 7–10 рабочих дней можно посчитать точность по каждому классу.
Для проверки инструкций я использую веб-чат SoftChat: в нём доступны потоковые ответы и переключение моделей в рамках разговора. Это удобно, когда нужно сравнить несколько вариантов формулировки одного задания и увидеть, где меняется классификация. Сам каталог SoftChat не заявляет почтовый шлюз, CRM-маршрутизацию или автоматическую передачу обращений сотрудникам, поэтому такие функции нельзя ему приписывать.
Практические сценарии внедрения лучше связывать с рабочим процессом, а не с отдельным экспериментом. Подход к этому описан в материале о внедрении нейросетей в рабочие процессы. Для бытовых потоков пригодится разбор применения нейросетей и чат-ботов в повседневных задачах, где хорошо видно, как отделять повторяемые операции от решений, требующих человека.
Какие ошибки чаще всего ломают маршрутизацию
Три ошибки встречаются чаще всего: слишком широкие категории, отсутствие порога уверенности и отсутствие обратной связи от операторов. Каждая из них проявляется в цифрах уже на первых 100–200 сообщениях.
Слишком широкая категория «вопрос по заказу» не помогает распределению. Её лучше разделить хотя бы на оплату, доставку, возврат и документы, если для них назначены разные сотрудники. Слишком мелкая классификация создаёт обратную проблему: 30 классов при 100 сообщениях дают мало примеров для каждого.
Отсутствие ручной границы приводит к тому, что сомнительное решение выглядит таким же надёжным, как очевидное. Явное правило «ниже 0,60, на проверку» делает риск видимым. Для P1 можно установить отдельный порог, например 0,90, если цена ошибки выше стоимости дополнительной проверки.
Без обратной связи справочник устаревает. Раз в неделю я просматриваю 20–50 расхождений, объединяю повторяющиеся причины и добавляю новые примеры. Если за месяц появляется 5 вариантов одной и той же ошибки, проблема обычно находится в описании категории, а не в количестве сообщений.
Что бы я сделал на вашем месте
Я начал бы с 10 рабочих дней, 8–12 категорий и теневого режима, а автоматическую передачу включил бы лишь после проверки 100–300 сообщений. Такой порядок сохраняет контроль над P1-обращениями и показывает, где правила требуют уточнения.
Затем я оставил бы человеку все случаи с низкой уверенностью, несколькими темами и отсутствующими идентификаторами. Для устойчивых категорий добавил бы правила по полям, для свободных формулировок применил бы нейросеть, а итог оценивал бы по точности каждого маршрута, а не по одной средней цифре. Если задача начинается с текстового прототипа, полезно свериться с материалом о создании структурированных текстов с помощью нейросетей.