ИИ в саппорте: сортировка обращений и черновики в 2026
Стендфирст: Практическая схема первичной обработки обращений: классификация тем, оценка срочности, подготовка черновика и контроль качества.
Саппорт начинает терять время ещё до ответа клиенту. Сотрудник читает сообщение, определяет тему, ищет похожий случай, проверяет приоритет и только после этого пишет первую строку. При потоке в 300 обращений за смену такая последовательность превращает сортировку в отдельную операцию.
ИИ помогает разделить эту работу на повторяемые этапы. Он извлекает признаки из текста, присваивает обращению категорию, находит сигналы срочности и готовит проект ответа. Решение всё равно должен контролировать сотрудник, особенно когда речь идёт о возврате денег, доступе к аккаунту, персональных данных или нарушении SLA.
Если нужен общий набор сценариев для рутинных задач, я рекомендую начать с разбора повседневного применения нейросетей. Ниже разберу процесс так, чтобы его можно было проверить на небольшой выборке сообщений.
Что именно делает ИИ при первичной обработке
ИИ может сформировать 4 результата: тему обращения, уровень срочности, извлечённые признаки и черновик ответа. Такой порядок снижает риск, что красивый текст скроет неверно определённую причину запроса.
На вход система получает текст клиента, историю диалога и доступные служебные поля, например канал, время создания и идентификатор очереди. На выходе я советую сохранять структурированную запись:
| Этап | Что получает сотрудник | Зачем это нужно |
|---|---|---|
| Определение темы | Одна основная категория и до 2 дополнительных меток | Быстро выбрать очередь и шаблон |
| Оценка срочности | Низкий, обычный или высокий приоритет | Не пропустить риск по SLA |
| Извлечение фактов | Номер заказа, дата, тип ошибки, сумма, если они есть | Не искать детали вручную |
| Черновик | Ответ из 4–6 смысловых блоков | Сократить время подготовки |
| Обоснование | Короткая причина выбранной категории | Проверить решение до отправки |
Модельный кейс: если из 500 сообщений 180 относятся к оплате, 120 к доставке, а остальные распределены по 8 темам, оператор сначала видит структуру очереди, а не длинный список писем. Эти числа иллюстрируют механику, а не результат конкретной компании.
Для проверки результата полезно просить ИИ возвращать не один ярлык, а объект с фиксированными полями. Например: «тема», «срочность», «причина», «извлечённые данные», «черновик», «сомнение». Такой формат проще сравнивать с разметкой специалиста, чем свободный абзац.
Как построить классификацию тем
Для первого пилота я бы взял 6–10 категорий и проверил их на 300–500 обращениях. Слишком широкая схема скрывает причины, а каталог из 40 тем заставляет модель угадывать различия, которые сами сотрудники трактуют по-разному.
Начинайте с дерева, которое отражает действие команды. Категория «оплата» полезна, если после неё сообщение попадает к специалисту по платежам. Метка «вопрос» сама по себе почти ничего не даёт. Хорошая тема отвечает на вопрос: что должен сделать следующий сотрудник?
Я обычно разделяю классификацию на два уровня. Первый уровень описывает направление: оплата, доставка, доступ, техническая ошибка, возврат, консультация. Второй уточняет причину: списание дважды, задержка, забытый пароль, ошибка при входе, изменение адреса. Для маршрутизации чаще достаточно первого уровня, для аналитики пригодится второй.
Не заставляйте ИИ выбирать категорию, которой нет в справочнике. Добавьте значение «нужна ручная проверка» и правило для сомнительных сообщений. Порог уверенности 0,80 можно использовать как стартовую настройку, но его нужно проверить на собственной разметке. При значении ниже порога обращение не следует автоматически отправлять в узкую очередь.
Модельный кейс: в выборке из 400 сообщений 60 содержат сразу два вопроса, например о возврате и смене адреса. В такой ситуации первичной меткой можно сделать действие, которое блокирует дальнейшую обработку, а вторую сохранить как дополнительную. Порядок должен быть записан в инструкции, иначе два оператора разметят один текст по-разному.
Для подготовки инструкций пригодится практика формулирования запросов для нейросетей. В промпте задайте список допустимых категорий, формат ответа, правило для неоднозначных случаев и 2–3 размеченных примера без персональных данных.
Как выделять срочные обращения
Срочность лучше определять по 3 уровням и отдельным признакам риска. Для каждой очереди нужно заранее записать срок реакции, например 15 минут для высокого приоритета и 4 часа для обычного.
Высокий приоритет получают сообщения, где есть блокировка доступа, подозрение на списание, угроза потери заказа, массовый сбой или прямое упоминание действующего SLA. Средний уровень подходит для проблемы, которая мешает работе, но имеет обходной путь. Низкий приоритет можно присвоить консультациям, запросам справочной информации и предложениям без срока исполнения.
Я не советую определять срочность по эмоциональности текста. Восклицательные знаки и слова «срочно» дают много ложных срабатываний. Надёжнее искать сочетание признаков: событие, последствие и срок. Фраза «не могу войти уже 2 часа перед закрытием отчётности» информативнее, чем одно слово «срочно».
Полезно хранить причину приоритета в отдельном поле. Оператор должен видеть: «высокий приоритет, заблокирован вход, указан срок до 18:00». Если ИИ выдаёт только число от 1 до 3, проверка превращается в повторное чтение всего сообщения.
Условный пример: в очереди из 100 обращений 12 имеют признаки высокого риска, 38 требуют ответа в течение рабочего дня, а 50 являются консультациями. При такой структуре руководитель сначала проверяет 12 сообщений, затем контролирует соблюдение срока по 38, а не распределяет время равномерно.
Как готовить черновик ответа
Хороший черновик состоит из 5 блоков: признание проблемы, краткое понимание ситуации, конкретный следующий шаг, срок и запрос недостающих данных. Такой каркас удерживает ответ в пределах задачи и уменьшает число обещаний, которые оператор не может выполнить.
Пример структуры для обращения об ошибке входа:
- Подтвердить, что сообщение понято: «Вы не можете войти в аккаунт после ввода пароля».
- Назвать проверяемый факт: «В обращении указано, что ошибка повторяется дважды».
- Предложить действие, разрешённое регламентом: проверить восстановление доступа или передать запрос второй линии.
- Указать срок следующего ответа, если он закреплён в SLA.
- Попросить один недостающий факт, например время последней попытки или код ошибки.
Черновик не должен самостоятельно придумывать статус заказа, сумму возврата или причину сбоя. Если данных нет, модель обязана написать «информация не найдена», а не заполнять пробел правдоподобной деталью. Для финансовых и доступных к изменению операций я бы оставлял обязательное подтверждение сотрудника.
Промпт лучше строить вокруг источников истины. В него можно передать регламент возврата, список статусов, правила эскалации и несколько обезличенных примеров. Текст ответа должен опираться только на эти материалы. Подход к созданию черновиков подробно разобран в статье о генерации текстов и проверке результата.
В веб-чате SoftChat доступны потоковая выдача ответа и переключение модели в рамках разговора. Я бы использовал такой режим для ручного сравнения двух инструкций или проверки формулировки черновика на небольшом наборе сообщений. Автоматическую маршрутизацию очереди приписывать чату не следует, если она не заявлена в продуктовой документации.
Как измерять качество сортировки
Минимальный набор контроля включает 4 метрики: точность темы, полноту обнаружения срочных случаев, долю принятых черновиков и время до первой реакции. Одной общей оценки недостаточно, потому что ошибка в консультации и ошибка в платёжном инциденте имеют разную цену.
Точность темы считают так: число верных классификаций делят на количество проверенных сообщений. Полнота по срочным случаям показывает, какую долю действительно критичных обращений система нашла. Для черновиков полезна отдельная оценка сотрудника по шкале от 0 до 2: 0 означает непригодный текст, 1 требует правок, 2 можно отправлять после быстрой проверки.
Условный пример: из 200 проверенных сообщений 176 получили правильную основную тему, значит точность составила 88%. Из 25 срочных обращений система нашла 23, полнота равна 92%. Эти числа не обещают результат для другой очереди, они показывают, как выглядит отчёт пилота.
Раз в неделю я бы просматривал не случайные сообщения, а 3 группы: все ошибки высокого приоритета, случаи с низкой уверенностью и черновики, которые сотрудник переписал более чем наполовину. За 4 недели получится материал для обновления справочника и промпта. Неудобные примеры часто полезнее гладких ответов, потому что показывают границы инструкции.
Для планирования внедрения пригодится разбор интеграции нейросетей в рабочие процессы. Там полезно смотреть на цепочку от входящего сообщения до измеримого результата, а не на отдельную генерацию текста.
Где нейросеть ошибается и как снизить риск
Два риска встречаются чаще всего: неверная трактовка неоднозначного текста и уверенный ответ при отсутствии данных. Снизить их помогают порог ручной проверки и журнал причин, где сохраняются входной текст, выбранная метка и исправление специалиста.
Персональные данные нужно сокращать до минимума ещё до обработки. В тестовой выборке заменяйте имя, телефон, адрес и номер заказа на нейтральные маркеры. Для оценки качества достаточно сохранить тип проблемы, дату, сумму в диапазоне и итоговую категорию, если конкретные значения не нужны.
Отдельно проверяйте смешанные обращения. Сообщение может содержать просьбу вернуть деньги, жалобу на доставку и вопрос о доступе. Если система выбирает одну тему, регламент должен объяснять, какая из них считается главной. Если выбрать нельзя, обращение уходит специалисту с пометкой «несколько задач».
Не подключайте автоматическую отправку сразу после первого теста. Сначала сравните черновик с ответом сотрудника на 100–200 сообщениях, затем ограничьте запуск одной очередью. После этого добавьте выборочную проверку, например 10% обычных ответов и 100% сообщений с высоким приоритетом.
Как запустить пилот за 10 рабочих дней
Я закладываю на первый пилот 10 рабочих дней: 2 дня на таксономию, 3 дня на разметку, 2 дня на настройку инструкций и 3 дня на проверку результатов. Такой срок подходит для проверки гипотезы на одной очереди, но не заменяет полноценное внедрение.
В первые 2 дня зафиксируйте список категорий, уровни срочности и правила эскалации. На 3–5-й день разметьте 300–500 обезличенных сообщений силами двух сотрудников. Расхождения между ними покажут, где описание темы слишком расплывчато.
На 6–7-й день подготовьте промпт и формат структурированного ответа. Запретите выдуманные факты, добавьте поле для сомнения и обозначьте случаи, когда требуется человек. На 8–10-й день сравните результаты с эталонной разметкой и посчитайте 4 метрики из предыдущего раздела.
Условный пример: если после проверки 300 сообщений точность темы достигла 90%, но полнота срочных случаев составила 68%, расширять автоматизацию рано. Сначала нужно разобрать пропущенные инциденты и изменить признаки приоритета. Если показатели стабильны на двух последовательных выборках, можно увеличивать долю черновиков, которые проходят через процесс.
Какое решение я бы принял на вашем месте
Я бы запускал ИИ в саппорте там, где есть повторяемая тема, понятный регламент и человек, способный проверить результат за 30–60 секунд. Если хотя бы один из этих элементов отсутствует, начинал бы с классификации и извлечения фактов, а черновик добавлял после первой оценки качества.
Практическое правило простое: автоматизируйте подготовку, но оставляйте сотруднику право изменить категорию, приоритет и текст. Через 2–4 недели журнал исправлений покажет, какие темы стоит объединить, какие признаки добавить и где нужна отдельная инструкция. Так нейросеть становится частью измеряемого процесса, а не заменой ответственности саппорта.