Классификация заявок: почему Service Desk есть, а порядка нет

Привет, на связи Алексей Носков, руководитель службы технической поддержки ALP ITSM. В этой статье разбираю, почему классификация заявок это только часть сервисного управления, а не весь ответ на вопрос «а порядок у нас есть?».

Коротко об ALP ITSM: работаем с 1996 года и с тех пор выстраиваем ИТ-поддержку и сервисное управление для компаний.

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

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

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

Так выглядит крайний случай. В ходе аудитов ALP выявляем одну из самых частых ошибок: ИТ-служба фактически замкнута на одном системном администраторе, который сам решает, что делать сначала, а что подождет. При этом руководство убеждено в стабильности ИТ, несмотря на постоянный фон из жалоб и сбоев. Пришлось заново оцифровать реальный путь заявки, чтобы найти, где он проваливается. Формально система была, а управления в ней не было.

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

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

Процесс обработки заявок можно построить по-разному. Кто-то классифицирует вручную. Этим занимается дежурный первой линии поддержки или руководитель, который знает специфику компании. Кто-то использует CRM или Help Desk-систему, где типы обращений заводятся заранее, инициатор выбирает из этого списка и заявка попадает в нужную очередь автоматически. Есть и вариант с алгоритмами на основе искусственного интеллекта (ИИ), обученными на истории обращений. Алгоритм предполагает тип обращения по тексту, а инженер подтверждает или поправляет его. Это ускоряет работу диспетчера.

Здесь сортировка заявок по типам заканчивается. Она отвечает на вопрос «что это за проблема», но не отвечает на вопрос «когда ее решат» и «в каком порядке, если задач одновременно несколько». Ответ на эти два вопроса дают не категории, а договоренности поверх них.

Среди типов обращений есть инцидент и запрос на обслуживание. На первый взгляд это просто два пункта одного списка, но на практике у них разная логика с самого начала. Упала почта? Это инцидент. Что-то, что работало, сломалось, и разбираться нужно быстро. Нужен новый ноутбук новому сотруднику? Это запрос на обслуживание. Ничего не сломано, просто требуется предоставить ресурс по уже согласованной процедуре.

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

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

Здесь и нужен каталог ИТ-услуг, то есть перечень типовых запросов и услуг, для каждого из которых заранее прописаны срок и порядок выполнения. Без каталога сроки в SLA приходится либо усреднять по всем заявкам сразу, что не работает (инцидент и запрос на обслуживание требуют разной скорости), либо определять вручную по каждому обращению, а это снова возвращает к тому, с чего мы начали: заявка есть, а правил нет. Каталог отвечает, что и в каком темпе делать. SLA, о котором пойдет речь дальше, добавляет к этому конкретные сроки и цену их нарушения.

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

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

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

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

Категорию заявки в конкретное время реакции и решения превращает соглашение об уровне обслуживания (Service Level Agreement, SLA). Обычно оно фиксирует сразу несколько параметров: время реакции, время решения и часы работы линии поддержки. По этим критериям потом определяют, уложились в SLA или нет.

Без соглашения приоритет «критично» ни к чему не обязывает. У заявки есть ярлык, но нет критерия, с которым можно сверяться. Разрыв между ожиданием бизнеса и возможностями ИТ в такой ситуации никто не видит, пока не случится реальный сбой. Компания рассчитывает на восстановление за час, а на деле ИТ способно закрыть проблему только за четыре. Обе стороны узнают об этом расхождении только на реальном инциденте. Эскалация тоже часть рабочего SLA. Если время реакции истекло, а ответственный не откликнулся, заявка не должна зависать у одного человека, а должна уходить на следующий уровень поддержки.

Подробно о том, как устроен рабочий SLA и зачем он нужен собственнику, а не только ИТ-отделу, я уже разбирал в статье «SLA — три волшебные буквы». Здесь скажу главное. Соглашение работает, только если нарушение имеет цену. По одному из наших тарифов мы фиксируем конкретные сроки реакции и обработки (например, до пяти минут на реагирование и решение 80% задач в течение часа), а за нарушение возвращаем клиенту по 1500 рублей за каждый час просрочки. Пока в договоре на обслуживание такие санкции не прописаны, SLA остается пожеланием, а не обязательством.

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

«Система приоритетов. Какие проблемы будут решаться в первую очередь? Формально срочно — это не значит важно для бизнеса. SLA должен разделять „важно для компании" и „срочно для сотрудника", чтобы критические задачи не терялись среди мелких поломок».

— Дмитрий Бессольцев, генеральный директор ALP ITSM

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

Порядок выполнения заявок с одинаковым приоритетом тоже вопрос регламента, а не случая. Предположим, поступили две заявки без явного различия по важности: у сотрудника в соседнем кабинете не работает мышка, а у бухгалтера завис перевод платежа в банк-клиенте. Заменить мышку: 10 минут. Разобраться с банк-клиентом: два часа. Суммарное время на обе заявки от порядка не меняется: 2 часа 10 минут в любом случае. Но реакция, то есть скорость, с которой хотя бы одна заявка получит решение, зависит от порядка целиком. Если начать с короткой задачи, первый ответ приходит через 10 минут. Если начать с длинной, ответа приходится ждать два часа, при формально одинаковом приоритете обеих заявок. Поэтому регламент должен закрывать не только уровни приоритета, но и правило на случай, когда приоритет совпадает.

У хорошо продуманной категоризации есть слепая зона. Обращения, которые вообще не попадают в систему, она не видит. На практике часть заявок в СМБ вообще не доходит до Service Desk. Люди пишут напрямую ИТ-специалисту, звонят или обсуждают проблему в рабочем чате: в телеграме или любом другом мессенджере. Для пользователя разницы никакой: он написал знакомому айтишнику и получил ответ, а не полез оформлять заявку через портал. Формально процесс охватывает все, что в него попало. По факту же он видит только часть реального потока.

Так было в одном из риск-чекапов ALP: задачи ведутся в рабочем чате, канбан-доска заведена, но реально не используется. Четких правил на обновления и смену паролей нет, а ключевые технические решения принимает один специалист без обсуждения с бизнесом. Управление в такой схеме получается реактивным. Реагируют по факту происходящего, а не по заранее согласованному плану. Формально все выглядит безупречно. Заявки заведены, категории определены. Просто половина реальных обращений вообще не доходит до Service Desk.

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

По опыту нашей команды, эта ситуация встречается во многих компаниях, которые формально внедрили Service Desk, но не довели дело до конца.

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

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

Проверьте, на чем держится порядок в ИТ

Пять минут и несколько вопросов: чек-лист «7 симптомов, что ИТ работает на честном слове» покажет, где стоит присмотреться в первую очередь.

Забрать чек-лист →

Каждый пробел из предыдущих разделов имеет свою цену, и это не абстрактный риск. По данным исследования (глубинные интервью со 180 заказчиками, 2026 год), 39% компаний за последний год почувствовали, что стоимость часа простоя ИТ-инфраструктуры выросла. Логика та же: чем дольше решается заявка, тем дороже обходится компании задержка.

Без SLA срок решения заявок и определение приоритета непредсказуемы. Заявки теряются и дублируются. Два сотрудника независимо друг от друга заводят одинаковые заявки: на одну проблему заводятся два обращения, и каждое решается отдельно, хотя в основе лежит одна проблема, решив которую комплексно можно закрыть сразу все типовые заявки. Без системы категоризации падает качество обслуживания: специалисты поддержки видят только часть картины (то, что дошло до Service Desk) и предлагают решения, не зная о параллельных обращениях по той же теме. На практике это означает, что количество повторных обращений по одной и той же проблеме растет: команда каждый раз тратит время на то, чтобы заново разобраться, а не продолжить с того места, где остановился коллега.

Цена отсутствия соглашений об уровне обслуживания (SLA) измерима. В одном из наших проектов у клиента «обслуживание» CRM без SLA обходилась в сезон в 1,5–1,9 млн рублей в месяц недополученной выручки и штрафов в 70–90 тысяч рублей за день простоя.

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

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

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

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

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

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

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

Стоит держать в голове и более длинный горизонт. Внедряя классификацию обращений и SLA в ИТ, вы по сути выстраиваете модель сервисного управления, а не разовую настройку для одного отдела. Через год-два эта модель нередко выходит за пределы ИТ: на HR, офис, бухгалтерию. Это хороший знак: значит, подход реально работает, и другим подразделениям тоже хочется порядка.

Дальше вопрос не в том, что делать, а в том, каким инструментом. Иногда достаточно понять, где именно система буксует.

Экспресс-диагностика «ИТ-чекап» сделана специально для этого: без доступа к администрированию серверов и без остановки бизнеса, за 3–5 рабочих дней становится понятно, какие риски есть сейчас и с чего начинать.

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

Что сделать сейчас

Если видите, что Service Desk формально есть, а порядка все равно нет, начните с диагностики: экспресс-чекап покажет, где именно система буксует и что делать по приоритету.

Узнать про ИТ-чекап

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

Реклама: ООО «КТ-АЛП», ИНН 7703402450, erid: 2W5zFHoXiWV