Сортировка обращений нейросетью: почта, мессенджеры, CRM в 2026
Стендфрист: Практическая схема сортировки, суммаризации и маршрутизации обращений с сохранением контекста и ручной проверки.
Поток обращений редко выглядит как аккуратная очередь. В одной папке смешиваются вопросы о доставке, возвратах, оплате и технических сбоях. В мессенджере клиент может прислать 6 коротких сообщений вместо одного описания проблемы, а в CRM часть сведений уже будет записана в карточке. Нейросеть помогает привести такой поток к единому виду, если заранее задать поля, категории и правила передачи человеку.
Я рассматриваю автоматизацию как помощника для первичного разбора, а не как замену сотруднику поддержки. Система может выделить тему, кратко пересказать историю и предложить маршрут. Решение по спорным, финансовым и юридическим вопросам должно оставаться за ответственным специалистом. Базовые принципы постановки задачи разобраны в материале о формулировке запросов для нейросетей, а ниже я применю их к потоку обращений.
Что именно можно автоматизировать
Автоматизировать разумно 4 операции: классификацию, извлечение полей, краткое резюме и предложение маршрута. Такой порядок уменьшает риск, что модель сразу начнёт отвечать клиенту без понимания сути запроса.
Сначала обращению присваивается одна основная категория. Например, «оплата», «доставка», «возврат», «доступ», «ошибка» или «другое». Для каждой категории полезно задать описание и 2–3 примера границ. Вопрос «Как изменить адрес после оформления?» относится к доставке, а сообщение «Деньги списали дважды» требует категории оплаты, даже если клиент упоминает заказ.
Затем нейросеть извлекает факты в фиксированные поля:
- идентификатор заказа или договора;
- канал и время последнего сообщения;
- просьба клиента, предполагаемая причина и требуемое действие;
- тональность, признаки срочности и наличие персональных данных;
- уже выполненные шаги и обещанный срок ответа.
Пустое поле должно оставаться пустым. Нельзя просить модель додумывать номер заказа, дату платежа или причину отказа. Если в письме сказано «вчера», лучше сохранить это как относительное указание и передать сотруднику точную дату из метаданных CRM.
Суммаризация нужна для быстрого чтения, а не для красивого пересказа. Рабочий шаблон состоит из 4 строк: проблема, факты, история действий, следующий вопрос к клиенту. Такой формат удобнее длинного абзаца, поскольку оператор сразу видит, что известно, а что нужно уточнить. Больше приёмов автоматизации текстовых задач собрано в статье о генерации текста и проверке результата.
Как сохранить контекст между каналами
Контекст сохраняется, когда обращение описывается минимум 6 устойчивыми полями, а не одним пересказом на свободную тему. Текст сообщения без даты, автора и истории действий быстро теряет смысл при передаче между отделами.
Для почты полезны тема, адрес отправителя, цепочка сообщений, время, вложения и идентификатор письма. Заголовок письма нельзя считать достаточным контекстом: клиент может продолжить старую переписку с новой проблемой. В мессенджере нужны идентификатор диалога, имя пользователя, временная последовательность сообщений и ссылка на связанную карточку CRM. Внутри CRM добавляются статус, ответственный сотрудник и предыдущие обращения.
Я советую разделять контекст на 3 слоя:
- факты, которые прямо указаны клиентом;
- выводы системы, например предполагаемую тему или уровень срочности;
- действия сотрудника, включая заданные вопросы и обещания.
У каждого вывода должен быть источник. Формулировка «клиент уже отправлял документы» полезна только тогда, когда рядом видны дата и сообщение, подтверждающее факт. Если источник не найден, поле получает значение «не указано».
Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает письмо из 9 сообщений о задержке поставки. При кратком пересказе без временной шкалы легко перепутать дату обещанной доставки и дату последнего звонка. Формат с полями «событие», «дата», «источник» и «следующее действие» сохраняет порядок событий и сокращает число повторных вопросов внутри команды.
Для визуальной проверки потока удобно использовать такую схему:
| Этап | Что получает специалист | Что проверяется вручную |
|---|---|---|
| Приём | Сообщение, канал, время, идентификатор | Полнота исходных данных |
| Сортировка | Категория, срочность, ответственный маршрут | Корректность категории |
| Резюме | Факты, история, незакрытый вопрос | Нет ли потери смысла |
| Передача | Карточка для отдела или сотрудника | Правильный адресат и срок |
Подход к рабочим сценариям лучше строить постепенно. В материале о внедрении нейросетей в рабочие процессы я подробно разбираю, почему сначала стоит описать повторяемый процесс, а потом выбирать инструмент.
Как выбрать маршрут для обращения
Маршрутизация должна учитывать 2 параметра: тему обращения и цену ошибки. Вопрос о статусе доставки можно направить по категории, а запрос на возврат крупной суммы требует дополнительной проверки независимо от уверенности модели.
На практике встречаются 4 схемы. Их различия лучше зафиксировать в таблице до запуска:
| Подход | Подходит для | Сильная сторона | Ограничение |
|---|---|---|---|
| Жёсткие правила | Фразы «счёт», «возврат», «пароль» | Предсказуемый результат | Плохо работает с двусмысленным текстом |
| Классификация нейросетью | Свободные обращения и длинные письма | Учитывает смысл сообщения | Может ошибиться на редкой теме |
| Гибридная схема | Поток с категориями и исключениями | Правила закрывают рискованные случаи | Требует настройки порогов |
| Ручной разбор | Жалобы, спорные платежи, юридические запросы | Ответственность у специалиста | Очередь растёт при большом объёме |
Гибридный вариант обычно проще контролировать. Например, уверенность выше 0,85 позволяет отправить обращение в обычную очередь, диапазон от 0,60 до 0,85 направляет его на быструю проверку, а значение ниже 0,60 оставляет сообщение человеку. Эти числа не являются универсальным стандартом, их нужно проверить на собственной выборке.
Для каждого отдела задаётся отдельный маршрут. Поддержка получает технические ошибки и вопросы по статусу, финансовая команда проверяет платежи и возвраты, менеджер по работе с клиентами рассматривает конфликтные обращения. Если категорий становится больше 12, я рекомендую проверить, не раздроблена ли таксономия чрезмерно. Сотруднику трудно стабильно различать близкие классы вроде «изменение заказа» и «отмена заказа», если в инструкции нет чёткой границы.
В SoftChat можно переключать модели по диалогу и получать потоковый ответ в веб-чате. Это удобно для ручной проверки нескольких вариантов инструкции: я сравниваю, как разные модели выделяют категорию, срочность и незакрытый вопрос. Сам чат не следует выдавать за готовый конвейер CRM, если задача требует автоматической передачи данных между системами.
Где нужен ручной контроль
Ручная проверка обязательна минимум в 5 случаях: деньги, юридические обязательства, персональные данные, конфликтная тональность и низкая уверенность классификации. Здесь ошибка может стоить дороже, чем сэкономленные минуты.
Финансовое обращение нельзя маршрутизировать только по слову «оплата». Сообщение может касаться двойного списания, отменённой транзакции, мошеннического платежа или обычного вопроса о сроке зачисления. Эти темы требуют разных инструкций и уровня доступа.
Юридические формулировки тоже опасны для автоматического ответа. Фразы «претензия», «требую компенсацию» и «нарушены условия договора» должны поднимать приоритет проверки. Нейросеть может выделить признаки и подготовить резюме, но сотрудник проверяет договор, даты и фактические обязательства.
Персональные данные нужно обрабатывать по утверждённой политике организации. В России требования к обработке таких данных связаны, в частности, с 152-ФЗ. Я бы заранее определил, какие поля можно передавать в анализ, какие нужно маскировать, а какие запрещено сохранять в рабочем журнале.
Модельный кейс: интернет-магазин получает 1 000 обращений за неделю, из них 70 содержат номера заказов и телефонов. Для иллюстрации можно настроить маскирование этих значений в резюме, а сотруднику оставить ссылку на защищённую карточку CRM. Такой процесс не доказывает полное соответствие требованиям автоматически, зато отделяет аналитический текст от исходных реквизитов.
Человек должен видеть исходное сообщение рядом с кратким резюме. Если интерфейс показывает только вывод модели, оператору трудно заметить пропущенное отрицание, неверную дату или условие в приложенном документе. Для спорных случаев полезна кнопка «вернуть на уточнение» с обязательным указанием причины ошибки.
Как измерять качество сортировки и резюме
Для контроля достаточно 5 показателей: точность категории, полнота обнаружения срочных сообщений, доля ручных исправлений, время до назначения и число повторных обращений. Один показатель не описывает качество всей цепочки.
Точность отвечает на вопрос, как часто выбранная категория верна. Полнота показывает, сколько действительно срочных обращений система нашла среди всех срочных сообщений. Эти величины могут конфликтовать: строгий фильтр даст меньше ложных срабатываний, но пропустит часть важных писем.
Долю ручных исправлений стоит считать отдельно по категориям. Если среднее значение равно 8%, это не означает одинаковое качество: для доставки может быть 3%, а для возвратов 22%. Разбивка по каналам выявляет другой источник ошибок. Короткие сообщения из мессенджера часто требуют больше уточнений, чем письма с темой и подписью.
Модельный кейс: команда проверяет 300 исторических обращений, среди которых 60 относятся к срочным. Система нашла 54 срочных сообщения, но 9 из них были ошибочно помечены как срочные. Полнота составит 90%, однако для решения о запуске нужно дополнительно посчитать точность, стоимость ручной проверки и последствия пропуска одного критичного обращения.
Для тестовой выборки полезно включить пограничные примеры: одно сообщение с двумя темами, длинную цепочку из 15 писем, саркастичную жалобу, неполный номер заказа и обращение без вопросительного знака. Проверка только на ясных письмах создаёт завышенное ощущение качества.
Промпт и формат ответа нужно версионировать. Если поменялась инструкция, модель или список категорий, рядом сохраняется дата изменения и результат повторной проверки. В статье о повседневном применении нейросетей есть полезный принцип: сначала определить повторяемую операцию, затем измерить её до автоматизации и после.
Как запустить процесс без потери управляемости
Рабочий запуск можно разделить на 4 этапа и начать со 100–300 обезличенных обращений, а не со всего потока. Такой объём позволяет увидеть типовые ошибки без риска сразу изменить работу всей поддержки.
На первом этапе формируется словарь категорий. Для каждого класса фиксируются название, положительные примеры, исключения и целевой маршрут. Категория «другое» нужна обязательно, иначе модель будет насильно помещать непонятные сообщения в ближайший класс.
На втором этапе задаётся схема результата. Например:
Категория: …
Уверенность: …
Срочность: низкая / средняя / высокая
Факты: …
Что уже сделано: …
Что нужно уточнить: …
Маршрут: …
Причина ручной проверки: …
На третьем этапе команда сравнивает результат с разметкой двух сотрудников. Разногласия нужно обсуждать до запуска, иначе система будет обучаться на неустойчивом эталоне. Если один специалист относит «не пришёл возврат» к оплате, а другой к возвратам, в инструкции должна появиться явная граница по типу операции.
На четвёртом этапе автоматизируется только низкорисковая часть. Сообщения с высокой уверенностью идут в обычную очередь, сомнительные остаются у оператора, а финансовые и юридические темы получают обязательную проверку. Через 7 дней собираются исправления, через 30 дней сравниваются показатели с исходной линией.
Модельный кейс: отдел из 12 операторов запускает сортировку сначала для вопросов о статусе заказа и адресе доставки. За 2 недели он собирает исправления, находит 4 повторяющиеся ошибки в категориях и меняет инструкцию до подключения возвратов. Такой порядок снижает ширину эксперимента и даёт понятную точку остановки.
Что бы я сделал на вашем месте
Я бы начал с одной очереди, 6 категорий и обязательного показа исходного сообщения рядом с резюме. Через 14 дней посмотрел бы на точность по каждой теме, долю ручных исправлений и число пропущенных срочных обращений. Если показатели стабильны, добавил бы второй канал и отдельное правило для финансовых запросов.
Для проверки формулировок можно использовать веб-чат SoftChat, где доступны разные модели и потоковое отображение ответов. Но границы ответственности я бы закрепил отдельно: нейросеть сортирует и объясняет, сотрудник подтверждает маршрут, меняет данные и отправляет клиенту финальный ответ. Такая схема сохраняет контекст, делает ошибки видимыми и позволяет расширять автоматизацию без резкого отказа от ручного контроля.