ИИ для поддержки: классификация обращений и срочность в 2026
Нейросеть превращает поток сообщений в понятную очередь: определяет тему, срочность и предлагает менеджеру черновик ответа.
Поддержка и продажи часто теряют время не на сам ответ, а на первичный разбор входящих сообщений. Менеджеру приходится прочитать текст, понять намерение клиента, найти нужный сценарий, проверить приоритет и только потом написать ответ. При потоке в 200 обращений такая подготовка занимает часы, даже если содержание многих сообщений повторяется.
Нейросеть может взять на себя предварительную сортировку. Она не принимает решение вместо сотрудника, а выделяет признаки обращения, присваивает категории и объясняет, почему сообщение попало в конкретную очередь. Я рассматриваю этот подход как слой подготовки: менеджер получает уже разобранный запрос и тратит время на решение, а не на ручную навигацию.
Что именно делает нейросеть в потоке обращений
Нейросеть обрабатывает обращение в 4 шага: извлекает смысл, присваивает категорию, оценивает срочность и готовит следующий шаг. Менеджер видит результат до отправки ответа и может его исправить.
Сначала система определяет намерение клиента. Сообщение «не могу войти в личный кабинет» относится к доступу, «где найти акт за май» связано с документами, а «хочу подключить тариф для 15 сотрудников» указывает на продажу. Одна фраза может получить несколько меток, например «не пришёл счёт, из-за этого заблокировали оплату» относится к биллингу и потенциальной остановке обслуживания.
Затем модель выделяет сущности и контекст. К ним относятся номер заказа, название услуги, дата платежа, канал связи и упомянутый срок. Я рекомендую хранить минимум 5 полей: намерение, продукт, срочность, тональность и следующий шаг. Если отрасль регулируемая, добавляется признак наличия персональных данных.
Результат лучше показывать в компактном виде, а не прятать в длинном объяснении. Менеджеру нужны категория, причина, рекомендуемый маршрут и уровень уверенности. При уверенности ниже заданного порога сообщение отправляется на ручную проверку.
В веб-приложении SoftChat можно переключать модели в рамках разговора. Это удобно для проверки одного шаблона на 2 вариантах обработки, но финальную схему категорий я всё равно задаю через внутренние правила отдела и реальные примеры переписки.
Как настроить категории без хаоса
Для старта достаточно 6–10 категорий и отдельной метки срочности, иначе классификация быстро становится слишком подробной. Я сначала собираю примеры за 2–4 недели, удаляю дубли и фиксирую границы каждой категории.
| Подход | Что получает менеджер | Когда применять | Ограничение |
|---|---|---|---|
| Ручная сортировка | Сообщение без предварительных меток | До 50 обращений в день или при редких запросах | Результат зависит от смены и опыта сотрудника |
| Жёсткие правила | Маршрут по словам, полям и условиям | Для повторяемых тем, например оплаты или доставки | Правила плохо видят смысл и сложные формулировки |
| Нейросетная классификация | Категория, срочность, краткое объяснение | При разнообразных сообщениях и нескольких очередях | Нужны тестовая выборка и контроль ошибок |
| Смешанный вариант | Автоматическая сортировка плюс ручная проверка | Для потока с разной ценой ошибки | Требует согласованных порогов и владельца процесса |
Хорошая категория описывает действие, а не абстрактную тему. «Оплата» слишком широко: в неё попадут вопросы о счёте, возврате, промокоде и неудачном списании. Лучше разделить её на «проверить платёж», «уточнить возврат» и «исправить данные счёта», если для этих случаев назначены разные сотрудники.
Я проверяю каждую категорию четырьмя вопросами:
- Понимает ли менеджер, что делать после присвоения метки?
- Можно ли найти 10–20 примеров без натяжки?
- Отличается ли маршрут от соседней категории?
- Есть ли понятное действие при низкой уверенности?
Гипотетический пример: при потоке 600 сообщений за неделю отдел оставляет 8 основных намерений и 3 специальных флага, «VIP», «риск оттока» и «юридический вопрос». Такая схема обычно понятнее, чем каталог из 40 меток, где сотрудники спорят о границах понятий.
Больше идей по проектированию рабочих сценариев я собрал в материале как внедрить нейросети в рабочие процессы и личную продуктивность. Для поддержки особенно полезна часть о закреплении ответственного и проверке результата.
Как выделять срочные запросы
Срочность лучше задавать через 3 уровня и набор наблюдаемых признаков, а не через эмоциональность текста. Слово «срочно» само по себе не доказывает критичность обращения.
Я использую такую основу:
- Высокая срочность. Клиент не может оплатить заказ, получить доступ к оплаченной услуге или продолжить рабочий процесс. Есть конкретный срок, массовый сбой или риск финансового ущерба.
- Средняя срочность. Проблема мешает работе, но существует временный обходной путь. Нужна реакция в течение рабочего дня.
- Низкая срочность. Клиент просит инструкцию, уточняет свойства продукта или хочет получить справочную информацию.
Модель должна искать факты, а не ставить диагноз по тону. Фраза «если вопрос не решится до 18:00, мы отменим заказ» содержит срок и последствие. Спокойное сообщение «после оплаты доступ не появился» может быть более срочным, чем эмоциональная жалоба без конкретной проблемы.
Я задаю минимум 4 признака для высокой срочности: блокировка услуги, денежный риск, установленный дедлайн и повторное обращение без решения. Два признака одновременно повышают приоритет, но это правило нужно подтвердить на исторических данных.
Условный пример: клиент пишет «платёж списался в 09:20, доступ не открылся, презентация начинается в 11:00». Здесь есть время операции, проблема доступа и дедлайн через 100 минут. Система должна передать сообщение в приоритетную очередь и показать менеджеру эти 3 факта, а не ограничиться меткой «негатив».
Для контроля я рекомендую еженедельно просматривать 20 сообщений с высокой срочностью. Если среди них много обычных вопросов, меняются признаки или порог. Если критичные обращения попадают в низкий приоритет, сначала корректируется разметка, затем шаблон классификации.
Как предлагать ответ и сохранять контроль
Нейросеть должна предлагать черновик, а не отправлять его без проверки, особенно в темах оплаты, возвратов и доступа. Практичная схема состоит из 2 стадий: сначала классификация, затем подготовка ответа по найденному контексту.
В запросе к модели я фиксирую роль, формат и ограничения. Например: «Определи намерение, срочность и недостающие данные. Составь ответ до 600 знаков. Не обещай срок, скидку или возврат, если этого нет в исходной информации». Такой шаблон снижает риск, что вежливая формулировка скроет отсутствие решения.
Черновик должен содержать 4 элемента:
- Короткое подтверждение сути обращения.
- Конкретный ответ или следующий шаг.
- Запрос недостающих данных, если без них нельзя продолжить.
- Условие эскалации, когда вопрос передаётся специалисту.
Я отдельно запрещаю модели выдумывать номера заявок, статусы платежей и сроки. Если данных нет, безопаснее написать «нужно проверить операцию по номеру заказа», чем создать правдоподобную, но ложную деталь.
Модельный кейс: интернет-магазин получает 80 сообщений о доставке за день. Для вопроса «курьер будет сегодня?» черновик должен запросить номер заказа и город, если эти сведения отсутствуют. Для сообщения «заказ нужен к 16:00» система дополнительно выставляет высокий приоритет, но не обещает доставку без проверки логистики.
Качество черновика проверяется по 5 критериям: точность категории, соответствие фактам, полнота следующего шага, отсутствие неподтверждённых обещаний и подходящий тон. Я выставляю оценки на выборке из 30–50 сообщений до запуска и повторяю проверку после изменений в справочнике.
При подготовке текстов полезно сверяться с материалом нейросеть для генерации текста: задачи и проверка результата. Там хорошо разобраны границы между черновиком и готовым материалом, это различие критично для ответов клиентам.
Как измерить разгрузку менеджеров
Разгрузку нужно считать по 4 показателям: время до первого ответа, доля ручной сортировки, процент исправлений черновика и доля ошибочных приоритетов. Одной скорости недостаточно, если количество исправлений растёт.
Я использую простую формулу для оценки трудозатрат:
экономия времени = число обращений × минуты ручной подготовки × доля автоматизированных операций
Модельный кейс: если 400 обращений требуют в среднем по 3 минуты первичного разбора, общий объём составляет 1200 минут, или 20 часов. При автоматизации половины операций расчётная экономия равна 10 часам, но это ещё не чистый результат. Из него нужно вычесть время на проверку классификации и исправление черновиков.
Для оценки качества полезны две матрицы. Первая показывает, какие обращения система отнесла к правильным категориям. Вторая сопоставляет предсказанную срочность с решением старшего сотрудника. Ошибка в теме «справка о продукте» обычно дешевле ошибки в теме «двойное списание», поэтому одинаковый вес для всех промахов искажает картину.
Я делю контроль на короткие интервалы. В первые 3 дня проверяю каждый результат на тестовой очереди. На второй неделе смотрю случайную выборку из 50 сообщений в день. После стабилизации достаточно еженедельного аудита, если не менялись продукты, тарифы, правила возврата или состав команды.
Для продаж добавляю ещё 2 метрики: долю обращений с явным коммерческим намерением и время до передачи лида ответственному сотруднику. В статье о нейросетях в маркетинге и инструментах автоматизации есть полезный контекст о тестировании гипотез и разделении контентных задач. В поддержке этот принцип переносится на проверку маршрутов и ответов.
Где находятся границы автоматизации
Основные риски связаны с 3 зонами: ошибочной категорией, неверной срочностью и выдуманными деталями в ответе. Каждую зону нужно закрывать отдельной проверкой.
Первая проблема возникает при коротких и двусмысленных сообщениях. «Опять не работает» без продукта и номера заказа может относиться к оплате, входу или доставке. В такой ситуации модель должна задавать уточняющий вопрос либо отправлять сообщение в общую очередь, а не выбирать категорию наугад.
Вторая проблема связана с изменением правил. Если срок возврата поменялся с 14 на 30 дней, старый шаблон становится опасным даже при безошибочной классификации. Я веду журнал изменений с датой, владельцем правила и примерами затронутых ответов.
Третья зона касается конфиденциальности. В текстах могут встречаться телефоны, адреса, номера документов и сведения о платежах. Перед передачей данных в любой внешний сервис нужно определить разрешённый состав информации, срок хранения и порядок удаления. Для тестов я использую обезличенные сообщения, где заменены имена, телефоны и номера заказов.
Если задача связана с повседневной обработкой информации, полезно сопоставить её с рекомендациями из материала как использовать нейросети и чат-боты для повседневных задач. Там описан тот же принцип: сначала ограничить контекст, затем проверить результат на понятном примере.
Что бы я сделал на вашем месте
Я бы начал с одной очереди и 6–8 категорий, затем взял тестовую выборку из 100 обезличенных обращений. Первые 2 дня посвятил бы разметке, следующие 2 дня проверил бы срочность, а ещё 3 дня сравнивал бы черновики с ответами сотрудников.
Решение о запуске принимал бы по цене ошибки. Если неверная метка лишь отправляет письмо не тому менеджеру, допустим осторожный автоматический маршрут. Если ошибка может привести к потере платежа, нарушению срока или конфликту с клиентом, оставил бы обязательное подтверждение человеком.
Через неделю у процесса должны появиться измеримые границы: сколько сообщений классифицировано, сколько попало на ручную проверку, сколько черновиков переписано и какие 5 ошибок повторяются чаще всего. Эти данные дают основание менять категории и шаблоны, а не спорить о впечатлениях.
Такой подход разгружает сотрудников постепенно. Сначала нейросеть убирает механическую сортировку, затем помогает готовить ответы, а окончательное решение остаётся у человека там, где цена промаха высока.