FAQ — Can I un-breach an SLA?

Short answer: no. Once a metric breaches, the historical record is permanent. There’s no admin override that resets the badge to Urgent or marks it Met retroactively.

This is intentional. SLAs are accountability instruments — they’re meant to capture what actually happened, not what was supposed to happen. Letting admins rewrite history would defeat the purpose: every breach would get explained away, and the data would stop being useful for retrospectives, target calibration, or contractual reporting.

What you can do

1. Respond fast to minimize the breach window

The breach is logged regardless of when you respond, but a 30-minute breach is meaningfully better than a 5-hour breach. The timer flips to count up once breached, and that count-up duration is recorded. Lowering it improves both customer experience and your post-mortem analysis.

2. Reassign or escalate

If the breach is happening because the original assignee is unavailable (out sick, in a long meeting, on PTO), reassign immediately to someone who can respond. The breach badge stays, but the actual response is faster, and the conversation’s audit trail shows the reassignment was the catalyst for resolution.

3. Update the SLA target if the breach was a mis-set policy

If you’re seeing breaches because the target was unrealistic — “we set First Reply Urgent at 30 minutes but the team is staffed for 4-hour responses” — fix the target. Future conversations get the new target. Past breaches stay logged but stop accumulating. See Track SLA compliance for the calibration rubric.

What about the conversation reopening?

A common follow-on question: “What if the conversation closes (Met) and then a customer replies — does that re-arm the SLA?”

Yes, but mostly. When a conversation moves from done back to active:

• Resolution Time and All Messages restart fresh — new countdown, full target window again
• First Reply Time is not re-armed if an agent has already replied. It stays Met.

So a reopen gives you a new chance on Resolution and All Messages, but a previously-Met First Reply stays Met. A previously-Breached First Reply stays Breached. There’s no scenario where a closed-and-reopened conversation walks back to a healthier state on the metric that originally breached.

What about wiping history for analytics?

There’s no built-in way to exclude a specific breach from analytics. If a breach was caused by something genuinely outside team control (a multi-day infrastructure outage that affected every conversation, say), the cleanest options are:

• Annotate, don’t erase. Pull the relevant conversations into a saved view tagged infrastructure-outage, and reference that view when reporting numbers. The headline numbers include the breach; your analysis explains it.
• Set the targets so this doesn’t happen again. If a policy can be breached by an event the team has no control over, the policy’s wrong. Look at scoping (exclude the affected channel during the outage window) or move to a less-catastrophic target structure.

What if a breach was wrong because the conversation shouldn’t have had this SLA in the first place?

That’s not an “un-breach” — that’s a misconfigured assignment. Trace why the wrong policy attached, fix the assignment matrix going forward, and accept the historical breach as data about your config (not your team’s performance). See Set up channel-specific SLAs.

See also

• Risk states reference — the one-way escalation rule
• Track SLA compliance in Analytics