Как навести порядок
в категориях и типах заявок

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

Структура нужна ради управляемости бизнеса, чтобы поток заявок можно было контролировать, измерять и масштабировать. Вот основные выгоды для бизнеса:

• Снижается стоимость обработки заявки. Меньше ручных пересылок, уточнений и повторной работы → сотрудники тратят меньше времени на одну заявку.

• Ускоряется время реакции и решения (SLA). Заявки сразу попадают в нужные команды, без «перекидываний» между отделами.

• Уменьшается нагрузка на первую линию и руководителей. Меньше ситуаций, где нужно вручную решать «куда это отнести» или «кто это должен делать».

• Повышается точность распределения нагрузки. Видно, какие команды перегружены, а какие недозагружены.

• Улучшается операционная аналитика. Можно реально понять, какие типы задач генерируют больше всего работы и где теряются ресурсы.

• Снижается количество ошибок в обработке заявок. Меньше человеческого фактора при маршрутизации → меньше «не туда отправили» и возвратов, значит меньше негатива от клиентов.

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

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

Хорошая древовидная структура решает эту проблему незаметно для пользователя. Она не заставляет думать, она подсказывает. Человек просто идет по логичному пути и заявка попадает к нужному исполнителю.

Древовидная структура – это способ разложить все обращения на понятные уровни – от общего к частному. Сначала пользователь выбирает область, к которой относится его вопрос, затем уточняет услугу, а уже потом – конкретный тип запроса.

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

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

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

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

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

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

Человек не обязан знать, какой именно отдел отвечает за его задачу. Более того, он не хочет об этом думать. Его интересует результат: получить доступ, починить оборудование, оформить отпуск.

Попытка «придумать идеальную структуру с нуля» почти всегда заканчивается тем, что создается еще одна теоретическая модель, не имеющая отношения к реальности. Гораздо надежнее опираться на уже существующие данные.

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

Интересно, что даже изначально правильное дерево со временем может превратиться в источник проблем. Это происходит постепенно: добавляются новые категории, появляются дубли, разрастаются формулировки, и в какой-то момент система теряет свою ясность. Особенно показательный симптом – рост категории «прочее». Если в нее уходит значительная часть заявок, это означает, что пользователи не находят подходящий вариант в основной структуре.

В этот момент важно не усложнять систему еще больше, а наоборот – упростить ее. Убрать лишнее, объединить пересекающиеся категории и вернуть структуре исходную логику.

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

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

В правильно настроенной системе пользователь направляет заявку, и после этого сервис-деск самостоятельно определяет нужный отдел и назначает ответственного или группу сотрудников.

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

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

• срочные заявки теряются среди обычных;
• старые обращения зависают без движения;
• сотрудники берут «что ближе», а не «что важнее»;
• руководителю сложно контролировать загрузку.

Фильтры – это способ превратить один хаотичный список в несколько управляемых потоков. Сотрудник должен видеть не все подряд, а только то, что относится к его зоне ответственности здесь и сейчас. Оптимальный набор, без которого работать будет сложно, выглядит так:

• по ответственному – чтобы видеть только свои заявки;
• по статусу – новые, в работе, на согласовании, закрытые;
• по приоритету – чтобы отделять срочное от обычного;
• по категории – когда специалист работает с конкретным типом задач.

Эти фильтры закрывают 80% повседневных сценариев.

Если фильтры отвечают на вопрос «что смотреть», то сортировка – на вопрос «в каком порядке работать». Без нее даже отфильтрованный список остается просто списком. Сотрудник всё равно решает сам, какую задачу взять первой.

Чаще всего используют сортировку:

• по сроку выполнения (SLA) – чтобы не пропускать дедлайны;
• по приоритету – чтобы сначала обрабатывать критичные заявки;
• по дате создания обращения – чтобы не забывать старые обращения.

В Admin24 можно сделать сортировку по формам, например с сайта или мессенджера, а уже внутри формы настроить услуги и подуслуги, а также назначать ответственных.

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

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

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

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

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

На практике обычно выделяют три ключевых типа:

• инциденты – когда что-то сломалось;

• запросы на обслуживание – когда нужно что-то сделать (выдать доступ, настроить, оформить);

• изменения – когда требуется вмешательство в систему или процесс.

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

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

Есть простой критерий: тип заявки должен влиять на процесс.

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

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

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

Важно помнить, что структура – это не разовая настройка, а рабочий инструмент, который должен развиваться вместе с компанией. Появляются новые задачи, меняются процессы, растет нагрузка – все это должно отражаться в классификации. Чем проще и логичнее устроена система на этом уровне, тем стабильнее работает сервис-деск в целом.