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

Но о серьезном сбое собственник чаще узнает не из отчета Service Desk, а от партнера, который две недели ждал ответа на письмо.

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

На связи Алексей Носков, руководитель службы технической поддержки ALP ITSM. Уже 30 лет наша команда обеспечивает сервисную поддержку ИТ у клиентов на аутсорсинге — и у многих один и тот же вопрос: почему Service Desk есть, а порядка все равно нет.

Путь заявки в Service Desk: от обращения до исполнителя

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

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

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

Классификация заявок — один из ключевых этапов поддержки

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

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

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

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

Где компании обычно останавливаются: классификация без SLA и критериев приоритизации

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

SLA переводит категорию в обязательство по времени

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

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

Подробно о том, как устроен рабочий SLA и зачем он нужен собственнику, а не только ИТ-отделу, мы уже разбирали в статье «SLA — три волшебные буквы». Здесь скажем главное. Он работает, только если нарушение имеет цену.

Регламент приоритизации превращает список заявок в очередь по важности

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

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

Разрозненные обращения: какую часть заявок вы не видите вовсе

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

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

Формально процесс охватывает все, что в него попало. По факту — только часть.

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

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

Симптомы формального Service Desk: кейс из нашей практики

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

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

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

Что теряет бизнес без правил игры

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

Без SLA заявки просто зависают: у специалиста нет ориентира, с чего начинать, — он берет то, что легло сверху, или то, что попросили погромче, а не то, что реально горит для бизнеса. С приоритетами похожая история: не договорились, что важнее, — получаем дубли. Два сотрудника независимо просят «поднять этот вопрос», заводятся две карточки на одну проблему, а то, что реально важно, тонет.

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

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

С чего начинать: от классификации к сервисному управлению

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

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

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

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

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

Больше разборов и историй из практики ALP ITSM — в Telegram-канале ALP ITSM.

Алексей Носков — руководитель службы технической поддержки ALP ITSM.