SLA and business hours
Response and resolution targets that mean something, and the business hours without which they do not.
Policies
A policy sets a response target and a resolution target per priority, and says whether it is measured against business hours or around the clock. Four sensible defaults are already in your workspace.
| Priority | Response | Resolution |
|---|---|---|
| P1 — critical | 15 minutes | 4 hours |
| P2 — high | 30 minutes | 8 hours |
| P3 — normal | 4 hours | 24 hours |
| P4 — low | 8 hours | 72 hours |
Business hours come first
Set your working hours per weekday and your holidays before you tune any targets. A four-hour resolution target measured across a weekend is not a commitment.
Warnings and breaches
A sweep runs every five minutes. At 80% of a target it raises an sla.warning event; past the target it raises sla.breach. Both can drive an automation rule — escalate, notify a manager, raise the priority.
Pausing on the requester
A ticket set to pending-requester stops its resolution clock and starts it again when they reply. Leave this on. Without it you breach targets on tickets where you were waiting for somebody else, and a team that is measured on other people's reply speed soon stops asking clarifying questions at all.
Mapping policies to categories
A policy can be attached to a ticket category as well as to a priority, which is how you give password resets a tighter target than laptop procurement without adding priorities nobody can tell apart. Category wins where both apply, and the ticket panel names which policy was chosen.
Explaining a deadline
Every ticket has a panel that names the policy, the clock start, each paused interval and the resulting deadline. Use it before arguing with somebody about whether a breach was real — it usually ends the argument in one screen.