Автоматизация сортировки писем: срочность и маршрутизация в 2026

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

Ручной разбор почты быстро становится узким местом: в одном ящике смешиваются вопросы клиентов, счета, претензии, запросы от сотрудников и рекламные сообщения. Оператор читает письмо, ищет контекст, выбирает получателя, копирует данные в рабочую систему и только потом начинает готовить ответ. При потоке в 100 сообщений в день даже 3 минуты на письмо превращаются в 5 часов первичной обработки.

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

Что должна делать автоматическая сортировка писем

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

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

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

Как описать письмо перед классификацией

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

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

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

Как выделять срочные запросы

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

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

Числовой порог уверенности, например 0,85, используйте как настройку для передачи без дополнительной классификации, а не как доказательство правильности. Если модель оценила письмо в 0,84, его можно отправить оператору на проверку. При высокой уверенности всё равно нужен контроль для P1, потому что ошибка в срочности дороже ошибки в рекламной категории.

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

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

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

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

Модель должна опираться на утверждённые источники: правила возврата, тарифы, график работы, список документов и шаблоны отдела. Если нужного факта нет в переданном контексте, безопаснее написать «требуется уточнение», чем придумать срок или сумму. Финансовые значения, номера договоров и юридические формулировки оператор проверяет вручную.

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

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

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

Как передавать письма по отделам

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

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

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

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

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

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

Возьмите 100 писем из обычного потока и разметьте их вручную до автоматизации. Затем сравните результат по четырём вопросам:

1. Сколько писем получили правильную категорию.
2. Сколько P1-сообщений дошли до ответственного без задержки.
3. Сколько черновиков оператор принял с небольшими правками.
4. Сколько обращений попало не в тот отдел.

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

Модельный кейс: интернет-магазин может в течение 2 недель проверять 20 писем в день, сравнивая автоматическую метку с решением старшего оператора. Если доля согласия растёт с 70% до 90%, это сигнал к расширению словаря, но не повод убрать человеческую проверку для P1. Такой пример показывает метод контроля, а не обещанный результат конкретного проекта.

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

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

Я бы запускал первую версию за 7 рабочих дней на одной очереди писем и 4 категориях, без автоматической отправки клиенту. В первый день собрал бы 100 сообщений и разметил их вручную. На второй описал бы поля, уровни P1–P3 и владельцев категорий. На третий подготовил бы инструкции для классификации и черновика.

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

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

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