SLA compliance: how to measure and control it
SLA (Service Level Agreement) compliance shows the share of requests/orders/incidents completed within agreed target thresholds: first response time, resolution/delivery time, service window, availability (uptime). It is a core metric of service reliability and discipline for support, logistics, and IT/operations teams.
What the Metric Measures
The share of events that meet all relevant SLA conditions by priority/Severity, channel, request type, and department or supplier. For a complete picture, it is worth looking at the individual components: First Response, Resolution, Delivery Window, Uptime.
Calculation
- SLA Compliance, % = Items within all SLA conditions / Items with an active SLA × 100
- First Response SLA, % = Tickets with FRT ≤ Target / All relevant tickets × 100
- Resolution SLA, % = Tickets with TTR ≤ Target / All relevant tickets × 100
- Delivery SLA, % = Deliveries within the window / All deliveries × 100
- Uptime, % = (Available time / Total time) × 100; Error Budget = 100% − SLO
- Breach Rate, % = SLA breaches / Items with an SLA × 100
Define the "clock": start/stop, business hours vs. calendar hours, time zones/holidays, Paused/Waiting for Customer statuses, and rules for partial shipments and handling of repeat requests.
Calculation example
The support SLA is a first reply within 1 hour and resolution within 8 hours. Of 1,000 tickets in a month, 970 got a first reply on time and 910 were resolved on time. SLA compliance is 97% for replies and 91% for resolution — the 95% resolution target was missed.
Data Sources
CRM/Helpdesk/ITSM (Zendesk, JSM, ServiceNow), monitoring/APM (uptime/alerts), OMS/WMS/TMS (delivery windows, POD), telephony/chat, SLA/SLO catalogs, and team and supplier work schedules.
Interpretation
- Compliance↑ — stable service; check that quality/repeat requests are not suffering
- Breach Rate↑ — capacity shortage, long queues, weak planning, or inaccurate ETAs/windows
- Beware of "gaming" the metric: fast responses without resolution, artificial transfers between queues
Useful Breakdowns
- Priority/Severity; channel (phone/chat/email/in-app); request/order type
- Team/agent/shift; region/time zone; supplier/carrier
- New vs. repeat; correlations with backlog age and queues
Dashboard Visualizations
- Trend of SLA Compliance and Breach Rate with target corridors
- Heatmap of breaches by hour/day, channel, priority, carrier
- Funnel "created → picked up → first response → resolved"
- FRT/TTR distributions, a map of queues and backlog age
- Uptime and Error Budget burn-down
How to Set Targets
Define SLAs by priority (e.g., P1: FRT ≤ 15 min 24×7, TTR ≤ 4 h; P2: FRT ≤ 1 h, TTR ≤ 1 day), windows/slots for delivery, and SLO uptime for platforms (e.g., 99.9%). Agree on the error budget, escalations, and backup scenarios.
Common Mistakes
- Mixing business hours and calendar hours; unclear "waiting for customer" pause rules
- Summing up channels with different SLAs without normalization
- Focusing only on first response instead of resolution/quality metrics (CSAT/FCR)
- No single reference list of priorities/Severity and work calendars
Questions for Discussion
- Where are 80% of breaches: channel, priority, shift, supplier?
- What is the impact of auto-assignment/bots/triage on FRT and TTR?
- Are delivery windows/working hours aligned with demand and resources?
- How will SLA compliance change after priorities and escalations are revised?