Виконання SLA

Виконання SLA (Service Level Agreement) показує частку звернень/замовлень/інцидентів, виконаних у межах погоджених цільових порогів: час першої відповіді, час вирішення/доставки, вікно сервісу, доступність (uptime). Це базова метрика надійності та дисципліни сервісу для команд підтримки, логістики, IT/операцій.

Що вимірює показник

Частку подій, що відповідають усім релевантним умовам SLA за пріоритетом/Severity, каналом, типом запиту та підрозділом або постачальником. Для повноти варто дивитись окремі компоненти: First Response, Resolution, Delivery Window, Uptime.

Розрахунок

  • SLA Compliance, % = Об’єкти в межах усіх умов SLA / Об’єкти з чинним SLA × 100
  • First Response SLA, % = Тікети з FRT ≤ Ціль / Всі релевантні тікети × 100
  • Resolution SLA, % = Тікети з TTR ≤ Ціль / Всі релевантні тікети × 100
  • Delivery SLA, % = Доставки в межах вікна / Всі доставки × 100
  • Uptime, % = (Час доступності / Загальний час) × 100; Error Budget = 100% − SLO
  • Breach Rate, % = Порушення SLA / Об’єкти з SLA × 100

Зафіксуйте «годинник»: старт/стоп, бізнес-години vs календарні, таймзони/свята, статуси Paused/Waiting for Customer, правила часткових відвантажень та обробки повторних звернень.

Джерела даних

CRM/Helpdesk/ITSM (Zendesk, JSM, ServiceNow), моніторинг/APM (uptime/алерти), OMS/WMS/TMS (вікна доставки, POD), телефонія/чат, каталоги SLA/SLO та графіки роботи команд і постачальників.

Інтерпретація

  • Compliance↑ — стабільний сервіс; перевірте, чи не страждає якість/повторні звернення
  • Breach Rate↑ — дефіцит потужності, довгі черги, слабке планування або неточні ETA/вікна
  • Остерігайтесь «геймінгу» метрики: швидка відповідь без вирішення, штучні перекидання між чергами

Корисні розрізи

  • Пріоритет/Severity; канал (телефон/чат/email/in-app); тип звернення/замовлення
  • Команда/агент/зміна; регіон/таймзона; постачальник/перевізник
  • Нові vs повторні; кореляції з backlog age і чергами

Візуалізації на дашборді

  • Тренд SLA Compliance та Breach Rate із цільовими коридорами
  • Heatmap порушень за годиною/днем, каналом, пріоритетом, перевізником
  • Фанел «створено → взято в роботу → перша відповідь → вирішено»
  • Розподіли FRT/TTR, карта черг і віку беклогу
  • Uptime та Error Budget burn-down

Як ставити цілі

Визначте SLA по пріоритетах (напр., P1: FRT ≤ 15 хв 24×7, TTR ≤ 4 год; P2: FRT ≤ 1 год, TTR ≤ 1 день), для доставки — вікна/слоти, для платформ — SLO uptime (напр., 99.9%). Узгодьте error budget, ескалації та резервні сценарії.

Типові помилки

  • Мікс бізнес-годин і календарних; нечіткі правила паузи «waiting for customer»
  • Підсумовування каналів із різними SLA без нормалізації
  • Фокус лише на першій відповіді замість вирішення/якісних метрик (CSAT/FCR)
  • Відсутність єдиного довідника пріоритетів/Severity та робочих календарів

Запитання для обговорення

  • Де 80% порушень: канал, пріоритет, зміна, постачальник?
  • Який вплив автоприсвоєння/ботів/триажу на FRT і TTR?
  • Чи узгоджені вікна доставки/робочі години з попитом і ресурсами?
  • Як зміниться виконання SLA після перегляду пріоритетів і ескалацій?