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

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

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

Путь обращения до ответаПять этапов, которые удобно проверять отдельно1СообщениеТекст, дата,канал и контекст2ОчисткаФакты иперсональные данные3КлассТема иприоритет4ЧерновикФакты, шаги уточнения5ПроверкаМенеджерподтверждает ответКонтрольные поляПричина приоритета · найденные факты · пропущенные данные · следующий шаг
Инфографика

Что именно делегировать нейросети

Схема сортировки входящих обращений нейросетью и проверки менеджером

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

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

  1. Категория. Например, доставка, оплата, техническая ошибка, возврат или общий вопрос.
  2. Срочность. Четыре уровня от критического обращения до нерелевантного сообщения.
  3. Факты. Номер заказа, дата, сумма, название услуги, описанный симптом.
  4. Причина оценки. Короткая цитата или пересказ признака, из-за которого выбран приоритет.
  5. Черновик. Ответ без выдуманных сроков, скидок и действий, которых нет в регламенте.

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

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

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

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

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

В служебной карточке полезно оставить 4 поля:

  • время поступления;
  • канал, например почта, форма или чат;
  • текущий статус обращения;
  • ответственный сотрудник.

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

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

Как устроить классификацию обращений

Я начинаю с 4 классов и добавляю новые только после просмотра ошибок на реальных примерах. Небольшая таксономия с понятными границами обычно надёжнее списка из 15 расплывчатых категорий.

Класс Признаки Действие менеджера
Срочное Риск потери денег, блокировка услуги, угроза претензии, жёсткий срок Проверить в ближайшем рабочем окне
Обычное Вопрос о функции, статусе заказа или настройке без немедленного риска Ответить по стандартному регламенту
Информационное Просьба о справке, документах, условиях или доступных вариантах Дать ссылку или короткое пояснение
Нецелевое Реклама, дубликат, пустое сообщение или тема вне зоны поддержки Перенаправить, объединить или закрыть по правилу

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

Сначала я проверяю 50–100 обезличенных сообщений, собранных за разные дни недели. В выборке должны быть короткие обращения из 1 строки, длинные описания на 10–15 предложений, дубликаты и сообщения со смешанными темами. Один пример не показывает устойчивость классификации, а разнородная выборка выявляет спорные границы.

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

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

Я задаю модели такие вопросы:

  1. Есть ли риск финансового ущерба, блокировки доступа или потери данных?
  2. Назван ли конкретный срок, после которого проблема станет дороже или сложнее?
  3. Может ли человек продолжить пользоваться услугой без ответа поддержки?

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

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

Я прошу выводить причину оценки в отдельном поле. Формулировка «высокий приоритет, потому что клиент не может завершить оплату» пригодна для контроля. Фраза «похоже на важный вопрос» не объясняет решение и затрудняет разбор ошибки.

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

Проверка качества классификации обращений перед запуском

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

Я использую инструкцию примерно такой формы:

Ты готовишь черновик для менеджера поддержки. Определи тему и срочность. Извлеки номер заказа, дату, сумму и описанный симптом. Не выдумывай сведения. Если данных не хватает, перечисли вопросы для уточнения. Составь ответ на русском языке в 3–5 предложениях. Не обещай возврат, компенсацию или точный срок без подтверждения регламентом. Отдельно укажи причину выбранного приоритета.

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

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

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

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

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

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

  • полнота срочных обращений, доля действительно срочных сообщений, которые система нашла;
  • точность приоритета, доля сообщений с высоким приоритетом, которые действительно требовали быстрой реакции.

Нельзя оценивать качество одной средней цифрой. Если из 100 сообщений 90 классифицированы верно, но среди 10 ошибок есть 4 пропущенных блокировки оплаты, настройка требует доработки. В поддержке цена ошибки зависит от класса обращения, поэтому для срочных случаев нужен отдельный порог ручной проверки.

Модельный кейс: компания из сферы онлайн-торговли, примерно 60 сотрудников, проверяет 200 обезличенных обращений. В тесте 40 сообщений относятся к срочным, 36 из них распознаны, а 4 пропущены. Полнота составит 90 процентов. Если система пометила срочными 48 сообщений и 36 из них действительно попали в эту группу, точность составит 75 процентов. Такой результат уже даёт материал для настройки правил, но не оправдывает отправку ответов без человека.

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

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

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

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

Условный пример: 240 сообщений в день при ручной обработке по 3 минуты требуют 720 минут, то есть 12 часов работы. Если для 70 процентов обращений черновик проверяется за 45 секунд, а остальные 30 процентов по-прежнему занимают 3 минуты, расчёт составит 168 умножить на 0,75 плюс 72 умножить на 3, всего 342 минуты. Теоретическая экономия равна 378 минутам, или 52,5 процента. Это модель расчёта, а не обещание результата: она не включает исправления, повторные проверки и время на сложные случаи.

Сравнивать нужно одинаковые периоды, например 5 рабочих дней до настройки и 5 после. Если в одной неделе было 240 обращений, а в другой 80, процент ручных исправлений потеряет смысл. Я фиксирую объём, состав категорий, число сотрудников и долю сообщений, отправленных на эскалацию.

Как использовать SoftChat для проверки сценария

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

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

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

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

Как принять решение о запуске

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

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

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