SLA policies
Setting first response and resolution targets per priority, and what happens when one is missed.
An SLA policy sets two clocks on a ticket: how long you have to send the first customer-facing reply, and how long you have to solve it. Policies live at Settings, SLA policies.
How a policy is chosen
A policy applies to one priority. When a ticket is created, the workspace's enabled policy for that ticket's priority is stamped onto it, and the two deadlines are written on the ticket.
If two enabled policies exist for the same priority, the oldest one wins. If there is no enabled policy for that priority, the ticket gets no deadlines at all and can never be overdue.
Creating one
Press New policy and fill in four things.
| Field | Notes |
|---|---|
| Name | Free text, unique in the workspace. |
| Applies to priority | One of urgent, high, normal, low. |
| First response (mins) | Minutes allowed before the first reply. Optional. |
| Resolution (mins) | Minutes allowed before the ticket is solved. Optional. |
Both targets are optional and you can set one without the other. A policy with a first-response target only will never make a ticket overdue for taking a long time to solve.
The toggle in the list enables and disables a policy. Only enabled policies are stamped onto new tickets. Disabling one does not change the deadlines already written on existing tickets.
When the clocks stop and restart
- The first reply stops the first-response clock. It is the first customer-facing reply that counts, not an internal note.
- Changing the priority of a live ticket restarts both clocks from that moment, using the policy for the new priority. Escalating a normal ticket to urgent gives it the urgent target rather than instantly breaching the old one.
- Reopening restarts both clocks and clears the first-response stamp, so the next reply counts as a first response again.
What a breach does
A background watcher checks for elapsed deadlines. When one has passed it does three things:
- flags the ticket as breached, and records whether it was the first-response or the resolution deadline,
- writes an SLA breach entry on the ticket's timeline,
- notifies the assignee. If the ticket has no assignee but does have a team, every current member of that team is notified instead.
A ticket is flagged once. A ticket already flagged is skipped on later passes, so one breach is one notification.
Nothing else happens. A breach does not change the ticket's status, its priority, or its assignment. It is a flag and a notification, and the work of recovering is yours.
Seeing breaches
In the Inbox, a breached ticket carries an Overdue flag beside its subject, and the Overdue chip and the Overdue counter both show how many there are. The chip filters the queue down to them.
A ticket whose first response is still due but not yet late shows a countdown instead, such as in 20m, which turns amber in the last few minutes.
Deleting a policy
Deleting is admin only. Tickets already carrying its deadlines keep them.
These are your internal targets
An SLA policy here is a target you set for your own team and a flag when you miss it. It is not a commitment made to anyone on your behalf, and nothing in the product tells a customer what it is.