Your Monthly Ticket QA Review Is Already Too Late
An MSP owner I work with reviewed two weeks of automated quality flags on his service desk. Twenty-two tickets came back with real problems — missing resolution notes, time entries logged days after the work, a couple of exchanges where the tone was sharper than he’d want a client to read.
His reaction wasn’t frustration at his team. It was this: every single one of these was fixable at the moment it happened.
By the time they surfaced, the tickets were closed, the clients had moved on, and the technicians had no memory of the specifics. The findings were true and useless.
That’s ticket QA at most MSPs. Not wrong — just late.
Why monthly QA doesn’t change behaviour
Most MSPs that do quality review at all do it in one of three ways:
- A manager samples a handful of tickets before a monthly ops meeting
- A team lead reviews tickets when a client complains
- Nobody reviews anything and you find out at the QBR
All three share the same defect. The feedback arrives long after the behaviour, addressed to someone who no longer remembers doing it.
Behavioural change requires proximity. Tell a technician on Tuesday that Monday’s ticket closed without a usable resolution note, and he can go fix it, and he’ll remember the standard next time. Tell him on the 4th of next month, and you’ve given him a performance conversation instead of a correction.
There’s a second problem, subtler and worse: sampling teaches you nothing about your distribution. If you review 15 tickets out of 3,000, you don’t know whether the issues you found are systemic or anomalous. So you can’t tell whether you have a training problem, a process problem, or one technician having a rough month. Every conclusion you draw is a guess dressed as a finding.
What QA at close actually looks like
The alternative is to evaluate every ticket at the moment it closes and act within hours. In practice, that’s only feasible with automation — no human is reading 3,000 tickets a month — but the criteria are yours, not the machine’s.
Across the MSPs we work with, the criteria that keep coming up are remarkably consistent:
Resolution note quality. Is there a resolution note at all? Is it in the field the PSA actually treats as a resolution, rather than buried in an internal note? Is it customer-readable? Does it describe what fixed the problem, or just that the problem went away?
Time entry timeliness. One MSP holds a hard two-hour rule: work logged within two hours of being done, even on tickets that stay open for a week. They currently catch violations reactively through BI reports — days later, when the memory is gone.
Time entry proportionality. Does the logged time make sense for the complexity of the work? This is where the billing conversation lives. One partner told me flatly that “work done versus time billed” is his single highest-value QA output — not because he suspects his team, but because under-logging is endemic and invisible.
Tone and professionalism. Not policing personality. Catching the message written at 6pm on a Friday by someone who’d had a day.
Missing time entries entirely. Tickets closed with no time logged at all. At one MSP, someone spends part of every Monday manually hunting these down.
Aging and hot-list flags. Tickets past a threshold of hours or days that nobody has escalated.
None of that requires AI to define. It requires AI to apply at volume.
The design decision that determines whether this works
Here’s the thing I’d get right before anything else, because I’ve watched it decide the outcome.
Show the flags to the technician, not just the manager.
If quality findings flow into a manager’s dashboard and come back down through one-on-ones, you’ve built a surveillance system. Technicians will experience it as such, and you’ll spend your political capital defending the tool instead of improving the work.
If the technician sees their own flags in their own view, same day, most of them self-correct without anyone having a conversation about it. Nobody wants to be sloppy. Most people just don’t know, in the moment, that they were.
One MSP owner put it well: he wanted his techs to see their flagged tickets and fix them before he ever brought it up, so that one-on-ones could be about coaching rather than about a list of infractions.
That’s the whole difference between a quality program that works and one that gets quietly abandoned.
Cadence: daily digest beats real-time alerts
Real-time alerting sounds like the obvious choice. The MSPs we work with taught us otherwise.
The reason is obvious in hindsight: a stream of individual alerts is another interruption in a day already made of interruptions. What ops leaders actually want is a daily email digest — one message, everything flagged since yesterday, sorted so the ugly items are at the top.
Daily is fast enough to be actionable and slow enough to be readable. Weekly digests work for lower-volume desks. Real-time alerting should be reserved for things that genuinely can’t wait until tomorrow morning — an angry client, a breach risk — and nothing else.
One more practical note: if your dashboard filters by technician, your team leads probably won’t use it. They think in clients, not in people. Filtering by customer matched how one partner’s leads actually work, and usage went up immediately. Small detail, real difference.
This is the shape Mizo’s Quality Review Agent ships in: every ticket evaluated at close against your criteria — resolution notes, time entries, tone, billing — findings routed to the technician first, a daily digest sorted worst-first, and one-click dismissal so false positives become tuning signal instead of noise.
The honest caveats
I’d be selling you something if I stopped there. Three things you should go in expecting.
False positives are real. Automated quality review flags things that aren’t problems — a short resolution note on a genuinely trivial ticket, an unusual time entry with a good explanation. You need a one-click way to dismiss a finding, and someone needs to actually look at the dismissals, because a pattern of false positives is a tuning signal.
Your criteria will be wrong on the first pass. Every MSP we’ve onboarded has revised their QA criteria within the first month. Expect to.
QA surfaces problems it can’t solve. The most common early findings are missing resolution notes and time entry gaps. Automation tells you they exist. It doesn’t write the note, and it doesn’t make the technician log time. That part is still management.
Why this matters more than it used to
Two reasons.
The first is money. Under-logged time and missing entries are pure margin leakage, and they’re invisible in aggregate reporting because you can’t miss what was never recorded. For an MSP running average profitability, tightening this is one of the few levers that moves EBITDA without touching pricing or headcount. Service Leadership’s benchmarking puts average adjusted MSP EBITDA at roughly 11%, with best-in-class firms sustaining 19%+ — that gap is largely operational discipline, not strategy.
The second is that quality data is the input to everything else you want to automate. Resolution notes train resolution suggestions. Consistent classification trains routing. If you’re planning any kind of AI on your service desk, ticket QA isn’t a nice-to-have adjacent project — it’s the thing that determines whether the rest of it works.
Where to start
- Write down five quality criteria. Just five. Get your team leads to agree they’re fair.
- Apply them to every ticket at close, not to a sample at month end.
- Route findings to the technician first, the manager second.
- Daily digest, sorted worst-first.
- Review your false positive rate after 30 days and re-tune.
The goal isn’t a scorecard. It’s that the ticket closed last Tuesday is one your best technician would have been happy to put his name on.
From a former MSP operator. We built quality review into our platform because we’d been doing it badly with a spreadsheet for years.