Для получения качественных ответов рекомендуется ограничиться 2-3 вопросами. Большое количество вопросов повышает риск отсутствия ответов или получения случайных, невнимательно заполненных ответов, так как пользователи часто не хотят тратить много времени на такие опросы.

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

Активно расширяющиеся компании выделяют на 'развитие и управление ИТ' лишь 1-2% от общего размера ИТ-бюджета, что значительно меньше, чем компании, придерживающиеся стратегии выживания (которые выделяют 4-8%).

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

Назначение начальника отдела поддержки пользователей (Service Desk) менеджером процесса управления инцидентами приводит к вытеснению функций менеджера сквозного процесса функциями руководителя отдела поддержки. Это создает ряд проблем: сложности во взаимодействии со второй линией поддержки, появление изолированных видов поддержки, когда обращения поступают мимо первой линии без регистрации в системе автоматизации. Особенно эта проблема актуальна в отделах сопровождения прикладных систем, так как первая линия часто недостаточно компетентна для оказания полноценной поддержки по прикладному ПО. В результате пользователи и специалисты воспринимают первую линию как лишнее звено, увеличивающее время обработки обращений, а ценность процесса управления инцидентами снижается, так как основные риски связаны с нарушениями в работе прикладного ПО.

Availability (Availability) представляет собой показатель, определяющий, насколько система, компонент или услуга могут быть использованы в заданное время. В технической надежности, согласно ГОСТ 27.002-89 (ГОСТ Р 53480-2009), этот термин переводится как «готовность». В ITIL и ISO/IEC 20000 он трактуется как «доступность». Разница кроется в контексте применения: «готовность» акцентирует внимание на технической способности системы функционировать, тогда как «доступность» в ИТ-управлении связана с предоставлением услуги пользователю. Термины отражают разные аспекты одной метрики и требуют уточнения в документах для избежания неоднозначности.

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

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

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

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