Как ИИ ускоряет первичную обработку обращений

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

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

Я рассматриваю ИИ в поддержке как слой предварительной работы, а не замену специалиста. Нейросеть выделяет признаки, присваивает категорию, предлагает текст и передаёт человеку спорные случаи. Такой подход описан и в материале о внедрении нейросетей в рабочие процессы: сначала задачу встраивают в понятный процесс, затем измеряют результат.

Что входит в первичную обработку обращений

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

Сотрудник на этом этапе ещё не решает проблему полностью. Он отвечает на четыре практических вопроса:

1. О чём пишет человек: оплата, доставка, доступ, возврат, техническая неисправность или консультация?
2. Есть ли риск пропустить срок, деньги, блокировку услуги или конфликт с клиентом?
3. Можно ли дать ответ по утверждённой базе знаний?
4. Кому передать обращение, если требуется доступ, полномочия или экспертиза?

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

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

Как устроить конвейер обработки

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

1. Получение. Система принимает письмо или сообщение и сохраняет исходный текст без пересказа.
2. Извлечение. Из текста выделяются номер заказа, продукт, дата, контакт, причина обращения и ожидаемый результат.
3. Классификация. Запрос получает категорию, приоритет и признак необходимости участия специалиста.
4. Черновик. Нейросеть формирует ответ по базе знаний, без самостоятельного добавления неподтверждённых условий.
5. Маршрутизация. Простые случаи попадают в обычную очередь, срочные и спорные передаются ответственному сотруднику.

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

!Схема первичной обработки обращения

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

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

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

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

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

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

Модельный кейс: компания из сферы логистики, около 200 сотрудников, получает 600 сообщений в день. В её правилах обращение о недоступности личного кабинета для одного пользователя получает высокий приоритет, а сообщение о недоступности кабинета у 20 сотрудников переводится в критическую очередь. Число затронутых пользователей здесь меняет маршрут сильнее, чем эмоциональная окраска текста.

У каждой категории должен быть срок реакции. Например, критические обращения проверяются человеком в течение 15 минут, высокие в течение 1 часа, обычные в течение 8 рабочих часов. Это не универсальные нормативы, а стартовые значения для внутреннего регламента. Их корректируют по реальной нагрузке и договорённостям с клиентами.

Как классифицировать запросы без путаницы

Классификация становится устойчивой, если у каждой категории есть название, границы, 3–5 положительных примеров и список исключений. Одного короткого описания вроде «вопрос по оплате» для модели недостаточно.

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

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

Для каждой категории зафиксируйте три границы:

• что входит в группу;
• что относится к соседней группе;
• при каком условии обращение нужно передать человеку.

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

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

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

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

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

Модельный кейс: для условной службы с 1 000 обращений в месяц черновики разрешают отправлять без полной перепроверки только по двум категориям, например «статус доставки» и «поиск инструкции». Все запросы о возврате денег и спорных списаниях остаются у сотрудника, даже если модель оценила уверенность в 0,95.

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

Как передавать сложные случаи специалисту

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

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

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

Для контроля SLA я фиксирую 5 временных точек: поступление, классификация, передача, первый ответ и закрытие. По ним видно, где возникает задержка. Если классификация занимает 20 секунд, а передача специалисту 3 часа, улучшать промпт бессмысленно, проблема находится в очереди.

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

При потоке до 50 обращений в день достаточно правил и ручной проверки, при 50–300 полезна связка правил с нейросетью, а свыше 300 требуется отдельный контроль качества и распределения очередей. Точный порог зависит от длины сообщений, числа категорий и цены ошибки.

Таблица показывает главное: автоматизировать стоит повторяемую часть процесса, а не весь контакт сразу. Для первой версии я выбираю 1–2 категории с понятной базой знаний и оставляю обязательное подтверждение сотрудника.

Как измерять экономию времени и качество

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

Экономию времени можно считать по формуле: количество обращений умножить на среднее время ручного разбора до запуска, затем вычесть время проверки после запуска. Если 400 сообщений раньше требовали по 4 минуты, это 1 600 минут, или 26 часов 40 минут. При проверке по 90 секунды на сообщение остаётся 600 минут, экономия составляет 1 000 минут, или 16 часов 40 минут.

Эта арифметика имеет смысл лишь при сохранении качества. Если среднее время снизилось на 30%, а доля пропущенных срочных обращений выросла с 2% до 7%, процесс нельзя считать улучшенным. В отчёте я отдельно показываю скорость, точность и ошибки с высокой ценой.

Раз в 2 недели пересматривайте 20–30 ошибочных примеров. Удаляйте двусмысленные категории, добавляйте новые формулировки в набор примеров и меняйте правила эскалации. Полезные бытовые сценарии работы с нейросетями собраны в материале как использовать нейросети для повседневных задач, но для поддержки их нужно адаптировать под конкретные регламенты.

Как я бы запускал процесс

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

После этого я бы описал четыре уровня срочности, подготовил примеры для каждой категории и ввёл обязательную проверку всех черновиков. На 7-й день сравнил бы ошибки с ручной разметкой, на 14-й, время первого ответа и долю корректных маршрутов.

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

Так ИИ экономит время там, где работа повторяется и поддаётся проверке. Человек сохраняет контроль над деньгами, претензиями, доступом и любым случаем, где цена неверного ответа выше нескольких минут ручного разбора.