The 8-Business-Hour Response SLA That Never Breaches
The 'P2 Response' SLA definition is configured with: start condition when the incident is created; pause condition when state is 'Awaiting User'; stop condition when the incident is assigned; schedule Monday-Friday 09:00-17:00; target 8 business hours; retroactive start enabled. Over 90 days the SLA report shows zero breaches. Customers disagree strongly. Sample record: INC0012345 was created Friday 16:00, set to Awaiting User Friday 16:30, returned to In Progress Monday 09:00, and assigned Monday 15:00. The service owner says the report is authoritative because 'the system calculates it.'
1. Compute the SLA elapsed time for INC0012345 and state whether it breached.
Read the worked answer
Only scheduled business time counts, and the pause window does not count at all.
- Friday 16:00-16:30 - running, 0.5 business hours.
- Friday 16:30 -> Monday 09:00 - paused, 0 hours (and most of it is outside the schedule anyway).
- Monday 09:00-15:00 - running, 6 hours.
- After Monday 15:00 the stop condition fires; nothing further counts.
Total elapsed = 6.5 business hours against a target of 8. No breach.
Note the wall-clock reality the customer experienced: Friday 16:00 to Monday 15:00 is roughly 71 hours. Both numbers are 'correct' - they answer different questions, which is the whole problem.
2. Why does the report show zero breaches while customers are unhappy? Identify at least two distinct causes.
Read the worked answer
The definition is measuring something narrower than the customer's expectation. Distinct causes:
- Business-hours schedule vs. wall clock. 8 business hours across a weekend is three calendar days. The customer waited 71 hours; the SLA registered 6.5. Any P2 that lands on a Friday afternoon gets a free weekend.
- Stop condition is 'assigned', not 'worked' or 'responded to'. Assignment is an administrative act. An incident can be assigned to a queue and sit untouched while the SLA stops the clock and reports success. This measures dispatch, not response.
- Pause condition on 'Awaiting User' is gameable. If that state is set (or auto-set) before the customer has actually been contacted, the clock pauses on the wrong party. A 30-minute pause here is small, but across 90 days it can suppress many breaches.
- Retroactive start is enabled - useful when records are created after the fact, but it silently changes elapsed time on backdated records, so anyone reconciling manually will disagree with the report.
Zero breaches over 90 days is not a good result; it is a signal that the definition is not measuring the commitment.
3. What changes would you make to the SLA definition and to how the team reads the report?
Read the worked answer
Fix the definition:
- Change the stop condition to something that represents actual response - first agent work note, first customer contact, or state moving to In Progress with a responder - not mere assignment.
- Decide deliberately between a business-hours schedule and a 24x7 calendar for P2. If the customer promise is wall-clock, the schedule must be calendar; if it stays business-hours, state that explicitly in the SLA and set the target accordingly.
- Tighten the target if 8 business hours is not what was sold. A target that cannot be breached is not a control.
- Constrain the 'Awaiting User' pause: require evidence of contact, and cap total pause time.
- Keep retroactive start only if backdated ingestion genuinely occurs, and document the effect.
Fix the reading:
- Report both business-hours elapsed and wall-clock elapsed side by side; the gap is the customer-experience metric.
- Add a pause-usage report and an assignment-without-work report as leading indicators.
- Verify applicability conditions so incidents from all channels (portal, integration, phone) actually attach an SLA record - a reporting gap can look identical to compliance.
- Re-baseline in 30 days and expect breaches to appear immediately; that is the definition starting to work, not a new failure.