Сортировка писем нейросетью: срочность и ответы в 2026
Практическая схема для менеджеров: как разобрать поток обращений, выделить срочные запросы и подготовить черновики ответов без потери контроля.
Поток писем становится управляемым, когда каждое обращение проходит через понятные этапы: выделение признаков, определение намерения, назначение приоритета и подготовка следующего действия. Нейросеть не должна принимать решения вслепую. Ей нужны категории, примеры, правила эскалации и проверка результата человеком.
Если менеджер тратит 2 минуты на одно письмо, разбор 200 обращений занимает 400 минут, или 6 часов 40 минут. Автоматизация предварительного анализа сокращает объём механической работы, но ответственность за спорные случаи и обещания клиенту должна оставаться у сотрудника.
Что именно должна делать нейросеть с письмом?
Нейросеть должна выполнить 4 операции: определить тему обращения, найти признаки срочности, выделить намерение клиента и подготовить черновик следующего ответа. Такой порядок снижает риск, что красивый текст будет создан для письма, которое сначала требовало срочной передачи руководителю.
Я разделяю обработку на отдельные поля:
- Тема. Оплата, доставка, возврат, техническая проблема, консультация или другое обращение.
- Намерение. Вопрос, жалоба, просьба о расчёте, отмена заказа, уточнение статуса, запрос документов.
- Срочность. Признаки остановки работы, финансового риска, претензии с дедлайном или повторного обращения.
- Следующий шаг. Ответить по шаблону, запросить данные, передать специалисту или поставить задачу на контроль.
Вместо просьбы «разбери письмо» я задаю модели формат результата. Это соответствует базовому принципу из материала об искусстве формулировать запросы для нейросетей: заранее определённые поля делают ответ проверяемым.
Пример формата:
Тема: одно значение из списка категорий.
Намерение: одно значение из списка намерений.
Приоритет: P1, P2 или P3.
Основание приоритета: до 2 фактов из письма.
Нужные данные: что необходимо запросить у клиента.
Черновик ответа: до 100 слов, без обещаний, которых нет в исходных данных.
Последняя строка особенно полезна. Модель может уверенно дописать срок, скидку или техническую причину, которых в письме не было. Ограничение на неподтверждённые обещания помогает обнаружить такую ошибку до отправки.
Как настроить категории и приоритеты?
Начните с 5–7 категорий и 3 уровней срочности, иначе менеджеру придётся исправлять классификацию чаще, чем читать письмо. Категории должны отражать реальную работу очереди, а не всю терминологию компании.
Для стартовой схемы подойдут такие группы:
- вопрос по оплате;
- доставка или статус заказа;
- возврат и отмена;
- техническая неисправность;
- претензия;
- запрос коммерческого предложения;
- прочее.
Уровни приоритета лучше связывать с действием и сроком. Например, P1 означает передачу ответственному сотруднику в течение 15 минут, P2 требует ответа в течение 60 минут, P3 можно обработать в обычной очереди до 240 минут. Это рабочие ориентиры, а не универсальный норматив. Их нужно сверить с вашим соглашением об уровне сервиса.
Я не смешиваю категорию и срочность. Письмо о возврате может быть P3, если клиент спокойно просит инструкцию. Техническая проблема может стать P1, если из текста понятно, что остановилась оплата или работа нескольких сотрудников.
Для каждой категории стоит дать модели 3–5 размеченных примеров. В примерах должны быть короткое письмо, правильная категория, приоритет и объяснение решения. При 7 категориях это даёт от 21 до 35 примеров для первого набора. Затем спорные письма добавляются в отдельный список, а не смешиваются с исходными примерами без проверки.
Как определять срочность без ложных тревог?
Для оценки срочности достаточно 3 групп сигналов: риск для денег, остановка процесса и явный срок со стороны клиента. Эмоциональный тон сам по себе не должен повышать приоритет с P3 до P1.
Я прошу модель искать конкретные признаки:
- упоминание списания, блокировки оплаты или финансового ущерба;
- слова о невозможности продолжить работу;
- дедлайн с датой или временем;
- повторное обращение после отсутствия ответа;
- требование передать вопрос руководителю;
- ссылка на уже нарушенный срок.
Проверка должна включать цитату или краткий пересказ основания. Если модель пишет только «клиент недоволен», этого недостаточно для P1. Менеджер должен увидеть, какое обстоятельство повлияло на решение.
Модельный кейс: компания из сферы логистики получает 200 писем в день. В правилах обработки указано, что сообщение с фразой «машина не приехала к 18:00» получает P1, а просьба «уточните дату доставки» получает P2. Модель классифицирует оба письма по теме доставки, но назначает разные сроки реакции из-за конкретного дедлайна.
Полезно добавить статус «нужна проверка». Он применяется, если в письме есть конфликтующие даты, неполный номер заказа, угроза претензии или просьба, которую нельзя закрыть шаблонным ответом. Лучше отправить 12% писем на ручную проверку, чем автоматически ошибиться в нескольких дорогих или юридически чувствительных обращениях.
Как готовить черновик ответа?
Хороший черновик состоит из 6 элементов: обращения, подтверждения сути вопроса, известного факта, следующего шага, запроса недостающих данных и нейтрального завершения. Его задача не заменить менеджера, а убрать повторяющиеся фразы и сохранить контекст.
Я задаю модели следующие ограничения:
- не выдумывать наличие товара, сроки и компенсации;
- не ссылаться на внутренние инструкции, которых нет в переданных данных;
- не использовать категоричные обещания;
- задавать максимум 2 уточняющих вопроса;
- укладываться в 80–100 слов для стандартного ответа;
- отдельно указывать места, которые должен проверить менеджер.
Промпт может выглядеть так:
Ты готовишь черновик ответа менеджеру.
Используй только сведения из письма и блока правил.
Сначала укажи намерение, приоритет и недостающие данные.
Затем напиши ответ до 100 слов.
Не придумывай сроки, цены, наличие и компенсации.
Если данных недостаточно, напиши: «Нужна ручная проверка».
Перед отправкой я проверяю три вещи: совпадает ли ответ с намерением, не появились ли новые факты и понятен ли следующий шаг для клиента. Подробный разбор таких сценариев есть в статье о нейросети для генерации текста и проверке результата.
В веб-чате SoftChat можно переключать модели для конкретной беседы, а ответы поступают потоково. Это удобно для ручного сравнения нескольких вариантов инструкции на одинаковом наборе писем. Я сохраняю удачный шаблон отдельно и не считаю один удачный ответ доказательством качества всей схемы.
Как проверить качество перед запуском?
Проверьте минимум 100 писем, а для потока с 5–7 категориями лучше собрать 200 примеров с ручной разметкой. Одной оценки «ответ выглядит правдоподобно» мало: нужны отдельные показатели для категории, приоритета и черновика.
Я использую четыре измерения:
- Точность категории. Доля писем, которым назначена правильная тема.
- Полнота поиска срочных обращений. Сколько реальных P1 модель обнаружила среди всех P1.
- Доля ложных тревог. Сколько обычных писем ошибочно попало в срочную очередь.
- Приемлемость черновика. Процент текстов, которые менеджер может отправить после небольшой правки.
Для срочных обращений полнота обычно важнее внешней краткости ответа. Если из 20 размеченных P1 система нашла 19, полнота равна 95%. Если при этом она отправила в срочную очередь 8 обычных писем, нужно отдельно оценить нагрузку на менеджеров.
Тестовый набор разделите на две части. На первой уточняйте категории и инструкции, вторую не меняйте до окончания проверки. Если использовать один и тот же набор для настройки и оценки, результат будет выглядеть лучше реальной работы.
Проверяйте ошибки по типам. Например, отдельно соберите пропущенные дедлайны, перепутанные возвраты и оплату, лишние обещания, неверно распознанные повторные письма. Таблица ошибок полезнее единого среднего процента, потому что показывает, где именно ломается процесс.
Как встроить обработку в рабочий процесс?
Рабочий контур лучше разделить на 2 очереди: обычную и требующую ручной проверки. Сначала нейросеть создаёт разметку и черновик, затем менеджер подтверждает приоритет, исправляет факты и решает, отправлять ли сообщение.
| Этап | Что получает менеджер | Рекомендуемый срок | Контрольный вопрос |
|---|---|---|---|
| Первичный разбор | Категория, намерение, приоритет | до 1 минуты | Правильно ли понята задача клиента? |
| Срочная очередь | Основание P1 и черновик | до 15 минут | Есть ли риск денег или остановки процесса? |
| Обычная очередь | Черновик и список вопросов | до 60 минут | Хватает ли данных для ответа? |
| Контроль качества | Исправленное письмо и причина правки | 1 раз в день | Какая ошибка повторяется чаще всего? |
| Обновление правил | Новые примеры и уточнённые условия | 1 раз в неделю | Нужно ли изменить категорию или порог? |
Поток удобно запускать по расписанию, например 4 раза в час для срочной очереди и 1 раз в час для обычной. Частота зависит от объёма и SLA. При 30 письмах в час задержка в 15 минут означает, что в очереди может накопиться около 7–8 обращений, поэтому один общий список без приоритетов быстро создаёт узкое место.
В статье о внедрении нейросетей в рабочие процессы хорошо описан принцип постепенного запуска. Я применяю его к входящим письмам: сначала ручное подтверждение каждого результата, затем выборочная проверка стабильных категорий, после этого расширение охвата.
Как снизить риски для данных и клиентов?
Безопасная схема требует 4 правил: минимизировать передаваемые сведения, маскировать лишние персональные данные, разделять черновик и отправку, хранить журнал исправлений. Эти меры не зависят от конкретной нейросети.
Из письма можно убрать номер карты, паспортные данные, полный адрес и внутренние токены, если они не нужны для классификации. Для определения темы обычно достаточно текста запроса, даты, типа продукта и обезличенного идентификатора заказа. Если менеджеру нужен исходный номер, его можно вернуть на этапе работы во внутренней системе, не включая в текст для анализа.
Не разрешайте модели самостоятельно отправлять письмо без отдельного подтверждения. В черновике должна быть видна граница между фактами из сообщения и предложенной формулировкой. Для претензий, возвратов, юридических угроз и финансовых вопросов я оставляю обязательную ручную проверку.
Журнал исправлений помогает понять, что менять в инструкции. Если за неделю менеджеры 18 раз исправили сроки доставки и 11 раз меняли приоритет возвратов, эти случаи нужно превратить в новые примеры. Такой подход связывает качество текста с конкретными редакторскими действиями.
Для небольших команд полезно начать с одной повторяющейся категории. Например, сначала разобрать запросы о статусе заказа, где обычно нужны дата, номер заказа и следующий шаг. После 2 недель проверки можно добавить оплату или возвраты. Материал о повседневных задачах для нейросетей и чат-ботов помогает оценить, какие операции проще всего перенести в такой порядок.
Как оценить экономию времени?
Оценку начинайте с арифметики одного письма: исходное время обработки умножьте на объём, затем отдельно посчитайте проверку черновика и ручную работу со спорными случаями. Не подставляйте обещанный процент экономии без измерения до запуска.
Модельный кейс: при 200 письмах в день и исходных 2 минутах на каждое команда тратит 400 минут. Если после предварительной сортировки менеджер проверяет стандартный черновик за 45 секунд, 150 минут уходят на проверку 200 сообщений. Разница составляет 250 минут, или 4 часа 10 минут, но этот расчёт не учитывает P1, сложные обращения и повторное редактирование.
Поэтому я фиксирую базовую линию за 5 рабочих дней. Записываю число писем, медианное время до первого ответа, долю срочных обращений, количество исправлений и число пропущенных P1. Через 2 недели сравниваю те же показатели. Медиана полезнее среднего значения: одно письмо с 3 часами ручной работы не должно скрывать типичную обработку простых запросов.
Как я бы принял решение о запуске?
Я бы запускал сортировку, если 3 условия уже выполнены: есть минимум 100 размеченных писем, определены сроки P1–P3 и менеджер согласен проверять черновики. Без этих условий нейросеть лишь ускорит неясный процесс.
Первый этап занимает одну категорию и 1 неделю наблюдений. Второй добавляет ещё 2 категории, тестовый набор из 200 писем и разбор ошибок каждый рабочий день. Третий переносит стабильные правила в регулярный контур, сохраняя ручную проверку претензий, денег и неясных запросов.
Мой практический критерий простой: если после 2 недель стало меньше ручного копирования, срочные письма находятся быстрее, а доля исправляемых черновиков растёт, схему можно расширять. Если менеджеры получают больше ложных тревог или тратят время на исправление выдуманных фактов, нужно менять категории и инструкции, а не просто выбирать другую модель.