Help Center
DocsSLA Targets & Queues
Set response and resolution targets and route tickets to the right team
Open the gear affordance in the Service section nav to reach Service settings, then choose SLA policies or Queues. The two areas are gated separately, so ask for the right key rather than a blanket one.
- SLA policies: creating and editing a policy needs the SLA manage permission (
sla.manage). The SLA view permission (sla.view) opens the same page read-only, so a lead can check the targets without being able to move them. - Queues: creating, renaming, and setting members needs the ticket assign permission (
tickets.assign), not the SLA one. Anyone who can view tickets (tickets.view) still opens the Queues page and reads the queue list; the create and rename controls are simply absent for them.
Agents without the manage permissions still see SLA timers and queues on their tickets. They just cannot change the configuration.
An SLA target is a clock that measures how quickly you respond to and resolve a ticket.
A Service Level Agreement (SLA) policy sets time targets for support tickets. When a ticket matches a policy, Service stamps it with one or more target clocks. Each clock counts down toward a due time and surfaces as a countdown chip on the ticket and in the queue list.
Target Types
- First response: how long until an agent first replies to the customer.
- Next response: how long until the next reply after the customer responds again.
- Resolution: how long until the ticket is resolved.
Every SLA target advances through these states automatically:
- Pending: the clock is running and the target has not yet been hit or missed.
- At risk: the target is approaching its due time. The chip warns you before the deadline so you can act.
- Met: you responded or resolved in time. The clock stops.
- Breached: the due time passed without the target being met. The breach is recorded in the ticket history and surfaced on the SLA dashboard.
When a ticket is waiting on the customer, you do not want the resolution clock to keep running against you. SLA targets account for pause windows so time spent waiting on the customer does not count against your targets. Business-hours configuration on the policy lets a clock run only during your working hours.
A policy can apply to tickets based on their queue, priority, channel, or account tier, so an Urgent ticket from a top-tier account can get a much tighter first-response target than a Low ticket from a free-plan user. Escalation rules let a breach notify a lead or escalate the ticket.
When more than one could apply, the narrowest wins: a policy pinned to the ticket itself, then the default SLA policy set on the ticket’s queue, then the policy marked Default for the organization. Leave a queue on “Organization default” and its tickets follow the organization-wide policy.
A queue is a named bucket of tickets, for example “Billing,” “Tier 1,” or “VIP.” Queues appear in the queue rail on the left of the Inbox, each with a live open-ticket count, so agents can focus on the work that belongs to their team.
Create a queue
In Service Settings → Queues, create a queue and give it a clear name. Queues are organization-scoped and isolated to your tenant.
Add members
Add the agents who work that queue. Membership is what auto-assign draws from, and it tells Service who can pick up work from the queue.
Route tickets to it
Assign tickets to the queue manually, via inline triage, or automatically from an automation. Tickets can move between queues as they are triaged.
Queues can auto-assign each new ticket to the member with the fewest open tickets, skipping anyone at their per-member ticket cap, so work is shared evenly without a lead manually dispatching every ticket. Assignment is safe under concurrency: two tickets arriving at the same moment never both land on the same agent by accident.