ИИ для сортировки писем и заявок: сценарии и метрики в 2026
Обновлено в июне 2026. Я переписал этот материал под текущую практику: меньше разговоров про «магическую автоматизацию», больше схемы, метрик, промптов и ограничений.
Когда входящие идут из почты, формы на сайте и мессенджеров, проблема редко в самом количестве сообщений. Болит другое: каждое обращение надо открыть, понять контекст, определить срочность, найти владельца задачи и ответить так, чтобы не сорвать ожидания клиента. Нейросеть хорошо подходит для первого слоя обработки: классифицировать обращение, выделить срочное, кратко пересказать суть и подготовить черновик ответа. Решение не обязано начинаться с большой интеграции. Часто достаточно взять типовые обращения за 2–4 недели, описать правила сортировки и прогнать их через языковую модель по стабильному шаблону.
Я смотрю на такой сценарий как редактор процесса, а не как поклонник автоматизации ради автоматизации. ИИ не должен решать всё за команду. Его сильная сторона, снять с людей механическую работу: первичное чтение, разметку, краткое резюме и заготовку ответа. Человек оставляет за собой решение в спорных случаях, финальную формулировку и ответственность перед клиентом.
Что изменилось в обновлённой версии
В прежних материалах про обработку входящих часто делали акцент на отдельных инструментах и громких обещаниях. Сейчас рабочий подход стал спокойнее. Команды сначала описывают категории обращений, затем вводят проверяемые правила, после этого подключают нейросеть к одному узкому участку.
Я обновил структуру под практический сценарий из четырёх шагов:
- собрать входящие из разных каналов в один список или выгрузку;
- разметить обращения по типу, срочности и ответственному;
- получить короткое резюме и черновик ответа;
- измерить ошибки и экономию времени до расширения процесса.
Для читателя, который только начинает внедрение ИИ в рутину, полезно сначала разобрать общую логику изменений. Я подробно описывал этот путь в статье про то, как внедрить нейросети в рабочие процессы, а здесь сосредоточусь на входящих заявках и письмах.
Какие обращения отдавать нейросети в первую очередь
Начинать лучше не с самых рискованных сообщений. Я беру входящие, где много повторяемых форматов и мало юридической или финансовой неоднозначности. Типичный набор:
| Тип обращения | Что просим сделать ИИ | Что остаётся человеку |
|---|---|---|
| Вопрос по статусу заказа | найти номер, пересказать суть, предложить короткий ответ | проверить данные в учётной системе |
| Жалоба на задержку | определить срочность, выделить эмоцию и требование | выбрать компенсацию или тон ответа |
| Заявка с формы сайта | классифицировать лид, отдел, срочность | принять коммерческое решение |
| Повторное письмо | найти, что изменилось с прошлого сообщения | проверить историю диалога |
| Запрос документов | составить список нужных вложений | отправить актуальные файлы |
Для примера: если за день приходит 120 обращений, а на первичное чтение одного уходит 45–90 секунд, команда тратит 1,5–3 часа только на понимание «что это такое». Нейросеть может сократить этот слой до проверки готовой разметки: тип, срочность, короткая суть, следующий шаг. Это не делает поддержку автономной, зато убирает самый скучный проход по одинаковым письмам.
Схема сортировки: тип, срочность, владелец, действие
Хорошая разметка начинается с простого словаря категорий. Я не советую заводить 30 типов с первого дня. Для большинства команд хватает 6–8 классов:
- новый лид;
- вопрос по оплате;
- техническая проблема;
- жалоба;
- запрос документов;
- партнёрское предложение;
- повторное обращение;
- спам или нерелевантное сообщение.
Срочность удобнее считать по трём уровням. «Высокая» означает риск потери денег, клиента, доступа или срока. «Средняя» относится к обращениям, где нужен ответ в течение рабочего дня. «Низкая» подходит для информационных вопросов без явного дедлайна.
Дальше добавляется владелец: продажи, поддержка, бухгалтерия, операционный менеджер, руководитель смены. Если владелец неочевиден, нейросеть должна честно поставить «нужна ручная маршрутизация», а не угадывать. Это правило снижает вред от уверенных, но неверных ответов.
Промпт для разбора входящих
Нейросеть работает стабильнее, когда запрос не просит «разобраться», а задаёт формат ответа. В SoftChat можно сохранить такие заготовки как шаблоны промптов и возвращаться к ним без переписывания инструкции с нуля. Если команда тестирует несколько подходов, удобно вести диалоги с историей по организации и менять модель в рамках беседы, когда нужно сравнить качество формулировок.
Рабочий шаблон может выглядеть так:
Ты помощник для первичной обработки входящих обращений.
Разбери сообщение по схеме.
1. Категория: выбери одну из списка.
2. Срочность: высокая, средняя или низкая.
3. Краткая суть: до 2 предложений.
4. Данные, которые надо проверить: список.
5. Рекомендуемый владелец: отдел или роль.
6. Черновик ответа клиенту: вежливо, без обещаний, которые не подтверждены.
7. Риск ошибки: низкий, средний или высокий.
Если данных мало, напиши, чего не хватает.
Для примера: сообщение «Оплатили счёт вчера, доступа до сих пор нет, номер заказа 48321» нейросеть должна отнести к оплате или доступу, поставить высокую срочность, попросить проверить платёж и подготовить ответ без фразы «мы всё исправили», если факт ещё не подтверждён.
Для текстовых черновиков полезно отдельно задавать тон. Разбор приёма с формулировками есть в материале про нейросеть для генерации текста и проверку результата. В обработке входящих это особенно заметно: одно и то же письмо можно пересказать сухо, сочувственно или слишком оборонительно.
Черновик ответа: где ИИ помогает, а где мешает
Черновик ответа экономит время, если он содержит три элемента: признание запроса, конкретный следующий шаг, срок или условие ответа. Плохой черновик звучит гладко, но ничего не обещает по делу. Хороший черновик сразу показывает, что команда поняла проблему.
Условный пример: для обращения «не пришёл закрывающий документ за май» модель может предложить такой каркас: «Здравствуйте. Проверим документы за май по вашей компании и сверим отправку. Если акт был сформирован, пришлём повторно; если нет, уточним причину и вернёмся с ответом сегодня до 17:00». В этом тексте нет лишних извинений, нет выдуманного результата, есть понятный следующий шаг.
Я всегда добавляю в инструкцию запрет на неподтверждённые обещания. Нейросеть не должна писать «возврат уже оформлен», «доступ восстановлен», «менеджер свяжется через 5 минут», если этих данных нет в исходном сообщении или системе. Для черновика допустимы фразы «проверим», «уточним», «передадим ответственному», «вернёмся с ответом до указанного срока», когда такой срок принят внутри команды.
Если вы только учитесь формулировать задания для моделей, начните с базовых правил из статьи про искусство промптинга для нейросетей. Для входящих это даёт быстрый эффект: меньше расплывчатых ответов, больше проверяемых полей.
Метрики, которые показывают реальную пользу
Автоматизация входящих без измерений быстро превращается в спор вкусов. Одному кажется, что стало быстрее. Другой видит больше ошибок. Поэтому я предлагаю фиксировать 5 метрик до пилота и после него.
| Метрика | Как считать | Зачем нужна |
|---|---|---|
| Время первичной разметки | минуты на 50 или 100 обращений | показывает экономию на чтении |
| Доля ручных исправлений | исправленные поля к общему числу | показывает качество классификации |
| Ошибки срочности | неверные уровни приоритета | защищает от пропуска критичных писем |
| Скорость первого ответа | медианное время до черновика | влияет на ожидания клиента |
| Доля эскалаций | обращения, ушедшие руководителю | показывает, где правила неясны |
Условный пример: команда поддержки обрабатывает 80 обращений за рабочий день. До пилота оператор тратит 60 секунд на первичную оценку каждого сообщения, то есть около 80 минут. После внедрения разметки он проверяет карточку за 20–30 секунд. Экономия получается заметной, но её надо сравнить с числом исправлений. Если каждое третье обращение приходится переклассифицировать, промпт и категории требуют доработки.
Как не сломать процесс безопасностью
В письмах и заявках часто есть телефоны, адреса, суммы, номера договоров и внутренние детали. Перед запуском надо решить, какие данные можно передавать в ИИ-сценарий, а какие нужно маскировать. Для пилота достаточно удалить лишние персональные сведения из тестовой выборки и оставить только те поля, без которых классификация невозможна.
Я разделяю обращения на три зоны:
- зелёная зона: общие вопросы, заявки без чувствительных данных, типовые запросы;
- жёлтая зона: коммерческие условия, реквизиты, номера договоров;
- красная зона: документы с персональными данными, претензии, юридически значимые формулировки.
Зелёную зону можно тестировать первой. Жёлтая требует правил маскирования и доступа. Красную лучше оставлять на ручной обработке или подключать только после внутренней проверки рисков.
В SoftChat можно работать с чатами, историей диалогов, системными промптами и пользовательскими помощниками. В сообщениях доступны вложения документов и изображений, но результат зависит от возможностей выбранной модели. Поэтому я не закладываю в процесс допущение, что любая модель одинаково хорошо прочитает файл, таблицу или скриншот. Если ответ выбранной модели не получился пригодным, SoftChat может получить ответ от резервной модели и показать строку «Ответ получен на резервной модели». Неудачная попытка при полном сбое не списывает кредиты, что удобно для рабочих сценариев с повтором.
Пошаговый пилот на две недели
Я бы не начинал с интеграции всех каналов. Сначала нужен пилот на небольшой, но реальной выборке.
День 1–2: выгрузите 100–200 входящих за последние недели. Уберите лишние персональные данные, оставьте текст обращения, канал, дату и текущий результат обработки.
День 3: создайте словарь категорий и уровней срочности. Для каждой категории напишите 2–3 примера. Чем яснее границы, тем меньше спорных ответов.
День 4–5: прогоните выборку через один промпт. Не меняйте инструкцию после каждых 5 сообщений, иначе сравнение потеряет смысл.
День 6–7: разберите ошибки. Отдельно считайте неверную категорию, неверную срочность, плохой черновик ответа и случаи, где модели не хватило данных.
Неделя 2: обновите промпт, добавьте правило для спорных случаев и повторите проверку на новой выборке. Если качество держится, переносите сценарий на один канал, например формы сайта или общий почтовый ящик.
Для личной продуктивности подход похож: сначала найти повторяемую рутину, затем дать нейросети строгий формат результата. Больше бытовых сценариев я разбирал в тексте о том, как использовать нейросети для повседневных задач.
Финальный вывод после обновления
Обновлённая версия статьи сводит тему к рабочей схеме: нейросеть сортирует входящие, выделяет срочные обращения, делает резюме и готовит черновик ответа, а человек проверяет рискованные места. Такой подход не требует менять весь процесс за один раз. Достаточно начать с 100–200 сообщений, измерить ошибки и закрепить правила.
Главный критерий успеха простой: команда быстрее понимает, что пришло, кто должен отвечать и какой следующий шаг нужен клиенту. Если это видно в метриках, сценарий можно расширять. Если нет, проблема почти всегда в слабом словаре категорий, расплывчатом промпте или попытке отдать модели слишком сложные решения без контроля.