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

Автоматическая классификация тикетов — одно из самых «благодарных» применений NLP в бизнесе. Здесь AI не заменяет человека полностью (как в случае с чат-ботами), а убирает рутину и ускоряет процесс. Оператор получает тикет уже с категорией, приоритетом и контекстом — и может сразу начать решать проблему, вместо того чтобы разбираться, о чём вообще речь.

Но чтобы классификация работала, нужны правильные категории, качественные данные для обучения и понимание того, как встроить AI в процесс.

Зачем вообще классифицировать тикеты

Казалось бы, оператор сам прочитает тикет и поймёт, о чём он. Зачем автоматизировать? На самом деле причин несколько.

Маршрутизация — главная из них. Не все операторы одинаковые. Кто-то специализируется на биллинге, кто-то — на технических проблемах, кто-то — на новых клиентах. Правильная классификация позволяет отправить тикет тому, кто решит его быстрее и качественнее. Без классификации тикеты распределяются случайно или по принципу «кто свободен», что неэффективно.

Ещё одна причина — приоритизация. Обращение «у меня не работает всё» важнее, чем «как изменить email в профиле». Но пока человек не прочитает оба тикета, он не знает, какой брать первым. AI определяет приоритет автоматически и выстраивает очередь так, чтобы критичные проблемы решались первыми.

Не забываем про аналитику. Чтобы понять, какие проблемы возникают чаще всего, где узкие места в продукте, что бесит клиентов — нужны данные. А данные — это классифицированные обращения. Без классификации вы не знаете, что 40% тикетов — про доставку, а 5% — про баг в приложении. С классификацией картина становится прозрачной.

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

Типы классификации

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

Тематическая классификация — о чём тикет: биллинг, техническая проблема, вопрос о продукте, жалоба, благодарность. Это может быть дерево категорий с несколькими уровнями: «Технические проблемы → Мобильное приложение → Авторизация».

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

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

Классификация тональности — как клиент себя чувствует: нейтрально, раздражён, гневный, доволен. Это влияет на то, как обрабатывать обращение.

Классификация сложности — справится ли junior-оператор, или нужен specialist. Можно ли решить по скрипту, или нужен индивидуальный подход.

На практике обычно комбинируют несколько типов: определяют тему + приоритет + тональность. Это даёт полную картину для маршрутизации и обработки.

Как работает классификация под капотом

Технически это задача классификации текста — одна из базовых в NLP. На вход подаётся текст тикета, на выходе — метка категории (или несколько меток). Есть разные подходы.

Классический ML-подход: текст превращается в числовой вектор (TF-IDF, word embeddings), затем обучается классификатор (SVM, Random Forest, градиентный бустинг). Этот подход работает хорошо, когда категорий немного и есть чёткие слова-маркеры для каждой. Например, слово «оплата» сильно коррелирует с категорией «Биллинг».

Нейросетевой подход: используются трансформеры (BERT, RoBERTa) или их русскоязычные аналоги (ruBERT, SBERT). Модель понимает не только ключевые слова, но и контекст: «не могу зайти» и «не работает вход» — это про одно и то же, хотя слова разные. Качество обычно выше, но нужно больше данных и вычислительных ресурсов.

LLM-подход (GPT, Claude): модель получает текст тикета и prompt с описанием категорий, возвращает классификацию. Этот подход не требует обучения на ваших данных (zero-shot), но дороже в эксплуатации и сложнее контролировать. Подходит для прототипов или когда категории меняются часто.

На практике часто комбинируют: быстрая классическая модель для 80% случаев, LLM для сложных или неоднозначных. Это оптимизирует cost и quality.

Какие данные нужны для обучения

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

Откуда взять данные? Обычно из истории. Если операторы классифицировали тикеты вручную — это ваш датасет. Проблема в том, что ручная классификация часто неконсистентна: разные люди размечают по-разному, категории меняются со временем, много ошибок.

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

Если размеченных данных мало — придётся размечать. Это можно сделать силами операторов (качественно, но дорого), краудсорсингом (дешевле, но нужен контроль качества), или полуавтоматически (AI предлагает категорию, человек подтверждает или исправляет).

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

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

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

Правила хороших категорий. Взаимоисключающие: один тикет попадает только в одну категорию (или используйте multi-label, если это не так). Полные: любой тикет имеет подходящую категорию, нет «прочее», куда попадает 30% обращений. Понятные: оператор, видя категорию, понимает, что это значит. Сбалансированные: категории примерно равны по объёму (не 90% в одной и по 1% в остальных).

Глубина дерева категорий — отдельный вопрос. Можно сделать плоский список из 10 категорий, а можно — трёхуровневое дерево. Глубже = точнее, но сложнее обучить модель и сложнее использовать. Обычно 2 уровня — оптимум.

Хорошая практика — начать с data-driven анализа. Посмотрите существующие тикеты, кластеризуйте их по темам, определите естественные группы. Это лучше, чем придумывать категории «из головы».

Интеграция в рабочий процесс

Модель обучена — что дальше? Классификация должна встроиться в процесс так, чтобы приносить пользу.

Вариант 1: Автоматическое присвоение категории. Модель классифицирует, результат сразу записывается в тикет. Оператор видит готовую категорию. Это самый простой сценарий, но требует высокого качества модели (иначе ошибки будут раздражать).

Вариант 2: Предложение с подтверждением. Модель предлагает категорию, оператор подтверждает или исправляет. Это даёт обратную связь для улучшения модели и снижает риск ошибок, но добавляет шаг в процесс.

Вариант 3: Invisible classification. Классификация работает под капотом, но оператору не показывается. Используется только для маршрутизации и аналитики. Подходит, когда классификация нужна системе, а не людям.

Выбор зависит от use case. Для маршрутизации часто достаточно варианта 3. Для отчётности, где важна точность категорий, лучше вариант 2.

Пример: классификация для IT-службы

Проект для IT-департамента крупной компании. К ним поступало около 500 тикетов в день: от «не работает принтер» до «нужен доступ к SAP». Раньше все тикеты попадали в общую очередь, и диспетчер вручную распределял их по командам. Это занимало 2-3 часа в день.

Мы спроектировали систему категорий: 12 категорий первого уровня (оборудование, доступы, сеть, ПО и т.д.) и 45 — второго. Каждой категории соответствовала команда-исполнитель.

Для обучения использовали историю за год — около 120 000 тикетов с разметкой. Разметка была неидеальна (около 15% ошибок), поэтому мы прогнали очистку: исправили очевидные ошибки, убрали тикеты с неактуальными категориями, добавили примеры для редких классов.

Модель (BERT-based) показала точность 87% на тестовой выборке. Для 13% ошибочных — ручное перенаправление, но это всё равно быстрее, чем классифицировать вручную.

Интеграция: при создании тикета модель автоматически присваивала категорию и назначала команду. Если уверенность модели ниже порога (70%) — тикет уходил диспетчеру для ручной проверки. Это было около 10% тикетов.

Результат: время на маршрутизацию сократилось с 3 часов до 20 минут (ручная проверка edge cases). Среднее время решения тикета уменьшилось на 15% — потому что тикеты сразу попадали к нужной команде.

Мониторинг и улучшение

Запустили модель — работа только начинается. Качество классификации нужно мониторить и постоянно улучшать.

Метрики для мониторинга. Accuracy — общая доля правильных классификаций. Precision и Recall по категориям — особенно важно для критичных категорий. Confusion matrix — какие категории путаются чаще всего. Confidence distribution — сколько классификаций с высокой/низкой уверенностью.

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

Обратная связь от операторов. Дайте возможность исправлять категорию — и используйте эти исправления для дообучения. Это создаёт петлю улучшения: чем больше исправлений, тем лучше модель.

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

Типичные ошибки и как их избежать

Ошибка 1: Слишком много категорий. Когда категорий 100, модели сложно различать похожие, операторам сложно выбирать. Начните с 10-15 и расширяйте по необходимости.

Ошибка 2: Категория «Другое». Это ловушка — туда попадает всё, что непонятно. Модель учится кидать в «Другое» любой сложный случай. Лучше: если что-то не попадает в существующие категории — это сигнал создать новую.

Ошибка 3: Игнорирование редких классов. Если категория появляется в 1% тикетов, модель её плохо выучит. Но это может быть критичная категория (например, жалобы VIP-клиентов). Решение: oversampling, class weights, или специальный порог уверенности.

Ошибка 4: Отсутствие fallback. Что происходит, когда модель не уверена? Если нет механизма — тикет получает случайную категорию с низкой уверенностью. Нужен порог: если уверенность ниже X — отправлять на ручную классификацию.

Ошибка 5: Забыть про multi-label. Иногда тикет относится к нескольким категориям: «не могу оплатить» — это и биллинг, и техническая проблема. Если ваши данные такие — используйте multi-label классификацию.

ROI классификации

Как посчитать экономический эффект? Вот основные составляющие.

Экономия времени на маршрутизацию. Если раньше диспетчер тратил 3 часа в день, а теперь 30 минут — это 2.5 часа × стоимость часа × рабочие дни в год.

Ускорение решения тикетов. Правильная маршрутизация = меньше переназначений = быстрее решение. Если среднее время решения сократилось на 10% — это экономия времени всей команды поддержки.

Улучшение CSAT. Быстрое и точное решение → довольные клиенты → меньше оттока. Это сложнее измерить, но часто даёт наибольший эффект.

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

Типичный ROI для проекта классификации — 3-5x за первый год. Это консервативная оценка; в компаниях с большим объёмом обращений эффект может быть ещё выше.

Заключение

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

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

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