Как разгрузить почту с помощью ИИ: сортировка и черновики

Нейросеть помогает разобрать входящие по теме и срочности, а менеджер получает готовый черновик с понятным следующим шагом.

Почта перегружает команду не из-за одного большого письма, а из-за десятков мелких решений: к какой теме отнести сообщение, кому его передать, нужен ли ответ сегодня, какие данные запросить. В рабочем ящике обычно смешаны лиды, обращения клиентов, счета, уведомления и внутренние письма. Если разбирать их в случайном порядке, срочное сообщение легко оказывается под письмами, которые можно открыть через 2 дня.

Нейросеть снимает часть механической работы, но не заменяет правила отдела. Я рассматриваю её как первый слой обработки: модель извлекает признаки, предлагает категорию, объясняет приоритет и пишет черновик. Финальное решение остаётся за сотрудником, особенно когда письмо связано с деньгами, договором, претензией или персональными данными. Подробно о проверке результата генерации я писал в материале «Нейросеть для генерации текста: задачи и проверка результата».

Что именно сортирует нейросеть

Нейросеть может разложить письмо минимум по 5 признакам: теме, срочности, типу отправителя, требуемому действию и полноте данных. Такой разбор превращает длинный список сообщений в очередь с понятными следующими шагами.

Сначала модель выделяет смысл обращения. Для входящей почты подходят категории «новый запрос», «текущий клиент», «оплата», «документы», «техническая проблема», «жалоба» и «рассылка». Набор категорий лучше ограничить 6–10 пунктами. Если создать 30 похожих меток, сотрудники начнут выбирать их по-разному, а статистика потеряет смысл.

Затем модель извлекает сущности. В письме это могут быть название организации, номер заказа, дата поставки, сумма счёта, город, продукт или фамилия ответственного. Отдельное поле должно показывать, каких сведений не хватает. Например, запрос «Нужна цена на обслуживание» не содержит числа пользователей, срока договора и состава работ.

Третий слой, это определение намерения. Фразы «пришлите расчёт», «почему списали оплату» и «не открывается файл» относятся к разным действиям, даже если отправитель использует одинаковую тему письма. Модель должна возвращать короткую формулировку намерения, а не пересказ всего сообщения.

Четвёртый признак, предполагаемая очередь. Для неё достаточно значений «срочно», «в течение рабочего дня», «планово» и «не требует ответа». Пятый, уверенность классификации. Если модель сомневается между «оплатой» и «документами», письмо нужно отправить на ручную проверку, а не маскировать сомнение уверенным ярлыком.

В запросе к модели я задаю фиксированный формат ответа:

Категория: одно значение из списка
Срочность: срочно / сегодня / планово / без ответа
Намерение: одна фраза до 12 слов
Извлечённые данные: список полей
Недостающие данные: список полей
Уверенность: число от 0 до 1

Такая схема полезнее просьбы «разбери почту». Она ограничивает произвольные формулировки и позволяет перенести результат в таблицу, очередь задач или внутренний интерфейс.

Как построить поток обработки

Рабочий поток состоит из 6 этапов: получение письма, очистка, классификация, проверка приоритета, создание черновика и подтверждение сотрудником. Разделение этапов помогает найти ошибку, если сообщение попало не в ту очередь.

На первом этапе сохраняются исходные поля: тема, текст, дата, адрес отправителя, цепочка переписки и вложения. Текст письма нужно отделить от подписи и повторяемой истории цитирования. Иначе модель будет принимать старый вопрос из предыдущего сообщения за новый запрос.

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

На третьем этапе модель возвращает структурированный результат. Я советую хранить рядом с категорией исходный фрагмент, на котором основано решение. Для срочности это может быть дата отключения, упоминание просрочки, блокировка услуги или прямой запрос руководителя. Сотрудник быстрее проверит 2–3 основания, чем перечитает весь поток.

На четвёртом этапе срабатывают правила маршрутизации. Категория «оплата» может уходить финансовому специалисту, «техническая проблема» инженеру, «новый запрос» менеджеру по продажам. Нейросеть предлагает решение, а простое правило подтверждает его, если обязательные поля заполнены.

Пятый этап, черновик ответа. Модель получает исходное письмо, извлечённые данные, допустимый тон и список фактов, которыми разрешено пользоваться. В черновик нельзя автоматически добавлять сроки, скидки, юридические выводы или обещания, которых нет в базе отдела.

Шестой этап, контроль человеком. Менеджер проверяет адресата, цифры, даты, вложения и следующий шаг. После отправки полезно сохранять исправления: они показывают, где инструкция модели слишком расплывчата.

Для отладки я разделяю тестовую выборку на 4 группы: обычные запросы, срочные обращения, письма с неполными данными и сообщения с несколькими темами. Если проверять только спокойные письма, система покажет красивый результат, но провалится на смешанных случаях.

В веб-чате SoftChat можно переключать модели в рамках одного разговора. Это удобно для ручного сопоставления двух вариантов классификации или черновика, когда команда ещё выбирает рабочую инструкцию. Саму почтовую очередь при таком подходе нужно организовать в своём контуре обработки.

Как выделять срочные обращения

Срочность лучше определять по 4 группам сигналов: сроку, ущербу, статусу услуги и явному требованию ответа. Одного эмоционального слова вроде «срочно» недостаточно, оно часто встречается в обычной переписке.

Я задаю модели шкалу, связанную с действием сотрудника:

1. Срочно, ответственный должен проверить письмо в течение 1 часа.
2. Сегодня, обработка нужна до конца рабочего дня.
3. Планово, ответ можно включить в обычную очередь.
4. Без ответа, письмо сохраняется для истории или статистики.

Это не универсальные сроки для каждого бизнеса. Для службы поддержки с круглосуточным дежурством порог в 1 час может быть нормой, а для отдела закупок он окажется слишком жёстким. Поэтому SLA задаёт руководитель процесса, а нейросеть лишь сопоставляет текст с утверждёнными условиями.

В инструкцию я добавляю признаки высокого приоритета: дата, после которой заказ теряет смысл; остановка оплаченной услуги; риск штрафа; повторное обращение без ответа; просьба исправить ошибку в документе. Отдельно указываю отрицательные признаки. Письмо с фразой «буду признателен за быстрый ответ» не становится срочным автоматически.

Модельный кейс: для компании из сферы логистики, ~200 сотрудников, правило «срочно» может срабатывать при упоминании сегодняшней даты отгрузки и заблокированного заказа. Если есть только вопрос о тарифе без срока поставки, письмо получает уровень «планово».

Срочность нужно проверять по двум показателям. Первый, полнота обнаружения действительно срочных писем, это полнота. Второй, доля писем, помеченных срочными правильно, это точность. Когда срочным становится каждое третье сообщение, очередь теряет смысл, даже если модель ничего не пропускает.

Как готовить черновик ответа

Хороший черновик содержит 3 обязательных блока: подтверждение сути вопроса, конкретный ответ и следующий шаг. Если данных недостаточно, третий блок превращается в короткий список уточнений.

Первое предложение должно показать, что письмо понято. Вместо «Мы получили ваше обращение» лучше написать: «Вы спрашиваете о сроке поставки партии из 40 единиц». Число здесь берётся из письма, а не придумывается моделью. Если количество не указано, его нельзя добавлять для гладкости текста.

Второй блок отвечает только на подтверждённые вопросы. Я передаю модели справочник фактов с датами обновления, допустимыми формулировками и ответственными подразделениями. Данные старше установленного срока помечаются для повторной проверки. Для тарифов, юридических условий и технических ограничений такой контроль нужен всегда.

Третий блок предлагает действие: запросить номер заказа, передать обращение инженеру, назначить звонок или сообщить срок следующего ответа. Фраза «Мы вернёмся с информацией» слабее, чем «Проверим статус заказа и ответим до 16:00 12 марта». Точная дата допустима, если её подтвердил сотрудник или внутреннее правило.

Я запрещаю модели самостоятельно менять тональность под раздражённого отправителя. Вежливость должна оставаться спокойной, без признания вины до проверки обстоятельств. Для жалобы полезны поля «факт», «эмоция отправителя», «требуемое действие» и «нужна ли эскалация».

Отдельное правило нужно для вложений. Если письмо ссылается на договор, акт или скриншот, черновик должен сообщить, что документ замечен, но не утверждать его содержание без разбора файла. Нельзя писать «мы исправили ошибку», если модель лишь увидела фразу «ошибка» в тексте.

Подход к формулировкам я разбираю в статье «Искусство промптинга: как правильно формулировать запросы для нейросетей». Для рабочих писем особенно полезны ограничения по формату, источникам данных и условиям передачи человеку.

Как измерить результат без самообмана

Результат нужно оценивать по 4 метрикам: доле правильно определённых категорий, полноте обнаружения срочных писем, времени до первого действия и доле черновиков, принятых после короткой правки. Одна скорость обработки не показывает качество.

Для классификации используют матрицу ошибок. Она показывает, сколько писем из категории «оплата» попало в «документы», а сколько срочных обращений оказалось в плановой очереди. Я начинаю с ручной выборки из 100–200 сообщений, потому что на 10 письмах случайная ошибка слишком сильно меняет процент.

Полноту срочных обращений считаю так: количество найденных срочных писем делю на общее количество срочных писем в проверенной выборке. Точность считаю иначе: правильные срочные метки делю на все сообщения, которым присвоен высокий приоритет. Эти показатели нельзя смешивать.

Время до первого действия измеряется от момента поступления до открытия, передачи ответственному или отправки ответа. Для команды можно задать базовую линию за 5 рабочих дней, затем сравнить её с неделей после запуска. Если сообщений стало меньше в очереди, но выросло число исправлений, автоматизация дала плохой обмен.

Доля принятых черновиков требует ясного определения. Черновик считается принятым, если менеджер изменил не более 2 предложений и не исправлял факты, адресата или срок. Правка одного приветствия и правка суммы, это разные события, их нужно учитывать отдельно.

Модельный кейс: в отделе поддержки с выборкой из 200 писем можно отдельно посчитать 40 срочных сообщений, 70 вопросов по оплате и 90 плановых обращений. Такой разрез показывает, где ошибка влияет на маршрут сильнее: пропуск срочного письма обычно опаснее, чем смешение двух близких тематических меток.

После запуска я смотрю на ошибки раз в 7 дней. Повторяющиеся ошибки группирую по причине: неполная инструкция, неточный справочник, неоднозначное письмо или неверное правило маршрутизации. Менять промпт после каждого единичного сбоя не нужно, иначе команда не поймёт, какое изменение дало эффект.

Практика измерения и внедрения рабочих сценариев подробно разобрана в материале «Как внедрить нейросети в рабочие процессы и личную продуктивность». Там полезно заимствовать принцип постепенного запуска: сначала узкая задача, затем расширение очереди после проверки.

Как выбрать режим работы

Для почты подходят 2 режима: помощник с обязательным подтверждением и автоматическая обработка безопасных писем. Выбор зависит от цены ошибки, наличия справочника и требований к персональным данным.

Я бы начинал с режима помощника. Первые 100–200 писем дают материал для словаря категорий, списка исключений и оценки порогов. Автоматическое перемещение можно подключать после того, как команда понимает причины ошибок, а не просто видит итоговую цифру.

Для финансовых, юридических и кадровых сообщений нужен ручной контроль. В таких письмах встречаются персональные данные, суммы, реквизиты и обязательства. В инструкцию следует добавить маскирование лишних сведений, ограничение доступа к журналу и срок хранения исходных сообщений. Конкретный срок хранения определяется внутренними правилами организации и применимыми требованиями к данным.

Письма с низким риском тоже нужно проверять выборочно. Например, можно вручную просматривать каждое 20-е уведомление, все сообщения с вложениями и все случаи, где уверенность модели ниже 0,8. Это не гарантия безошибочности, а способ быстрее заметить дрейф формулировок и новые типы обращений.

Для повседневных задач полезно сравнить сортировку почты с другими сценариями применения нейросетей. В статье «Как использовать нейросети и чат-боты для решения повседневных задач» хорошо показано, почему результат зависит от заранее описанного процесса, а не от одной короткой команды.

Какие ошибки мешают разгрузить почту

Чаще всего процесс ломают 5 ошибок: слишком широкие категории, отсутствие примеров, смешение фактов и предположений, отсутствие ручного контроля и измерение только времени ответа.

Слишком широкая категория «прочее» скрывает причины нагрузки. Если в неё попадает 35% входящих, руководитель не видит, какой процесс нужно изменить. Я разбиваю её после ручного просмотра 50–100 писем, но оставляю категорию для действительно редких случаев.

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

Модель может уверенно додумать отсутствующий факт. Поэтому поля «найдено в письме», «получено из справочника» и «требует проверки» должны быть разделены. Нельзя объединять их в один гладкий ответ, иначе сотрудник перестанет видеть источник утверждения.

Отдельный риск, повторная обработка одной цепочки. Если письмо пришло с новым сообщением поверх старой переписки, система должна сравнить идентификатор цепочки, дату и текст последнего ответа. Иначе одно обращение попадёт в очередь несколько раз.

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

Заключение: как начать без потери контроля

Разгрузить почту можно за счёт последовательной схемы: 6 этапов обработки, 4 уровня срочности и ручная проверка спорных писем. Я бы начал с одной категории, например новых запросов, собрал выборку из 100–200 сообщений и зафиксировал, что считается правильной классификацией.

После этого следует добавить черновики ответов, но оставить отправку за менеджером. Через 7 дней нужно сравнить точность категорий, полноту срочных обращений, время до первого действия и число фактических исправлений. Если показатели улучшаются, очередь можно расширять. Если нет, сначала исправляется инструкция и справочник, а не повышается степень автоматизации.

Веб-чат SoftChat подходит для проверки разных формулировок и переключения моделей в одном разговоре. Для полноценной обработки внешней почты понадобится отдельный рабочий контур, правила доступа и журнал решений. Такой порядок позволяет получить экономию времени, сохранив понятную ответственность за каждое отправленное письмо.