Нейросеть для сортировки обращений и черновиков ответов в 2026

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

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

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

Что происходит с входящим обращением

Нейросеть превращает одно обращение минимум в 5 рабочих полей: категорию, срочность, теги, извлечённые данные и черновик ответа. Такой результат удобнее передавать в CRM, таблицу или очередь оператора, чем исходный текст без структуры.

Последовательность выглядит так:

1. Очистка текста. Из письма убираются подпись, повторяющаяся цитата и технический шум. Для сообщения из мессенджера достаточно сохранить текст, дату и идентификатор диалога.
2. Извлечение признаков. Система ищет тему, номер заказа, дату, сумму, название услуги и признаки недовольства.
3. Классификация. Обращение получает один основной класс, например «оплата», «доставка», «техническая ошибка» или «претензия».
4. Оценка приоритета. Система проверяет сроки, слова срочности, блокирующие обстоятельства и заданные правила SLA.
5. Подготовка результата. Формируются теги, краткое резюме и черновик ответа с указанием, какие сведения ещё нужно уточнить.

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

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

Какие признаки нужны для классификации

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

1. Тема

Тема отвечает на вопрос, о чём обращение. Практичная иерархия содержит 5–10 верхних категорий, например оплату, доставку, возврат, доступ и техническую проблему. Слишком широкий класс «прочее» быстро превращается в склад неразобранных сообщений.

2. Намерение

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

3. Сущности

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

4. Сигналы срочности

Слова «сегодня», «до 15:00», «не могу войти» и «деньги списали дважды» имеют разный вес. Их нужно описывать в правилах отдельно, а не складывать в один список ключевых слов.

5. Контекст переписки

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

6. Тональность

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

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

Как выделять срочные обращения

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

Я использую четыре уровня, если поток небольшой:

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

Условный пример: если SLA на ответ равен 2 часам, а в сообщении указан срок до 15:00, в карточке нужно хранить оба значения, исходный текст и рассчитанное время до дедлайна. Так оператор видит причину приоритета, а не только красный маркер.

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

Как проектировать систему тегов

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

Теги должны отвечать на конкретные вопросы:

• что произошло;
• какое действие требуется;
• есть ли срок;
• нужен ли другой отдел;
• повторяется ли обращение.

Я бы ограничил начальную схему 20–30 тегами. Это не универсальная норма, а удобный диапазон для пилота: при 100 похожих обращениях легче увидеть дубли и пустые категории. Если сразу создать 80 тегов, операторы начнут выбирать разные варианты для одной и той же ситуации.

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

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

Как готовить черновик ответа

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

Пример структуры:

1. «Мы получили запрос о задержке доставки».
2. «В обращении указан заказ и дата, но не указан город получения».
3. «После проверки статуса можно сообщить новый срок».
4. «Уточните, пожалуйста, номер заказа, если он отличается от указанного в переписке».

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

Условный пример: в письме указаны сумма 4 900 рублей и номер заказа, но нет даты платежа. Корректный черновик просит дату или подтверждение операции. Некорректный вариант утверждает, что платёж уже проверен.

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

Правила, нейросеть или гибридный процесс

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

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

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

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

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

Для выборки из 100 сообщений удобно составить таблицу проверки:

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

Если из 20 действительно срочных обращений система нашла 18, полнота составила 90%. Если среди 25 помеченных срочными 5 оказались обычными, точность этой метки составила 80%. Эти показатели нужно считать отдельно по классам, потому что общий результат скрывает ошибки в редких категориях.

Я советую хранить причину решения рядом с меткой. Запись «приоритет высокий, потому что указан срок» проверяется быстрее, чем безымянный балл уверенности. Для спорных случаев можно задать порог: например, всё ниже 0,70 отправлять сотруднику без автоматического назначения отдела. Это рабочее правило для пилота, его нужно проверить на своих данных.

Как встроить процесс в рабочий день

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

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

Условный пример: при 300 входящих сообщениях в день можно сначала обрабатывать автоматически только 3 класса, а остальные оставлять в ручной очереди. Через 7 дней стоит сравнить распределение ошибок, количество исправленных тегов и среднее время реакции. Если одна категория даёт много ложных срабатываний, её правила нужно изменить, а не расширять список тегов.

Для команды полезен журнал изменений. В нём фиксируются дата, исходный класс, исправленный класс, причина правки и сотрудник. Через 2–4 недели такой журнал показывает, где инструкция непонятна, где не хватает категории и какие формулировки клиентов система регулярно путает.

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

Что делать с персональными данными

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

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

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

Что бы я сделал на вашем месте

Я бы начал с одного канала, 3–4 классов и 20–30 тегов, затем собрал выборку из 100 обезличенных обращений. На этой выборке команда вручную согласует правила срочности, формат причины и шаблон черновика.

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

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