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

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

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

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

Как нейросеть разбирает поток обращений

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

Сначала для очереди задают рубрикатор. Обычно достаточно 6–10 категорий, например «оплата», «доставка», «возврат», «ошибка входа», «техническая проблема» и «другое». Чем шире классы, тем проще запуск, но тем меньше пользы от сортировки. Если в категории попадают 3 разных процесса, оператор всё равно будет перечитывать сообщения вручную.

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

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

Модельный кейс: в очереди из 600 сообщений настроены 8 тем и отдельный флаг срочности. После автоматической сортировки оператор проверяет 60 случайных карточек, то есть 10% потока. Если в 6 карточках из 60 найдены ошибки, рубрикатор и примеры для обучения нужно пересмотреть до расширения пилота.

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

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

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

К первой группе относятся подозрение на списание денег, блокировка доступа, потеря результата оплаты и утечка персональных данных. Ко второй относятся слова и даты, указывающие на дедлайн: «сегодня», «до 18:00», «рейс через 2 часа», «заказ уже у курьера». Третья группа включает массовые ошибки, повторные обращения и одинаковые сообщения от нескольких пользователей.

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

Удобна шкала из 4 уровней:

1. Критический случай, реакция в течение 15 минут.
2. Высокий приоритет, ответ в течение 1 часа.
3. Обычный вопрос, обработка в течение рабочего дня.
4. Информационный запрос, ответ по общей очереди.

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

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

Как готовить черновик ответа

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

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

Последняя часть нужна для исключений. Если инструкция не сработала, клиент должен понимать, что делать дальше. Фраза «ответьте нам» слишком расплывчата. Лучше указать условие: «Если статус не изменится в течение 30 минут, передайте оператору номер операции».

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

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

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

Как встроить контроль качества

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

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

Полезно хранить причину исправления. Если оператор заменил «вероятно» на точный факт, это одна ошибка. Если он полностью переписал ответ из-за неверной темы, это уже другая проблема, связанная с классификацией. Через 2–4 недели такой журнал показывает, где требуется новая инструкция, а где не хватает примеров.

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

Какие метрики считать

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

Время до первого ответа показывает скорость реакции, но не качество решения. Поэтому его нужно смотреть вместе с повторными обращениями. Если среднее время снизилось с 40 до 25 минут, а доля повторных сообщений выросла с 12% до 20%, ускорение привело к дополнительной нагрузке.

Модельный кейс: команда сравнивает две недели. В первую неделю 480 обращений получили ручной ответ, среднее ожидание составило 36 минут. Во вторую неделю нейросеть подготовила черновики для 300 сообщений, среднее ожидание снизилось до 24 минут, а 54 черновика из 300 были полностью переписаны. Такой результат нельзя назвать готовым автоматическим процессом, но он показывает, что нужно измерять принятие черновиков, а не количество сгенерированных текстов.

Для классификации считайте ошибки отдельно по каждой теме. Общая точность 92% может скрывать показатель 99% для доставки и 71% для возвратов. Именно второй класс потребует новых примеров и более точных правил.

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

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

Где проходит граница автоматизации

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

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

Не стоит смешивать в одном сценарии классификацию, поиск причины сбоя и принятие финансового решения. Это разные задачи с разной ценой ошибки. Разделение помогает понять, на каком шаге возникла проблема и кто отвечает за исправление.

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

Как начать пилот без расширения команды

На моём месте я бы выбрал 1 повторяющийся процесс, собрал 100–200 обезличенных обращений и заранее описал 5 критериев качества. Такой объём позволяет увидеть типовые ошибки, не превращая запуск в большой проект.

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

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

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

Что делать после обновления процесса

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

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

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