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

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

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

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

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

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

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

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

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

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