Практическая схема для продаж, поддержки и администраторов, от определения срочности до проверенного черновика ответа.

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

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

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

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

Что именно делает нейросеть с входящим письмом

Визуальная схема сортировки входящих писем по признакам

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

В классическом формате письма есть заголовки From, To, Date и Subject. Их структура описана в RFC 5322, опубликованном в октябре 2008 года. Тело сообщения может содержать обычный текст, HTML и вложения, а правила MIME для разных частей письма закреплены в документах RFC 2045–2049, опубликованных в 1996 году.

Для автоматизации я выделяю следующие поля:

  1. Срочность. Например, высокая, если в сообщении есть срок сегодня, остановка операции или риск финансовой потери.
  2. Тема. Это предмет обращения, например оплата, доставка, возврат, доступ, техническая ошибка или партнёрский запрос.
  3. Намерение. Отправитель просит объяснение, действие, документ, расчёт или подтверждение.
  4. Следующий шаг. Ответить шаблоном, передать специалисту, запросить недостающие сведения или оставить письмо в обычной очереди.

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

При настройке я прошу модель возвращать короткие значения полей, а не свободное эссе. Для одного письма достаточно 20–40 слов объяснения, если рядом находятся метки, уровень уверенности и рекомендуемый маршрут. Подход к созданию таких форматов подробно разобран в материале о задачах и проверке результата генерации текста.

Как устроен конвейер сортировки писем

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

Почтовый сервер может отдавать сообщения через IMAP, а отдельные системы используют API почтового провайдера. Актуальная спецификация IMAP4rev2 опубликована в RFC 9051 в июне 2021 года. На практике полезно сохранять идентификатор письма, дату, адрес отправителя, тему, наличие вложений и исходную папку.

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

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

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

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

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

Явный срок распознаётся по датам, времени и словам вроде «до 16:00», «сегодня», «к началу смены». Цена задержки определяется по последствиям: остановится отгрузка, возникнет просрочка платежа, клиент не получит доступ или нарушится договорённый процесс. Стадия операции помогает различать предварительный вопрос и уже возникшую проблему.

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

  • Высокая срочность, реакция в пределах установленного SLA, например 15 или 30 минут.
  • Средняя срочность, обработка в течение рабочего дня, например до 8 часов.
  • Плановая задача, ответ в обычном порядке или после уточнения данных.

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

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

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

Как выделять тему и очередь

Для первого запуска достаточно 6–8 тем, иначе сотрудники будут тратить больше времени на выбор метки, чем на чтение письма. Категории должны соответствовать реальным очередям, ответственным и правилам ответа.

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

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

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

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

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

Как готовить шаблонный ответ

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

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

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

Для типовых сообщений полезно задать длину ответа от 120 до 180 слов, допустимое обращение и запрет на лишние рекламные формулировки. Длину можно менять по типу очереди. Техническое уведомление часто укладывается в 80 слов, а запрос на коммерческое предложение требует нескольких уточняющих вопросов.

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

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

Как проверять качество и безопасность

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

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

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

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

Содержание почты часто включает имя, телефон, адрес, номер договора и сведения о платеже. Федеральный закон № 152-ФЗ «О персональных данных» принят 27 июля 2006 года, поэтому до запуска нужно определить правовое основание обработки, сроки хранения и круг доступа. В тестовой выборке я заменяю персональные данные на маркеры вроде «КЛИЕНТ_1» и «НОМЕР_ДОГОВОРА».

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

Что бы я сделал на вашем месте

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

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

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

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

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