Почему классификация обращений клиентов ломается на объёме
На потоке в сотни обращений в день классификация держится на людях: оператор первой линии читает заявку, вручную определяет тему и перекладывает её в нужную очередь. Пока запросов немного, схема работает — тематик десяток, и человек удерживает их в голове целиком, без справочника.
Узкое место обработки обращений проявляется, когда поток растёт, а темы начинают пересекаться. Один и тот же запрос содержит вопрос по оплате, претензию к доставке и просьбу закрыть доступ — ручная сортировка обращений требует выбрать одну категорию, и выбор каждый раз делается заново. Решение принимается последовательно, по одному обращению, поэтому пропускная способность первой линии не растёт вместе с нагрузкой.
Дальше включается накопление: очередь первой линии растёт быстрее входящего потока, часть заявок ждёт разбора дольше, чем длится сам ответ. На пиках ошибочная маршрутизация отправляет запрос не в тот отдел — клиент получает ответ по чужому вопросу, пишет повторно, а исходное обращение оседает в истории переписки без владельца. Метрика времени первого ответа ещё держится, а время полного решения расходится с ней в разы.
Разбираем, как это закрывается: от разметки корпуса и правил разбиения пересекающихся тем до автоматической классификации, которая проставляет тематику и приоритет в момент поступления и оставляет человеку только спорные случаи.
Что даёт автоматическая маршрутизация обращений
Классификатор разбирает обращение на входе: определяет тематику, язык, признаки срочности и отдаёт его в нужную очередь вместе с черновиком ответа. Доля автораспознавания на закрытом наборе тем держится в диапазоне 0,75–0,9 — остаток не «докидывается» наугад, а попадает в общую очередь с пометкой для оператора.
Порог уверенности — главный параметр настройки. Ниже него система честно сообщает «не знаю» и передаёт обращение человеку: ложная маршрутизация дороже ручной разметки, потому что клиент получает ответ не от того, кто решает вопрос. Порог подбираем на удержанной выборке реальных обращений, а не на показательных примерах, и пересматриваем по мере появления новых тем.
Время первичного ответа сокращается за счёт автоматического подтверждения: клиент сразу видит номер обращения, определённую тему и ожидаемое время реакции. Операторы перестают тратить первую линию на сортировку — загрузка выравнивается между группами, а пиковые часы больше не упираются в одного дежурного.
Отдельный эффект — уходит класс потерянных обращений: без владельца, принятых вне часов работы, повторно отправленных после сбоя приёма. У каждого обращения появляется маршрут и срок, а отклонения от него видны в отчёте. Стыкуем это с той системой учёта, что уже работает у вас, — от Zendesk до самописной на почте и в мессенджерах.
Подходы к разметке: правила, словари, обучение на истории
Разметка потока обращений — это не выбор «правила или обучение на данных», а решение о том, где заканчивается зона ответственности словарей и начинается статистика. Ниже — три схемы, между которыми реально выбирают на старте, и ограничения каждой: они проявляются не на демо, а на второй-третий месяц эксплуатации, когда поток меняется.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Правила и словари | 5–15 устойчивых тематик, есть характерная лексика: артикулы, названия услуг, типовые формулировки | Ломается на перефразах и опечатках; словарь растёт быстрее потока; конфликт правил разводят приоритетами вручную |
| Обучение на исторических данных | Накоплена история обращений с проставленными тематиками, формулировки клиентов разнообразны | Нужна выверенная разметка выборки; при появлении новой тематики требуется дообучение; на редких классах качество падает |
| Гибридная схема разметки | Правила закрывают явные случаи, обучение — остальное, спорные уходят на ручной разбор | Нужны согласованные пороги уверенности и обратная связь: разбор ошибок возвращается в разметку выборки |
Гибридная схема даёт лучший баланс: словари снимают предсказуемую часть потока, обучение на истории — перефразированные обращения, а порог уверенности решает, что уходит оператору. Контур получается объяснимым на каждом шаге: видно, какое правило или какой пример из истории дал тематику, — и это же упрощает расширение набора классов без полной пересборки.
Как проходит внедрение: этапы работ от аудита до передачи
Классификация обращений не сводится к установке готовой модели: состав тем, пороги уверенности и правила маршрутизации зависят от вашего потока. Поэтому идём этапами, и каждый закрывается результатом, который можно проверить на ваших же данных.
- Аудит потока обращений — выгружаем историю из всех каналов, считаем объём, долю дублей, коротких и смешанных запросов.
- Перечень тем — рабочая таксономия на 15–40 тем первого и второго уровня, класс «прочее» и правило для запросов, попадающих сразу в две темы.
- Инструкция и разметка — фиксируем правила разметки и разбор спорных случаев, чтобы разметчики не расходились между собой.
- Настройка и обучение — базовый вариант модели, пороги уверенности по каждой теме, отдельная обработка коротких обращений и вложений.
- Пилот на срезе данных — прогон на отложенном срезе, который модель не видела, и сверка с ручной разметкой по каждой теме.
- Приёмка по метрикам — точность и полнота по темам, доля «прочее», доля уверенно отнесённых; порог, ниже которого решение не выходит в работу, согласуем заранее.
- Передача в поддержку — документация по таксономии, регламент дообучения и переразметки, мониторинг потока и порядок действий при падении метрик.
Что происходит после приёмки
Таксономия продолжает жить: появляются новые продукты, меняется сезонность, распределение запросов уходит от обучающей выборки. Раз в квартал пересматриваем пороги и дообучаем модель на новых размеченных обращениях — доля автоматической маршрутизации держится, а не сползает.
Артефакты проекта: правила, схемы, регламенты пересмотра
После сдачи проекта у команды заказчика не остаётся «чёрного ящика»: всё, что определяет поведение классификатора, лежит в его репозитории и версионируется вместе с кодом. Без этих артефактов проекта первая же новая тематика обращений потребует нас — и поддержка встанет на паузу.
- Схема интеграции: откуда обращения попадают в классификатор (CRM, канал поддержки, очередь), где точки отказа и как настроены повторы при сбое.
- Матрица доступа: кто видит разметку, кто правит тематики, кто меняет порог уверенности — права разведены по ролям, а не «у админа всё».
- Регламент пересмотра тем: периодичность (по расписанию или по доле неклассифицированных), порядок добавления темы и проверка на пересечение с уже существующими.
- Инструкция для операторов: что делать с сомнительным обращением, как его пометить, куда оно уходит и как быстро разметка попадает в дообучение.
- Конфигурация классификатора: порог уверенности, словари-исключения, правила маршрутизации спорных обращений на ручную проверку.
- Каталог тематик со словарём синонимов: как называются темы, что в них входит, какими формулировками клиенты их обозначают.
- Контрольная выборка обращений с ожидаемыми тематиками — прогоняется после каждой правки, чтобы видеть, не сломали ли старое.
- Журнал изменений: что, когда и по чьей заявке менялось в правилах — без него спорное решение не откатить.
Документы живут рядом с моделью и обновляются тем же порядком, что и код: правка — проверка на контрольной выборке — запись в журнал. Систему можно развивать своей командой, а нам отдавать только спорные участки.
Кейс: доля автоматической маршрутизации выросла до 92%
До внедрения маршрутизация держалась на правилах по ключевым словам и ручном разборе. Автоматически расходилось около 40% обращений, остальное операторы первой линии раскидывали по группам вручную и на пиках не успевали: ночная очередь отставала на 6–8 часов. Каждый пятый перевод оказывался ошибочным — обращение кочевало между группами, пока клиент ждал ответа.
От разметки к маршрутизации
Сначала мы разметили исторический массив обращений по единой таксономии. Спорные случаи закрывали не голосованием разметчиков, а по Регламенту разметки обращений: правило фиксировали один раз и дальше применяли ко всему потоку. Это подняло согласованность меток с 78% до 96% — модель перестала учиться на противоречивых примерах, где одна и та же формулировка помечена разными темами.
Что стало с метриками
В работу схема ушла с порогом уверенности: выше порога обращение уходит в группу автоматически, ниже — в очередь ручного разбора с подсказкой по вероятным темам. Доля автоматической маршрутизации выросла до 92%, ошибочные переводы упали с 17% до 4%, отставание ночной очереди сократилось с 6–8 часов до менее часа.
Устойчивость к пикам проверяли отдельно: при росте потока в 2,5 раза доля автоматики держалась на 89–91%, потому что нагрузка ложится на короткую очередь разбора, а не на людей. Каждое обновление проходит регрессионную проверку на отложенном наборе исторических обращений — если точность на редкой теме проседает, версия не выкатывается.
Чем отличается обучение на истории от правил и словарей?
Правила выигрывают там, где формулировка стабильна и цена ошибки высока. Номер договора, реквизиты, запрос выписки, заявка на закрытие счёта — это лексикон с фиксированным словарём, и правило по нему даёт точность, которую модель не воспроизводит: оно либо сработало, либо нет, и ответ повторяется от прогона к прогону. Пока тематик десяток и поток однородный, словарей достаточно — их проще объяснить поддержке и разобрать спорный случай.
Модель обходит правила там, где словарь кончается. «Перестало приходить», «списали дважды», «хочу как в прошлый раз» — на такие формулировки правил не напасёшься, а обученный на истории разбор ведёт их по смыслу и устойчив к опечаткам, транслиту и двум темам в одном обращении. Плата за это — вероятностный ответ: на выходе распределение по тематикам, и решение принимается по порогу уверенности.
Гибридный подход строится на разделении ролей. Правила берут короткие однозначные маршруты и защищённые категории, где ошибка дороже отказа от автоматизации, а модель — всё, что осталось после отсечения. Обращения ниже порога уходят в очередь оператора, и именно она становится источником разметки для следующего дообучения.
Словари при этом не отменяются, а сужаются до роли справочника и страховки. Раз в квартал разбираем, что попало в «остальное» и где правило сработало ложно, добавляем формулировки — но как только одна фраза подходит двум правилам, тему выгоднее перевести в модель. Пересмотр словарей становится регулярной процедурой, а не ремонтом накопившихся конфликтов.
Разметка, качество и пересмотр: вопросы перед стартом
Перед стартом заказчик обычно проверяет четыре вещи: хватит ли данных и как обеспечить качество разметки, что делать с пересекающимися и редкими темами, как подключать новые каналы обращений и можно ли обучать модель на реальных диалогах. Ниже — прямые ответы, без общих слов.
Сколько обращений нужно, чтобы качество разметки не развалилось?
Решает не объём, а согласие разметчиков: на спорных темах двое специалистов расходятся в 15–20% случаев, и эту дельту нужно снять до обучения. Мы закладываем инструкцию разметки с граничными примерами, контрольную выборку и замер согласия — иначе модель выучит шум вместо тематики.
Темы пересекаются и постоянно пересматриваются — что тогда?
Пересечение — норма: доставка и возврат живут в одном обращении. Мы задаём правила приоритета и разрешаем обращению получать основную тему плюс смежные, а пересмотр тем ведём по журналу ошибок: смотрим, какие пары классов путаются чаще всего, и уточняем границы формулировок.
Редкие темы не тонут в общем потоке?
По редким классам точность падает первой, поэтому мы считаем качество отдельно по каждой теме, а не одной средней цифрой. Дисбаланс выравниваем весами и добором примеров, а редкие темы помечаем для ручной проверки — так они не растворяются в массовых.
Как подключаются новые каналы и что с персональными данными?
Новый канал входит как отдельный источник со своим форматом, и мы сверяем его разметку с уже принятой — иначе классификация обращений клиентов поедет на непривычных формулировках. Персональные данные обезличиваются до обучения: телефоны, адреса и номера заказов заменяются метками, доступ к исходникам ограничен.
Обсудим задачу и вернёмся с оценкой и планом
Старт проекта упирается не в модель, а в данные и в решения, которые может принять только ваша сторона. Готовая чистая выгрузка нам не нужна — приведение обращений к единому виду и первичная обработка на нашей стороне. Что действительно нужно с вашей, чтобы не терять время на первые недели:
- история обращений за несколько месяцев в исходном виде: письма, тикеты, диалоги в чатах, расшифровки звонков — без ручной чистки и фильтрации;
- существующая рубрикация, если она есть: список тем, инструкции для операторов, примеры спорных случаев;
- ответственный за тему с вашей стороны — тот, кто подтверждает границы категорий и разбирает разночтения, иначе классификация разойдётся с вашей внутренней логикой;
- доступ к реальному контуру источников (почта, система учёта обращений, справочная служба, мессенджеры) с теми же правами, что у операторов;
- перечень тем, где операторы размечают уверенно, и тех, где спорят — эта граница определяет, где на выходе нужен человек;
- ограничения по персональным данным и выгрузке за периметр — от них зависит схема обработки;
- критерий приёмки: какая доля верных попаданий считается рабочей и на какой выборке её измеряем.
Опишите задачу — по этим пунктам вернёмся с оценкой объёма и планом работ, включая схему тем, порядок разметки и способ контроля качества на ваших данных.
