Every AI help desk pitch leads with a deflection rate. Seventy percent, maybe more, the slide says the tool keeps most tickets off your queue. The rate can be real and your Level 1 queue can still be as deep as it was last quarter.
Deflecting a ticket and closing a ticket sound like the same win, and vendors are happy to let the two blur together. The difference is who ends up doing the work. Deflection means the user never filed a ticket, because a bot or an article sent them off to help themselves. Closing means a Level 1 issue got fixed, confirmed, and written down in your PSA. One of those takes work off your techs. The other mostly moves it somewhere you can’t see: onto the client’s staff, into a reopened ticket next week, onto a tech’s Teams DMs outside the queue. The deflection number stays high either way.
So judge a tool by the number that moves your queue: how many tickets it closed and documented, not how many it waved off. Our position is close, don’t deflect: automate the work first, put AI and people behind it, and count resolved Level 1 tickets, not deflected conversations.
Deflection vs closing: The short answer
Deflecting means steering the client’s end user to self-serve before a ticket exists. The user gets an article, a portal answer, or a chatbot reply, and no ticket gets created. Closing means the Level 1 issue was fixed, the fix was confirmed with the user, and your PSA records what was done.
Only closing a ticket reliably lightens the queue. That’s the core of ticket deflection vs resolution, and most vendor pitches lean on the overlap.
The two numbers also differ in how you can check them. A closed ticket leaves a record you can audit: who asked, what changed, who confirmed it.
A deflected ticket is an absence. The metric counts something that never reached your PSA, so you can’t open it and see whether the user’s problem went away or whether the user went somewhere else to get it fixed.
What does deflection look like at an MSP?
At an MSP, deflection is usually a knowledge base, a client portal, or a chatbot that answers a question with a link. Some of that earns its place; the tension comes with requests that need an action, not an article.
Self-service works well for questions that only need information:
- How do I set up my out-of-office reply?
- Is email down, or is it me?
- Where’s the VPN client download?
A good article ends those requests in a minute, and nobody misses the ticket.
Trouble starts when the request needs someone to do something in a system. A user locked out of Microsoft 365 doesn’t need an article about lockouts. They need someone to unlock the account, after confirming they are who they say they are. When a chatbot hands that user a how-to, they might follow steps they don’t have permission to run. They walk down the hall to the office manager who “knows computers.” Or they email your tech directly, outside the queue.
All three move the work onto your client’s staff, the people who pay you so they don’t have to do IT. None of those paths created a ticket, so the headline deflection rate never dips.
Self-service has a weak record even in general customer service. In a Gartner survey, only 14% of customer service and support issues were fully resolved in self-service. For issues customers called “very simple,” the figure was 36%.
Those figures come from a survey about customer service and support issues, and IT help desk requests weren’t the focus. Still, if self-service fully resolved barely a third of the issues customers called very simple, it’s a poor bet for an MFA re-enrollment on a new phone that needs an admin action.
What should “closed” mean for a Level 1 ticket?
A closed Level 1 ticket is all of these:
- Solved: The underlying problem is fixed. The password works, the user is in the group, the app opens.
- Verified: The user confirmed it works, or the system shows it plainly, as with a successful sign-in after a reset.
- Documented: The PSA records what was done, by whom, and when, in notes your techs can read six months from now.
Plenty of tickets reach a closed status without meeting all three, and most PSAs make that easy. A bot that marks its own conversation resolved has not closed anything. Neither has the “closed, presumed resolved” status an auto-close rule applies after three days without a reply. And a resolution field that reads “sent user KB article” describes a deflection that happened to get logged.
HDI put the incentive problem plainly in a 2026 SupportWorld article: “If agents are rewarded primarily for closing tickets, tickets will close. Whether the employee believes the problem was resolved can become secondary.” The same applies to bots, only faster.
So when we say close, we mean the strict version. The status change is the last step, and it comes after the fix, the confirmation, and the notes.
Why don’t deflection numbers and tech workload line up?
Deflection counts the tickets that didn’t appear. Your techs work the tickets that did. The work that slipped between the two still has to land somewhere.
The pattern repeats across the queue.
- A user tries the chatbot, gets an article that doesn’t fit, and gives up. That session counts as deflected. An hour later the same user calls, and now your tech starts from zero, with an annoyed caller who has already lost an hour. The dashboard shows one deflection plus one ticket for a single problem.
- Reopens follow the same path. A bot marks a lockout resolved because it sent reset instructions. The user can’t complete them, replies to the thread, and the ticket comes back to a human with less goodwill attached.
- Duplicates are the quieter version: the user abandons the portal, emails the help desk, and then pings a tech on Teams, so one problem creates two records and a deflection.
Most of these failures are silent. No alert fires when a user quits the portal and asks a coworker instead.
The cost shows up later, at the QBR, when the client’s operations lead mentions that “the new help bot” is something her team works around. The deflection rate in your slide deck won’t help you there. She was the one doing the resets.
HDI’s article asks the question every MSP should put to its own data: “How many start in self-service and eventually call the service desk anyway?” If your tools can’t answer that, the deflection number can’t tell you what changed for your techs.
Which Level 1 requests can be closed end to end?
The Level 1 requests worth closing end to end are the ones that need an action in a client’s systems, not an article:
- Password resets and account lockouts
- MFA resets and re-enrollment on a new device
- Group membership changes
- Application access requests
- The routine steps inside onboarding and offboarding: create the account, assign groups, disable sign-in, revoke sessions
Each of these maps to a defined action in an identity platform. Microsoft Entra ID, Okta, and Google Workspace expose password resets, MFA resets, group changes, and account provisioning to admins and through their APIs. That’s why these tickets can be closed without a tech touching them, provided something with the right permissions takes the action and logs it.
They also pile up. Fixify’s 2026 IT Help Desk Benchmark Report, drawn from more than 50,000 tickets across 30-plus organizations between January 2025 and February 2026, put identity and access work at about 16% of ticket volume. At an individual client it can run much higher, which is why password reset tickets eat the Level 1 queue at so many MSPs.
Closing these tickets also means verifying the requester first, and that step can’t be skipped. CISA’s Scattered Spider advisory describes attackers posing as employees and using social engineering to convince help desk staff to reset passwords and MFA tokens.
A chatbot that tells an end user how to reset MFA hasn’t verified anyone. A process that checks the end user against the client’s policy before acting has.
Every client also has its own rules. One wants sign-off from a named manager. Another wants a callback to the number on file. That kind of detail is why these tickets bounce off new techs and land on your senior people, and it’s why an article can’t stand in for a closed ticket.
How can you tell whether a tool deflects or closes?
Ask questions in the demo that make the vendor show where the work ends up. These six do most of the job:
- Does a ticket exist in the PSA? If the request never reaches ConnectWise, Halo, or Ninja, you can’t audit it, bill against it, or report it to the client.
- Who takes the action? Ask whether the tool changes the user’s account itself, hands steps to the user, or hands the ticket to your tech. Only the first one closes anything.
- How is the fix verified? Ask how the tool confirms the user is back in, and how it confirms the requester’s identity before acting.
- What gets logged? Ask to see a completed ticket with the notes, the actions taken, and the timestamps. If the notes need cleanup before a tech could read them, budget your techs’ time for that cleanup.
- What happens after hours? Ask who handles the 11 p.m. lockout and the request that falls outside the playbook, and whether a person is watching.
- How is “done” defined? Get the definition of a resolved ticket in writing. If an abandoned chat or an unanswered thread counts, the headline rate includes them.
Then ask for the count that matters: tickets closed and documented. A vendor that only reports deflection is telling you how much work it kept away from your techs. It isn’t telling you who did that work instead.
This choice is where your margin is decided. When you deflect requests, you keep work off your dashboard. When you close them, you cut the technician hours your team spends on L1. Ask each vendor which of the two it is selling you.
Where Fixify fits
Fixify is managed automation that works Level 1 tickets to close inside your PSA. Fixify builds, runs, maintains, and supervises the automation, so your team doesn’t operate a platform or maintain workflows.
Requests come in through your normal intake and land in ConnectWise PSA, HaloPSA, or NinjaOne PSA.
- For an agreed L1 scope, Fixify takes the action in the client’s systems under your brand and documents the outcome back to the ticket.
- Fixify-employed analysts approve automation plans before they run and handle the judgment calls, with 24/7 human supervision.
- Work outside the scope goes back to your team. Your L2 and L3 work stays with you.
Coverage begins with the highest-frequency, lowest-risk requests and broadens as client playbooks settle. Fixify bills on resolved tickets, so your spend moves with outcomes rather than headcount or device counts.
The speed difference shows up in resolution, not response. In Fixify’s 2026 IT Help Desk Benchmark Report (50,000+ tickets, 30+ organizations, January 2025 through February 2026), median resolution was 4.4 hours for AI-automated tickets versus 71 hours without automation. First-response times were identical.
Start with your own queue. Upload 90 days of ticket data to the free IT Help Desk Ticket Snapshot for a customized benchmarking report in 48 hours, with no credit card or commitment.
To see how Fixify would close your L1 tickets inside your PSA, book a demo and bring your queue and stack.
