ИИ сортирует обращения и передаёт сложные случаи оператору в 2026

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

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

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

Что делает автоматическая сортировка обращений

Автоматическая сортировка выполняет четыре операции: определяет тему, оценивает срочность, предлагает ответ и выбирает маршрут для человека. Такой порядок сокращает число решений, которые оператор принимает вручную в первые 30 секунд после получения сообщения.

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

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

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

Модельный кейс: в очереди из 120 обращений 72 относятся к четырём повторяющимся темам, 31 требуют уточнения, а 17 содержат признаки срочности. Нейросеть не принимает решение о компенсации, она лишь раскладывает поток по этим трём рабочим группам и показывает оператору основания для маршрута.

Как устроен маршрут от сообщения до ответа

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

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

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

На третьем этапе результат приводится к фиксированной схеме. Например, у сообщения могут быть поля «тема», «приоритет», «ответ разрешён» и «причина передачи». Человек быстрее проверяет четыре коротких поля, чем длинное рассуждение на 600 слов. Для аналитики полезно сохранять исходный текст, метку и итоговое решение оператора.

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

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

Как задавать правила срочности

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

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

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

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

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

Где автоматический ответ должен остановиться

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

Первое стоп-условие связано с полномочиями. Если ответ меняет сумму, срок, состав услуги или условия договора, нужна проверка сотрудника. Нейросеть может подготовить черновик и перечислить недостающие сведения, но не должна сама придумывать разрешение на исключение из правил.

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

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

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

Как измерять эффект без самообмана

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

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

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

Доля передачи человеку показывает, сколько диалогов автоматизация не пытается закрыть сама. Высокое значение не всегда плохо. На старте безопаснее передавать 70–80 процентов сообщений и постепенно расширять набор типовых тем, чем сразу разрешать автоматический ответ для всей очереди.

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

Повторные обращения и исправления нужно считать вместе. Если после автоматического ответа клиент возвращается в течение 24 часов, это сигнал проверить точность текста, полноту инструкции и корректность маршрута. Время оператора можно измерять выборочно, например по 30 заявкам каждой категории, чтобы не перегружать сотрудников ручным учётом.

Какой подход выбрать для разных отделов

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

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

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

Как запустить пилот за 14 дней

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

В первые 2 дня я собираю обезличенные сообщения и объединяю дубли. На 3-й и 4-й день фиксирую категории, приоритеты и стоп-условия. В выборке желательно иметь минимум 30–50 примеров на каждую частую тему, а редкие случаи описать отдельными правилами.

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

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

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

Что бы я сделал на вашем месте

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

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