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

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

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

Поток обработки обращенийПочта, формы и мессенджеры объединяются в единую карточку, затем проходят классификацию, проверку и передаются оператору.Как проходит обращениеЕдиная схема для трёх каналов и ручного контроляПочтатема и текстФормыполя заявкиМессенджерыистория диалогаЕдинаякарточка8 базовых полейКласстема и срочностьПроверкафакты и запретыЧерновикследующий шагОператоррешениеи отправка
Инфографика

Что именно автоматизировать в потоке обращений

Схема объединения писем, форм и сообщений в единую карточку обращения

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

Сначала система приводит разные источники к единому виду. Для письма это тема, тело, адрес отправителя и вложения. Для формы добавляются поля заявки, выбранная услуга и время отправки. В мессенджере полезны идентификатор диалога, последние 5–10 сообщений и признак повторного обращения.

Затем нейросеть присваивает сообщению метки. На старте я рекомендую ограничиться 4–7 классами, например «оплата», «техническая проблема», «статус заказа», «претензия», «запрос документов» и «другое». Слишком подробный справочник из 20–30 категорий затрудняет обучение сотрудников и повышает число пограничных решений.

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

Для первичной настройки полезно описать маршрут в таблице:

Канал Минимальные поля Примеры классов Следующий шаг
Почта тема, текст, отправитель, дата оплата, договор, претензия очередь специалиста
Форма поля заявки, комментарий, согласие консультация, ошибка формы, заказ карточка обращения
Мессенджер идентификатор диалога, последние сообщения статус, вопрос по услуге, жалоба ответ или эскалация

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

Как построить классификацию до первого ответа

Рабочая классификация обычно содержит 6 полей: тему, тип запроса, срочность, тональность, статус и маршрут. Каждое поле должно иметь допустимые значения, иначе два оператора будут по-разному трактовать одну и ту же заявку.

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

Пример структуры результата:

{
  "тема": "оплата",
  "тип": "проверка платежа",
  "срочность": "ускоренная",
  "тональность": "нейтральная",
  "уверенность": 0.86,
  "маршрут": "финансовый специалист",
  "черновик": "Проверю данные платежа и передам обращение ответственному специалисту."
}

Число 0,86 здесь является оценкой уверенности, а не доказательством правильности. Порог 0,80 можно использовать как стартовое правило, затем пересмотреть его на размеченной выборке. Сообщения ниже порога отправляются в очередь ручной проверки. Если модель путает «отмену заказа» и «возврат денег», проблему нужно искать в описании классов и примерах, а не просто повышать порог.

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

Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 120 сообщений в сутки. Для пилота ей достаточно 5 классов, 3 уровней срочности и 2 маршрутов, «оператор» и «специалист». После 10 рабочих дней можно посмотреть на спорные метки и решить, нужна ли шестая категория. Расширять справочник заранее не стоит.

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

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

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

Для каждого обращения фиксируются пять результатов:

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

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

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

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

Как объединить почту, формы и мессенджеры

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

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

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

Общий процесс выглядит так:

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

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

Какие KPI показывают пользу автоматизации

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

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

Для иллюстрации: из 420 обращений 315 получили верный маршрут, а 105 потребовали переназначения. Доля верной маршрутизации составит 75%. Если после изменения справочника она выросла до 86% на сопоставимой выборке, улучшение уже можно обсуждать предметно. Нельзя сравнивать 420 писем в январе с 30 короткими сообщениями в феврале.

SLA удобно разделить на три уровня, например 15 минут для критической блокировки, 60 минут для ускоренного запроса и 240 минут для обычного вопроса. Это не универсальные нормы, а рабочие пороги, которые нужно согласовать с командой. Если фактический ответ зависит от специалиста, первичный черновик не должен обещать клиенту выполнение задачи внутри этих интервалов.

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

Как запустить пилот без потери качества

Для первого пилота достаточно 14 дней, 100–300 размеченных обращений и одной очереди, а не всего контактного центра. За этот срок команда успевает проверить справочник, пороги уверенности и реакцию операторов на черновики.

В первые 2 дня я фиксирую классы и запрещённые формулировки. На 3–5-й день собираю примеры по каждой категории, включая ошибки и короткие сообщения. С 6-го по 9-й день запускаю теневой режим: модель классифицирует обращения, но сотрудник принимает решение по старому процессу. На 10–14-й день можно разрешить подготовку черновиков для одной категории с низким риском, например для вопросов о статусе заявки.

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

Как принять решение по итогам пилота

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

Я бы не начинал с автоматической отправки. Сначала оставил бы режим черновика, затем добавил правила для безопасных вопросов и только после повторной проверки разрешил ограниченный контур без редактуры. Решение о расширении принимается по журналу из 100–300 обращений, а не по впечатлению от нескольких удачных ответов.