Your Zendesk SLA dashboard says you're hitting 94% first-reply compliance. Your ops manager knows that number is wrong. She just can't prove it — because the same system producing the incorrect reports is the one she'd use to audit them.
Bad ticket data doesn't announce itself. It accumulates silently in the fields agents skip, misfile, or leave blank — and it surfaces months later as SLA reports that don't match reality, dashboards that mislead leadership, and manual correction sessions that eat hours every month.
Here is exactly which field failures cause which metrics to lie.
The fields that break SLA reporting
Zendesk SLA policies are built on ticket attributes — priority, type, group, tags. When those attributes are wrong or missing, the SLA policy either doesn't apply correctly, or applies the wrong targets entirely.
Priority field
This is the most common failure point. SLA breach calculations in Zendesk run against the priority assigned to the ticket. A ticket marked Normal when it should be Urgent gets Normal SLA targets — which are typically longer. If the ticket breaches the Normal target but would have breached the Urgent target much earlier, the report shows a breach at the wrong time, or in some configurations, no breach at all because Normal resolution time gives more room.
When agents under pressure mark everything Normal to keep their metrics clean — a well-documented behaviour — the SLA dashboard becomes a record of their workaround, not of actual support performance.
Type field
Zendesk distinguishes between Questions, Incidents, Problems, and Tasks. Some SLA policies are scoped to specific types. A ticket filed as Question when it's an Incident may miss the SLA policy designed for Incidents entirely — meaning no policy attaches, no breach is recorded, and the ticket ages without appearing in any SLA report.
Group routing
SLA policies in Zendesk are often configured at the group level. A ticket routed to the wrong group — or to a group with no SLA policy — starts no clock at all. The ticket counts toward your open volume. It doesn't count in SLA compliance. If it never gets rerouted, it can sit indefinitely without appearing as a breach.
Resolution notes and close fields
These don't affect SLA calculations directly, but they corrupt the data that feeds reporting. When agents close tickets without filling in resolution type, root cause, or contact attempt fields, the downstream reports — category breakdowns, resolution analysis, trend data — become unreliable. Ops managers then spend time manually validating what the report should have shown automatically.
Why agents skip the fields
This isn't a discipline problem. It's a system design problem.
Zendesk does not require field completion at ticket close unless you explicitly configure mandatory fields and enforce them with triggers. Most Zendesk instances don't. The default setup lets agents close a ticket in two clicks regardless of what's filled in.
The fastest path to clearing queue volume is always the path with the fewest steps. Agents under pressure learn the minimum viable close sequence. Fields that aren't mandatory become fields that are frequently empty.
The enforcement gap compounds over time. A team that's been operating for 18 months with non-mandatory fields has 18 months of incomplete data in its reports. The ops manager running a cohort analysis on resolution times is working with a dataset that has significant gaps she can't easily quantify.
What the manual fix looks like
Most support ops teams that have hit this problem end up in the same place: a monthly manual QA session.
The process typically runs like this. Export a sample of closed tickets — sometimes 50, sometimes 200, depending on team size. Open each one and check: is priority set correctly? Is type accurate? Are resolution notes filled in? Is the category right? Manually correct the misfilings. Then re-run the SLA report against the corrected data.
This takes between two and four hours a month for a team of 10–20 agents. It's done manually because there's no native Zendesk tooling that identifies and flags bad field data at scale.
The ops manager running this session knows which agents are most likely to have skipped fields. She spot-checks their tickets first. She's built an informal mental model of where the data quality problems are concentrated. None of that knowledge is captured anywhere — and when she moves on, it leaves with her.
The manual QA process and what it actually costs is worth examining in full.
The reporting blindspot nobody talks about
There is a version of this problem that's harder to see than individual field errors.
SLA compliance reports in Zendesk measure breach rate against the tickets that had an SLA policy applied. They do not measure the tickets that should have had an SLA policy applied but didn't — because priority was blank, because the group was wrong, or because the ticket type caused the policy to miss.
This means your compliance number is a ratio with a denominator that's too small. You're measuring breaches against the subset of tickets the system managed to track, not against the total volume that needed tracking. A 94% compliance rate calculated against 800 tickets looks very different from one calculated against 1,100 tickets — but Zendesk's native reporting doesn't surface the gap.
The way most ops teams find this is by manually comparing total closed ticket volume against tickets with SLA records. When those numbers diverge significantly, the difference represents tickets that fell outside the policy — and most of those fell outside it because of bad field data, not because of a deliberate exception.
What automated data quality scanning changes
The manual QA process is reactive. You run it after the reporting period, against data that's already been submitted to leadership. The errors have already made it into the record.
An automated scan runs against your open ticket queue in real time — flagging every ticket with a missing priority, an incorrect type, a blank category, or a missing contact attempt field before the ticket is closed. The ops manager sees the field quality problem while there's still time to correct it.
The output isn't a corrected report. It's a ranked list of tickets with data quality issues — which agents have the highest field error rates, which ticket categories are most affected, and which open tickets are at risk of closing with bad data attached.
That's a different intervention point. And it's one that compounds: catch the errors on open tickets this week, and next month's SLA report is cleaner without anyone running a manual correction session.