Plan requirement
| Subscription | Suite Growth or higher, Support Professional or higher |
| Access | Agent |
Why an SLA did what it did on this ticket. The app for settling arguments about a breach.
Use it
- Install the app.
- Open a ticket with an SLA.
- Read the timeline: when the clock started, paused and stopped.
The question it answers
"Why does this show as breached when we replied within the hour?" Usually because the clock started earlier than anybody thought, or a status change did not pause it.
Without the timeline that argument goes in circles.
What it typically reveals
- The clock did not pause when the ticket went to pending.
- The wrong policy applied, because a field was set after creation.
- The schedule was not what people assumed, so overnight counted.
- A trigger changed something that restarted the measurement.
Read it before changing the policy
Most reported SLA problems are the policy behaving exactly as configured. Adjusting it before understanding the timeline usually creates a second problem.
Check the schedule first
A policy in calendar hours on a team that works office hours breaches every weekend. That is the single most common cause, and it is visible immediately here.
Useful for agents, not only admins
An agent who can see why a ticket is at risk can act on it. Restricting this to admins means the person who could fix it has no information.
Use it on a sample
Read the timeline on five breached tickets a month. Patterns show up quickly, and they are almost always configuration rather than performance.
Comments
0 comments
Article is closed for comments.