Zendesk SLA Breach

Zendesk doesn't have one SLA clock per ticket. It has a clock per target, and each one breaches independently. A ticket can hit its first reply target comfortably and still breach the next reply target six hours later.

The targets available cover the shape of most agreements: first reply time, next reply time, periodic update, requester wait time, agent work time, and total resolution time. A policy attaches targets to conditions and priorities, so an urgent ticket gets a tighter number than a low one.

A breach means the clock for one of those targets passed its target without the qualifying event. Nothing stops. The ticket stays open, work continues, and the record of the miss stays attached to the ticket.

A notification that fires on breach is a record of failure. A notification that fires before it's a chance to prevent one.

The pattern that works is an automation checking tickets approaching their target, notifying the group rather than the individual assignee. Group notification matters, because the single most common reason a ticket breaches is that its assignee is off sick, on holiday or in a meeting. Telling only them guarantees silence.

Alongside that, build a view sorted by time remaining on the SLA and keep it on a wall or a second monitor. Views update continuously, which makes them better than notifications for the last hour before a target. Notifications interrupt. Views inform.

Resist the urge to alert at four thresholds. Two is plenty: one warning with enough time to act, and one on the breach itself for the record.

Nobody owned it. Unassigned tickets breach more than any other category. Route on creation so nothing waits in a pile with no name on it.

The assignee was away. Individual assignment plus an absence equals a breach. Assign to groups, or reassign automatically when someone is out.

The wrong clock. Calendar hours on a policy for a team that works nine to five produces breaches that never happened in reality.

Coverage gaps. If tickets arriving at 16:45 on Friday consistently breach, your target and your rota disagree. One of them has to move, and it is usually cheaper to move the target.

The same question answered twice. A customer writes in twice, the second ticket sits unassigned because someone is already handling the first, and it breaches quietly. The work got done and the metric records a failure. That one is worth checking for before you conclude your team is slow.