Как ИИ сортирует обращения и готовит ответы для поддержки
Стендфирст: Разбираю, как нейросеть распределяет обращения, находит срочные запросы и создаёт черновики ответов без передачи контроля над перепиской автоматике.
Поток сообщений редко приходит в удобном порядке. В одной очереди могут оказаться вопрос о счёте, жалоба на сбой, просьба о расчёте стоимости и короткое «перезвоните мне». Сотруднику приходится читать каждое обращение, определять тему, искать данные в регламенте и выбирать тон ответа. При объёме 150–300 сообщений в день такая рутина быстро вытесняет работу с действительно сложными случаями.
Нейросеть помогает разложить поток по понятным признакам: теме, срочности, типу клиента, стадии сделки и нужному подразделению. Она может предложить текст ответа, но решение о публикации остаётся за сотрудником. Такой подход я разбираю в материале о внедрении нейросетей в рабочие процессы, где автоматизация рассматривается как часть регламента, а не как отдельная кнопка.
Что именно делает ИИ с потоком обращений
ИИ превращает неструктурированный поток писем и сообщений в 4 понятных результата: тему, приоритет, извлечённые данные и черновик действия. Человек получает очередь, где уже видны причина обращения и следующий шаг.
Сначала система определяет намерение. Для поддержки это могут быть «не прошёл платёж», «не открывается личный кабинет», «нужен возврат» и «как подключить тариф». Для продаж набор будет другим: «рассчитать стоимость», «сравнить варианты», «назначить встречу». Чем точнее названы категории, тем меньше ручной сортировки.
Затем нейросеть извлекает сущности. В обращении о доставке это номер заказа, город, дата и вид проблемы. В запросе потенциального клиента, название компании, число пользователей, желаемый срок запуска и канал связи. Эти поля можно передать оператору в компактном виде, чтобы он не перечитывал 20 строк переписки перед ответом.
Модельный кейс: при очереди из 100 сообщений система может распределить 45 вопросов по оплате, 25 по техническим сбоям, 20 по условиям покупки и 10 по возвратам. Эти числа иллюстрируют механику классификации, а не результат конкретной компании. На следующем этапе руководитель проверяет, правильно ли назначены ответственные группы и не потерялись ли обращения с несколькими темами.
На практике я советую начинать с 6–8 категорий, а не с 30. Слишком подробная схема создаёт путаницу: два сотрудника начинают по-разному трактовать близкие метки. Когда накопится 200–300 размеченных обращений, категории можно разделить по реальным ошибкам, а не по предположениям.
Как настроить классификацию обращений
Рабочая классификация строится вокруг 5 вопросов: о чём пишет человек, чего он хочет, насколько это срочно, кто должен ответить и какие данные нужно сохранить. Эти вопросы превращают свободный текст в набор полей, пригодных для маршрутизации.
Я начинаю с таблицы меток. Для каждой указываю название, короткое определение, 3–5 положительных примеров и 2 похожих, но неподходящих случая. Например, «ошибка оплаты» означает отказ при списании, а «вопрос о счёте» относится к документам и реквизитам. Такое различие снижает число спорных решений.
Отдельно задаю правило для смешанных обращений. Если клиент пишет: «Оплата прошла, но доступ не открылся», главной темой становится техническая проблема, а платёж сохраняется как дополнительный признак. Без этого система может направить сообщение в бухгалтерию, хотя клиент ждёт восстановления доступа.
Для новых категорий полезен порог уверенности. При значении ниже 0,75 обращение лучше отправлять в общую очередь на проверку. Число 0,75 не является законом природы, его подбирают по тестовой выборке. В одной сфере безопаснее проверять уже при 0,85, в другой допустим порог 0,65, если цена ошибки невелика.
В разборе генерации текстов и проверки результата есть тот же принцип: сначала задаётся структура, затем проверяется соответствие исходным данным. Для сортировки это означает простой контроль: метка должна объясняться фрагментом исходного сообщения, а не догадкой системы.
Модельный кейс: если в заявке встречаются слова «сегодня», «заблокирован» и «не могу оплатить», классификатор может присвоить ей тему оплаты и высокий приоритет. Если есть только фраза «подскажите способы оплаты», срочность должна быть низкой. Одинаковое слово «оплата» не означает одинаковое действие оператора.
Как выделять срочные запросы
Срочность лучше рассчитывать по шкале от 0 до 3, где 0 означает обычный вопрос, а 3 требует немедленной передачи ответственному сотруднику. Одного эмоционального тона недостаточно: спокойное сообщение о закрывающемся сегодня тендере может быть важнее резкой жалобы без срока.
Я использую 4 группы признаков:
- Прямой срок. Слова «до 16:00», «сегодня», «за 2 часа» дают системе временной ориентир.
- Последствие. Указание на заблокированный доступ, остановку оплаты или срыв отгрузки повышает приоритет.
- Масштаб. Один пользователь и 40 сотрудников затронуты по-разному, даже если описывается одна ошибка.
- История. Повторное обращение после двух нерешённых ответов требует отдельной отметки.
Правила нужно связать с регламентом. Например, уровень 3 направляется старшему специалисту за 15 минут, уровень 2 попадает в очередь поддержки за 60 минут, уровень 1 обрабатывается в течение рабочего дня. Это пример настройки SLA, а не универсальная норма. Если компания отвечает клиентам по другому графику, пороги меняются вместе с обещанным сроком.
Тон сообщения я не использую как самостоятельное основание. Восклицательные знаки и резкие слова могут поднять сигнал для проверки, но не должны автоматически назначать максимальный приоритет. Иначе система начнёт продвигать эмоциональные сообщения выше обращений с реальным финансовым риском.
Для контроля удобно считать полноту обнаружения срочных запросов. Формула проста: число найденных срочных обращений делится на общее число срочных обращений в проверенной выборке. Если из 50 таких сообщений система обнаружила 46, полнота составляет 92%. Это отдельный показатель, его нельзя заменять общей точностью всех меток.
Как нейросеть готовит черновик ответа
Черновик ответа должен состоять из 5 частей: обращение, краткое понимание проблемы, проверенный факт, действие клиента и следующий срок связи. Такая форма уменьшает риск красивого, но бесполезного текста.
Я задаю системе ограничения до генерации. Она должна использовать только переданные правила, не обещать возврат денег без подтверждения, не придумывать сроки и отмечать отсутствие нужных данных. Для технической заявки полезно требовать отдельные поля: устройство, версия приложения, время ошибки и уже выполненные шаги.
| Сценарий | Что передать нейросети | Что получить | Проверка сотрудника |
|---|---|---|---|
| Вопрос о счёте | Текст обращения, тип документа, реквизиты | Короткое объяснение и список действий | Сверить суммы и даты |
| Технический сбой | Симптом, устройство, время, код ошибки | Уточняющие вопросы и безопасные шаги | Проверить, не предложен ли рискованный совет |
| Запрос о покупке | Потребность, число пользователей, срок | Черновик ответа с 2 вариантами | Проверить цену, условия и обещания |
| Повторная жалоба | История переписки, предыдущий статус | Резюме проблемы и предложение эскалации | Решить, нужен ли руководитель |
В черновике полезно ограничивать длину. Для первого ответа клиенту обычно достаточно 80–140 слов, а для внутреннего резюме оператору часто хватает 4–6 пунктов. Длинный текст сложнее проверить, особенно когда в очереди ждут ещё 30 сообщений.
Модельный кейс: клиент пишет «третий раз отправляю документы, ответа нет». Нейросеть может выделить повторность, предложить проверить историю и подготовить спокойный ответ с указанием следующего шага. Сотрудник обязан открыть исходные сообщения, убедиться в наличии документов и только после этого отправлять текст.
Я не рекомендую разрешать автоматическую отправку в чувствительных сценариях. К ним относятся возвраты, претензии, юридические формулировки, изменение реквизитов и сообщения с персональными данными. Номер карты, пароль и код подтверждения не должны попадать в текстовый шаблон. Перед обработкой стоит маскировать такие сведения и определить срок хранения переписки.
Как измерить эффект и качество
Пилот стоит оценивать по 4 метрикам на выборке минимум из 200–300 обращений, а не по впечатлению операторов после одного дня. Сравнивайте время до первого ответа, долю верных меток, полноту обнаружения срочности и долю черновиков, которые сотрудник отправил после небольшой правки.
Я бы разделил проверку на два этапа. Сначала 100 обращений размечаются вручную двумя сотрудниками. Разногласия обсуждаются и фиксируются в правилах. Затем ещё 200 сообщений проходят через систему, а результат сравнивается с согласованной разметкой. Такой порядок показывает, где ошибается классификатор, а где сама инструкция допускает разные трактовки.
Для поддержки полезны следующие расчёты:
- Точность метки: правильные классификации делятся на все проверенные классификации.
- Полнота срочности: найденные срочные обращения делятся на все срочные обращения.
- Время обработки: медиана от открытия сообщения до готового ответа.
- Доля правок: сколько черновиков сотрудник изменил более чем на 30%.
Последний показатель особенно информативен. Если текст формально грамотный, но оператор переписывает половину ответа, система экономит мало времени. Если правки касаются только имени, даты и одной детали, черновик уже снимает значительную часть механической работы.
При проверке продаж добавьте конверсию в следующий шаг, но не смешивайте её с качеством текста. Ответ может быть написан хорошо, а предложение оказаться неподходящим по бюджету или сроку. Для этого нужны отдельные поля: назначена ли встреча, отправлен ли расчёт, получено ли уточнение от клиента.
Полезно проводить повторный аудит раз в 2–4 недели. За это время появляются новые формулировки, сезонные вопросы и нестандартные случаи. Метки, которые используются реже 1 раза на 100 обращений, стоит пересмотреть: они могут быть слишком узкими или плохо определёнными.
Где в этой схеме нужен чат
Чат нужен для ручного разбора спорных случаев, настройки инструкций и сравнения вариантов ответа, а не для подмены системы заявок. В веб-чате SoftChat можно переключать модели в рамках разговора и получать потоковые ответы, поэтому я использую его для проверки формулировок, структуры резюме и качества уточняющих вопросов.
Рабочая последовательность выглядит так: я вставляю обезличенный текст, указываю метки и правила, прошу выделить признаки срочности, затем проверяю черновик по исходному сообщению. Персональные данные, номера договоров и внутренние ссылки перед этим заменяются нейтральными обозначениями. Такой подход помогает тестировать промпт без публикации клиентской переписки.
Для повседневных операций полезно разделять задачи по времени. Сортировку и назначение приоритета выполняет автоматический контур, сложные случаи проверяет специалист, а чат используется для анализа ошибок и улучшения инструкций. Практические идеи для такого разделения собраны в статье о применении нейросетей для повседневных задач.
Если нужно выбрать между отдельным чат-интерфейсом и нейросетью внутри привычного сервиса, сравнивайте не количество кнопок, а 5 параметров: доступ к истории, контроль данных, скорость проверки, возможность менять модель и удобство передачи результата в рабочий процесс. Общий разбор такого выбора есть в материале о нейросети в браузере и голосовом помощнике, хотя для поддержки решающим остаётся регламент компании.
Какое решение выбрать для поддержки и продаж
Я бы начинал с одного типа обращений и тестовой выборки из 300 сообщений, а не с полной автоматизации всей очереди. Для поддержки разумно выбрать вопросы о статусе заказа или оплате, для продаж, первичную квалификацию заявки. У этих сценариев обычно понятнее входные поля и допустимые ответы.
После разметки задайте 6–8 категорий, шкалу срочности от 0 до 3 и правило обязательной проверки человеком. Через 2 недели сравните медианное время обработки, полноту срочных обращений и долю существенных правок. Если метки точны, а черновики требуют небольших изменений, можно расширять охват. Если ошибок много, сначала улучшите определения и примеры, а затем меняйте модель.
На вашем месте я бы оставил автоматике сортировку, извлечение полей и подготовку первого варианта ответа. Обещания, деньги, юридические претензии и нестандартные сбои передал бы сотруднику. Так нейросеть сокращает повторяющиеся действия, а ответственность за содержание остаётся у того, кто видит контекст и может проверить факты.
