IT support SLAs: how to avoid vanity metrics
Measuring response time is good. Measuring impact is better. Here’s a simple B2B framework.
An SLA that only measures response time can hide real issues. Example: a ticket resolved in 2h but blocking production for 48h is not a success.
Clear priorities: P1 (production down, data loss), P2 (major user impact), P3 (degraded functionality), P4 (improvement). Each level has its response window and escalation path.
Service window: define business hours (e.g., 09:00-18:00) and on-call coverage (24/7 for P1 only). Outside the window, automatic escalation to on-call.
Escalation: if no response within the window, escalate to the next level (technician → expert → manager). Escalation delay must be documented and auditable.
Reporting: measure actual resolution time (not just response time), escalation rate, and business impact (downtime, revenue loss). A simple dashboard with these 3 metrics is enough.
Key point: an SLA must be readable, aligned with business risk, and auditable. Avoid vanity metrics (number of closed tickets) that don’t reflect service quality.