Желания (Запад) в модели Compass Model представляют собой менее конкретные, не всегда осознаваемые потребителем, цели и пожелания. Эти пункты не являются критически необходимыми, но существенно повышают удовлетворённость, когда реализуются. Чтобы выявить желания, следует задавать вопросы: "Что клиент хотел бы дополнительно?", "Какие необязательные элементы улучшили бы его опыт?" Например, для такси в командировке желаниями могут быть: прибытие вовремя, вежливый водитель, комфортная езда, приятная музыка и отсутствие навязчивых разговоров. Желания часто определяют дифференциацию сервиса и возможность превосходства над конкурентами.

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

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

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

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

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

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

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

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

На уровне «Яркая молодость» лидер выступает в роли «мотора-метронома», поддерживающего скорость и ритмичность работы команды. Лидер-слуга на этом этапе наиболее востребован (на 100%), помогая команде поддерживать устоявшиеся партнерские отношения с заказчиками, развивать эволюционирующий рабочий процесс и конструктивно решать конфликты. Важная задача лидера - способствовать развитию у команды продуктовых компетенций, чтобы она могла стать полноправным партнером для заказчика и вести диалог на одном языке. Лидер помогает команде правильно интерпретировать первый принцип Agile Manifesto, понимая, что изменение требований приветствуется не как повод переписать все заново, а как возможность для конструктивного диалога и серьезного исследования. На этом уровне лидер фокусируется на усилении команды, а не на управлении ею директивно.