The dashboard says 96% SLA attainment. Customer satisfaction is 3.1 out of 5 and trending down. The disconnect is the SLA — it pauses too aggressively, starts too late, and stops on a state change that does not match the customer’s experience of “resolved.” Configuring SLAs that mean what users think they mean is the difference between a metric that drives behavior and a metric that hides reality.
Start and Stop Conditions
An SLA without clear start and stop conditions is a guess. Use state fields and not timestamps to anchor conditions — a state == 6 (Resolved) transition is unambiguous and auditable; “updated_at after X” is fragile and changes meaning with every related-record update. The condition builder on contract_sla should reference the workflow state explicitly. Avoid scripted conditions where declarative ones suffice; they hide the logic from the operations team.
SLA pattern for incident resolution:
start: state in (1 New, 2 In Progress)
pause: state in (3 On Hold, 4 Awaiting Customer)
stop: state in (6 Resolved, 7 Closed)
reset: state goes back from Resolved to In Progress (rework)Schedules Matter
A 24x5 schedule versus 24x7 affects every SLA. Assign the right schedule to the right SLA — operations teams that work follow-the-sun need 24x7, business-hours-only teams need their regional 8x5 or 12x5. Regional schedules handle timezone-based support teams properly; a single global schedule applied to a follow-the-sun team produces nonsense breach times.
Pause Conditions
Waiting on the customer? Pause the clock. The most common SLA bug is forgetting to pause during customer-wait states; without pause, the SLA measures the customer’s response time, not the team’s. Define pause conditions explicitly and audit them quarterly. The pause should resume automatically when the customer responds — usually a state transition triggered by the customer’s reply, not a manual update by the agent.
// Business rule: auto-resume SLA on customer reply
if (current.state == 4 && // awaiting customer
current.comments.changes() &&
current.sys_updated_by == current.opened_by.user_name) {
current.state = 2; // back to in progress
current.update();
}Breach Notifications
Notify the owner before breach, not after. A notification at 50% consumed sets the expectation; a notification at 80% consumed lets the team act; a notification at 110% is a post-mortem trigger. Configure escalation tiers with increasing urgency — owner at 50%, manager at 75%, director at 90%, paging at breach. Breach with no prior notification is an operational gap, not just a data point.
Reporting SLA Performance
SLA attainment belongs in the weekly service review. Report by team, by priority, by assignment group, and by category. A 99% attainment org-wide can hide a 60% attainment in one team handling the highest-priority work. Performance Analytics on top of task_sla produces the trend; raw reports against task_sla produce the snapshot. Both are useful and serve different audiences.
Common Failure Modes
SLA reset on rework not configured — when a resolved incident is reopened because the fix did not stick, the SLA should restart for the rework period; otherwise the second resolution is “instant.” Pause conditions that match too broadly — pausing whenever the priority is touched produces trivially perfect SLA numbers and silent customer dissatisfaction. SLA defined on the parent task only with no roll-up from child tasks — a multi-team request can complete the parent while child tasks linger.
What Changed in 2026
Service Operations Workspace (Washington DC and later) shows SLA gauges in the contextual sidebar with breach-time-remaining and pause indicators. The visualization makes pause-state mistakes more visible — agents notice when an SLA they expected to be running is actually paused. Older Service Portal layouts hid this state behind clicks.
Cost Considerations
Aggressive notifications at 50%, 75%, and 90% consumed create email volume that can overwhelm support teams. Tier the notification channels — early warnings as workspace badges or chat messages, near-breach as email, breach as paging. Email-only escalation produces an inbox of warnings nobody reads.
Implementation Sequence
Define one SLA cleanly end-to-end with explicit start, pause, stop, and notification policy. Validate against historical data — apply the SLA retroactively to last quarter’s tickets and check whether the attainment number matches what the team believes. Adjust the conditions until the math reflects reality. Then add the next SLA. Configuring 20 SLAs from scratch in a single sprint produces 20 SLAs that nobody trusts.
What to do this week: pick the SLA your operations team complains about most and walk through one breached ticket end to end; the gap between “what the SLA says happened” and “what actually happened” is the configuration finding.
