Ticket deflection is one of those numbers that only seems to go up. Every chatbot, portal and knowledge base comes with a figure attached, and they tend to be impressive.
The trouble is what gets counted. Most deflection figures measure an absence: a chat that didn’t turn into a ticket, an article view that wasn’t followed by a call, a portal session that ended quietly. Each of those might be a problem solved. It might also be someone who gave up, asked a colleague instead, or decided to live with it.
If you’re going to report deflection, or pay for it, it’s worth being stricter.
A definition that holds up
We’d use this one:
A deflected ticket is a problem that would have become a ticket, was resolved without one, and is confirmed as resolved.
All three parts matter. “Would have become a ticket” rules out counting every article view. “Resolved without one” is the bit everyone already measures. “Confirmed as resolved” is the bit that usually gets skipped, and it’s the only part the employee cares about.
Five ways to check your number
1. Look for the problem coming back. If the same device has the same problem within two weeks, the first one wasn’t resolved. It was postponed. Recurrence is the simplest honest check there is.
2. Count the side doors. When the official route doesn’t work, people go round it: a walk-up to the IT bench, a Teams message to an engineer they know, a word with the office manager. None of it becomes a ticket, so all of it can look like deflection. Ask your engineers to note those requests for a fortnight. It tends to be an eye-opener.
3. Compare before and after, problem by problem. Pick one problem, say printing on a particular floor, and count its tickets for a month before and a month after. A general fall in ticket volume tells you very little. Holidays, an office move or a new joiner cohort can all move it.
4. Use a comparison group if you can. Switch the new approach on for some sites and not others for a few weeks, then compare. It’s the closest thing IT gets to a controlled test, and it settles a lot of arguments.
5. Ask. A one-question follow-up a day later, “Is this sorted?”, tells you more than any session count.
Watch the denominator
When a vendor quotes a deflection rate, ask what it’s a percentage of. All tickets? Tickets in categories they cover? Chat sessions? A 40% rate of chatbot conversations is a very different thing from 40% of the service desk’s workload.
The same goes for your own reports. Write down how you calculate it, and calculate it the same way every month.
The ones that never needed a person
The cleanest deflection is the problem that’s fixed on the device before the employee notices, or at least before they’ve opened a browser to complain. There’s nothing to deflect, because nobody was ever going to call. It’s also the easiest kind to check: the device either recorded the fault and then the fix, or it didn’t.
That’s how Nanoheal counts it. Autoheal fixes the fault on the device as the operating system reports it, and each run is logged with what it fixed. We wrote more about the difference between deflecting and resolving on the ticket deflection page, and about why portals struggle in Why Nobody Uses the Self-Service Portal.