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

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

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

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

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

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

В отчете менеджера процесса должны быть два обязательных раздела: первый — 'Что можно сделать для повышения эффективности процесса?', где формулируются предложения по улучшению, соответствующие целям процесса (например, сокращение времени устранения инцидентов). Второй раздел — 'Что уже сделано для повышения эффективности процесса в отчетном периоде и какие получены результаты?'. Эти разделы фокусируют внимание на конкретных действиях и их измеримых результатах, а не только на автоматизированных KPI.

Автоматизация играет ключевую роль в процессе обработки запросов технической поддержки, позволяя существенно сократить временные затраты на несколько этапов. Программа автоматически собирает техническую информацию от пользователя через систему контекстно-зависимых вопросов, классифицирует запрос по соответствующей ИТ-услуге и маршрутизирует его к нужной группе специалистов. Это устраняет необходимость ручного перенаправления запросов, минимизирует ошибки классификации и ускоряет начало работы над инцидентом. В результате автоматизация обеспечивает более быстрое и точное обслуживание, что подтверждается снижением среднего времени решения инцидентов на 40% за полгода при достижении 90% использования новой системы.

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

Заказчик - это лицо или группа лиц, которые покупают товары или услуги. В контексте поставщика ИТ-услуг заказчик определяет и согласовывает целевые показатели SLA (Service Level Agreements). Хотя иногда термин 'заказчик' может использоваться неформально для обозначения конечных пользователей (users), в официальной терминологии ITIL эти понятия четко разграничены. Заказчик также может быть внутренним (подразделение в компании) или внешним (клиент компании).