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

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

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

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

Путь обращения от входящего сообщения до ответственногоЧетыре этапа классификации обращения: входящее сообщение, определение темы, оценка срочности и назначение ответственного.Маршрут обращенияСначала смысл, затем приоритет и ответственныйВходящиеПисьмо или заявкас исходным контекстомТемаКатегория и намерениеотправителяПриоритетСрочный, обычныйили ручная проверкаМаршрутРольсотрудника
Инфографика

Что именно нужно классифицировать

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

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

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

Третье поле показывает стадию работы. Письмо может быть новым, ожидающим ответа, переданным специалисту или готовым к закрытию. Четвёртое поле связывает категорию с ролью, например с менеджером продаж, специалистом поддержки или сотрудником административного отдела.

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

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

Как подготовить данные и правила

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

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

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

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

Хороший запрос к нейросети содержит 6 частей:

  1. роль, например оператор первой линии;
  2. список допустимых категорий;
  3. критерии срочности;
  4. формат результата;
  5. правило для сомнений;
  6. 2–3 коротких образца.

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

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

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

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

Рабочий стол с визуальной сортировкой обращений по срочности

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

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

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

Удобная схема выглядит так:

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

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

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

Что выбрать: ручную сортировку, правила или нейросеть

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

Подход Подходит для Преимущество Ограничение
Ручная сортировка Небольшого потока и сложных исключений Сотрудник видит весь контекст Результат зависит от внимания и загрузки человека
Жёсткие правила Повторяемых слов и стабильных форм Легко объяснить причину решения Плохо обрабатывает новые формулировки
Нейросеть с проверкой Разных формулировок и нескольких классов Учитывает смысл сообщения Нужны примеры, контроль и маршрут для сомнений
Смешанная схема Потока с разной ценой ошибки Простые случаи идут быстро, спорные проверяет человек Требуется поддерживать правила и выборку

Таблица показывает, почему вопрос «какая модель лучше» задан не полностью. Сначала определите требование к результату. Для юридически чувствительных писем важнее объяснимость и ручное подтверждение. Для типовых запросов статуса важнее скорость и стабильный формат.

В SoftChat можно работать в режиме чата, переключать модели в рамках разговора и получать ответ потоково. Я бы использовал это окно для подготовки и сравнения инструкций, а не как замену системе учёта обращений. Один и тот же набор из 10–20 примеров помогает увидеть, меняется ли разметка после правки запроса.

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

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

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

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

Модельный кейс: на выборке из 200 обращений проверяющий человек заранее отметил 25 срочных случаев. Нейросеть нашла 22, но 4 из них оказались ложными. Тогда полнота составила 88 процентов, а точность, 18 верных случаев из 22, примерно 82 процента. Такие расчёты показывают, где именно требуется настройка.

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

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

Проверяйте выборку после каждого заметного изменения правил. Для небольшого пилота достаточно повторять проверку раз в 1–2 недели, а при активном изменении процессов лучше смотреть ошибки ежедневно. Отдельно храните новые формулировки, которые не встречались в первоначальных примерах.

Как провести запуск без перегрузки команды

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

В теневом режиме сравните решения человека и модели на 50–100 обращениях. Разберите каждое расхождение, особенно по срочности и ответственному отделу. Если причина непонятна, измените описание категории, а не пытайтесь компенсировать слабое правило дополнительными общими словами.

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

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

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

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

Мой рабочий вывод

Если бы я запускал такой процесс для команды из 6–10 человек, я начал бы с 5 категорий и 2 уровней срочности, а через 2 недели проверил бы 100 последних обращений. Это даёт короткий цикл обратной связи и не заставляет отдел сразу перестраивать всю работу.

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