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

Бизнес-услуга (или customer-facing service в терминах ITIL V3) - это услуга, которая непосредственно предоставляется заказчику и на которую заключается соглашение об уровне услуги (SLA). Это видимая для клиента услуга, с которой он непосредственно взаимодействует. Примером может служить комплексное ИТ-обеспечение процесса продаж или бухгалтерского учета, которое клиент заказывает и использует напрямую.

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

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

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

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

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

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

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

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