Zendesk SLA Achievement by Policy Report

Most support teams report one SLA number. That number is an average of every promise they made, weighted by how often each promise came up — which is exactly why it so often looks fine while a specific commitment is failing.

If you run separate policies for enterprise accounts, urgent incidents, and standard email, those are separate promises with separate targets and separate consequences. A 94% overall achievement rate can easily contain a 99% standard policy carrying 12,000 tickets and a 71% enterprise policy carrying 400. The number that matters contractually is the one you cannot see.

This guide builds the policy-level view in Zendesk Explore: which policies you are actually keeping, at which of the three achievement levels, and how to tell a genuine service failure from a reporting artifact.

What this report should answer

Which SLA policy has the lowest achievement rate, not just the most breaches?
Which target type within that policy is failing — first reply, next reply, or resolution?
How badly do we miss when we miss, and is that gap widening?
How much breach risk is still counting down right now?
Are misses concentrated in a group, priority, or hour we could staff differently?

For the underlying concepts see SLA achievement rate, SLA compliance, and SLA breach by priority. Keep this report beside the support metrics dashboard so achievement is read next to backlog and first reply time rather than in isolation.

Use the SLAs dataset, not the Tickets dataset

Build this on Support > Support - SLAs. The Tickets dataset holds status, priority, and assignee but not target status, target time, or completion time, so anything you assemble there is a reconstruction of an SLA rather than the SLA Zendesk actually evaluated.

Two things to know about the dataset before you trust a number from it:

It only appears if you have tickets with SLA policies applied. If you cannot see it, the policies are not attaching, which is itself the finding.
It includes SLA data from deleted tickets. Historical achievement can therefore differ slightly from a ticket-count report over the same window.

If you use group SLAs for internal handoffs, those live in a separate Support - Group SLAs dataset with parallel metric names. Do not expect the two to reconcile: a ticket can hold its customer-facing promise while every internal handoff inside it runs late.

Pick your achievement level deliberately

This is the decision that determines whether your report is honest. Explore offers achievement at three grains, and they answer different questions.

Level	Metric	Counts	Use it for
Target	% Achieved SLA targets	Each individual target event	Diagnosing which target type fails
Policy	% Achieved SLA policies	Each policy instance on a ticket	Comparing policies against each other
Ticket	% Achieved SLA tickets	The whole ticket, achieved only if every target was met	Reporting what customers experienced

Ticket level is always the lowest number, because a single missed first reply on a ticket with four targets marks the entire ticket breached. That strictness is the point. When leadership asks “how often do we keep our promise,” ticket level is the truthful answer; target level is the answer that flatters you.

The denominators matter too. Both % Achieved SLA targets and % Achieved SLA tickets divide by achieved plus breached only — active targets still counting down are excluded. Your reported rate therefore describes settled outcomes, not everything in flight. That is the correct default, but it means a report run mid-week understates exposure. Add Unbreached active SLA targets and Breached active SLA targets as separate tiles so open risk stays visible.

How to build the report in Zendesk Explore

1. Achievement by policy

In Explore, open Reports > New report, choose Support > Support - SLAs, and click Start report.
In Metrics, add % Achieved SLA tickets.
In Rows, add SLA policy name.
In Metrics, also add SLA tickets so every rate carries its volume next to it.
Sort ascending by achievement rate.

That last step is the one most teams skip. Sorting by breach count puts your highest-volume policy at the top every single time and hides the small policy that is failing most often. Sort by rate, read volume as context.

Before you interpret anything, apply a minimum volume floor — typically 30 settled targets. A policy with six tickets and four breaches reads as 33% achievement and means nothing.

2. Which target is failing inside that policy

Filter to the worst policy, then swap SLA policy name for SLA metric in Rows. Possible values are Agent Work Time, First Reply Time, Next Reply Time, Pausable Update Time, Periodic Update Time, Requester Wait Time, and Total Resolution Time.

This split is where the fix becomes obvious:

First Reply Time failing — a coverage or routing problem. Cross-check Zendesk First Reply Time by Group Report.
Next Reply Time failing — follow-up discipline, usually an ownership gap after the first touch. See Zendesk Next Reply Time Report.
Total Resolution Time failing while reply targets hold — the promise is unrealistic for the work, or tickets are stalling in a status nobody watches. See Zendesk Time in Status Report.
Periodic or Pausable Update Time failing — a process problem. These targets are met by communicating, not by resolving.

3. Measure the size of the miss, not just the count

Add SLA metric breach time (hrs) with a MED aggregator, still split by policy and metric. Breach time is the gap between the target time and actual fulfillment.

This separates two situations that a breach count treats identically: missing a four-hour target by nine minutes, and missing it by three days. The first is a tuning problem, the second is a broken commitment. Use the median — a handful of abandoned tickets will drag any average into fiction, the same reason median resolution time beats the mean.

Compare it against SLA metric target time (hrs) on the same rows. If median breach time approaches or exceeds the target itself, the policy is not being missed — it is being ignored.

4. Add live risk

Achievement is a rear-view metric. Add a second block using:

Breached active SLA targets — already breached, still open, still fixable today
Unbreached active SLA targets — in flight and not yet late

Breached active SLA targets is the most operationally valuable number in the whole dataset because every row in it is a recoverable customer situation. Route it to a view your team works from, not just a chart. For the wider approach see Zendesk SLA Risk by Group Report.

5. Explain the failure with one more cut

With the worst policy and target isolated, add a single explanatory attribute at a time:

Ticket priority — check whether the miss is concentrated in one tier (Zendesk SLA Breach by Priority Report)
Ticket group — coverage or skills
Time - SLA status update by hour of day — schedule gaps
Ticket organization name — contractual exposure on named accounts
Ticket channel or Ticket form — intake paths that arrive already behind

Stop at one attribute per view. Stacking three produces cells with four tickets each and a story you cannot defend.

Business hours are a policy property, not a report setting

Every SLA target carries its own operating-hours configuration, exposed as SLA target operation hours (Business Hours or Calendar Hours) and SLA target in business hours (true or false).

This matters more than it sounds. If some policies run on business hours and others on calendar hours, a blended achievement rate compares promises measured on different clocks — and the calendar-hours policies will look worse for reasons that have nothing to do with team performance. A weekend ticket under a calendar-hours resolution target burns through its budget while nobody is working.

Split by SLA target operation hours at least once before you draw conclusions about any policy. If the split explains the gap, the finding is a policy design decision, not a performance problem. See business hours vs calendar hours.

How to interpret the patterns

One policy fails while overall achievement holds

The expected case, and the reason this report exists. Check volume first: a low-volume, high-touch policy usually covers your most demanding customers, so it carries disproportionate commercial risk per breach. Overall rate will never surface it.

Achievement drops with no change in first reply time

Look for a policy or target change rather than a performance change. A tightened target, a new policy with a different scope, or a reordered policy list will move achievement immediately while the underlying metrics stay flat. Zendesk applies the first matching policy in order, so inserting a policy above an existing one silently re-scopes it.

High breach count but high achievement rate

Volume, not failure. A policy with 20,000 targets and 800 breaches sits at 96%. Those 800 still deserve attention, but the policy is not the one to fix first.

Achievement looks perfect on a new policy

Check for active targets. If most targets have not settled, the rate is computed from a small settled subset and will fall as the window matures. Wait a full cycle before reporting it.

Target-level achievement is healthy, ticket-level is not

Tickets are carrying multiple targets and failing at least one. This usually points at multi-touch conversations where the first reply lands on time and follow-ups drift. It is a genuine customer-experience gap that target-level reporting cannot express.

Common mistakes

Reporting a single blended achievement rate. It averages unrelated promises and hides the failing one by design.
Mixing achievement levels in one chart. Target, policy, and ticket rates are three different denominators; putting them side by side without labelling invites wrong conclusions.
Assuming active targets are achieved. They are excluded from the rate entirely. Track them separately or you will understate live risk.
Sorting by breach count. This ranks by volume and buries small failing policies every time.
Ignoring operating hours. Comparing a business-hours policy against a calendar-hours policy is not a like-for-like comparison.
Reading breach counts without breach time. A nine-minute miss and a three-day miss look identical until you add duration.
Building SLA reports from the Tickets dataset. You will reconstruct an approximation and then have to defend the discrepancy.
Forgetting group SLAs exist. Internal handoff misses are invisible in the customer-facing dataset.

What to do when a policy starts missing

Confirm the level. Re-check at ticket level so you know what customers experienced.
Identify the failing target type with the SLA metric split.
Measure the size of the miss with median breach time against target time.
Ask whether the target is achievable. If median breach time is a large fraction of the target, the promise may be the problem.
Check operating hours before blaming the team.
Find the concentration with one attribute — priority, group, hour, or organization.
Work the recoverable set from Breached active SLA targets today.
Re-measure after a full policy cycle, using the same level and the same volume floor.

Where this report fits in your dashboard

How to report SLA compliance in Zendesk — the starting point if you have no SLA reporting yet
Support SLA dashboard — what belongs on the dashboard around this report
Zendesk SLA Breach by Priority Report — the priority cut
Zendesk SLA Risk by Organization Report — contractual exposure by account
Zendesk Backlog Aging Report — where breach pressure builds before it lands
support metrics dashboard — the hub

FAQ

Which Explore dataset do I need for SLA achievement by policy? Support > Support - SLAs. Group SLA policies use the separate Support - Group SLAs dataset with parallel metric names.

Why is my ticket-level achievement lower than my target-level achievement? A ticket is only achieved when every target on it was met. One missed target on a four-target ticket marks the whole ticket breached, so ticket level is always equal to or lower than target level.

Are active SLA targets counted as achieved? No. Achievement percentages divide by achieved plus breached only. Report Unbreached active SLA targets and Breached active SLA targets separately to see live exposure.

Why did achievement change when we did not change how we work? Check whether a policy was added, reordered, or re-scoped. Zendesk applies the first matching policy, so a new policy above an existing one changes which tickets that policy covers.

Can I see how badly we missed, not just that we missed? Yes — use SLA metric breach time, which is the difference between target time and actual completion time. Report it as a median next to SLA metric target time.

Should I report on business hours or calendar hours? Neither globally. Operating hours are set per target, so split by SLA target operation hours and compare like with like.

See SLA achievement and live breach risk by policy - start free