В какой-то момент я перестал верить в «зеленые» дашборды. Вам, возможно, знакома ситуация, когда по красивым отчетам SLA 99,9% доступности сервиса, 95% заявок закрываются в срок, но при этом при общении с заказчиком выясняется, что несмотря на отличные показатели работать невозможно, системы периодически зависают, интерфейс неудобный.
Одна из таких ситуаций до сих пор стоит у меня перед глазами. Заявка отмечена как «решена», сроки соблюдены. По факту пользователь три дня подряд пытался решить проблему, звонил в техподдержку, каждый раз рассказывал историю заново, а проблема возвращалась. В SLA это выглядело как три успешно закрытых инцидента. Для человека — как три дня потерянного времени и ощущения, что ИТ «держит его за дурака».
Именно такие истории подтверждают, что SLA для оценки качества услуг недостаточно. Он говорит о средней температуре по больнице, но как живется конкретному пациенту по этим данным мы не узнаем и не поймем насколько ему плохо.
Меня зовут Авдей Мартынович, я руковожу подразделением по работе со средним и малым бизнесом. Более 20 лет я занимаюсь поддержкой ИТ-инфраструктуры. Работал как с крупными enterprise клиентами, розницей, так и с малым и средним бизнесом. И много раз видел ситуации, когда идеальные отчеты по факту не означают качественный сервис.
SLA измеряет работу систем, но не учитывает опыт пользователей. Именно поэтому появился XLA подход, который ставит во главу угла не техническую доступность, а реальную продуктивность сотрудников. В статье поделюсь опытом и расскажу как в ALP ITSM мы пришли к XLA через работу с обратной связью и что из этого реально работает.
Что такое SLA и XLA простыми словами
SLA (Service Level Agreement) — это соглашение об уровне сервиса. Это договор между бизнесом и ИТ, в котором фиксируются ключевые показатели качества работы систем.
Например, в показателях мы можем зафиксировать доступность системы в 99,9%, среднее время реакции на инцидент — 15 минут. Если служба поддержки обеспечивает эти показатели — SLA выполнен.
Последние годы SLA стал золотым стандартом. Но у него есть одна проблема — он показывает показатели работы систем и программного обеспечения, а не то, насколько довольны пользователи. Другими словами, он фокусировался на железе и софте, а не на человеке.
Т.е. дашборд может быть «зеленым», но при этом сотрудники при этом недовольны. Например, в одной из компаний SLA закрытия заявок на поддержку 95% в срок, но при этом сотрудники в опросах ставят 5 из 10, т.к. им приходится по несколько раз подавать заявки, т.к. проблема возникает повторно, а чтобы ее решить приходится просто «выбивать» решение из техподдержки. Или другой пример, доступность сервиса может быть 99,9%, но рабочие сценарии неудобны, пользователи тратят лишнее время на то, чтобы пробраться среди дебрей интерфейса к нужной функции и постоянно испытывают ощущение, что ИТ «тормозит бизнес», хотя и доступность высокая и время реакции при возникновении проблем быстрое. Такое явление еще называют «Эффект арбуза» (Watermelon Effect): зеленый снаружи, красный внутри.
XLA (Experience Level Agreement) — это соглашение об уровне опыта.
Здесь мы уже измеряем не технические параметры, а как сотрудник чувствует себя и работает с системами.
Если SLA спрашивает «Как работает система», то XLA спрашивает «Продуктивен ли сотрудник, работающий с ней?».
Важно понимать, что XLA не заменяет SLA. Они работают в связке. SLA гарантирует стабильность, XLA гарантирует бизнес-ценность.
Критерий | SLA (Service Level Agreement) | XLA (Experience Level Agreement) |
Что измеряет | Измеряет показатели работы ИТ-систем и процессов. | Показывает удовлетворенность пользователей и получаемую ценность при работе с сервисами |
Фокус внимания | На целях, сроках и бюджетах. | Фокусируется на опыте и потребностях пользователей. |
Отношение к успеху | Игнорирует реальный успех проекта, если формальные метрики соблюдены ("Эффект арбуза"). | Нацелен на реальную пользу для бизнеса и повышение производительности персонала. |
Мотивация | Фокус на санкциях и штрафах за невыполнение. | Фокус на вознаграждении за улучшение пользовательского опыта. |
Динамика метрик | Методика измерения остается неизменной. | Целевые уровни меняются для непрерывного улучшения. |
Таблица. Сравнение SLA и XLA
Когда я впервые услышал термин XLA, подумал: «Очередная аббревиатура для продажи консалтинга». Но потом понял — мы занимались этим последние шесть лет, просто не называли это модным словом. Главное не в терминах, а в умении слышать обратную связь от клиента: «Доволен ли человек, который работает с нашими системами?»
Как возникла тема XLA
Первые точечные упоминания XLA появились еще в 2018–2019 годах, но последние годы публикаций на тему стало больше. Это создает ощущение, что XLA это что-то новое. Но по сути XLA опирается на давно известную практику работы с обратной связью.
Например, в ALP ITSM мы уже последние лет шесть после каждой закрытой заявки автоматически спрашиваем у пользователя оценку от 1 до 5, комментарий к оценке и при желании он может оставить голосовое сообщение. Эта оценка идет прямо в KPI инженера и руководителя подразделения. Средний балл должен быть не менее 4,85. Заявки с оценкой ниже 3 мы разбираем на техническом комитете: поднимаем логи, время реакции, переписку, созваниваемся с самим пользователем и находим причину провала, в чем ошибка — где в процессе ошибка, что привела к недовольству клиента.
Давайте разберем примеры метрик XLA:
Оценка удовлетворенности пользователей (End-user satisfaction score)
CSAT по ИТ‑сервисам (например, «поставьте оценку от 1 до 5, насколько вам помогло решение»);
средний балл по опросам после обращения или по регулярным пульс‑опросам.
Индекс готовности рекомендовать (Net Promoter Score (NPS))
«Насколько вы готовы порекомендовать наш ИТ‑сервис/службу коллеге?» (0–10);
рассчитывается как % промоутеров минус % критиков, дает интегральную оценку лояльности к ИТ‑сервисам.
Интегральный индекс цифрового опыта (Digital Experience Score (DEX))
Он может включать:
технические показатели на уровне рабочего места (скорость приложений, число ошибок, время входа);
субъективные оценки удобства работы с основными системами;
частоту/характер жалоб и негативных комментариев.
Дополнительно в XLA могут могут считать:
Время, которое пользователь реально тратит на выполнение типовых задач (например, «от открытия формы до оформления договора — не более X минут»).
Количество «болезненных» сценариев в месяц (повторяющиеся жалобы на конкретный сервис или шаг процесса).
Индекс фрустрации (частота негативных слов в заявках и чатах по конкретному сервису).
Почему внедрять нужно именно сейчас
Многим еще не знакомо понятие XLA. Возможно вам незнакомо название, но если вы задумывались о том, насколько довольны ваши пользователи, а не только как хорошо работают эти системы — вы с ним работали. С каждым годом требования к оценке пользователями качества сервиса возрастает, т.к. они начинают играть ключевую роль в удовлетворенности работой и рабочим местом сотрудников.
Институт XLA официально объявил этот год «годом перехода от разговоров к действиям». Причины этому две:
Технологическая зрелость. Раньше измерять «опыт» было дорого и сложно. Сейчас AI-инструменты встроенные в Service Desk позволяют автоматически анализировать тональность общения в реальном времени. У нас появился точный инструмент измерения «счастья». Насколько нам известно, в многих банках и крупных ИТ-компаниях при общении с ботами и автоответчиками работает это правило: как только уровень недовольства клиента возрастает, он автоматически переадресуются на реального специалиста, который может помочь снять накал страстей.Это и есть XLA в действии — система реагирует на пользовательский опыт, а не на формальные значения (длительность разговора, качество связи и т.д.).
Массовое принятие. По данным опроса Version1, 55% опрошенных планируют внедрение XLA в ближайший год. Тема из разряда «инноваций» попала в планы. Даже в сообществах Gartner дискуссия сместилась с вопроса «Зачем?» на вопрос «Как?».
Цена игнорирования
Если вы считаете, что «опыт сотрудников» — это лирика, а не управляемый показатель, внешних исследований предостаточно. Например, оценка плохого цифрового опыта (DEX — Digital Employee Experience) наносит финансовый ущерб:
32 рабочих дня в год теряет каждый сотрудник из-за медленной работы и сложности с взаимодействием с ИТ-системами.
$438 млрд — глобальные потери производительности из-за низкой вовлеченности сотрудников.
29% сотрудников готовы уволиться, если рабочие инструменты неудобны и тормозят.
В России запрос на прозрачность ИТ-услуг огромен: 64% компаний называют управляемость услуг своим приоритетом, но только треть имеет достаточно зрелые процессы.
У нас в ALP это давно рабочая рутина. Если где-то начинают повторяться инциденты, мы не ждем новой волны жалоб, а заводим проблему и разбираем ее как отдельный кейс. Два-три одинаковых обращения по одному и тому же поводу — это уже системная деградация, даже если мониторинг молчит. Такой подход не раз спасал нас от крупных аварий. Мы «ловили» проблемы на уровне мелких инцидентов, пока они не стали критичной проблемой.
Самые показательные примеры связаны с 1С. Классический сценарий: мониторинг показывает, что сервер доступен, нагрузка в норме, но пользователи просят перезагрузить сервер, мы перезагружаем, ненадолго становится лучше, но дальше картина повторяется. При детальной диагностике вскрывали истинную причину. Она могла лежать в разных плоскостях:
на уровне гипервизора, где не хватало ресурсов;
в коде 1С, который годами никто не оптимизировал;
в огромной базе, куда годами складывали все подряд без обслуживания.
Дальше уже совместно с клиентом мы планировали работы, чтобы устранить корневую причину.
Если бы мы подходили к вопросу формально, то все эти ситуации могли стать обычными инцидентами с выполненным SLA. Но для пользователей такие проблемы становились вечным пинг-понгом заявок, где запрос перекидывался между несколькими подрядчиками или исполнителями, где каждый отвечает за свою часть и не готов взять ответственность за работу сервиса целиком.
XLA подход позволяет разорвать этот порочный круг, смотреть не только на время восстановления, время реакции и решения, но и на то, сколько раз человек вынужден возвращаться к одной и той же проблеме, сколько сил он на это тратит.
Почему зрелый DEX/XLA — это деньги
Еще одно исследование подтверждает, что опыт сотрудников критически важен — отчет Forrester «Digital Employee Experience Maturity Enables The Future Of Anywhere Work».
Компании с высокой зрелостью DEX:
в 7 раз чаще сообщают о снижении числа простоев в работе сотрудников (65% против 9%);
в 3 раза чаще говорят о сокращении нагрузки на Service Desk за счёт проактивного подхода и самовосстановления (64% против 20%);
в 3 раза чаще фиксируют 0 утечек данных за год (21% против 6%);
на 62% чаще удерживают ключевых сотрудников.
На бумаге это выглядит красиво, но ценность XLA становится по‑настоящему осязаема, когда начинаешь измерять свой опыт. Ранее я уже писал, как у нас устроены оценки по заявкам и разбор низких баллов — это, по сути, XLA в ежедневной рутине.
Когда ты годами честно разбираешь каждый провал по оценкам, а не просто складываешь их в отчёт, начинают происходить интересные изменения:
становятся незаметными повторяющиеся инциденты — их ловят и решают на уровне проблем, а не бесконечных тикетов;
эскалаций «до директора» становится меньше, потому что до взрыва пользователю уже кто‑то позвонил и разрулил ситуацию;
команды поддержки меньше выгорают: люди видят, что их не «бьют по шапке» за чужие ошибки или кривой процесс, а разбираются, где реально источник боли.
Если говорить об эффективности, то сотрудники меньше времени простаивают, меньше времени уходит на разрешение конфликтов. Не тратят время и нервы на управление инцидентом, последующие разборы полетов, отчеты.
Как внедрить XLA
Не стройте «космолет». Двигайтесь по уровням зрелости, от простого к сложному.
XLA 1.0: Начните с оценки настроения и анализа тональности
Что делат��: Поменяйте подходы к сбору обратной связи. Замените вопросы типа «Оцените качество обслуживания по 10-балльной шкале» на: «Насколько легко вам было решить проблему?». Это покажет усилия сотрудника (Customer Effort Score, CES) при решении проблемы с ИТ-сервисом.
Инструмент: Внедрите AI-анализ тональности в чатах. Фраза «Опять ничего не работает!!!» должна стать инцидентом связанным с пользовательским опытом, даже если мониторинг молчит.
Просто начните спрашивать пользователей не только о доступности сервисов, а о том, насколько им удобно и легко решать свои задачи с помощью ИТ-систем.
Самые ценные инсайты приходят не из автоматических опросов, а из разговоров. Когда ты лично звонишь пользователю, поставившему «двойку», и спрашиваешь: «Что случилось?» — там всплывают такие детали, которые никакой мониторинг не покажет.
XLA 2.0: Научитесь сопоставлять метрики опыта и технические показатели
Что делать: Сопоставьте технические метрики с данными опыта. Начните измерять показатели ИТ-систем в связке с обратной связью пользователей. Если в чате накал страстей, а показатели немного упали, но при этом системы еще зеленые, это повод задуматься, насколько такая «зеленая» зона действительно рабочая.
Например, если время отклика 1С превышает 3 секунды, количество жалоб в чате бухгалтерии растет. Отслеживая время отклика системы вы можете прогнозировать настроения пользователей и отслеживать реальную работоспособность сервиса.
Уровень 3. XLA 3.0: Выделите роли и требования к каждой
Что делать: Не все по��ьзователи одинаковы. Выделите ключевые пользовательские роли.
Пример:
Полевой инженер: критична надежность VPN с телефона.
Топ-менеджер: критична персональная поддержка и работоспособность связи.
Удаленщик: критична скорость удаленного доступа к системам.
Для каждой роли должен быть свой набор метрик. Один и тот же простой в 5 минут для топ-менеджера — это катастрофа, а для полевого инженера — обычное дело. XLA 3.0 учитывает эти различия и строит разные модели для разных групп пользователей.
Пилотный проект: начните с малого
Не внедряйте XLA везде сразу. Сделайте двухнедельный пилот.
Выберите один процесс: Например, «Выход нового сотрудника».
Поставьте цель XLA: «Сотрудник полностью готов к работе и имеет все доступы в первый час» (вместо SLA «Учетка создана за 24 часа» после запроса руководителя).
Соберите простую команду: IT + HR + Представитель бизнеса. Проводите 20-минутные ревью раз в неделю: «Где красная зона? Почему? Что чиним?».
Такой подход позволяет быстро получить ощутимые результаты и показать ценность XLA заинтересованным сторонам без масштабных вложений.
Смена культуры: почему штрафы работают в контракте, но не в команде
Внедрение XLA мы упираемся не только в метрики, но и в мотивацию команды. Здесь важно разделитьотношения «Заказчик — Подрядчик» и отношения внутри ИТ-команды.
1. Внешний контур: Ответственность бизнеса
Когда вы работаете с внешним провайдером — язык денег. Мы придерживаемся именно этого принципа: в наших договорах с клиентами жестко прописана финансовая ответственность. Если мы нарушаем обязательства по доступности сервиса, мы платим штраф. Это наш риск и наша гарантия качества для бизнеса.
2. Внутренний контур: Люди — главная ценность
Механически переносить эту «карательную» логику на сотрудников — тупиковый путь.
Если каждый инженер будет знать, что за малейшее отклонение его лишат премии, включится режим «самосохранения». Сотрудники начнут «накручивать» показатели, лишь бы не получить штраф. Страх убивает инициативу и желание.
💬 Моя позиция: Штрафы за ошибки — это путь в никуда. Я видел компании, где инженеров лишали премий за каждую просроченную заявку. Результат? Люди начинали «рисовать» метрики, закрывать тикеты формально, лишь бы не получить штраф. Вместо решения проблем — имитация работы.
В философии ALP люди — это ключевая ценность компании. Чтобы сотрудники хотели развиваться и решать сложные задачи клиентов, применять штрафы — тупиковый путь, если только в исключительных случаях грубых нарушений, после которых как-правило с такими сотрудниками расстаются. Наш подход основан на мотивации и вовлеченности.
Мы поменяли парадигму от страха ошибки к подходу — поощрение за результат. Если ИТ-команда помогла бизнесу заработать больше денег, она заслуживает долю этого успеха. Это превращает ИТ из «обслуживающего персонала» в полноценного бизнес-партнера.
У нас есть положение о премировании, где благодарность от клиента — основание для премии инженеру. Не важно, в какой форме она пришла:
комментарий в заявке;
письмо на почту;
«спасибо, вы нас спасли» в разговоре с IT‑менеджером.
Мы обязательно учитываем их при расчете ежемесячной премии. Размер доплаты согласуется с менеджером клиента и идёт из его внутреннего бюджета — по сути, бизнес голосует рублём за конкретного специалиста и его работу.
Отдельная история — про проактивных инженеров. В отделе системных администраторов есть много случаев, когда сотрудники за счёт насмотренности и опыта замечают то, чего базовый мониторинг не увидит:
устаревшая прошивка на центральном шлюзе;
небезопасный VPN‑протокол;
конфигурация, которая «еще работает», но уже тянет систему к деградации.
Формально это не инцидент и не SLA‑событие. Но специалист поднимает вопрос, предлагает решение, доносит риск до клиента. Такая вовлеченность не остается «просто молодец»: мы фиксируем эти случаи, обсуждаем их в команде и отдельно отмечаем при премировании. Это как раз тот случай, когда XLA — не про «быстро потушили пожар», а про то, что пожар не случился и пользователи даже не заметили угрозу.
По сути, KPI инженера в этой парадигме звучит не как «закрой тикет за N минут», а как «сделай так, чтобы пользователь остался доволен и вернулся к работе без лишних сложностей». Именно поэтому мы опираемся не только на технические метрики, но и на оценки пользователей и их живые реакции.
История из практики: как региональный банк научился видеть скорость глазами сотрудников
Поделимся историей одного регионального банка, которая иллюстрирует применение подхода. По данным мониторинга все системы работали штатно. Мониторинг доступности — зеленый, SLA соблюден, система доступна. Но сотрудники жаловались, что системы работают медленно. Стояла задача решить эту проблему.
Шаг 1. Собрали обратную связь — и обнаружили правду
ИТ-команда поехала в несколько офисов и просто посмотрела как работают менеджеры.
Картина оказалась печальной:
При заполнении карточки клиента — каждый переход от экрана к экрану 10-15 секунд ожидания. Менеджер сидит, смотрит на экран, клиент напротив тоже ждет.
Проверка кредитной истории — минуты. Чтобы занять паузу, менеджер начинает диалог с клиентом, чтобы занять время.
Распечатка договора … Это можно продолжать вечно.
Умножьте на 10-15 клиентов в день — получается 20-30 минут на каждого сотрудника. А теперь умножьте на 2000 сотрудников — масштаб потерь становится колоссальным.
Плюс психологический момент — медленная работа напрягает как сотрудника, так и клиента. В итоге у клиента складывается впечатление, что «в этом банке все медленно и неудобно».
Шаг 2. Оцифровали проблему через APDEX
Банк решил внедрить методику APDEX (Application Performance Index) — способ измерить производительность системы с точки зрения пользовательского опыта.
Как работает APDEX:
Определяются пороговые значения для каждого действия: удовлетворительное время (T) и приемлемое время (4T).
Если действие выполняется быстрее T — пользователь доволен.
Если от T до 4T — терпимо, но уже напрягает.
Если дольше 4T — пользователь откровенно недоволен.
Шаг 3. Установили метки на действия в информационных системах
Следующий шаг — встроили в систему автоматический сбор данных. На каждое ключевое действие в CRM и банковской системе поставили метки времени:
Начало операции
Конец операции
Фиксация задержек на каждом этапе
Данные стали стекаться в единый дашборд. И тут началось самое интересное.
Шаг 4. Научились видеть деградацию до того, как она стала проблемой
Через месяц наблюдений обнаружили паттерн: по понедельникам утром (с 9:00 до 11:00) скорость работы падала в 1,5-2 раза. Формально система работала, мониторинг не показывал критических проблем. Но по метрикам APDEX было видно: пользовательский опыт в эти часы проваливался в красную зону.
Начали разбираться. Выяснилось, что в понедельник утром запускались автоматические синхронизации данных между всеми точками и головным офисом. Нагрузка на базу данных возрастала многократно, и пользовательские запросы обрабатывались значительно медленнее.
Решением стал перенос синхронизации на воскресенье вечером и ночь с понедельника на вторник. Результат: скорость работы в понедельник утром выросла, APDEX вернулся в зеленую зону.
По результатам работ средний APDEX вырос, время обслуживания сократилось. Пользователи перестали жаловаться на медленную работу систем,а индекс удовлетворенности сотрудников (по внутренним опросам) вырос. Проще говоря, менеджеры перестали тратить по полчаса в день на «смотреть на крутящийся кружочек» и смогли вернуться к нормальной работе с клиентами..
Ещё один пример: как «вал заявок на смену пароля» превратили в метрику
Другой показательный случай был у крупного клиента с распределенной инфраструктурой: часть сотрудников работала в офисе, часть — на площадках их заказчиков, часть — на удаленке. Многие машины были не в домене, все заходили на общую терминальную ферму, по сути, как с тонких клиентов.
Раз в месяц, в строго определенный день, на первую линию обрушивался вал обращений «смена пароля». Мы уже могли по календарю сказать: «послезавтра прилетит двадцать–тридцать заявок только по этому поводу». Формально ничего страшного: каждая заявка закрывается, SLA по времени реакции выполняется. Но для пользователей это выглядело как «каждый месяц мы внезапно перестаем работать, звоним в поддержку и полдня меняем пароли».
Здесь XLA‑логика как раз и сработала. Мы принесли эти данные менеджеру клиента в виде простой картины:
– сколько заявок по паролям прилетает в один день;
– сколько времени уходит у первой линии на обработку каждой;
– сколько рабочего времени теряют пользователи, пока пытаются «пробиться» в систему.
Вместо того чтобы дальше героически закрывать по 20–30 обращений раз в месяц, мы предложили изменить сам процесс:
– сдвинули срок истечения паролей пользователям, чтобы в один день пароли не обнулялись всем разом;
– добавили заблаговременные уведомления пользователям о скорой смене пароля.
– добавили возможность самостоятельной смены пароля удаленно без участия специалистов техподдержки (опция доступна там, где нет возражений от ИБ клиента и логика самостоятельной смены не противоречит внутренним регламентам компании.)
В результате пик «боли» разма��ался по времени, объем заявок в один день заметно упал, а для пользователей эта история перестала быть ежемесячным стрессом. Формально SLA можно было бы оставить тем же, но XLA‑подход позволил увидеть реальный опыт людей и убрать системный источник раздражения.
Заключение: SLA и XLA без практики — просто слова
В 2026 году успех ИТ-директора измеряется не количеством закрытых заявок в срок, а количеством продуктивных часов компании. SLA по‑прежнему нужен как фундамент — без него всё просто развалится. Но если останавливаться только на нём, вы будете бесконечно подкрашивать дашборды, не понимая, как живётся людям внутри этих зелёных графиков.
XLA для меня — не модный термин и не попытка продать услуги подороже. Это признание простого факта, что цифры сама по себе ничего не дают. Можно поставить инженеру KPI «получать только пятерки», но без разбора каждой сложной оценки мы будем работать не на качество, а на отчет. Да, разбирать одну «тройку» по часу впятером — дорого и местами неприятно. Но без этого XLA превращается в ещё одну метрику, за которую всех ругают, а не в инструмент улучшения опыта.
Скрытый текст
Как найти надежного ИТ-партнера, который уже живет по этим принципам? Выбор подрядчика — это не просто сравнение цен. Это выбор союзника, который разделит ответственность за результат. Мы подготовили чек-лист с рекомендациями по выбору ИТ-аутсорсера, чтобы вы могли избежать ошибок на старте.
📌 Забрать рекомендации по выбору подрядчика в нашем Telegram-канале. Без заполнения форм, ПД и других сложностей.
А как у вас?
Меряете ли вы «счастье» сотрудников или ограничиваетесь аптаймом и SLA?
За что вас чаще всего ругают пользователи, когда в отчетах «всё работает»?
Что для вас в XLA выглядит как реальная польза, а что как маркетинг?
Поделитесь опытом в комментариях!
