Zendesk SLA policies agents actually hit share three traits: they measure the right metrics (first reply, next reply, resolution), they set targets by priority against business hours, and they're backed by views that surface at-risk tickets before the clock runs out. Miss any of the three and you get the familiar failure mode — leadership announces response-time guarantees, agents breach them daily, and everyone quietly agrees to stop looking at the dashboard.
SLAs fail as morale tools when they're set as aspirations. They work when they're set as honest commitments with an early-warning system. This guide covers both halves: setting targets that reflect reality, and building the visibility that keeps them green.
Which SLA metrics should you actually measure?
Start with three: first reply time, next reply time, and requester wait time (or full resolution time). Each one measures a different promise to the customer.
- First reply time — how long until a human (not an auto-acknowledgment) responds to a new ticket. This is the metric customers feel most, and the one leadership usually means when they say "response time."
- Next reply time — how long each subsequent customer message waits for an agent response. This is the metric that stops tickets going quiet after a strong first reply — a very common pattern.
- Requester wait time / resolution time — how long the customer spends waiting overall. Requester wait time pauses while the ticket is Pending (waiting on the customer), which makes it fairer to agents than raw resolution time; the customer's own delays don't count against your team.
Resist the urge to activate every metric on day one. Two or three well-chosen metrics that agents understand beat six that nobody can hold in their head.
Business hours or calendar hours?
Business hours — almost always. A calendar-hours SLA means a ticket arriving Friday at 6 p.m. with a 4-hour target is already breached before Monday's coffee, through no fault of anyone. That's how you train agents to ignore the SLA entirely.
The decision rule is simple: your SLA clock should only run when someone is scheduled to answer. If you staff 8 to 6 Central, measure in business hours against that schedule. If you genuinely run 24/7 coverage, calendar hours are honest. The one legitimate exception: an urgent-priority tier for critical issues can run on calendar hours if you actually have on-call coverage behind it — a calendar-hours promise without calendar-hours staffing is just a scheduled breach.
Set your schedule (and holidays) in Zendesk first, because SLA policies reference it. Multi-timezone teams can apply different schedules to different tickets — worth doing properly if you support customers across regions.
How do you set priority-based targets agents can hit?
Work backwards from your actual performance, not forwards from a wish. Pull your current median and 80th-percentile reply times from Zendesk Explore, then set initial targets slightly tighter than the 80th percentile — ambitious enough to matter, achievable enough to be taken seriously. Tighten quarterly as you improve.
Structure targets as a ladder by priority. A hypothetical shape (yours should come from your own data):
- Urgent — first reply within the hour, aggressive next-reply targets, all-hands visibility
- High — first reply within a few business hours
- Normal — first reply by end of next business day
- Low — a generous multi-day target that's still a real promise
Two rules make the ladder work. First, priority must be assigned consistently — by triggers based on customer tier, form answers, or channel, not by whoever feels alarmed that morning. Inconsistent priority makes every SLA number meaningless. Second, every ticket should match exactly one policy; Zendesk applies the first policy whose conditions match, so order your policies from most specific to most general.
How do you catch breaches before they happen?
Build views sorted by the SLA countdown, so the tickets closest to breaching float to the top of every agent's screen. Zendesk exposes "Next SLA breach" as a sortable column — a queue ordered by it becomes a self-prioritizing to-do list, and agents stop needing to guess what to work next.
Layer on early warnings:
- A "breaching soon" view filtered to tickets within an hour or two of their target — the team lead's homepage.
- An automation that escalates at-risk tickets — when a ticket crosses the warning threshold, notify the assignee, then the lead, then a Slack channel. (Time-based condition, so it's an automation, not a trigger.)
- A weekly breach review — fifteen minutes on which targets breached and why. Chronic breaches on one metric mean the target is wrong or the staffing is; either way, that's information, not failure.
This is the honest part: some breaches are diagnostic. An SLA program that never breaches is usually measuring targets too soft to mean anything.
How do you get agents to buy in?
Agents hit SLAs they helped set and can see; they game SLAs that feel imposed and punitive. Three practices make the difference:
- Set targets with the team, from the data. An agent who saw the percentile math trusts the number.
- Coach on patterns, not incidents. Using individual breaches as gotchas teaches agents to send hollow "just checking in!" replies that stop the clock without helping anyone. Reward genuine first-touch resolution instead.
- Fix the system when the system is the problem. If Tuesdays always breach, that's a staffing insight, not an agent failing.
Well-built SLAs are one of the highest-leverage pieces of a customer service ticketing setup — and one of the easiest to get subtly wrong. If yours breach more than they inform, we configure this for a living.
Frequently Asked Questions
What is a good first reply time SLA for support?
There's no universal number — a good first-reply target is set slightly tighter than your team's current 80th-percentile performance, measured in business hours, and tiered by priority. Urgent issues typically warrant a within-the-hour target; normal-priority tickets often carry a next-business-day target. Tighten gradually as your team improves.
Should Zendesk SLAs use business hours or calendar hours?
Use business hours unless you genuinely staff support around the clock. Calendar-hour SLAs breach over nights and weekends when nobody is scheduled to respond, which trains agents to ignore the SLA entirely. Reserve calendar hours for urgent tiers that have real on-call coverage behind them.
Why do my agents keep breaching SLA targets?
Chronic breaches usually mean one of three things: targets were set aspirationally instead of from performance data, priority is assigned inconsistently so the wrong tickets get tight clocks, or agents lack a view sorted by time-to-breach so at-risk tickets stay invisible until it's too late. All three are configuration fixes, not effort problems.