Как автоматически классифицировать и маршрутизировать обращения клиентов

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

Клиент пишет в поддержку: «Не могу войти, завтра закрытие месяца». В одной короткой фразе спрятаны четыре решения: о каком продукте идёт речь, что сломалось, насколько срочна ситуация и какой команде передать диалог.

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

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

Коротко: как классифицировать и маршрутизировать обращения

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

Я бы не заставляла клиента расплачиваться за неопределённость системы.

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

Маршрутизация начинается не с модели, а с очередей

До выбора технологии полезно открыть журнал обращений за последние два–три месяца и посмотреть, что происходило с каждым диалогом после первого сообщения. Куда его назначили? Сколько раз переназначили? Где изменился приоритет? Какой информации не хватало оператору? Именно эти переходы показывают будущую логику маршрутизации.

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

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

Какие признаки действительно нужны

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

Категория описывает проблему, а не отдел

Для клиента здесь важно: в этом месте мне важна честная граница между AI и оператором.

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

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

Продукт задаёт контекст

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

Срочность нельзя выводить только из эмоций

Раздражённый тон не всегда означает высокий операционный риск, а спокойное письмо может описывать остановку критичного процесса. На приоритет должны влиять последствия: заблокирована ли работа, затронуты ли деньги или персональные данные, сколько пользователей пострадало, близок ли договорный срок. Тональность полезна для коммуникации, но опасна как единственный критерий SLA.

Подразделение — результат, а не исходная метка

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

Когда AI действует сам, а когда должен остановиться

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

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

Как я разделяю ответ, источник и действие

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

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

Разделение важно для диагностики. Если письмо попало не в ту очередь, команда должна ответить: потерялся ли контекст при приёме, неверно ли определён продукт, устарело ли правило владения или сбой произошёл уже при записи в CRM. Без такой трассировки все ошибки выглядят как «AI опять не понял».

Для событийных интеграций нужна идемпотентность: повторная доставка webhook не должна создавать второй тикет. Концепция трасс в OpenTelemetry помогает связать этапы обработки в одну наблюдаемую цепочку.

Контекст из базы знаний не даёт права действовать

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

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

Что показывает реальный кейс Koralplay

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

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

Где система ломается и как сделать ошибку безопасной

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

Модель уверена в неправильном решении. Такое случается с короткими или двусмысленными фразами. Одного confidence недостаточно: нужны пороги по классам, выборочная ручная проверка и мониторинг дорогостоящих ошибок.

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

В тексте есть инструкция для модели. Клиентское сообщение — недоверенный ввод. Оно не должно менять системные правила, раскрывать скрытые данные или инициировать внешнее действие. OWASP относит prompt injection к ключевым рискам приложений с языковыми моделями. Критичные действия проходят через детерминированные правила и явное разрешение.

Недоступна CRM. Сообщение сохраняется в очереди повторной доставки с исходным идентификатором; оператор видит деградацию и может продолжить работу вручную.

Метрики, которые показывают качество маршрута

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

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

План внедрения без «большого взрыва»

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

Как принять пилот

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

Где чаще всего нужна ясная граница

Нужна ли большая языковая модель?

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

Можно ли сразу подключить все каналы?

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

Что делать с несколькими темами в одном сообщении?

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

Как часто переобучать систему?

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

Можно ли автоматически отвечать после классификации?

Это отдельное решение. Правильная категория помогает найти инструкцию, но не гарантирует, что ответ безопасен и применим к конкретному клиенту. Генерация ответа требует собственной оценки источников, прав доступа и правил эскалации.

Источники и методика

Архитектурные и контрольные принципы сверены с документацией Microsoft и Google Cloud, профилем рисков NIST AI RMF, рекомендациями OWASP, документацией OpenTelemetry и официальным кейсом Koralplay. Универсальные числовые пороги намеренно не приводятся: их выбирают на данных конкретного процесса и с учётом цены ошибки.

В «Как автоматически классифицировать и маршрутизировать обращения клиентов» я оставляю простую границу: AI помогает, пока действительно понимает контекст. Когда уверенности не хватает, честная передача оператору лучше красивого ответа.