How to Set Up SLA Policies in Zendesk (Step by Step)
Setting up SLA policies in Zendesk looks like a five-minute job and turns into an afternoon — not because any single step is hard, but because the order of operations matters and a couple of non-obvious gotchas (a missing priority value, the wrong hours setting, a breach escalation that quietly can't be built the way you expect) can leave your SLAs silently doing nothing. This guide walks through the whole setup end to end: prerequisites, creating the policy, conditions and per-priority targets, ordering, surfacing the clock on tickets, escalating breaches the way Zendesk actually allows, and testing.
If you want the concepts first — what the seven metrics mean, how requester wait time differs from total resolution time, Group SLAs, plan details — read Zendesk SLAs explained first; this post is the hands-on setup. Every step below is verified against Zendesk's own documentation.
Before you start: two prerequisites
Check these two things before you open the admin, or you'll build a policy that doesn't behave.
1. You need the right plan. SLA policies are available on Suite Growth, Professional, Enterprise, and Enterprise Plus (and on Support Professional and Enterprise) — but not on Suite Team. If you're on Team, SLA tracking is a reason to step up a tier. (Group SLAs, for internal team-to-team handoffs, are Enterprise-only.) Plans and packaging change, so confirm against your own account.
2. You need a schedule if you want business-hours targets. Most teams want their SLA clock to pause overnight and on weekends rather than count around the clock. That only works if a business-hours schedule — your working days, hours, time zone, and holidays — exists first. Without one, "business hours" has nothing to pause against and you'll rack up phantom 3 a.m. and Sunday breaches. Set the schedule up before the SLA, then come back here.
One more conceptual prerequisite that bites everyone: every ticket the SLA should cover needs a value in the Priority field. Targets are set per priority, so a ticket left with no priority gets no SLA clock at all — more on fixing that in Step 3.
Step 1 — Open the SLA policies screen
In Zendesk, head to Admin Center → Objects and rules → Business rules → Service level agreements, then click Create policy. (If you don't see "Service level agreements" in that menu, you're almost certainly on a plan that doesn't include SLAs — see the prerequisite above.)
This screen lists any existing policies in priority order (top to bottom) and, on Enterprise, shows a separate Group SLAs tab. For now we're building a standard, customer-facing policy.
Step 2 — Name and describe the policy
Give the policy a clear name and description. This is purely for your future self and teammates, but it pays off the moment you have more than one policy. Name it for who or what it covers, not the times — Standard customers, Enterprise / VIP, Billing queue — because the targets inside may change but the segment usually won't. A one-line description ("First reply + resolution targets for all standard, non-VIP tickets") saves the next admin from opening the policy to figure out what it's for.
Step 3 — Set the conditions (which tickets it applies to)
Conditions decide which tickets this policy governs. Like any Zendesk business rule, you build them from ticket fields — and you have "meet all" (AND) and "meet any" (OR) condition blocks.
Common ways teams scope an SLA policy:
- By priority — e.g. nothing here, and let the targets per priority do the work (the most common setup for a single, account-wide policy).
- By group —
Group is Billing, so the billing team has its own commitments. - By organization or tag —
Organization is Acmeor tagvip, to give a premium segment tighter targets. - By brand — if you run multiple brands with different promises.
If you want one policy to cover all your tickets, you can leave conditions effectively open — but be deliberate, because of ordering (Step 5).
The non-negotiable rule to remember here: the system Priority field must have a value (Low, Normal, High, or Urgent) for the SLA to apply — this is true regardless of your conditions. So make sure something is setting priority on intake. The usual fix is a trigger that stamps a default priority (say, Normal) on new tickets, or consistent agent triage. If you skip this, your policy will quietly ignore every untriaged ticket. (For how priority and type work, see Zendesk ticket priority and type.)
Step 4 — Set the targets per priority
This is the heart of the policy. You pick the metrics you want to commit to, and for each one you enter a time target for every priority (Low, Normal, High, Urgent). Zendesk's seven metrics fall into three groups:
- Reply time: First reply time, Next reply time
- Update time: Periodic update, Pausable update
- Resolution time: Requester wait time, Agent work time, Total resolution time
You don't use all seven. Most teams start with First reply time (the single most important one — it sets the customer's expectation for the whole interaction) and one resolution metric. Pick the resolution metric that matches what you actually promise: Requester wait time (excludes Pending, i.e. time you're waiting on the customer), Agent work time (only New + Open), or Total resolution time (everything, including Pending — the strictest). The differences are explained in SLAs explained; choosing wrong here is the most common reason a "resolution SLA" feels unfair.
For each metric, enter a target per priority. A realistic starting table for a standard policy:
| Metric | Low | Normal | High | Urgent |
|---|---|---|---|---|
| First reply time | 8 hrs | 4 hrs | 1 hr | 15 min |
| Periodic update | — | 24 hrs | 8 hrs | 2 hrs |
| Total resolution time | 5 days | 3 days | 1 day | 8 hrs |
(Example only — set times your team can actually sustain. The minimum target Zendesk allows is 15 seconds.)
Business hours vs. calendar hours. For each priority/target, choose calendar hours (every minute counts, 24/7) or business hours (only time inside your schedule counts; the clock pauses when you're closed). A "4-hour first reply" means very different things under each — in calendar hours a ticket arriving at 11 p.m. is three hours into its clock by 2 a.m.; in business hours it doesn't start until you open. A common pattern: calendar hours for Urgent (you've promised 24/7 on the worst issues) and business hours for everything else. Remember business-hours targets only work if a schedule exists (the prerequisite).
Step 5 — Order your policies (first match wins)
Zendesk evaluates SLA policies top-down and applies the first one whose conditions match — a ticket gets exactly one policy. So order is not cosmetic. The rule of thumb Zendesk recommends: put your most restrictive / most specific policies at the top and your broadest catch-all at the bottom.
In practice that means a narrow Enterprise / VIP policy (tighter targets, specific conditions) must sit above a Standard customers catch-all. If the catch-all is on top and its conditions match everything, your VIP policy below it never fires. Drag to reorder on the SLA list screen.
Step 6 — Save
Click Save. The policy is live immediately and begins applying to newly created and updated tickets that match — it doesn't retroactively rewrite the history of already-closed tickets. From this moment, matching tickets carry their SLA targets as a live countdown.
Step 7 — Surface SLAs on tickets and build a breach workflow
A saved policy is only half the job. If agents can't see the clock and nobody is alerted when a target is at risk, the SLA is just a number in a report after the fact. Two moves make SLAs operational.
a) Build an at-risk view. This is the single most effective SLA habit. Open or create a view, choose Edit view, and under formatting Add column → SLA. Then set Order by → SLA, Ascending. The column shows the calendar time left before each ticket's next target breaches, and ascending order floats the most overdue (or closest-to-breaching) tickets to the top — so the team naturally works the riskiest ones first.
b) Escalate with an automation — not a trigger. Here's the gotcha that trips up most admins: you cannot build a trigger on SLA breach status. Triggers fire on ticket events, not on the SLA clock. Escalation is an automation job, because automations are time-based and can act on the conditions "Hours until next SLA breach" and "Hours since last SLA breach." For example:
- Hours until next SLA breach is (calendar) less than 1 → add tag
sla_at_risk, notify the team lead. - Hours since last SLA breach is (calendar) greater than 0 → raise priority or notify a manager.
Note Zendesk has no native "send a notification on breach" feature — the automation conditions above plus the at-risk view are how you build escalation yourself. Trying to do it with a trigger is a frustrating dead end; reach for an automation instead.
Step 8 — Test it
Don't trust an SLA you haven't watched run. Create (or update) a test ticket that matches the policy's conditions and make sure it has a priority set. Then confirm:
- The SLA badge / next-target countdown appears on the ticket and in your at-risk view.
- The target matches the priority you set (an Urgent test ticket should show your Urgent first-reply target, not the Normal one).
- Business vs. calendar hours behave as expected — if it's a business-hours target and you're currently closed, the clock should be paused.
- Post a public reply and confirm the first-reply clock stops (internal notes should not stop it).
- Let a target lapse (or shorten one temporarily) and confirm your escalation automation fires.
If the SLA doesn't show at all, 90% of the time it's a missing priority value; the other causes are the ticket not matching any policy's conditions, or matching a higher policy first (ordering).
Best practices
- Start with one or two policies. Only the first matching policy applies, so a long overlapping list is hard to reason about. Add policies only when a real segment (a brand, a VIP tier, a team) genuinely needs different commitments.
- Set targets you can actually hit. An aspirational "15-minute reply on everything" you breach 40% of the time is worse than an honest "1 hour" you meet. An SLA is a commitment, not a stretch goal — tie it to staffing reality.
- Use business hours unless you truly staff 24/7. Reserve calendar hours for the priorities you genuinely cover around the clock.
- Always set priority on intake. A default-priority trigger is the cheapest insurance against SLAs silently skipping tickets.
Common mistakes to avoid
- Forgetting the priority field. No priority, no SLA clock — the number-one reason a policy "isn't working."
- Business-hours targets with no schedule. The clock counts around the clock, and you breach overnight and on weekends through no fault of the team.
- Wrong policy order. A broad catch-all above a specific VIP policy means the VIP policy never fires.
- Trying to escalate breaches with a trigger. It can't be done — use an automation with the breach-hours conditions plus the at-risk view.
- Over-promising on resolution. Don't commit to Total resolution time if your workflow legitimately parks tickets in Pending for days; Requester wait time may reflect your real obligation more fairly.
Where AI fits — hitting first reply time
The target most teams struggle to meet is first reply time, and it's almost always a capacity problem: tickets pile up overnight or during spikes faster than agents can post that first response. That's exactly the gap an AI layer addresses — and it doesn't change anything you set up above.
Macha is an AI agent layer that runs on top of Zendesk — not a help desk and not a Zendesk replacement, so your SLA policies, schedules, and escalations stay exactly as configured. Connected to your tickets and knowledge, it can post an accurate first reply the moment a ticket arrives — resolving routine ones outright and drafting a head start on the rest — so the first-reply clock is satisfied even at 2 a.m. or mid-spike, while anything it can't handle stays a normal ticket for a human with full context. Being straight: it's another vendor to maintain and only as good as the knowledge you connect. On cost, Macha bills per AI action (any automated step — draft, tag, route, look up data, or resolve — costing 0.5–9 credits depending on the model you choose), not per closed ticket, because most of what helps an SLA is work done along the way, not a single "resolution." If first reply time is your weak number, that's the lever — more in how to automate Zendesk with AI, or try it free, 7-day free trial, no credit card required.
Frequently asked questions
How do I set up an SLA in Zendesk? Go to Admin Center → Objects and rules → Business rules → Service level agreements and click Create policy. Name it, set conditions for which tickets it applies to, enter time targets for each metric per priority (Low, Normal, High, Urgent), choose business or calendar hours, order it correctly among your other policies (first match wins), and save. Make sure tickets have a priority value or the SLA won't apply.
Which Zendesk plan do I need for SLAs? SLA policies are available on Suite Growth, Professional, Enterprise, and Enterprise Plus (and on Support Professional and Enterprise) — but not on Suite Team. Group SLAs, which track internal team handoffs, are Enterprise-only. Confirm against your own account, as packaging changes.
Why isn't my SLA policy applying to tickets? The most common cause is a missing priority value — SLA targets are set per priority, so a ticket with no priority gets no SLA clock. Other causes: the ticket doesn't match the policy's conditions, or it matches a different policy listed above this one (only the first matching policy applies).
How do I escalate a ticket when its SLA is about to breach? Use an automation, not a trigger — you can't build a trigger on SLA breach status. Time-based automations can act on the conditions "Hours until next SLA breach" and "Hours since last SLA breach" to add a tag, raise priority, or notify a lead. Pair this with a view that has an SLA column ordered ascending so at-risk tickets surface first.
What's the difference between business hours and calendar hours when setting targets? Calendar hours count every minute around the clock, including nights and weekends. Business hours count only the time inside your configured schedule, so the clock pauses when you're closed. Business-hours targets only work if a schedule exists. Most teams use business hours for normal priorities and calendar hours only for issues they cover 24/7.
Do SLAs apply to existing tickets? A new or edited policy applies to tickets created or updated after you save it — it begins tracking matching tickets going forward rather than retroactively rewriting already-closed history.
The bottom line
Setting up SLAs in Zendesk is a clear sequence: confirm your plan and (if you want business hours) a schedule, create the policy, scope it with conditions, set per-priority targets in the right hours, order it so the most specific policy wins, save, then make it operational with an at-risk view and a breach-escalation automation — and test before you trust it. Two things cause almost every "my SLA isn't working" moment: a ticket with no priority, and trying to escalate breaches with a trigger instead of an automation. Get those right and the riskiest tickets will always rise to the top before they slip. From here, deepen the concepts in SLAs explained, and shore up the foundations in business hours and schedules, ticket priority and type, and views.
SLA setup steps verified against Zendesk's official documentation, June 2026. Zendesk updates its product and packaging periodically — confirm specifics in your own account before relying on them.
