Большинство заявок попадают в категорию «Прочее»? Это не клиенты ленятся, а классификатор сломан

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

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

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

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

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

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

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

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

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

Ключевое условие — древовидная структура должна совпадать с тем, как человек формулирует проблему у себя в голове. Он не думает категориями «вторая линия» или «группа администрирования». Он думает: «мне нужен доступ», «у меня не печатает», «хочу в отпуск». Структура строится под эту логику, а не под оргсхему компании.

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

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

➤ Первая — сущности разного уровня в одном списке. Когда рядом стоят «ИТ», «Срочно» и «Помощь», у пользователя нет шансов сделать осознанный выбор: одно — область, второе — приоритет, третье — вообще не понятно что. Он не видит принципа, по которому построен список, и перестаёт пытаться его понять.

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

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

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

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

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

На практике типов обычно достаточно трёх:

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

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

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

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

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

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

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

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

Когда все заявки лежат в одном списке, срочное теряется среди обычного, старое зависает без движения, сотрудники берут «что ближе», а не «что важнее». Фильтры превращают один хаотичный список в несколько управляемых потоков. Минимальный набор — четыре: по ответственному, по статусу, по приоритету, по категории; они закрывают около 80% повседневных сценариев. Сортировка отвечает на следующий вопрос — в каком порядке брать в работу: по сроку выполнения SLA, по приоритету, по дате создания. Без неё даже отфильтрованный список остаётся списком, в котором сотрудник сам решает, за что хвататься, — и обычно хватается за то, что понятнее.

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

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

Масштаб потерь от беспорядка в обращениях не стоит недооценивать. Согласно опросу НАФИ и «Яндекс 360» за 2025 год, офисные сотрудники теряют до четырёх часов в день на рутинные операции, и значительная часть этих потерь связана с постоянным переключением между мессенджерами, почтой и порталами. Заявка, которую пользователь отправил «куда-то», а потом три раза переспросил в чате, «дошла ли», — это ровно такой случай.

Три совпадения из шести — классификатор пора пересобирать. Пять — он уже не работает, работают люди вопреки ему.

Почти всё это можно сделать в любом современном сервис-деске — принцип не зависит от инструмента. В Админ24, например, структура строится как каталог услуг и подуслуг. Каждой услуге назначается ответственный сотрудник или группа, а если указать «Все пользователи», заявку получает наименее загруженный в этот момент. Формы с сайта и из мессенджеров могут вести в разные ветки каталога. Но структура, которую вы создадите в этом каталоге, за вас не построит ни одна система — это работа руководителя поддержки, и делать её придётся руками и по имеющимся данным.

Интересно, как это устроено у вас: сколько категорий в вашем классификаторе и какая доля заявок уходит в «Прочее»? И кто в итоге решает, куда идёт заявка, — структура или живой человек, который «и так всех знает»?