Автоматическая сортировка писем и черновики ответов в 2026

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

Автоматизировать разумно четыре операции: выделение темы, определение срочности, извлечение фактов и подготовку черновика ответа. Финальное решение по спорным, финансовым и юридическим письмам оставляют сотруднику.
Сначала задайте фиксированную схему классификации. Для поддержки подойдут категории «ошибка», «вопрос по продукту», «оплата», «возврат» и «жалоба». Для продаж набор будет другим: «новый запрос», «повторный контакт», «действующий клиент», «партнёрство» и «нецелевое обращение».
Одного ярлыка мало. В структурированном результате полезно хранить семь полей:
- категорию письма;
- уровень срочности;
- краткую тему в одной фразе;
- имена, даты, номера заказов и суммы, если они есть;
- недостающие сведения;
- черновик ответа;
- причину, по которой выбран такой класс.
Последнее поле нужно для проверки. Если система пометила письмо как срочное, сотрудник должен увидеть основание, например упоминание остановки поставки или установленного срока ответа. Голая метка «высокий приоритет» плохо помогает при разборе ошибок.
Пример классификатора можно описать так: письмо о списании денег без понятного результата относится к оплате, сообщение о повторяющейся неисправности получает высокий приоритет, а просьба прислать презентацию попадает в продажи. Подобные правила лучше формулировать короткими абзацами, без пяти взаимоисключающих инструкций в одном пункте. Практика составления запросов разобрана в материале о точной формулировке запросов для нейросетей.
Как устроить конвейер обработки
Рабочий конвейер состоит из пяти шагов: подготовка текста, классификация, проверка срочности, генерация черновика и передача результата сотруднику.
На первом шаге уберите технический шум. В модель можно передавать тему письма, основной текст, дату получения, сведения об отправителе и доступные метаданные цепочки. Подпись, повторяющиеся цитаты и служебные заголовки лучше отделить. Вложения следует обозначать явно, например «файл приложен», если их содержимое не извлекается автоматически.
На втором шаге нейросеть возвращает категорию и краткое объяснение. Формат лучше сделать предсказуемым, например в виде JSON с ключами category, priority, facts, missing_data и draft. Так проще передавать результат в таблицу, очередь обращений или внутренний интерфейс.
На третьем шаге срабатывают правила риска. Письмо с банковскими реквизитами, угрозой претензии, упоминанием простоя или повторным обращением без ответа нельзя отправлять клиенту автоматически. Для таких сообщений допустим черновик, но рядом должна появляться пометка о ручной проверке.
На четвёртом шаге система готовит ответ. Она должна опираться на текст письма и утверждённые материалы, а неизвестные сведения помечать как вопросы. Запрет на выдумывание цены, срока доставки, статуса заказа и обещаний руководителя нужно прописать прямо.
На пятом шаге сотрудник принимает решение: отправить черновик после правки, переписать его или вернуть на повторную классификацию. Если человек исправил категорию, полезно сохранить исходный и исправленный вариант. Через 30, 50 или 100 проверенных писем команда увидит, где правило создаёт путаницу.
Веб-чат SoftChat поддерживает потоковую выдачу ответов и переключение моделей для разговора. Я использую такой интерфейс, когда нужно быстро уточнить формулировку правила или посмотреть, как меняется структура ответа при выборе другой модели. Обработку реального почтового потока при этом следует строить отдельным процессом, а не приписывать её самому чату.
Как выделять срочные обращения
Срочность лучше определять двумя слоями: по явным словам и по смыслу письма. Например, срок «до 16:00» является сильным сигналом, но отсутствие такой даты не означает, что обращение можно отложить.
Первый слой содержит проверяемые признаки:
- дата или время, к которым нужен ответ;
- остановка работы, срыв поставки или блокировка доступа;
- повторное обращение после отсутствия реакции;
- спор по оплате или возврату;
- ссылка на претензию, договорное обязательство или регламент.
Второй слой оценивает контекст. Фраза «не могу войти» может быть обычным вопросом, а может описывать блокировку рабочего места у всей команды. Поэтому классификатор должен извлекать число затронутых пользователей, длительность проблемы и наличие уже выполненных действий.
Практично использовать три уровня. «Высокий» означает реакцию в течение рабочего часа или по внутреннему регламенту. «Средний» требует ответа в тот же рабочий день. «Обычный» можно включать в плановую очередь. Это не универсальный норматив, а стартовая настройка, которую нужно связать с реальным соглашением об уровне сервиса.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 100 писем за рабочий день. Для пилота команда размечает 30 сообщений вручную, выделяет 5 причин срочности и проверяет, сколько обращений каждого типа попало в правильную очередь. Такая выборка не доказывает качество на всех письмах, зато быстро показывает, какие признаки надо уточнить.
Не просите модель угадывать приоритет без объяснения. Пусть она возвращает два значения: уровень и основания. Если основания противоречат уровню, письмо отправляется на ручной просмотр.
Как собирать черновик ответа
Хороший черновик собирается из четырёх блоков: подтверждение сути, ответ на известную часть, запрос недостающих данных и следующий шаг.
Первое предложение должно показать, что обращение прочитано. Вместо общего «мы получили ваше письмо» лучше кратко повторить предмет: «Вы сообщаете о повторном списании по заказу и просите проверить возврат». Такое резюме помогает сотруднику заметить ошибку до отправки.
Затем модель отвечает только на подтверждённые вопросы. Если в базе нет данных о конкретном заказе, нельзя создавать номер обращения, дату возврата или обещание компенсации. Корректная формулировка звучит проще: «Чтобы проверить операцию, пришлите номер заказа и дату списания».
Запрос недостающих сведений должен быть коротким. Для обращения об оплате может понадобиться 3 поля: номер заказа, дата операции и последние 4 цифры карты. Полный номер карты, пароль и код из сообщения передавать в черновик нельзя.
Финальный блок описывает следующий шаг без необоснованного обещания. Если срок зависит от проверки бухгалтерии, так и напишите: «После получения данных передадим запрос на проверку». Приоритет и тон ответа должны соответствовать категории. Жалоба требует спокойной конкретики, коммерческий запрос, ясного описания дальнейшего контакта.
Я советую задавать модели ограничение по объёму, например 120–180 слов для обычного ответа. Для сложной претензии лимит можно снять, но структуру всё равно сохранить. Результат должен быть черновиком, а не самостоятельным решением.
Материалы о том, как встроить нейросеть в повторяющиеся операции, собраны в статье о внедрении нейросетей в рабочие процессы. Для офисных задач полезен тот же принцип: сначала описывается маршрут письма, затем выбирается место для автоматизации.
Как проверять качество и риски
Качество оценивают минимум по четырём показателям: точность категории, полнота обнаружения срочных писем, доля принятых черновиков и среднее время правки.
Точность категории считают так: число правильно размеченных писем делят на объём проверенной выборки. Для срочности важнее полнота, то есть доля действительно важных обращений, которые система не пропустила. Эти показатели нельзя смешивать. Модель может часто выбирать один класс и показывать приличную точность на перекошенной выборке, но пропускать жалобы и платежные проблемы.
Для пилота подготовьте минимум 50 писем из разных дней и типов обращений. Разделите их на обучающую и контрольную части, например 35 и 15 сообщений. В контрольной части сотрудник заранее фиксирует правильные категории, приоритет и обязательные факты, а затем сравнивает их с результатом модели.
Отдельно проверьте четыре вида ошибок:
- выдуманный факт, которого нет в письме;
- потеря суммы, даты или номера заказа;
- неверный приоритет из-за эмоциональной формулировки;
- слишком уверенное обещание результата.
Перед передачей данных удаляйте пароли, токены, полные платёжные реквизиты и документы, которые не нужны для ответа. Если письмо содержит персональные данные, определите, какие поля действительно требуются для классификации. Сокращённый текст часто даёт достаточно контекста для выбора очереди.
Для отслеживания эффекта хватит простой таблицы с датой, категорией, уровнем срочности, решением сотрудника и временем правки. Через 2 недели в ней появятся повторяющиеся причины ошибок. На их основании обновляют инструкцию, а не пытаются решить каждую проблему новым длинным запросом.
Что выбрать для разных потоков
Выбор схемы зависит от объёма писем и цены ошибки: для 20 обращений в день достаточно подсказок, для 100 и более нужен формализованный конвейер с очередью проверки.
| Подход | Подходящий объём | Плюс | Ограничение |
|---|---|---|---|
| Ручной разбор по шаблону | до 20 писем в день | легко начать без настройки | результат зависит от конкретного сотрудника |
| Классификация и черновик | 20–100 писем в день | сокращает повторяющееся чтение и набор текста | нужен контроль фактов перед отправкой |
| Очередь с приоритетами и метриками | свыше 100 писем в день | видны пропуски, задержки и причины ошибок | потребуется разметка выборки и регулярный пересмотр правил |
Модельный кейс: отдел продаж с 60 входящими письмами в день может начать с 6 категорий и ручного подтверждения каждого черновика. Если через 2 недели выяснится, что 2 категории постоянно смешиваются, их лучше переименовать или разделить по одному ясному признаку.
Малому офису не нужен сложный маршрут для каждого сообщения. Достаточно выделить оплату, документы, срочные вопросы и обычные запросы. Поддержке с большим числом повторяющихся обращений полезнее вложиться в словарь терминов, примеры правильных ответов и контроль пропущенных срочных писем.
Для повседневной работы с нейросетями полезно заранее определить границы: какие действия разрешены, какие данные скрываются и в какой момент нужен человек. Практические сценарии такой работы описаны в материале о применении нейросетей и чат-ботов в повседневных задачах.
Заключение
Для старта достаточно одной очереди, 4–6 категорий и выборки из 50 писем. Я бы сначала настроил классификацию и обнаружение срочности, затем добавил черновики ответов с обязательной проверкой сотрудником.
Рабочая схема видна по цифрам: сколько писем попало в правильную категорию, сколько срочных обращений обнаружено, сколько черновиков принято после правки и сколько минут занимает проверка. Если эти показатели не записывать, автоматизация быстро превращается в ощущение экономии без доказанного результата. Если записывать, правила можно улучшать постепенно, сохраняя смысл переписки и контроль над решениями.