Нейросеть для сортировки писем и заявок в 2026

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

Основная потеря возникает из-за 4–6 последовательных действий с каждым сообщением, даже если само решение занимает меньше минуты. В цепочке обычно есть чтение, классификация, поиск данных, оценка срочности, подготовка ответа и регистрация результата.
Для примера: при 120 входящих за день и 3 минутах первичной обработки на каждое сообщение получается 360 минут, то есть 6 часов. Если часть писем требует 8–10 минут из-за вложенных вопросов или неясной темы, фактическая загрузка становится выше расчётной.
Я разделяю поток на четыре типа:
- запрос клиента, где требуется ответ;
- заявка с конкретным действием, например расчётом или уточнением;
- внутреннее сообщение, которое нужно направить ответственному;
- информационное письмо, не требующее срочной реакции.
Такое деление снижает число решений, которые менеджер принимает вручную. Оно задаёт нейросети ограниченное поле выбора, а человеку оставляет контроль над исключениями.
Перед автоматизацией полезно собрать обезличенную выборку из 50–100 сообщений. В ней должны быть короткие письма, длинные цепочки, неполные заявки, дубли и сообщения с несколькими вопросами. На такой выборке быстро видно, где правило работает, а где нужна дополнительная категория.
Как подготовить входящие для анализа?
Надёжная подготовка занимает 3 шага: убрать лишние элементы, выделить текст запроса и передать нейросети понятные поля результата. Без этого модель начинает смешивать подпись, историю переписки и новую задачу.
Сначала я отделяю последнее сообщение от цитируемой переписки. Затем удаляю технические подписи, повторяющиеся приветствия и служебные уведомления. Адреса, телефоны и номера заказов можно заменить метками, если они не нужны для классификации.
Второй шаг связан с форматом. Вместо свободного ответа задаётся структура:
- категория;
- краткая суть в 1–2 предложениях;
- требуемое действие;
- срок или упоминание срочности;
- отсутствующие данные;
- уровень уверенности.
Шесть полей дают менеджеру компактную карточку сообщения. Если в письме нет срока, модель должна написать «не указан», а не додумывать дату. Если вопрос содержит два разных поручения, их нужно перечислить отдельно.
Третий шаг, проверка на неоднозначность. Я добавляю правило: при конфликте между темой письма и содержанием приоритет получает содержание, а при нехватке данных ставится пометка «нужна проверка». Это полезнее, чем заставлять модель выбирать категорию любой ценой.
В статье о генерации текста и проверке результата подробно разобран принцип, который здесь работает особенно хорошо: сначала получить структурированный черновик, затем проверить факты и только после этого использовать текст в работе.
Как выставлять приоритет заявкам?
Для первичной сортировки достаточно шкалы от 0 до 3, где 0 означает отсутствие срочного действия, а 3 требует реакции в текущем рабочем окне. Простая шкала лучше пяти разных слов, которые сотрудники понимают по-разному.
Я задаю четыре признака:
| Признак | 0 баллов | 1 балл | 2 балла | 3 балла |
|---|---|---|---|---|
| Срок | не указан | больше 3 дней | 1–3 дня | сегодня или просрочен |
| Влияние | общий вопрос | один пользователь | несколько участников | остановлена работа |
| Риск | справочная тема | возможна задержка | финансовый или договорной риск | жалоба, сбой или потеря срока |
| Готовность данных | всё есть | не хватает 1 поля | не хватает 2 полей | невозможно начать без уточнения |
Сумма не должна механически определять порядок ответа. Например, высокая срочность при пустых исходных данных означает, что первым действием станет уточняющий вопрос. Поэтому в результате нужны две отдельные величины: числовой балл и рекомендуемое действие.
Модельный кейс: для обращения с дедлайном сегодня, остановкой работы и полным набором данных можно получить 8 баллов из 12. Это не обещание результата, а пример настройки шкалы, который команда проверяет на собственной выборке из 50–100 сообщений.
Я советую измерять не «точность ИИ» вообще, а конкретные показатели: долю правильно выбранных категорий, число пропущенных срочных обращений, количество исправлений в черновике и среднее время до первого ответа. Даже 4 показателя дают понятную картину качества.
Полезные принципы формулировки правил собраны в материале как правильно составлять запросы для нейросетей. Для сортировки особенно нужны примеры границ: чем отличается срочная заявка от просто эмоционального письма и когда сообщение нельзя отнести к категории без человека.
Как готовить черновик ответа без лишнего риска?
Безопасный черновик состоит из 3 частей: признание запроса, подтверждённый следующий шаг и список недостающих данных. Нейросеть должна предлагать формулировку, а не принимать обязательство от имени компании.
В инструкции я отдельно фиксирую запреты. Модель не должна обещать срок, которого нет во входных данных, придумывать стоимость, ссылаться на несуществующий статус заказа или утверждать, что действие уже выполнено. При отсутствии факта допустима формулировка «проверю и вернусь с ответом», но отправлять её нужно после человеческой проверки.
Для каждого черновика полезно выводить блок контроля:
- какие факты взяты из письма;
- какие сведения отсутствуют;
- где требуется подтверждение менеджера;
- какой вопрос нужно задать следующим сообщением.
Такой формат уменьшает риск незаметной выдумки. Он помогает увидеть, почему появился конкретный ответ, и быстро исправить одну фразу вместо полного переписывания письма.
Я не смешиваю в одном запросе сортировку и окончательное решение. Сначала прошу определить тип обращения и факты, потом отдельным шагом подготовить нейтральный черновик. Разделение задач упрощает тестирование: если ошибка возникла, понятно, на каком этапе она появилась.
В SoftChat можно переключать модели внутри одного диалога. Я бы использовал эту возможность для сравнения нескольких вариантов инструкции на одинаковых обезличенных сообщениях, а потоковую выдачу ответа применял для быстрой проверки длинных результатов. Это помогает оценивать именно качество структуры, а не приписывать одной модели все ошибки процесса.
Ручная обработка и нейросеть: что выбрать?
Для потока до 10 сообщений в день ручная обработка обычно проще; при 50–100 сообщениях нейросеть полезна как слой предварительной сортировки, но финальное решение всё равно зависит от риска и содержания.
| Подход | Когда подходит | Плюс | Ограничение |
|---|---|---|---|
| Полностью вручную | до 10–20 сообщений в день | легко объяснить каждое решение | растёт время на повторяющиеся действия |
| Нейросеть для классификации | однотипные входящие и стабильные категории | менеджер видит краткую выжимку | ошибки на новых формулировках |
| Нейросеть для черновиков | типовые вопросы с проверяемыми ответами | ускоряется первый вариант письма | нужен контроль фактов и обещаний |
| Смешанная схема | разные уровни срочности и риска | автоматизируются простые шаги | требуется настройка правил эскалации |
Сравнивать нужно не красивость ответа, а стоимость ошибки. Пропущенная жалоба, неверная сумма или обещанный без подтверждения срок опаснее лишних 2 минут ручной проверки. Для таких категорий я оставляю обязательное подтверждение сотрудником.
Если поток меняется каждую неделю, не стоит начинать с десятков категорий. Достаточно 4 основных групп и отдельного статуса «не уверен». Его доля показывает, где инструкция или сама схема маршрутизации требует доработки.
Как проверить схему на небольшой выборке?
Проверка на 30 сообщениях занимает меньше ресурсов, чем внедрение ошибочного правила на весь поток. Для теста нужны одинаковые входные данные, фиксированная версия инструкции и таблица с эталонной разметкой сотрудника.
Я прохожу пять этапов. Сначала отмечаю правильную категорию и приоритет вручную. Затем запускаю нейросеть на тех же сообщениях, не меняя формулировку запроса между попытками. После этого сравниваю расхождения по типам: неверная тема, пропущенный срок, выдуманный факт, слишком общий черновик или неправильная эскалация.
Отдельно проверяю крайние случаи: письмо без темы, сообщение из одного слова, длинную цепочку из 20 и более реплик, два поручения в одном письме и конфликт между срочностью и отсутствующими данными. Именно такие случаи показывают границы применения лучше, чем средний запрос.
Модельный кейс: если на выборке из 40 сообщений найдено 6 ошибок классификации, доля совпадений составляет 85%. Для рабочего решения одной цифры мало: нужно посмотреть, пришлись ли эти 6 ошибок на безобидные информационные письма или на обращения с риском потери клиента.
Не меняйте сразу всё. Сначала поправьте одно правило, повторите тест на той же выборке, затем добавьте 10–20 новых сообщений. Такой порядок показывает, действительно ли изменилась инструкция, а не просто случайно улучшился результат.
Что бы я сделал на вашем месте?
Я бы начал с одной категории, где много повторяющихся вопросов и мало юридического или финансового риска. Для неё зафиксировал бы 4 статуса, 6 полей результата и шкалу приоритета от 0 до 3. Затем сравнил бы 30–40 обезличенных сообщений с ручной разметкой.
Если нейросеть стабильно извлекает факты, следующий шаг, черновики без обещаний и список пропущенных данных, можно расширять поток. Если ошибки связаны с неоднозначными правилами, я бы не добавлял автоматические действия, а уточнил инструкции и оставил человеку право финального решения.
Смысл такой схемы в экономии внимания, а не в попытке убрать менеджера из процесса. Человек решает спорные вопросы и отвечает за обязательства, а нейросеть сокращает путь от сырого входящего сообщения до понятной рабочей карточки.