Автоматизация сортировки писем: суть, срочность и ответ в 2026
Стендфирст: Практическая схема обработки входящих писем для поддержки, продаж и аккаунтинга, с классификацией, оценкой срочности и проверкой черновиков.
Входящее письмо редко содержит одну чистую задачу. В нём могут одновременно быть вопрос о счёте, жалоба на срок, просьба о консультации и вложение с техническими данными. Если сотрудник вручную читает каждое сообщение, сортирует его и пишет ответ с нуля, очередь быстро растёт. Нейросеть способна снять повторяющиеся операции, но качество зависит от правил, примеров и человеческой проверки.
Я рассматриваю автоматизацию как конвейер принятия решения, а не как кнопку «ответить всем». Сначала система извлекает факты из письма, затем присваивает категорию и уровень срочности, после чего предлагает черновик. Такой порядок проще контролировать: ошибка на каждом шаге видна отдельно.
Что именно автоматизировать в письме
Автоматизировать стоит 4 операции: классификацию, выделение сути, определение срочности и подготовку черновика ответа. Каждая операция должна возвращать отдельный результат, иначе сотруднику сложно понять, откуда появилась рекомендация.
Для поддержки я обычно начинаю с таких категорий:
- техническая проблема;
- вопрос по оплате или документам;
- запрос на подключение или консультацию;
- претензия;
- повторное обращение;
- нерелевантное сообщение.
Для продаж список меняется: новый запрос, уточнение условий, запрос демонстрации, продление, отказ. В аккаунтинге полезны категории «изменение договора», «статус задачи», «риск оттока» и «расширение использования». Универсального набора нет, зато число категорий лучше ограничить на старте 5–8 позициями. Если добавить 20 почти одинаковых меток, сотрудники начнут исправлять классификацию чаще, чем использовать её.
В карточке обращения достаточно хранить 7–10 полей: тему, краткую суть, категорию, срочность, автора, компанию, упомянутый продукт, обещанный срок и рекомендуемое действие. Пустое значение должно оставаться пустым. Нейросеть не должна угадывать номер договора или дату оплаты по косвенной фразе.
Подробно о проверке черновиков и повторяющихся форматов я пишу в материале нейросеть для генерации текста и проверка результата. Там же полезно сверить границу между автоматическим черновиком и текстом, который сотрудник обязан перечитать.
Как устроить конвейер обработки
Практичная схема состоит из 5 этапов: очистка письма, извлечение фактов, классификация, оценка срочности и подготовка ответа. Я сохраняю результаты каждого этапа отдельно, чтобы быстро найти источник ошибки и не переделывать весь процесс.
| Этап | Что получает нейросеть | Результат для сотрудника |
|---|---|---|
| Очистка | Тему, тело письма, дату, вложения | Текст без подписей и повторных цитат |
| Извлечение | Факты, суммы, даты, номера обращений | Краткая карточка запроса |
| Классификация | Список допустимых категорий | Одна основная метка и одна дополнительная |
| Срочность | Правила риска и сроки | Уровень от 1 до 3, причина оценки |
| Черновик | Карточку запроса и правила тона | Ответ с местами для проверки |
На первом этапе нужно удалить длинную переписку из цитаты, рекламную подпись и технический мусор. При этом нельзя выбрасывать дату, имя отправителя и номер заявки. Для письма с 6 ответами в цепочке полезно оставить последнее сообщение и 1–2 абзаца контекста, а не всю историю.
На втором этапе модель должна выписать только то, что действительно есть в тексте. Формулировка «клиент просит вернуть 18 500 рублей до 12 марта» содержит три проверяемых факта: действие, сумму и дату. Если дата не указана, поле получает значение «нет данных», а сотрудник видит вопрос для уточнения.
На третьем этапе я запрещаю свободное изобретение меток. Модель выбирает значение из заданного списка и добавляет короткое объяснение, например «оплата, потому что упомянут счёт и закрывающие документы». Такое объяснение помогает быстро пересмотреть спорное письмо.
В SoftChat доступны веб-чат с потоковыми ответами и переключение моделей в рамках разговора. Эти возможности подходят для ручного просмотра формулировок и сравнения вариантов ответа на отдельных письмах, но саму маршрутизацию в почту или CRM нужно проектировать отдельно.
Как составить инструкцию для нейросети
Надёжная инструкция состоит из 6 блоков: роль, задача, допустимые категории, формат результата, правила неопределённости и пример. Чем точнее эти блоки, тем меньше разрыв между ожидаемой карточкой и фактическим ответом.
В начале я задаю роль: «Ты классифицируешь входящие обращения службы поддержки». Затем описываю цель одним предложением: «Определи категорию, срочность, суть запроса и следующий шаг». После этого перечисляю метки с короткими границами. Например, «оплата» относится к счетам, возвратам и документам, а «продажи» к новым условиям и запросу коммерческого предложения.
Формат результата лучше зафиксировать заранее. Для одной заявки достаточно такой структуры:
- категория;
- срочность от 1 до 3;
- суть в 1–2 предложениях;
- факты из письма;
- чего не хватает;
- черновик ответа;
- причина передачи сотруднику.
Отдельное правило должно касаться неизвестных данных: «Не придумывай цену, срок, статус заявки и обещание сотрудника. Если сведений нет, напиши “нет данных”». Я добавляю запрет на самостоятельную отправку, потому что черновик и опубликованный ответ имеют разный уровень риска.
Для настройки сценария полезно подготовить 20–40 обезличенных писем. В наборе должны быть простые обращения, неоднозначные формулировки, повторные письма и сообщения с несколькими вопросами. Каждый пример получает эталонную категорию, уровень срочности и допустимый ответ. Подход к составлению запросов подробно разобран в статье как правильно формулировать запросы для нейросетей.
Я проверяю инструкцию на письмах, которых не было в примерах. Если модель уверенно выбирает категорию при отсутствии фактов, проблема обычно находится в правиле неопределённости, а не в длине запроса. Если ответ получается слишком длинным, задаю лимит в 80–120 слов и прошу вынести вопросы к сотруднику отдельным блоком.
Как определить срочность обращения
Для первой версии достаточно 3 уровней срочности и 2 явных триггеров: риск остановки работы и зафиксированный срок от клиента. Такая шкала понятнее, чем семь градаций с разницей в несколько минут.
Я использую следующую логику:
- уровень 3, критично: остановлена оплаченная услуга, не проходит платёж, нарушен согласованный срок или есть риск потери доступа;
- уровень 2, повышенный: клиент ждёт решение в течение 1–2 рабочих дней, сообщает о повторной проблеме или связывает вопрос с запуском проекта;
- уровень 1, обычный: консультация, общий вопрос, просьба прислать материалы или уточнение без срока.
Число «3» должно означать конкретное действие, а не эмоциональную оценку. Если письмо содержит слова «срочно» или «критично», этого недостаточно для высокого уровня. Нужна причина: дата, финансовый риск, остановка процесса или обязательство из договора.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 120 обращений в сутки. В 18 письмах упоминается остановка отгрузки, а в 27 есть срок ответа до конца рабочего дня. Для такой очереди уровень 3 можно присвоить 18 письмам по признаку остановки, а 27 сообщений проверить на пересечение условий, чтобы не считать одну заявку дважды.
Я добавляю поле «основание срочности». Если модель пишет «высокий приоритет» без цитаты или пересказа факта, сотрудник возвращает письмо на ручную проверку. Такой контроль снижает риск, что слово «срочно» в подписи или теме поднимет обычный запрос наверх очереди.
Как подготовить черновик ответа
Хороший черновик содержит 5 частей: обращение, подтверждение сути, конкретный следующий шаг, запрос недостающих данных и безопасное завершение. Его задача состоит в экономии времени сотрудника, а не в замене проверки.
Структура может выглядеть так:
- «Здравствуйте, [имя]».
- «Понимаю, что нужно уточнить статус счёта за [период]».
- «Я проверю данные и вернусь с ответом до [дата]».
- «Пожалуйста, пришлите номер договора, если он не указан в письме».
- «С уважением, [имя сотрудника]».
Квадратные скобки здесь обозначают обязательные места для проверки. Нейросеть не должна сама подставлять имя, срок или сумму, если они отсутствуют в источнике. Для претензии нужен более осторожный тон: признать проблему, зафиксировать следующий шаг и не обещать компенсацию без подтверждённого правила.
Модельный кейс: очередь из 60 писем содержит 24 типовых вопроса о документах, 21 обращение по статусу и 15 нестандартных сообщений. Нейросеть может подготовить черновики для первых двух групп, а все 15 нестандартных писем направить сотруднику без автоматического текста. Такой подход ограничивает область риска и даёт материал для следующего цикла настройки.
Для продаж черновик должен отвечать на вопрос клиента, фиксировать запрошенный срок и предлагать следующий контакт. Для аккаунтинга полезно показать историю обращения и открытые обязательства, однако эти данные нужно брать из проверенных систем, а не просить модель восстановить их по памяти. О сценариях внедрения в регулярную работу можно почитать в материале как внедрить нейросети в рабочие процессы.
Как проверить качество до запуска
Минимальный контроль включает 4 показателя: точность категории, полноту обнаружения срочных писем, долю выдуманных фактов и время правки черновика. Проверять их нужно на отложенной выборке, а не на тех же письмах, по которым формулировались правила.
Для стартовой оценки я беру 40–60 писем и вручную отмечаю эталон. Рабочий порог для категории может составлять 90%, то есть 36 правильных решений из 40. Для срочности важнее не пропустить критичные обращения: если из 10 действительно срочных писем обнаружены 9, полнота равна 90%, но одно пропущенное письмо нужно разобрать отдельно.
| Показатель | Как считать | Практический сигнал |
|---|---|---|
| Категория | Верные метки / все письма | Ниже 90%: пересмотреть список категорий |
| Срочность | Найденные критичные / все критичные | Любой пропуск требует разбора причины |
| Факты | Проверенные поля без выдумок | Сумма, дата и номер должны совпадать с письмом |
| Правка | Время от открытия до готового ответа | Более 3 минут: черновик слишком общий |
Числа здесь являются рабочими ориентирами для пилота, а не обещанием результата. На сложность влияют язык писем, длина переписки, вложения и наличие внутренних терминов. Если 8 из 40 сообщений требуют полной переписки, сначала нужно понять причину: неверная категория, нехватка данных или плохой шаблон ответа.
Я веду журнал ошибок с четырьмя полями: текст проблемы, ожидаемый результат, фактический результат и исправленное правило. Через 2–3 цикла становится видно, повторяется ли одна ошибка. Дополнительные приёмы проверки результата и работы с черновиками собраны в материале задачи и проверка результата генерации текста.
Что запускать первым
Первый запуск я бы ограничил 1 очередью, 5–8 категориями и ручным подтверждением каждого ответа. Такой контур позволяет собрать статистику без риска отправить клиенту неподтверждённую сумму, дату или обещание.
Сначала стоит выбрать письма с повторяющейся структурой: вопросы по документам, статусы заявок или запросы на консультацию. Затем нужно собрать 20–40 обезличенных примеров, разметить их и определить 3 уровня срочности. После этого команда сравнивает черновик с исходным письмом и фиксирует время правки.
Если точность категории держится около 90%, а критичные письма не теряются, можно расширять очередь. Если показатель ниже, не нужно сразу добавлять новые инструкции. Сначала я сокращаю число меток, уточняю границы и добавляю примеры спорных формулировок. Для повседневных повторяющихся операций пригодится разбор использования нейросетей и чат-ботов для повседневных задач.
Практическое правило простое: автоматизировать можно то, где ошибка обнаруживается до отправки и не меняет финансовое или договорное обязательство. Сложные претензии, нестандартные условия и письма с неполными данными я оставляю под контролем сотрудника. Так сортировка ускоряет очередь, сохраняя ответственность за финальный ответ у человека.