Разработка AI-системы автоматического создания тикета после обращения

Автоматическое создание тикета: где ломается обработка обращений

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

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

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

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

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

Что меняется после внедрения: скорость и полнота разбора

Эффект внедрения измеряется не «стало удобнее», а числами, которые снимаются с панели отчётности поддержки. Мы фиксируем их до запуска и принимаем систему по этому списку — каждая строка берётся из штатной выгрузки за период.

• [ ] Доля обращений, разобранных без человека. Модель читает текст обращения, вытаскивает сущности и сама закрывает типовые сценарии — в массовых темах это 60–75% входящего потока.
• [ ] Время до назначения исполнителя. Обращение больше не ждёт ручной сортировки в очереди: срок сокращается с десятков минут до секунд, а первый ответ приходит в ту же сессию.
• [ ] Доля возвратов на уточнение. Если в тикете нет продукта, версии или шагов воспроизведения, исполнитель возвращает его автору — цель по этому показателю однозначные проценты от общего числа.
• [ ] Ушедший класс отказов маршрутизации. Ошибочные назначения между очередями (запрос по оплате падает в техподдержку) перестают быть системной проблемой: очередь выбирается по содержанию, а не по форме заявки.
• [ ] Нагрузка на поддержку. Освободившиеся часы уходят на сложные кейсы, а не на механическую сортировку и переписывание полей.
• [ ] Полнота тикета. Обязательные атрибуты заполняются на входе из данных обращения, а не по памяти автора или оператора.

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

Способы приёма обращений: правила, классификатор, языковая модель

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

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

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

Этапы внедрения: от аудита обращений до первых тикетов

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

1. Аудит потока обращений. Считаем каналы, типы запросов и их доли, повторяемость формулировок. На выходе — карта категорий и черновые правила маршрутизации.
2. Схема разбора. Договариваемся, какие поля тикета заполняются автоматически (тема, категория, приоритет, исполнитель), а какие остаются на человеке, и в каком виде система отдаёт результат.
3. Настройка интеграций. Подключаем источники обращений и систему учёта: почта, чат, форма на сайте, внутренний портал. Отдельно проверяем, что повторная доставка письма не порождает второй тикет.
4. Порог уверенности. Каждый разбор получает оценку достоверности. Выше порога тикет создаётся сразу, ниже — уходит оператору с предзаполненными полями, чтобы решение оставалось за человеком.
5. Пилот на исторических данных. Прогоняем закрытые обращения и сверяем категорию, приоритет и исполнителя с тем, что решили вручную. По расхождениям правим правила и формулировки подсказок.
6. Приёмка качества разбора. Фиксируем целевую точность по категориям и долю обращений, принятых без правок, разбираем самые частые классы ошибок.
7. Передача в эксплуатацию. Настраиваем мониторинг доли автозаполнения, регламент разбора спорных случаев и порядок изменения порогов без остановки приёма обращений.

Что передаём на руки: схемы, правила маршрутизации, регламенты

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

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

Кейс: разбор обращений в поддержке до и после внедрения

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

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

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

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

Чем отличается автоматическая классификация от правил маршрутизации?

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

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

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

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

Частые технические сомнения перед запуском

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

А если тема редкая и похожих примеров почти не было?

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

Как сохраняется история переписки и вложения?

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

Человек остаётся в цепочке и как контролируется качество разбора?

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

Обсудим задачу: чего не хватает для точной оценки

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

• Постановка задачи: какой результат считаем успешным — доля обращений, разобранных без оператора, точность определения темы и приоритета, время от сообщения до готового тикета.
• Выгрузка обращений: 2-3 месяца переписки в текстовом виде без персональных данных, обязательно включая случаи, которые операторы закрывали дольше обычного, — на них видны границы модели.
• Каналы приёма: почта, чат на сайте, мессенджеры, расшифровки звонков — сколько их, какой объём и в каком виде приходит текст.
• Системы учёта: где создаются тикеты, какие поля обязательны, как устроены справочники проектов, очередей и исполнителей.
• Правила эскалации: по каким признакам обращение уходит на человека, кому и в какой срок, что считается критичным и требует немедленной реакции.
• Ограничения по данным: требования к хранению и обезличиванию, запрет на передачу наружу, нужна ли изолированная среда.
• План внедрения: какие системы и доступы затрагиваем, кто принимает результат на стороне заказчика, в какие окна выкатываем изменения.

Опишите задачу и приложите то, что есть из списка, — вернёмся с оценкой, планом и перечнем рисков.