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

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

Среди деловых игр, ориентированных на ИТ, выделяются две: "Apollo - ITSM на практике" и "Grab@Pizza - ИТ и основной бизнес". Эти игры разработаны специально для ИТ-специалистов, хотя в них также предусмотрены отдельные роли для представителей бизнес-подразделений, что позволяет привлечь их к участию.

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

ITIL предоставляет структурированный подход к управлению стоимостью сервисов через Financial Management for IT, который описывает методы расчета стоимости ресурсов и услуг с учетом как прямых, так и косвенных затрат. Это обеспечивает точное распределение затрат между потребителями услуг, позволяет анализировать стоимость-эффективность различных сервисов и формировать обоснованные цены или внутренние ставки для учета ресурсов, что ведет к более прозрачному и экономически рациональному управлению ИТ-услугами.

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

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

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

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

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