SLA Achievement vs Compliance in Zendesk

Some Zendesk teams say their SLA compliance is 95%. Others say their SLA achievement rate is 95%. Those numbers can describe the same account, or they can describe different levels of the same dataset and lead to very different conclusions.

That is why SLA reporting so often becomes a meeting about whose definition is right instead of which promise is failing. SLA achievement rate, SLA compliance, and compliance rate are closely related terms, but they do not always point at the same denominator, grain, or decision.

This guide shows how to choose the right Zendesk SLA number for the question you are answering, how to compare target-, policy-, and ticket-level outcomes without mixing them up, and how to avoid the common trap of reporting a healthy-looking rate that hides a failing customer promise.

What this report should answer

Are we reporting performance at target, policy, or ticket level?
Which number best reflects what customers actually experienced?
Is the gap between achievement and compliance telling us something useful, or just reflecting different denominators?
Which policies or target types are failing underneath the headline rate?
Are active SLA targets still at risk even if the settled rate looks healthy?

Keep this report beside the support metrics dashboard, Zendesk SLA Achievement by Policy Report, Zendesk SLA Report, and Support SLA Dashboard.

Start with the question, not the metric label

The cleanest way to choose the right number is to ask what decision the report needs to support.

If the question is “Which target type is failing?”

Use target-level achievement. This is the right layer for diagnosing whether first reply, next reply, or resolution targets are the weak point.

If the question is “Which SLA policy is least healthy?”

Use policy-level achievement. This compares different promises against one another at the policy instance level.

If the question is “How often did the customer experience a fully kept promise?”

Use ticket-level achievement or compliance. This is the strictest layer because the whole ticket only counts as successful when every relevant target was met.

Ticket level is usually the number leadership expects, even when the dashboard happens to default to something friendlier.

Zendesk gives you multiple “right” numbers

In the Support - SLAs dataset, the most useful measures are:

% Achieved SLA targets
% Achieved SLA policies
% Achieved SLA tickets
counts of achieved, breached, and active targets or policies

These are all valid. They simply answer different questions.

The confusion starts when a team labels all of them as “SLA compliance” in slides, dashboards, or weekly reviews. That makes small disagreements look like data-quality problems when they are usually reporting-design problems.

Target, policy, and ticket level do not behave the same

Level	What it counts	Best use
Target	Each individual SLA event	Diagnose which metric breaks
Policy	Each policy instance on a ticket	Compare policies and scopes
Ticket	The full customer ticket	Report customer-visible promise keeping

Why ticket level is harsher:

A ticket with three achieved targets and one breached target is a breached ticket
The target-level rate can still look strong on that same ticket population

That gap is not an error. It is the difference between “most events went well” and “the customer’s full experience met the promise.”

How to build the comparison in Zendesk Explore

1. Use the Support - SLAs dataset

Open Reports > New report and choose Support > Support - SLAs.

Do not build this comparison from the Tickets dataset. The Tickets dataset is useful for broader context, but the native SLA verdicts, targets, and timing logic live in the SLAs dataset.

2. Put all three achievement levels in separate tiles

Create three KPI tiles or three simple charts:

% Achieved SLA targets
% Achieved SLA policies
% Achieved SLA tickets

Do not combine them into one unlabeled table. They need to stay visually separate or people will assume they are interchangeable.

3. Add raw volume next to each rate

Rates without counts create false urgency and false comfort.

Put these beside the percentages:

SLA targets
SLA policies
SLA tickets
achieved and breached counts

This immediately reveals whether a dramatic-looking miss is a tiny sample or a systemic failure.

4. Surface active risk separately

Achievement and compliance are usually settled-outcome metrics. Active targets still counting down are excluded from the headline percentages.

Add:

Breached active SLA targets
Unbreached active SLA targets

That protects the review from a very common failure mode: a healthy settled rate and a large pile of open tickets already heading toward trouble.

5. Isolate the reason the numbers diverge

If target-level achievement looks fine while ticket-level compliance drops, cut the report by SLA metric.

This usually reveals one of three patterns:

first replies are on time, but follow-ups drift
updates are late even though final resolution looks acceptable
one target type inside a policy breaks enough tickets to drag the strict rate down

That is the moment the comparison becomes useful rather than semantic.

Compliance and achievement are closest at ticket level

In many real-world conversations, teams use “compliance” to mean the strict customer-facing number: did the ticket comply with the SLA or not?

That is why ticket-level achievement is often the cleanest operational proxy for SLA compliance in Zendesk. It maps best to the experience of a customer whose ticket either satisfied every relevant promise or did not.

If you want to use the word “compliance” in dashboards, label it explicitly:

Ticket-level SLA compliance
Policy-level SLA achievement
Target-level SLA achievement

The label matters more than the jargon.

When alternate SLA metrics matter

Most of the time, native SLA target status is the right source of truth. But there is a real edge case Zendesk documents: schedule changes or target-status inconsistencies can make duration-based truth and native status disagree.

If you suspect that happened:

compare native achievement with duration-based alternate metrics
document which one you are using
treat it as a data-integrity exception, not the default methodology

This should be rare. If alternate logic becomes your normal reporting method, the reporting stack is already hard to trust.

How to interpret the patterns

Target-level achievement is healthy, ticket-level compliance is weak

Your tickets are failing at least one target often enough to damage the full experience. Look at multi-touch conversations, update targets, and slow follow-up ownership.

Policy-level achievement is weak, but the global rate is fine

One promise is failing behind overall volume. This is the reason to keep policy-level reporting in the dashboard at all.

Compliance looks worse after a schedule or SLA rule change

Do not assume the team got slower overnight. Check whether the promise changed, whether policies were reordered, or whether business-hours logic changed.

All settled rates look strong, but active breaches are rising

The review is backward-looking. The next miss is already forming in the live queue, and the dashboard needs a risk tile, not just a historical score.

Common mistakes

Calling every SLA percentage “compliance.” This is the root of most confusion.
Mixing target-, policy-, and ticket-level rates in one chart. That destroys interpretability.
Ignoring active targets. Settled success can hide live exposure.
Reading a rate without its volume. Tiny samples create noisy stories.
Explaining divergence as bad data before checking the denominator. Most gaps are expected.
Using the Tickets dataset as the main SLA source. It does not hold the native SLA verdicts you need.

What to do when the numbers disagree

Name the layer each number is using.
Decide which layer matches the decision you need to make.
Add raw volumes and active-risk counts beside the rate.
Cut by SLA metric, policy, or priority to find the hidden failure.
Standardize dashboard labels so the same confusion does not repeat next week.

Where this report fits in your dashboard

FAQ

Is SLA achievement the same as SLA compliance?
Not always. Teams often use the words interchangeably, but in practice they may refer to different denominators or reporting layers. Label the layer explicitly.

Which number should leadership see?
Usually ticket-level SLA compliance or ticket-level achievement, because it best reflects whether the customer experienced a fully kept promise.

Why is ticket-level performance lower than target-level performance?
Because a ticket only succeeds when every relevant target succeeds. One miss can fail the whole ticket while most individual targets still look healthy.

Should active SLA targets be included in the rate?
No. Keep them separate so you can see live risk without distorting the settled-outcome percentage.

Make your Zendesk SLA report say exactly which promise is failing - start free