Нейросеть для сортировки почты и подготовки ответов в 2026

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

Да, начать можно с четырёх полей: тема обращения, срочность, нужное действие и уверенность в результате. Не стоит поручать модели расплывчатую задачу «разберись с почтой», потому что разные сотрудники по-разному понимают слово «срочно».
Я задаю для каждого письма фиксированную структуру:
- Категория, например доставка, оплата, возврат, технический вопрос, коммерческий запрос или другое.
- Срочность, выраженная через срок ответа или риск для клиента.
- Следующий шаг, например запросить номер заказа, передать специалисту или подготовить расчёт.
- Краткое резюме в одной-двух фразах.
- Уверенность модели по шкале от 0 до 1.
- Признак нехватки данных.
Для первой проверки достаточно взять 100–200 обезличенных писем за 7 дней. В выборке должны быть короткие сообщения, длинные цепочки и обращения с опечатками. Иначе результат будет хорошо выглядеть на аккуратных письмах, но разрушится на реальной очереди.
Категории лучше ограничить пятью или шестью вариантами. Если создать 18 меток сразу, сотрудники начнут путать «возврат» с «претензией по оплате», а статистика станет трудноинтерпретируемой. Для поддержки полезно отдельно выделить «нужна проверка человеком», поскольку это рабочий выход, а не ошибка системы.
Похожую логику можно применить к другим повторяющимся задачам, о чём подробнее рассказывает материал о внедрении нейросетей в рабочие процессы. Сначала фиксируют действие и критерий результата, затем выбирают инструмент.
Как сформулировать запрос для разбора письма
Промпт должен описывать шесть элементов: роль, входной текст, допустимые категории, формат результата, критерий срочности и правила при нехватке данных. Такая схема уменьшает число свободных трактовок и облегчает последующую проверку.
Я использую инструкцию примерно такого вида:
Ты помощник оператора поддержки.
Проанализируй письмо и верни результат в полях:
категория, срочность, срок ответа, следующее действие,
краткое резюме, уверенность, недостающие данные.
Выбирай категорию только из списка:
доставка, оплата, возврат, технический вопрос,
коммерческий запрос, другое.
Считай обращение срочным, если клиент указал конкретный срок,
сообщил о блокировке оплаты или описал действующую проблему.
Не придумывай номер заказа, дату, сумму и обещание компании.
Если данных мало, напиши «нужна проверка человеком».
В поле срочности полезно требовать сразу два значения: уровень и основание. Формулировка «высокая, потому что клиент указал срок до 15:00» лучше, чем одно слово «срочно». Сотрудник видит логику и может быстро исправить неверный вывод.
Уверенность не равна точности, поэтому её используют как фильтр, а не как доказательство. В качестве стартового порога можно взять 0,8, а письма ниже этого значения направлять на ручной просмотр. После проверки 30–50 сообщений порог корректируют по фактической доле ошибок.
Пошаговые приёмы составления таких инструкций разобраны в статье о правильной формулировке запросов к нейросетям. Там же полезно посмотреть, как ограничивать формат ответа и запрещать выдуманные сведения.
Как определить, что обращение действительно срочное
Срочность лучше связывать с измеримым сроком, риском и договорённостью об обслуживании, а не с эмоциональными словами в письме. Для примера: сообщение «ответьте сегодня, платёж заблокирован» получает высокий приоритет по двум признакам, а фраза «очень жду» сама по себе ещё ничего не доказывает.
Я разделяю обращения на четыре уровня:
- критический, когда остановлена оплата, доступ к сервису или отгрузка;
- высокий, когда клиент назвал срок до конца рабочего дня или сообщил о повторной проблеме;
- обычный, когда вопрос можно закрыть в стандартное окно поддержки;
- низкий, когда это предложение, благодарность, общий вопрос или запрос без срока.
Для каждого уровня нужен внутренний норматив. Если команда отвечает на критические письма за 15 минут, а на обычные за 4 часа, эти значения следует прямо внести в инструкцию. Нейросеть не должна угадывать правила компании по интонации сообщения.
Приоритет стоит проверять по исходному фрагменту письма. В резюме модель может потерять дату, сумму или отрицание. Например, «не нужно отменять заказ» и «нужно отменить заказ» отличаются одним словом, но требуют противоположных действий. Поэтому вместе с меткой я прошу вернуть короткую цитату основания, без полного копирования переписки.
Какой способ обработки выбрать
Для первого запуска есть три подхода, и различаются они объёмом ручной работы, гибкостью и риском ошибок. Выбор зависит от того, повторяются ли формулировки и сколько писем проходит через очередь за смену.
| Подход | Когда подходит | Преимущество | Ограничение |
|---|---|---|---|
| Правила по словам и отправителям | Есть устойчивые шаблоны, 4–6 категорий | Легко объяснить результат | Плохо работает с опечатками, контекстом и отрицаниями |
| Нейросеть для первичного разбора | Формулировки сильно различаются | Учитывает смысл письма и цепочку аргументов | Требует выборки для проверки и понятной инструкции |
| Связка правил и нейросети | Нужно отсечь очевидные случаи до анализа | Простые письма обрабатываются быстро, спорные уходят человеку | Нужно поддерживать два набора условий |
Я обычно начинаю со связки. Правило может найти тему «счёт» или наличие номера заказа, а нейросеть разберёт смысл, если клиент пишет свободным языком. При конфликте условий приоритет получает ручная проверка.
Эта схема близка к принципу «сначала отбор, затем объяснение». Она пригодна для поддержки, продаж и внутренних заявок, однако конкретные категории нужно проверять на своей переписке. Обзор нейросети для генерации текста и проверки результата помогает выстроить контроль над черновиками, а не просто получать гладкие формулировки.
Как получать черновик ответа без выдуманных обещаний
Черновик должен содержать пять частей: обращение, подтверждение сути вопроса, известный факт, следующий шаг и место для проверки. Модель не должна самостоятельно добавлять скидку, дату доставки или компенсацию, если этих данных нет во входном письме.
Для примера: если клиент спрашивает о задержке заказа, безопасный черновик может признать проблему, попросить номер заказа и оставить срок пустым до проверки в рабочей системе. Такой текст полезнее уверенного ответа с придуманной датой.
В отдельной инструкции я задаю ограничения:
- использовать только сведения из письма и переданного справочного блока;
- не сообщать сумму, срок или статус без явного подтверждения;
- помечать пропуски квадратными скобками, например [проверить дату доставки];
- не писать, что вопрос решён, если в исходных данных нет такого факта;
- завершать текст одним понятным следующим действием.
Для продаж добавляется поле «цель контакта». Это может быть запрос цены, уточнение условий или повторное обращение после предложения. Поле помогает оператору понять, нужен ли короткий ответ, расчёт или передача менеджеру. Саму коммерческую информацию всё равно проверяют по актуальным данным компании.
Сотруднику удобнее редактировать черновик, когда сначала показано резюме, затем основания классификации и после этого текст ответа. Обратная последовательность создаёт ложное ощущение готовности: гладкая фраза появляется раньше, чем проверены факты.
Как проверить качество и посчитать пользу
Качество оценивают минимум по трём показателям: точность категории, доля верно найденных срочных писем и процент черновиков, которые оператор отправил после небольшой правки. Для стартовой проверки я беру 30–50 сообщений на каждую крупную категорию и сравниваю вывод модели с разметкой сотрудника.
Разметку лучше проводить до просмотра ответа нейросети. Иначе оператор начнёт подстраиваться под убедительную формулировку и незаметно примет ошибку за правильный вариант. В таблице проверки достаточно хранить идентификатор письма, эталонную категорию, вывод модели, решение сотрудника и тип ошибки.
Полезно разделять ошибки по последствиям. Пропуск срочного обращения опаснее, чем неверная метка «доставка» вместо «оплата», если оба письма всё равно попадают к одному оператору. Для этого вводят взвешенную оценку: критической ошибке назначают вес 5, обычной ошибке вес 1. Так среднее число не скрывает риск.
Время тоже нужно считать аккуратно. Измеряйте медиану обработки одного письма, количество исправлений в черновике и долю сообщений, отправленных на ручную проверку. Сравнение проводят на сопоставимых неделях, например при 100 письмах в каждой выборке и одинаковом составе смены.
Модельный кейс: для очереди из 200 писем команда может сначала проверить 40 сообщений вручную, затем прогнать остальные по одной инструкции и отдельно пересмотреть все письма с уверенностью ниже 0,8. Это демонстрация метода, а не обещание конкретной экономии времени или точности.
Результат фиксируют в журнале версий. Если изменились категории, порог срочности или шаблон ответа, рядом записывают дату и причину. Через 2–4 недели становится видно, какая правка действительно снизила число исправлений, а какая лишь увеличила объём ручного контроля.
Как использовать SoftChat для проверки рабочего сценария
SoftChat можно использовать как веб-чат для проверки формулировок и вариантов черновика, а не как заявленный почтовый модуль. В каталоге продукта указаны потоковые ответы и возможность переключать модели в рамках разговора, поэтому я могу последовательно проверить один обезличенный запрос в нескольких вариантах диалога.
Перед отправкой текста я удаляю адреса, имена, номера заказов, телефоны и платёжные данные. Вместо них оставляю нейтральные маркеры: [имя], [номер заказа], [дата]. Это сохраняет структуру письма и уменьшает риск раскрытия персональной информации.
Рабочий порядок выглядит так:
- Взять 10–20 обезличенных сообщений из одной категории.
- Отправить их с одинаковой инструкцией и записать результаты.
- Переключить модель в рамках диалога и проверить, меняются ли категории, сроки и предупреждения о нехватке данных.
- Сопоставить ответы с разметкой сотрудника.
- Оставить шаблон, который проще проверять, а не тот, что звучит эффектнее.
Потоковый ответ удобен для коротких итераций: видно, как формируется результат, и можно быстрее заметить, что инструкция задана неудачно. При этом проверка писем, запись меток в очередь и отправка готового ответа остаются отдельными действиями вашей рабочей системы. Я не называю их возможностями SoftChat, потому что в каталоге описан веб-чат, а не интеграция с почтовым ящиком.
Для бытовых и рабочих повторяющихся задач пригодятся идеи из материала о применении нейросетей и чат-ботов в повседневной работе. Его подход полезен при выборе небольшого сценария для первого теста.
Как перевести проверенный шаблон в рабочий процесс
Запуск лучше разделить на два контура: тестовый и операционный. В тестовом контуре проверяют 30–50 писем на категорию, а в рабочем сначала оставляют сотруднику право подтвердить каждую срочную метку и каждый внешний ответ.
На первой неделе я советую собирать четыре вида обратной связи: неверная категория, пропущенная срочность, выдуманный факт и слишком большой объём правок. Эти причины дают больше пользы, чем общая оценка «ответ хороший».
После 7 дней можно принять решение по правилам. Если модель часто путает две категории, их временно объединяют. Если она уверенно ошибается в одном типе писем, для него вводят обязательную проверку человеком. Если черновики требуют переписывания половины текста, меняют структуру запроса и добавляют исходные факты, а не просто повышают объём инструкции.
Я бы не начинал с автоматического ответа клиентам. Сначала оставил бы нейросети сортировку, резюме и черновик, затем проверил бы 100–200 сообщений на стабильность. Только после этого можно обсуждать более глубокую автоматизацию в тех системах, где она действительно поддерживается.
Как я принимаю решение после обновления статьи
Для первой итерации я выбираю один тип писем, 4–6 категорий и 7 дней наблюдения. Этого достаточно, чтобы увидеть частые ошибки, не смешивая поддержку, продажи и внутренние запросы в одну статистику.
Если письма однотипны, начинайте с правил. Если формулировки разнообразны, добавляйте нейросетевой разбор, но оставляйте порог уверенности и ручную проверку. Если нужен черновик, требуйте ссылку на исходные факты и явную отметку пропусков.
Мой рабочий критерий простой: технология должна сокращать повторяющиеся действия, не скрывая место, где человек принимает решение. Когда у каждой метки есть определение, у каждого черновика есть проверяемое основание, а у каждой ошибки есть категория, сортировка почты превращается из субъективной рутины в управляемый процесс.