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 for a priority, measured in your business hours. Five are already in your workspace — one per priority and a default — and you can change every number.
| Priority | Response | Resolution |
|---|---|---|
| P1 — critical | 30 minutes | 4 hours |
| P2 — high | 1 hour | 1 business day |
| P3 — medium | 4 hours | 3 business days |
| P4 — low | 8 hours | 5 business days |
| Default | 4 hours | 3 business days |
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 75% of a target it raises an sla.warning event; past the target it raises sla.breach. Both can drive an automation rule — escalate, notify admins or a named person, add a note.
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.
Reading a deadline
Every ticket has an SLA card with the first-response and resolution deadlines and whether each is running, paused, met or missed. Look there before arguing about whether a breach was real.