On the last Friday of every month, a support ops manager at a mid-market SaaS company opens a spreadsheet. She exports 200 closed tickets from the previous four weeks. She opens each one in Zendesk. She checks the priority field, the type, the category, the resolution notes, the contact attempt count. She corrects the ones that are wrong. She notes the agents whose field completion rates are lowest. She reruns the SLA and category reports against the corrected data. Then she sends the revised numbers to her VP.
This takes her about three and a half hours.
She has been doing this every month for fourteen months.
Nobody told her to. There is no internal policy requiring it. She does it because she knows that without it, the reports her leadership sees are wrong — and she's the person who will be held accountable when the numbers don't match reality.
This is the manual ticket QA tax. It's common enough to have a pattern, expensive enough to matter, and almost never named explicitly — because teams that are paying it have normalised it as just part of how support ops works.
It isn't. It's a workaround for a gap in how helpdesks enforce data quality at point of entry.
What the manual QA process actually catches
The ops manager running this process is correcting four categories of field error, in roughly this order of frequency:
Priority miscoding. Agents mark tickets Normal when the context suggests Urgent or High. This is partly a productivity behaviour — marking everything Normal reduces the scrutiny that comes with Urgent tickets — and partly a calibration issue where agents genuinely aren't sure which priority level applies. Either way, the ticket closes with the wrong priority attached, and every metric that flows from priority — SLA compliance, breach rate by tier, escalation frequency — is calculated from inaccurate data.
Blank resolution fields. Agents close tickets without filling in resolution type, root cause, or fix applied. In isolation, one blank field is noise. At scale across a team of 15 agents over four weeks, it means a significant portion of closed tickets have no resolution record — which makes trend analysis and category-level reporting unreliable.
Type misclassification. Questions filed as Incidents. Problems filed as Tasks. The downstream effect is that type-segmented reports — incident volume over time, problem recurrence rates — count the wrong tickets in the wrong buckets. This matters particularly for teams tracking product stability or common failure modes.
Missing contact attempt counts. For teams measuring resolution efficiency, contact attempts per ticket is a key signal. Agents who don't log follow-up attempts make multi-touch resolutions look like single-touch ones. The customer effort metric, where tracked, is understated.
None of these errors are dramatic. Each one individually is a minor data quality issue. Collectively, across a team, over months, they corrupt the reporting layer that ops managers use to make decisions and that leadership uses to evaluate support performance.
Why the platform doesn't catch it
This is the part that's worth sitting with.
Zendesk, Freshdesk, Help Scout — none of them enforce field completion at ticket close by default. The default configuration allows an agent to close any ticket in two clicks: click the status dropdown, click Solved. No field completion required. No validation prompt. No warning that priority is blank or resolution type is empty.
You can configure mandatory fields in Zendesk — it's a setting that exists. But most Zendesk instances are set up by teams who underestimate data quality as a problem until they've been burned by it. The mandatory field configuration happens reactively, after the ops manager has already spent months running manual QA sessions to compensate for the gap.
And even when mandatory fields are configured, they apply at close. They don't flag tickets that have been open for 10 days with a blank priority field, or tickets assigned to an agent who has a consistent pattern of misclassifying type. The enforcement is point-in-time and reactive — it stops bad data from being submitted at close, but it doesn't surface data quality issues in the open queue, where they could still be corrected before they affect a decision.
The cost, more precisely
Three and a half hours per month for one ops manager is the low end of the range.
Teams with more agents, more ticket volume, or more complex category taxonomies run longer sessions. Teams that don't run manual QA at all don't pay the time cost — they pay it in report accuracy and in the credibility gap that opens when leadership starts noticing that the numbers don't add up.
There's a harder-to-quantify cost as well. The ops manager running the monthly QA session has built informal knowledge about which agents produce the most data quality errors, which ticket categories are most affected, and which time periods tend to have the worst field completion rates. That knowledge shapes her decisions. When she leaves the role, it leaves with her — and the next person inherits a process they have to relearn from scratch.
The informal knowledge that accumulates in the manual QA process is actually a signal about where the system is failing. It's just stored in someone's head instead of somewhere the team can act on it.
What it looks like when the audit runs instead
The shift an automated data quality audit makes is from reactive to proactive — and from manual to systematic.
Instead of sampling closed tickets after the fact and correcting them in a spreadsheet, the audit runs against your open ticket queue. Every ticket with a blank priority field, a mismatched type, an empty resolution category, or a missing contact attempt field is flagged before it closes. The ops manager sees the data quality problem while there's still time to address it.
The output also includes agent-level field completion rates — which agents have the highest blank-field rates, which categories are most affected. That's the informal knowledge the experienced ops manager carries in her head, made visible and persistent.
Running the monthly QA session is a reasonable adaptation to a platform gap. Automating the underlying detection is a better use of three and a half hours a month.