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

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

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

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

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

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

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

Для контроля удобно требовать структурированный результат:

{
  "category": "возврат",
  "priority": "средняя",
  "order_number": "не найден",
  "customer_intent": "узнать условия возврата",
  "draft_answer": "...",
  "needs_human_review": true,
  "reason": "в письме нет номера заказа"
}

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

Как настроить классификацию писем и заявок

Схематичный поток обработки входящих обращений от письма до сотрудника поддержки

Для первого запуска достаточно 5–8 категорий, порога уверенности 0,80 и отдельной очереди для сообщений, где не хватает данных. Слишком подробная схема на старте создаёт больше ошибок, чем пользы.

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

Пример рабочего справочника:

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

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

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

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

Как получать пригодный черновик ответа

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

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

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

Черновик стоит проверять по 4 вопросам:

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

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

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

Как передать обращение нужному сотруднику

Маршрутизация должна опираться минимум на 2 признака, тему и срочность, а для сложных случаев нужна отдельная очередь эскалации. Простого правила «отправить всё менеджеру» недостаточно, потому что оно создаёт новое ручное узкое место.

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

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

Модельный кейс: интернет-магазин получает письмо с темой «Где заказ?» и текстом о доставке через 2 дня. Если номер заказа найден, обращение можно направить в логистику с обычным приоритетом. Если клиент пишет повторно через 24 часа и указывает, что заказ нужен к конкретной дате, добавляется признак эскалации. Это пример настройки правил, а не описание реального клиента.

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

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

Как измерять качество и экономию времени

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

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

Доля принятых черновиков показывает, сколько текстов сотрудник отправил после небольшой правки. Если из 50 черновиков приняты 35, показатель составляет 70%. Сам по себе результат не доказывает пользу: нужно проверить, не стали ли сотрудники принимать тексты быстрее ценой роста повторных обращений.

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

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

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

Как защитить данные и границы автоматизации

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

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

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

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

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

Как провести пилот без перестройки всей поддержки

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

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

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

Какое решение я бы выбрал для потока обращений

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

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