Стендфирст: Практическая схема для поддержки, продаж и административных запросов, от разметки входящих писем до контроля черновика ответа.

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

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

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

Что именно сортирует автоматическая система

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

Автоматическая сортировка распределяет обращение минимум по 4 полям: теме, срочности, ответственному направлению и следующему действию. Чем точнее описаны эти поля, тем меньше ручных исправлений после работы модели.

Для поддержки обычно достаточно начать с 6–10 категорий, а не пытаться описать весь справочник компании. Подходящие классы могут выглядеть так: оплата, доставка, возврат, техническая проблема, доступ к аккаунту, претензия, предложение о сотрудничестве. Для отдела продаж набор будет другим: новый запрос, действующий клиент, продление, запрос расчёта, партнёрство.

Я советую разделять тему и действие. Письмо «не пришёл счёт» относится к оплате, а действие может быть «проверить отправку документа». Запрос «нужен расчёт на 50 пользователей» относится к продажам, а действие, вероятно, связано с подготовкой коммерческого предложения. Одна категория не должна пытаться заменить весь маршрут.

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

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

Как устроить обработку письма по шагам

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

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

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

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

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

Гипотетический пример: при 100 входящих письмах 72 могут получить уверенную тему, 18 потребуют ручной проверки, а 10 окажутся вне справочника. Такая пропорция служит примером настройки отчёта, а не обещанием результата. Её нужно заменить фактическими данными после тестовой недели.

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

![Схема обработки обращения: от письма к маршруту и черновику](инфографика: схема)

Правила, классификатор или гибрид

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

Подход Когда применять Сильная сторона Ограничение
Правила по словам и полям До 3–5 устойчивых признаков, например номер заказа или служебный адрес Легко проверить причину маршрута Слабее работает с синонимами и длинным контекстом
Классификатор на основе текста От 6 категорий и при большом разнообразии формулировок Понимает смысл письма, даже если слова отличаются Нужны примеры, контроль уверенности и разбор ошибок
Гибридная схема Очередь содержит срочные исключения и типовые обращения Критичные правила срабатывают предсказуемо, остальные тексты разбирает модель Архитектура требует согласования приоритетов

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

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

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

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

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

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

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

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

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

Как готовить черновик ответа без лишнего риска

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

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

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

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

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

Модельный кейс: письмо «поменяйте адрес доставки заказа 48152 до 18:00» можно превратить в результат из 5 полей: категория, срочность, найденный номер, недостающие сведения и черновик. Если адрес уже присутствует в системе, сотруднику останется проверить полномочия и применить изменение по внутренней процедуре. Сам текст письма не доказывает, что операцию разрешено выполнять.

Как измерять качество после запуска

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

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

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

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

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

Как выбрать подход для своей очереди

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

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

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