Если в компании внедрен Service Desk, заявки регистрируются, у каждой есть категория, отчёты формируются исправно и кажется, что вопрос решения заявок пользователей и клиентов закрыт. Но наличие системы учета не означает, что заявки решаются в срок. Пока в Сервис деск не внедрена классификация заявок, правила приоритизации, SLA (соглашения об уровне сервиса) порядка не будет.
Меня зовут Алексей Носков, я руковожу службой технической поддержки ALP ITSM. Если у вас в компании Service Desk уже есть, а уверенности, что он реально управляет сервисом, нет, этот текст для вас.
Как заявка проходит путь от обращения до исполнителя
У каждой заявки в Service Desk один и тот же маршрут. Сотрудник или клиент обращается по почте, телефону, через портал или чат, и заявка регистрируется в системе, где фиксируются время, тема и автор обращения. Дальше ее классифицируют, то есть определяют тип проблемы и часто сразу присваивают уровень важности. И только потом назначают исполнителя, который берет заявку в работу и закрывает с отметкой о результате.
У каждой зарегистрированной заявки одинаковый набор полей: тема, автор, способ обращения, время создания, категория, приоритет, статус и позже — ответственный исполнитель. Эти параметры нужны не только для одной конкретной заявки: по ним потом считают количество обращений по типам и нагрузку на каждую линию поддержки. Заявку между специалистами распределяют с помощью маршрутизации с учетом типа обращения и текущей загрузки.
На бумаге кажется, что это просто. При внедрении сервисного управления регистрация и категоризация заявок — только видимая часть работы. Внутри идёт своя работа: команда разрабатывает процессы управления инцидентами, запросами, проектами и изменениями, прописывает правила доступа и ведёт документацию. Параллельно настраивают автоматизацию приёма и обработки заявок под эти процессы. Без этого слоя система все равно принимает заявки. Но выбирает, что с ними делать, уже не автоматика, а конкретный человек по своему усмотрению.
Так выглядит самый простой вариант работы Service Desk. В одном из аудитов ALP ИТ‑служба фактически была замкнута на одном системном администраторе, который сам решал, что делать сначала, а что подождет, а руководство было убеждено в стабильности ИТ, несмотря на то, что жалобы и сбои шли постоянным фоном. Пришлось буквально заново восстановить реальный путь заявки, чтобы найти, где он проваливается. Формально система была, а управления в ней не было.
Что дает классификация заявок и почему это только этап
У категоризации одна конкретная задача. Она отвечает на вопрос, что за проблема пришла и кому ее передать. Разбивка обычно идет по типу обращения (инцидент, стандартный запрос, консультация, проектная задача) и по объекту (оборудование, ПО, сеть, доступ). На этом этапе диспетчер или система понимает, к какой команде и какому специалисту направить заявку. Позже по этим же данным строится аналитика обращений: она показывает, каких заявок больше всего и где узкое место.
Качество этого анализа целиком зависит от точности типов обращений на входе: если дежурный на глаз относит разные проблемы к одному типу, это будет искажать картину и команда будет чинить не то, что реально «течет». Постепенно у команды накапливается база знаний — по старым заявкам видно, что уже помогало при похожей проблеме, и специалисту не приходится каждый раз решать с нуля.
Процесс обработки заявок можно построить по‑разному. Кто‑то классифицирует вручную. Этим занимается дежурный первой линии поддержки или руководитель, который знает специфику компании. Кто‑то использует CRM или Help Desk‑систему, где типы обращений заводятся заранее и заявка попадает в нужную очередь автоматически. Есть и вариант с алгоритмами на основе искусственного интеллекта (ИИ), обученными на истории обращений. Алгоритм предполагает тип обращения по тексту, а инженер подтверждает или поправляет его. Это ускоряет работу диспетчера.
Здесь сортировка заявок по типам заканчивается. Она отвечает на вопрос «что это за проблема», но не отвечает на вопросы «когда ее решат» и «в каком порядке, если задач одновременно несколько». Ответ на эти два вопроса дают не категории, а договоренности поверх них.
У инцидента и запроса на обслуживание разные правила
Среди типов обращения — инцидент и запрос на обслуживание. На первый взгляд это просто два пункта одного списка, но на практике у них разная логика с самого начала. Упала почта — это инцидент: что‑то, что работало, сломалось, и разбираться нужно быстро. Нужен новый ноутбук новому сотруднику — это запрос на обслуживание: ничего не сломано, просто требуется предоставить ресурс по уже согласованной процедуре.
Для инцидента цель — вернуть сервис в рабочее состояние как можно быстрее, и время реакции считается от момента, когда все встало. Для запроса на обслуживание цель — выполнить заранее согласованную процедуру, и разумный срок может измеряться не часами, а сутками или неделей — в зависимости от того, что именно запрошено и что нужно для выполнения (согласование бюджета, закупка оборудования, предоставление доступа третьей стороне).
Если в системе классификации нет этого разделения, оба типа обращений попадают в одну очередь с одинаковыми правилами: либо выдача нового ноутбука получает тот же приоритет, что и упавшая почта, либо реальный сбой ждет своей очереди наравне с запросом на обслуживание. Тип обращения без деления на инцидент и запрос на обслуживание отвечает на вопрос «кому передать», но не отвечает на вопрос «по какому правилу и как быстро решать обращение».
Здесь и нужен каталог ИТ‑услуг — перечень типовых запросов и услуг, для каждого из которых заранее прописан свой срок и порядок выполнения. Без каталога, SLA приходится либо усреднять по всем заявкам сразу, что не работает (инцидент и запрос на обслуживание требуют разной скорости), либо определять сроки вручную по каждому обращению — а это снова возвращает к тому, с чего мы начали: заявка есть, а правил нет. Каталог дает основу — что и в каком темпе делать; SLA, о котором дальше, добавляет к этому конкретные сроки и цену их нарушения.
Зачем связывать заявки между собой
Есть ещё один слой, который классификация по типу и объекту не закрывает сама по себе. Заявки, формально относящиеся к разным категориям, но по сути вызванные одной и той же причиной, нередко обрабатываются независимо друг от друга. Специалист решает конкретное обращение и закрывает его, не видя, что за последний час пришло еще пять похожих — просто с другой темой письма или от другого отдела.
Если систему настроить так, чтобы похожие по описанию или по времени поступления заявки связывались между собой, картина меняется. Вместо пяти отдельных заявок появляется один связанный кластер, за которым видна системная причина — например, один и тот же сервер или сервис, который затрагивает сразу несколько пользователей. Такая связка прежде всего разгружает первую линию поддержки: вместо пяти похожих разборов достаточно одного. Но дело не только в экономии времени: часть системных проблем в принципе видна, только если посмотреть на заявки не по одной, а вместе.
Без связки заявок аналитика по типам и объектам показывает, каких обращений больше всего, но не показывает, какие из них на самом деле — одна и та же проблема, повторившаяся у разных людей. Ресурс уходит на устранение симптомов, а не причины.
Компании останавливаются на классификации, не доходя до SLA
Самая частая ошибка не в том, что категоризацию обращений делают плохо, а в том, что на ней решают остановиться, посчитав дело закрытым. Категория присвоена, заявка видна в системе. Кажется, что порядок уже есть. Но категория сама по себе не превращается ни в срок, ни в очередность. Для этого нужны еще как минимум два слоя правил: SLA и регламент приоритизации.
SLA переводит категорию в обязательство по времени
SLA (Service Level Agreement, соглашение об уровне обслуживания) — он превращает категорию заявки в конкретное время реакции и решения. Обычно он фиксирует сразу несколько параметров: время реакции, время решения и часы работы линии поддержки, — и именно по ним потом сверяют, уложились или нет. Без него категория «критично» ни к чему не обязывает. У заявки есть ярлык, но нет числа, с которым можно сверяться. Разрыв между ожиданием бизнеса и возможностями ИТ в такой ситуации никто не видит, пока не случится реальный сбой. Компания рассчитывает на восстановление за час, а на деле ИТ способно закрыть проблему за четыре. Обе стороны узнают об этом расхождении только на инциденте. В рабочий SLA входит и эскалация: если время реакции истекло, а ответственный не откликнулся, заявка должна уходить на следующий уровень поддержки, а не зависать у одного человека.
Он работает, только если нарушение имеет цену. Практика показывает: если для критичных инцидентов заранее прописано время реакции (например, несколько минут на реагирование) и решения большей части задач в течение часа, а нарушение этих сроков влечет конкретную компенсацию, — SLA становится рабочим инструментом, а не формальностью. Пока такой цены нет, это остается пожеланием, а не обязательством.
Регламент приоритизации превращает список заявок в очередь по важности
Второй слой — правило, что делать, если заявок одновременно несколько. Без него важность заявки определяет тот, кто эмоциональнее написал или кто первым дозвонился, а не тот, у кого действительно горит критичный процесс.
Регламент приоритизации — письменное правило, которое заранее определяет, что важнее: сломанный принтер у одного сотрудника или упавший сервер, от которого зависит склад. Без него решение каждый раз принимается заново, вручную, и часто в пользу того, кто настойчивее.
Какую часть заявок компания вообще не видит
У хорошо продуманной категоризации есть слепая зона. Обращения, которые вообще не попадают в систему, она не видит. На практике часть заявок в малом и среднем бизнесе вообще не доходит до Service Desk. Люди пишут напрямую ИТ‑специалисту, звонят или обсуждают проблему в рабочем чате или любом другом мессенджере. Для пользователя разницы никакой: он написал знакомому айтишнику и получил ответ, а не полез оформлять заявку через портал. Формально процесс охватывает все, что в него попало. По факту он видит только часть реального потока.
Так выглядело в одном из риск‑чекапов ALP: задачи ведутся в рабочем чате, канбан‑доска заведена, но реально не используется. Четких правил обновления систем и смены паролей нет, а ключевые технические решения принимает один специалист без обсуждения с бизнесом. Управление в такой схеме получается реактивным. Реагируют по факту происходящего, а не по заранее согласованному плану. Формально все выглядит безупречно. Заявки заведены, ярлыки расставлены. Просто половина реальных обращений вообще не доходит до Service Desk.
Отсюда практический вывод. Прежде чем настраивать типы обращений и уровни важности, стоит закрыть вопрос единого канала входа. Заявка, откуда бы она ни пришла (по почте, телефону, из чата), должна попасть в одну систему. Без единого входа под контролем оказывается только тот поток заявок, который вообще добрался.
Формальный Service Desk без правил — кейс из практики
По опыту нашей команды, такая ситуация типична для многих компаний, которые формально завели Service Desk, но не довели дело до конца.
В одном из аудитов Service Desk формально был, заявки в системе создавались, отчеты строились. Но при этом правила классификации и приоритизации, а также сроки обработки, не были закреплены. В результате система превратилась не в инструмент управления сервисом, а в журнал заявок, где многое по‑прежнему зависит от личной памяти и ручного контроля руководителя.
Но по сути это работает как архив обращений, а не как инструмент поддержки, который сам подсказывает, что горит сейчас и кто за это отвечает.
Что теряет бизнес без правил игры
У отсутствия SLA, регламента приоритизации и единой точки входа — своя цена, и это не абстрактный риск. По данным исследования (глубинные интервью со 180 заказчиками, 2026 год), 39% компаний за последний год почувствовали, что стоимость часа простоя ИТ выросла. Это общий рыночный фон, а не измерение стоимости конкретно заявки. Но логика та же: чем дольше решается заявка, тем дороже обходится компании задержка.
Без SLA заявки задерживаются и накапливаются. У специалиста нет ориентира, с чего начинать. Поэтому задачи решаются в порядке поступления или личной симпатии, а не по важности для бизнеса. Без договоренности о том, что важнее, заявки теряются и дублируются. Два сотрудника независимо просят «поднять этот вопрос», заводятся две карточки на одну проблему, а то, что действительно важно, так и остается неявным. Без единой точки входа качество решения падает. Специалист видит только часть картины (то, что дошло до Service Desk) и предлагает решение, не зная о параллельных обращениях по той же теме. На практике это же означает, что количество повторных обращений по одной и той же проблеме растет: команда каждый раз тратит время на то, чтобы заново разобраться, а не продолжить с того места, где остановился коллега.
Цена измерима. В одном из проектов у клиента временная CRM без SLA и четких правил приоритизации обходилась в сезон в 1,5–1,9 млн рублей в месяц недополученной выручки и штрафов (70–90 тысяч рублей в день простоя). А там, где эти правила выстроили, эффект оказался быстрым. В одном ретейл‑проекте единая система с прозрачными критериями приоритизации сократила срок решения заявки с 2 дней до 3–4 часов. Обращения перестали теряться между почтой, звонками и личными договоренностями.
С чего начинать путь от классификации к сервисному управлению
Если классификация уже есть, а порядка все еще нет, процесс стоит достраивать по слоям, а не переделывать его с нуля.
Начинают обычно с каталога типовых услуг — деления на инциденты и запросы на обслуживание — и фиксации времени реакции по каждому типу, с понятной ценой за нарушение. Дальше нужна письменная договоренность, что важнее, если задач одновременно несколько, а не разовое решение по ситуации. Следующий шаг — свести все обращения в единую точку входа, потому что даже идеальный процесс видит только тот поток, который до него дошел. И в конце нужна проверка результата. Не «настроили и забыли», а регулярный взгляд на то, что реально происходит с заявками, зафиксированный в правилах, правах доступа и общей документации компании, а не в голове одного специалиста. Это же экономит время на обучении: новый дежурный читает готовую инструкцию про категории и приоритеты, а не подсматривает решение на живых примерах у более опытного коллеги.
Стоит держать в голове и более длинный горизонт. Внедряя классификацию и SLA в ИТ, компания по сути выстраивает модель сервисного управления, а не разовую настройку для одного отдела. Через год‑два эта модель нередко выходит за пределы ИТ — на HR, офис, бухгалтерию. Это не проблема, а хороший знак: значит, подход реально работает, и другим подразделениям хочется того же порядка.
Что делать дальше
Дальше вопрос не в том, что делать, а в том, каким инструментом это делать. Иногда достаточно понять, где именно система буксует, без доступа к серверам и без остановки бизнеса.
Если непонятно, какой инструмент диагностики нужен в конкретной ситуации (экспресс‑чекап, полноценный аудит или консалтинговый проект), этот выбор подробно разбирает статья «ИТ‑чекап, ИТ‑аудит или ИТ‑консалтинг: какой инструмент выбрать собственнику».
