Как ИИ сортирует обращения и готовит черновики ответов

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

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

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

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

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

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

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

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

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

Как построить классификацию обращений

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

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

Приоритет задаю через наблюдаемые признаки:

Пороги в таблице являются операционной настройкой, а не универсальным стандартом. Для службы с графиком 9:00–18:00 «24 часа» может означать следующий рабочий день, а для круглосуточной поддержки потребуется другое правило.

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

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

Как отделить срочные задачи от обычных

Срочность лучше определять по условиям, а не по эмоциональности текста, поэтому я использую 3 независимых признака: последствия, срок и статус клиента.

Фраза «Срочно ответьте!» сама по себе не доказывает высокий приоритет. А вот сочетание «оплата списана», «доступ закрыт» и «завтра заканчивается срок подачи документов» уже даёт модели проверяемые основания для эскалации. В инструкции следует перечислить слова и конструкции, которые требуют дополнительной проверки, но не превращать любой резкий тон в аварийный случай.

Для каждого канала задаю отдельные правила:

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

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

Условный пример: интернет-магазин получает 300 сообщений в день, из них 20 связаны с оплатой. Если правило выделяет эти 20 писем в отдельную очередь, специалист начинает с финансовых вопросов, а не просматривает все 300 сообщений подряд. Это модель расчёта нагрузки, а не обещание конкретного результата.

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

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

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

В инструкции я задаю 5 ограничений:

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

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

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

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

Что выбрать: ручную обработку, правила или нейросеть

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

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

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

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

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

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

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

Проверять нужно случайную выборку минимум из 100 сообщений. В ней отдельно считаю:

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

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

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

Мой рабочий вывод простой: автоматизировать нужно первый просмотр, а не ответственность. Я бы начал с одной очереди, 6 категорий и черновиков для нейтральных вопросов. Через неделю сравнил бы 4 показателя с базовой линией, оставил безопасные сценарии и только потом расширял охват. Такой порядок даёт понятную цену ошибки и показывает, где нейросеть действительно экономит время.