Separate response from resolution

The most common SLA mistake is conflating first response time with resolution time. They're different promises with different drivers. Response is about staffing and triage; resolution is about complexity. Set and measure them separately.

Tier by priority, not by customer tantrum

Define priority objectively:

  • P1 (Critical): production down, no workaround. Respond in 15 min, resolve in 4 hours.
  • P2 (High): major feature broken, workaround exists. Respond in 1 hour, resolve in 1 business day.
  • P3 (Normal): standard question or minor bug. Respond in 4 hours, resolve in 3 business days.
  • P4 (Low): feature request, cosmetic. Respond in 1 business day.

Anchor priority to impact and urgency, not to who's shouting loudest.

Honor business hours and calendars

A 4-hour response SLA means nothing if the ticket lands at 11pm Friday. Define business hours per policy, and make sure your SLA clock pauses outside them — and during "pending customer" waits, which aren't your delay.

Build in headroom

Set targets you hit 95% of the time, not 50%. An SLA you breach half the time isn't a commitment, it's a wish. Pull your historical data: what's your current P50 and P90 response time? Set the SLA near P90, then improve.

Make breaches visible early

The point of an SLA isn't to assign blame after a miss — it's to prevent the miss. Surface "approaching breach" warnings to agents 30 minutes before the clock runs out, so someone can act.

Review quarterly

As the team grows and the product matures, tighten the targets. SLAs should ratchet down over time as you get faster — but only after the data says you can keep the new promise.