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

Обновлено в 2025 году.

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

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

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

Контур обработки писемОт входящего сообщения до проверки сотрудникомВходящиеписьмаКатегорияи срочностьСутьи поляЧерновикответаПроверкачеловекомЖурнал: поля, версия инструкции, исправления, время
Инфографика

Что именно автоматизировать в почтовом потоке

Рабочий процесс сортировки входящих писем и проверки черновиков

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

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

Затем из письма извлекаются факты. Минимальный набор обычно включает тему, краткое описание проблемы, номер заказа, имя отправителя, срок реакции и требуемое действие. Поля From, To, Date и Subject относятся к стандартной структуре электронного письма, описанной в RFC 5322. Текст сообщения и вложения требуют отдельной проверки, поскольку одинаковая тема может скрывать разные задачи.

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

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

Как выглядит рабочий контур

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

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

После очистки нейросеть получает инструкцию с перечнем категорий и форматом результата. Для структурированного ответа удобно использовать поля category, summary, urgency, missing_data и draft. Даже если результат хранится в другом формате, такая логика помогает отделить факты от предположений.

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

В SoftChat доступен веб-чат с потоковой выдачей ответов через SSE и переключением моделей в рамках беседы. Вкладка «Текст» работает для текстовых запросов, а разделы «Видео», «Код», «Аудио» и «Презентации» в каталоге отмечены как будущие или разрабатываемые режимы, поэтому их нельзя описывать как готовый рабочий контур для обработки писем.

Схема обработки входящего письма от классификации до проверки черновика

Как задать категории и правила классификации

Для пилота достаточно 6–10 устойчивых категорий, каждая с коротким описанием и 3–5 примерами формулировок. Слишком широкий список из 20–30 меток создаёт пересечения и повышает число ручных исправлений.

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

Перед запуском соберите архив писем и обезличьте имена, телефоны, адреса и номера документов. Затем разметьте часть сообщений вручную. Для небольшой команды достаточно начать с 100–300 писем, если они покрывают основные типы обращений и сезонные исключения. Это не универсальная норма, а практический диапазон для первичной проверки правил.

Пример структуры категорий:

Категория Признак в письме Действие Что проверить вручную
Новый запрос Описаны потребность, бюджет или объём Передать в продажи Полноту контактов и срок ответа
Поддержка Есть ошибка, вопрос по работе или просьба о помощи Передать в поддержку Технические детали и номер обращения
Оплата Упомянут счёт, платёж, возврат или закрывающие документы Направить в финансовую очередь Сумму, дату и реквизиты
Закупка Есть товар, количество, срок поставки или условия Передать закупкам Единицы измерения и спецификацию
Претензия Описан ущерб, нарушение срока или несоответствие Повысить приоритет Факты, документы и дедлайн
Не по теме Запрос не относится к зонам ответственности Вернуть отправителю или перенаправить Причину исключения

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

Как готовить черновик ответа без выдуманных фактов

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

В первой части нужно кратко показать, что именно понял исполнитель. Например: «Вы запрашиваете срок поставки 40 комплектов и просите прислать обновлённый счёт». Число 40 в таком тексте допустимо только тогда, когда оно действительно есть в исходном письме.

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

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

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

Как маршрутизировать письма и соблюдать сроки

Маршрутизация должна опираться минимум на 2 признака, содержание обращения и правило ответственности. Одной темы письма недостаточно, поскольку цепочка с темой «Счёт» может относиться к продажам, финансам или закупкам.

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

SLA лучше переводить в измеримые интервалы. Формулировка «быстро ответить» не подходит для контроля. Запись «первичная реакция в течение 2 часов в рабочее время» позволяет сравнивать результат пилота по дням и сменам. Для критичных обращений можно установить 30 минут, для обычных запросов, 4 рабочих часа.

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

Как измерить эффект пилота

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

Не смешивайте скорость и качество. Черновик, созданный за 20 секунд, бесполезен, если оператор тратит 5 минут на исправление цены и даты. Поэтому измеряйте медианное время проверки, а не только скорость генерации. Медиана меньше зависит от редких длинных писем и крупных вложений.

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

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

Внутренний эффект стоит считать через часы, а не через абстрактную «экономию ресурсов». Если оператор тратит 3 минуты на сортировку одного письма, обработка 200 сообщений занимает 600 минут, то есть 10 часов без учёта перерывов. Это расчёт нагрузки, а не обещание конкретного результата нейросети.

Что проверить перед запуском

Перед запуском нужны 4 уровня контроля: доступ к данным, корректность инструкций, журналирование решений и право человека остановить автоматический сценарий.

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

Инструкция должна содержать запрет на выдумывание и понятный формат ответа. Проверьте минимум 30 сложных сообщений, включая короткие письма, длинные цепочки, несколько вопросов в одном обращении и противоречивые данные. Отдельно протестируйте вложения, HTML-разметку и автоматические подписи.

Журнал должен сохранять исходный идентификатор, результат классификации, извлечённые поля, версию инструкции и исправления оператора. Без этих данных нельзя понять, почему письмо попало в неправильную очередь. Дата и время особенно нужны при проверке SLA.

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

Как запустить пилот на одном канале

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

В первый день зафиксируйте исходные показатели: объём писем, среднее и медианное время сортировки, долю обращений с нарушенным SLA. В течение первой недели собирайте исправления операторов и не меняйте правила после каждой отдельной ошибки. Иначе невозможно понять, какое изменение повлияло на результат.

Во второй неделе разделите сообщения на обычные и сложные. Для обычных обращений проверяйте черновик по короткой форме, для сложных фиксируйте причину эскалации. Условный пример: если из 120 писем 30 содержат вложения, сравнивайте качество отдельно для 90 сообщений без вложений и для 30 сообщений с файлами. Разные типы входных данных нельзя объединять в одну оценку.

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

Вывод

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

Я бы начинал с одного почтового канала, 6–10 категорий и режима черновиков. Затем сравнил бы показатели за 10 рабочих дней с исходной нагрузкой, разобрал матрицу ошибок и отдельно проверил претензии, оплату и письма с вложениями. Такой путь даёт команде конкретные данные для решения, расширять сценарий или оставить его в узкой очереди.

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