Как ИИ сортирует обращения из почты, мессенджеров и CRM
Схема классификации помогает быстрее находить срочные сообщения, передавать их нужному отделу и проверять качество решений по измеримым показателям.
Поток обращений редко приходит в одном виде. В почте клиент присылает длинное описание проблемы, в мессенджере пишет короткое «не могу войти», а в CRM уже есть поля, история контактов и статус сделки. Ручная сортировка ломается на объёме: оператору приходится прочитать текст, определить тему, оценить срочность, найти ответственного и занести результат в рабочую систему. Нейросеть может подготовить такую классификацию за один проход, если заранее задать категории, формат ответа и правила передачи спорных случаев человеку.
Я рассматриваю ИИ здесь как помощника первого контакта. Он не принимает решение о возврате денег, блокировке аккаунта или юридическом ответе без контроля сотрудника. Его задача уже: разобрать входящий текст, извлечь признаки и выдать структурированный результат, который легко проверить.
Что именно делает нейросеть при сортировке обращений
Нейросеть обычно выполняет 4 операции: определяет тему, оценивает срочность, выбирает отдел и формирует краткое резюме. Для устойчивой работы я задаю минимум 5 полей в результате, включая категорию, приоритет, уверенность, причину решения и следующий шаг.
Сначала система выделяет смысл сообщения. Фраза «после оплаты доступ не появился» относится к платежу или к технической ошибке, а «карта списала деньги дважды» требует отдельной категории для двойного списания. Такие различия лучше описывать примерами, потому что одно ключевое слово редко передаёт весь контекст.
Затем модель присваивает обращению класс. В простом варианте это одна метка, например «доставка», «оплата» или «доступ». В рабочем варианте полезна иерархия: сначала общий блок, затем подкатегория. Для платежей это могут быть «не прошла оплата», «повторное списание» и «возврат».
Третий результат, срочность, должен иметь понятную шкалу. Я предпочитаю 3 уровня, чтобы оператор не тратил время на спор о разнице между «средне» и «выше среднего». Четвёртое поле, отдел, связывает категорию с ответственным маршрутом. Пятое поле, объяснение, показывает, какие слова или факты повлияли на решение.
Для точности промпта полезно заранее описать входные данные и ожидаемый формат. Практические приёмы подробно разобраны в материале о формулировке запросов для нейросетей. Я обычно прошу вернуть короткий JSON или таблицу, но каждое поле должно иметь допустимые значения. Свободный ответ на 5 абзацев неудобен для дальнейшей проверки.
Как подготовить категории и правила классификации
Рабочий справочник обычно содержит 6–10 основных категорий и отдельные правила для пограничных сообщений. Если категорий больше 20, я сначала объединяю близкие темы, иначе растёт число пересечений и спорных меток.
Начинать стоит с истории обращений за 2–4 недели. Из неё можно выбрать повторяющиеся причины контакта, а затем проверить, какие темы требуют разных действий. «Не пришёл заказ» и «хочу изменить адрес доставки» связаны с одной областью, но направляются разным сотрудникам и имеют разный следующий шаг.
Для каждой категории я фиксирую 4 элемента:
- название, которое понимает оператор;
- короткое определение, что входит в класс;
- 2–5 положительных примеров;
- 1–2 похожих, но исключённых случая.
Отдельно задаю метку «нужна проверка». Она нужна для сообщений, где мало данных, конфликтуют признаки или клиент просит действие с финансовыми последствиями. Модель не должна угадывать номер заказа, сумму возврата и причину блокировки. Если сведений нет, корректный ответ должен сообщать о нехватке данных.
| Подход к категориям | Когда применять | Плюс | Ограничение |
|---|---|---|---|
| 5–7 широких классов | Небольшой поток до нескольких сотен сообщений в неделю | Быстрый старт и простая проверка | Мало деталей для маршрутизации |
| 8–15 тематических классов | Несколько отделов и повторяющиеся типы запросов | Удобнее назначать ответственного | Нужны примеры пограничных случаев |
| Иерархия из 2 уровней | Большой архив с разными продуктами | Сохраняет общий порядок и детали | Ошибка на первом уровне влияет на второй |
| Свободное описание без меток | Разовая аналитика и исследование тем | Можно заметить неожиданные формулировки | Результат трудно сравнивать по неделям |
Модельный кейс: для очереди из 240 сообщений можно начать с 8 классов, проверить 30 примеров на каждый спорный маршрут и после этого добавить подкатегории. Это не обещание конкретной экономии, а безопасная последовательность настройки: сначала небольшой словарь, затем проверка ошибок, потом расширение.
Категории не должны повторять структуру отдела один к одному. Клиентская тема описывает содержание обращения, а маршрут показывает, кто отвечает за следующий шаг. Один класс «возврат» может попадать к поддержке, бухгалтерии или менеджеру сделки, если в тексте есть разные условия.
Как выделять срочные запросы
Срочность лучше определять по наблюдаемым признакам и 3 уровням, а не по эмоциональности письма. Слова «срочно» и несколько восклицательных знаков сами по себе не доказывают высокий приоритет.
Я разделяю признаки на фактические и контекстные. К фактическим относятся остановка услуги, двойное списание, утечка доступа, невозможность выполнить оплату или приближающийся срок. К контекстным относятся повторное обращение, отсутствие ответа после первого контакта и наличие действующего инцидента.
Пример правил может выглядеть так:
- высокий приоритет: финансовая ошибка, подозрение на несанкционированный доступ, массовый сбой или дедлайн в течение 2 часов;
- обычный приоритет: проблема мешает работе одного пользователя, но есть временный обходной путь;
- низкий приоритет: вопрос о функции, документации, настройках или будущем изменении.
Такие сроки являются внутренней настройкой команды, а не универсальным нормативом. Для одного сервиса «2 часа» означает реакцию до конца смены, для другого требуется ответ за 15 минут. Поэтому я прошу модель указывать причину уровня и цитировать короткий фрагмент исходного сообщения, а не выдавать одно слово «срочно».
Граница между приоритетами должна быть проверяемой. Если клиент пишет «не работает у всех сотрудников», система должна поднять уровень даже без слова «авария». Если человек спрашивает о функции, которая появится через месяц, эмоциональный тон не превращает запрос в инцидент.
Как маршрутизировать обращения по отделам
Маршрутизация строится на 4 полях: тема, продукт или услуга, требуемое действие и ответственная команда. Чем точнее описаны эти поля, тем меньше ручных пересылок между поддержкой, продажами, оплатой и техническими специалистами.
Я разделяю маршрут и готовый ответ. На первом этапе нейросеть может сообщить: «отдел оплаты, проверить транзакцию и запросить идентификатор операции». Это ещё не подтверждение возврата и не обещание результата. Решение остаётся у сотрудника, у которого есть доступ к внутренним данным и правилам компании.
Для каждого маршрута полезно установить условие передачи. Например, сообщения о списании без услуги направляются в оплату, вопросы о настройке доступа остаются у поддержки, а запрос на корпоративное предложение передаётся продажам. Если текст содержит два разных вопроса, модель должна вернуть главный маршрут и вторую тему отдельным полем.
Модельный кейс: компания из сферы логистики, около 200 сотрудников, может получать заявки о доставке, оплате и изменении адреса в одном общем ящике. Для такого потока разумно добавить поле «тип действия», чтобы отдел видел разницу между консультацией, исправлением данных и претензией. Число сотрудников здесь служит иллюстрацией масштаба, а не описанием проверенного клиента.
Почта, мессенджер и CRM часто передают разные наборы данных. В письме есть тема и подпись, в чате может быть только одно предложение, в CRM доступны номер сделки и предыдущий статус. Поэтому в промпте я явно указываю, какие поля могут отсутствовать. Пустой номер заказа должен обозначаться как «нет данных», а не заменяться догадкой.
Такой подход согласуется с практикой внедрения нейросетей в рабочие процессы: сначала описывается повторяемая операция, затем вводится контроль результата и только после этого оценивается возможность масштабирования.
Как проверить качество классификации
Качество нельзя оценивать по одному удачному ответу; для первой проверки я беру минимум 100 размеченных сообщений и считаю точность, полноту и F1 для каждой важной категории.
Точность отвечает на вопрос: сколько сообщений с данной меткой действительно относятся к ней. Полнота показывает, какую долю всех сообщений класса система нашла. Если из 40 срочных запросов обнаружены 36, полнота равна 90%. Если среди 45 сообщений, помеченных как срочные, правильными оказались 36, точность равна 80%. Эти две цифры раскрывают разные ошибки.
F1 объединяет точность и полноту в одном показателе, но среднее значение по всем классам может скрыть проблему. Категория «прочее» часто получается большой и лёгкой, а редкий класс «двойное списание» остаётся слабым. Поэтому я смотрю на каждую категорию отдельно и строю матрицу ошибок: какие пары меток модель путает чаще всего.
Разметка тестовой выборки должна быть независимой от самой модели. Один сотрудник назначает правильную категорию, второй проверяет спорные записи. Если согласие между людьми низкое, проблема находится в справочнике, а не в тексте запроса. В таком случае сначала уточняются определения и примеры.
Для срочности я добавляю стоимость ошибки. Пропустить сообщение о двойном списании может быть опаснее, чем ошибочно поднять приоритет обычного вопроса. Значит, для финансовых и связанных с доступом классов нужен более строгий порог уверенности и обязательный просмотр человеком.
Практика проверки результата генерации описана в статье о нейросети для создания текста и контроле ответа. Для сортировки я переношу оттуда главный принцип: черновик модели считается рабочим только после сверки с исходным сообщением.
Как начать настройку без автоматизации всего потока
Я запускаю процесс в 2 контура: сначала проверяю классификацию на обезличенных примерах, затем отдаю сотруднику только подготовленные метки и резюме. Передача писем между системами требует отдельной технической схемы, которой нельзя приписывать обычному чату без подтверждённой интеграции.
Для ручной настройки SoftChat можно использовать как веб-чат с потоковой выдачей ответа и переключением моделей внутри разговора. Я загружаю в диалог небольшую подборку обезличенных обращений, задаю справочник категорий и сравниваю несколько вариантов инструкции. Это помогает увидеть, где модель путает «возврат» и «ошибку оплаты», ещё до обсуждения рабочего процесса.
В интерфейсе SoftChat доступны вкладки «Текст» и «Графика». Для этой задачи нужна текстовая работа: классификация, извлечение признаков и подготовка краткого резюме. Другие вкладки не следует считать готовым каналом автоматической сортировки, если в продукте для них указано состояние разработки или будущего запуска.
Модельный кейс: при проверке 50 обезличенных сообщений я фиксирую для каждого результата 6 значений: исходный текст, категорию, приоритет, отдел, объяснение и решение проверяющего. Через 1–2 итерации становится видно, какие инструкции дают повторяемый результат, а какие зависят от случайной формулировки.
Для рабочего применения я добавляю журнал изменений. В нём хранятся версия справочника, дата проверки, причина исправления и итоговая метка человека. Без такой истории трудно понять, почему доля ошибок выросла после добавления новой категории или изменения правила срочности.
Нейросеть можно применять и к бытовым очередям, где нет отдела маршрутизации. В разборе повседневных задач с чат-ботами хорошо виден тот же принцип: сначала формулируется повторяемая операция, затем проверяется результат и только после этого сокращается ручная работа.
Какое решение я бы выбрал для потока обращений
Я бы начал с одной очереди, 6–8 категорий и тестовой выборки из 100 сообщений, а автоматическое действие оставил бы за пределами первого этапа. Так проще увидеть реальные ошибки маршрутизации и не смешать проблемы справочника с проблемами интеграции.
Мой порядок такой: собрать обезличенные тексты, описать классы, добавить положительные и отрицательные примеры, задать 3 уровня срочности, проверить метрики по каждой категории, затем провести ручной разбор спорных случаев. Если точность нужного класса ниже принятого командой порога, я не маскирую проблему общим показателем F1, а возвращаюсь к определениям и тестовой выборке.
После настройки можно расширять схему на второй канал, например с почты на мессенджер. Я сохраняю прежние категории, добавляю особенности нового формата и заново проверяю не менее 50 сообщений из каждого канала. Такой порядок снижает риск, что короткие реплики из чата будут ошибочно обрабатываться по правилам длинных писем.
Результат сортировки должен экономить время на чтении и поиске маршрута, но последнее слово в спорных, финансовых и связанных с доступом обращениях остаётся за человеком.