ИИ для классификации и маршрутизации обращений в Jira и Zendesk

Краткий ответ: классификация обращений с помощью ИИ полезна, когда категории четко определены, а качество отдельно проверяется для каждого класса, а не одной общей метрикой точности. Тема, язык, приоритет и эмоциональность обращения — разные поля. Эмоциональное письмо не обязательно является критическим инцидентом, а спокойное описание может оказаться аварией.

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

Какие решения автоматизировать

Слово «маршрутизация» объединяет несколько отдельных решений. Их стоит разделить: у каждого своя логика и цена ошибки.

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

Самая распространенная ошибка — смешивать тональность и приоритет. Фраза «Срочно, где мой счет?!» звучит как авария, но это обычный вопрос об оплате. А письмо «Добрый день, с утра ни один сотрудник не может войти в систему» написано спокойно, хотя описывает инцидент, затронувший всю компанию клиента. Если выставлять приоритет по эмоциям, первое письмо обойдет второе.

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

Подготовка категорий

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

Что нужно для рабочей таксономии:

• Непересекающиеся определения. Одно-два предложения для каждой категории: что в нее входит, а что нет. Например: «Доступ: проблемы со входом, сброс пароля, права пользователей. Не включает: полную недоступность сервиса для всех — это технический сбой».
• Примеры. Несколько реальных обращений для каждой категории, особенно пограничных.
• Категория для неизвестного. Обращение, не подходящее ни к одной категории, должно попасть в отдельную очередь на ручную проверку, а не в наиболее похожую категорию.
• Разумное количество. Категорий должно быть достаточно для маршрутизации и столько, сколько команда способна качественно размечать. Двадцать мелких категорий без различий в обработке только увеличивают число ошибок.

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

Встроенные функции и собственный классификатор

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

Zendesk. Функция intelligent triage классифицирует новые обращения по теме (раньше поле в интерфейсе называлось «намерение»), тональности, языку и сущностям, например названиям продуктов, а также показывает уровень уверенности классификации. Согласно документации Zendesk, на октябрь 2026 года классификации доступны на планах Suite и Support Professional и выше, а для использования в триггерах и других рабочих процессах требуется дополнение Copilot. Первичная классификация основана на теме обращения и первом публичном комментарии. Если в вашем аккаунте включена динамическая классификация, тема и тональность могут переоцениваться после последующих ответов клиента; язык при этом не обновляется с каждым ответом. Zendesk также рекомендует отдельно для каждой темы определить, какой уровень уверенности нужен для автоматического действия.

Jira Service Management. Atlassian предлагает ИИ-сортировку очереди: агент выбирает несколько обращений, получает предложения по новым типам запросов и заполнению полей, просматривает их и применяет выбранные. То есть перед применением изменений их подтверждает человек. Есть ограничения: тип запроса, обязательные поля которого ИИ не может заполнить, недоступен для выбора; функция требует включенных возможностей ИИ и недоступна в некоторых средах.

Что нужно проверить в своей учетной записи:

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

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

Критические ошибки

Не все ошибки классификации одинаковы. Рассматривайте отдельно две группы.

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

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

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

Практические меры защиты:

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

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

Измерение

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

Учебный пример: как общая точность скрывает пропущенные инциденты

Размеченная выборка: 200 обращений. Из них 196 обычных (оплата, доступ, технический сбой, возврат) и 4 критических инцидента.

Классификатор правильно определил 188 из 196 обычных обращений и только 1 из 4 критических.

• Общая точность: (188 + 1) / 200 = 189 / 200 = 94,5%.
• Полнота (recall) для класса «критический инцидент»: 1 / 4 = 25%. То есть три из четырех аварий попали не туда.

Показатель 94,5% выглядит хорошо, но для бизнеса результат неприемлем. Поэтому метрики считают по каждому классу.

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

Учебная таблица проверки отдельных обращений

Какие метрики считать:

• Точность (precision) по классам: какая доля обращений, отнесенных моделью к классу, действительно ему принадлежит.
• Полнота (recall) по классам: какую долю всех обращений класса обнаружила модель. Для критических классов это главная метрика.
• Матрица ошибок: показывает, с какими классами модель путает каждый класс и какие определения нужно уточнить.
• Ручные переназначения: как часто агенты перемещают обращение в другую очередь после автоматической маршрутизации.
• Время до первого ответа и решения по очередям до и после запуска с учетом сезонности.

Запуск и обновление

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

1. Теневой режим. Модель классифицирует обращения, но результат только записывается в поле и не влияет на маршрутизацию. Команда работает как прежде, а вы сравниваете прогнозы с фактическими решениями агентов.
2. Ограниченная очередь. Автоматическую маршрутизацию включают для одной-двух категорий с лучшими метриками и низкой ценой ошибки. Критические классы пока остаются под ручным контролем или отдельными правилами.
3. Расширение. Новые категории подключают только после того, как их precision и recall на свежей размеченной выборке достигнут уровня, согласованного руководителем поддержки.
4. Регулярный пересмотр. Обращения меняются вместе с продуктом, проблемами и сезонами. Регулярно пересчитывайте метрики и обновляйте таксономию с примерами, если растет доля ручных переназначений или обращений в категории «неизвестное».

Вывод

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

Что можно сделать в своем процессе:

1. Разделите решения на тему, очередь, язык, приоритет и тональность. Определите, что решает модель, а что — правила.
2. Опишите непересекающиеся категории с примерами и категорией «неизвестное». Проверьте согласованность разметки двумя людьми.
3. Уточните, какие функции классификации и маршрутизации доступны именно на вашем тарифе Jira или Zendesk.
4. Соберите размеченную выборку с отдельной группой критических обращений и считайте precision и recall по классам, а не только общую точность.
5. Запустите классификацию в теневом режиме, затем подключите ограниченную очередь с низкой ценой ошибки.
6. Назначьте ответственного за регулярный пересмотр метрик, таксономии и правил приоритета.

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

Часто задаваемые вопросы