Автоматическая классификация обращений: темы и отделы в 2026

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

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

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

Что именно классифицировать во входящих сообщениях

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

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

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

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

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

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

Как устроить процесс автоматической сортировки

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

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

Сообщение → очистка → тема и срочность → проверка уверенности → отдел

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

Как измерить качество классификации

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

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

Для примера: из 200 обращений 80 относятся к оплате, а система отправила в финансовый отдел 76 из них. Если 4 сообщения потерялись в другой категории, полнота по оплате составит 95%. Если система отправила туда 90 сообщений, из которых 14 оказались ошибочными, точность составит около 84,4%. Такой разбор полезнее общей оценки по всему потоку.

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

Контроль проводите в два периода. Сначала проверьте исторические сообщения, где уже есть правильные ответы сотрудников. Затем возьмите свежий поток за 5–7 рабочих дней. Так видно, не изменилась ли лексика после запуска новой услуги, рекламной кампании или изменения регламента.

Какой подход выбрать для разных объёмов

Для потока от 50 до 500 обращений в день я бы сравнил три подхода: правила, нейросетевую классификацию и смешанную схему с ручной проверкой.

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

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

Как составить инструкцию для нейросети

Хороший запрос фиксирует шесть элементов: задачу, список категорий, определения, формат, примеры и действие при сомнении.

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

Формат лучше сделать машинно читаемым. Например:

{
  «тема»: «оплата»,
  «срочность»: «высокая»,
  «отдел»: «финансы»,
  «уверенность»: 0.87,
  «причина»: «указана ошибка при списании»
}

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

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

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

Где автоматизация должна остановиться

Ручная проверка нужна минимум для 5–10% сообщений на старте, а для критических категорий её лучше сохранить при любом уровне уверенности.

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

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

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

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

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

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

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

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

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

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

Итоговый выбор для команды

Автоматическая классификация оправдана, когда поток содержит от 50 сообщений в день, категории повторяются, а сотрудники регулярно тратят время на первичную сортировку. Начинать следует с тем, срочности и отдела, затем добавить уверенность и журнал исправлений.

На вашем месте я бы взял 200 обезличенных обращений, разметил их вручную и проверил смешанную схему с порогом 0,85. Если точность по критическим категориям ниже 90%, автоматический маршрут оставил бы только для обычных запросов. Если доля ручной проверки превышает 30%, пересмотрел бы справочник и примеры, а не просто снизил порог.

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