The most useful number in an AI support business case is not the deflection rate. It is the share of your tickets that can be resolved without anyone looking at a specific machine.
Almost nobody measures that one. It is, however, the number that decides whether an AI support program is a necessity or an expensive way to agree with a board deck.
The forecasts are about issue classes, not about your queue
The headline projection in circulation is Gartner’s: agentic AI resolving around 80% of common IT service issues without human involvement by 2029. It gets quoted in vendor decks with the word “common” doing enormous, silent work.
The same firm published a less comfortable forecast a year earlier — that more than 40% of agentic AI projects would be cancelled by the end of 2027, over cost, unclear value, and weak risk controls.
Gartner also estimated that of the thousands of vendors advertising agentic capability, only around 130 were building anything that merited the label, and gave the practice a name: agent washing.
Worth noting that this second forecast was published in mid-2025 and has been recirculating since without its date, which makes it look like fresh evidence of a market correction rather than an early warning that has been running for a year.
Both forecasts can be right, because they describe different things. One describes what a mature system can do to a category of issue. The other describes what happens when organizations buy the category description instead of measuring their own queue.
Two kinds of ticket, and only one of them automates cleanly
Sort a month of tickets into two piles.
The first pile is resolvable through information and entitlement: password resets, group membership, licence assignment, a documented fix for a known error code, a policy question, provisioning a new starter. These are transactions against systems that expose APIs.
They automate well, and they always have — agentic AI is simply the first automation layer that can handle them without someone writing a rule for every variation.
The second pile is resolvable only by acting on the state of one particular machine. A driver that half-installed. A profile that got corrupted after an interrupted update. An application that works for forty people and fails for one, on one laptop, with one dock attached.
These are not information problems. They require somebody to observe a specific system, form a hypothesis, act, and watch what happens.
The ratio between those piles varies enormously. A 2,000-seat organization with standardised, centrally managed hardware might find the first pile is 70% of contacts. A support operation covering mixed client environments, unmanaged devices, or specialised workstations might find it is 25%.
Peripheral-dependent desks skew that way hardest: a post room running mailroom management software lives or dies on a barcode scanner, a label printer and a handheld that talk to one workstation, and none of those fail in ways a knowledge base article closes.
The industry forecast is an average across a market that contains both. It is not a prediction about anyone’s queue in particular.
The residue is denser than the queue it came from
Here is the part that rarely makes the business case. Automation does not shrink the second pile. It removes the first one from around it.
That has three consequences worth planning for.
The remaining work gets harder on average, because the easy tickets that used to pad the day are gone. Handle time per human-touched ticket goes up, and it should — that is the system working. It also looks like a productivity regression on any dashboard that still measures tickets per technician.
The training ground disappears. Tier-one queues were where junior technicians learned the estate before they had to diagnose anything hard. Remove them and the pipeline into competent tier-two work has to be built deliberately, or it does not exist.
And the escalation path becomes load-bearing. Every ticket that reaches a human now arrives with the easy explanations already eliminated and, usually, a user who has already spent time with a bot. The gap between “escalated” and “someone is actually looking at the machine” turns into the visible part of the experience.
There is a measurement trap sitting on top of all this. Deflection counts a contact the AI closed. It does not distinguish a solved problem from a user who gave up and re-contacted through another channel two hours later — a distinction several 2026 support-benchmark analyses have pushed hard, recommending that teams net out repeat contacts within 48 hours before calling anything deflected. An operation can report high containment while the hard queue quietly lengthens behind it.
What “AI-powered” means on a remote support product page today?
It is worth being specific about the current state of the art in this particular category, because it is narrower than the discourse suggests.
Across remote support and remote access products, the AI features shipping today are mostly assistive: generated session summaries so technicians do not write up notes by hand, suggested replies and tone rewriting in session chat, real-time chat translation for cross-language support, and diagnostic surfacing that puts device telemetry in front of the technician faster. These are genuine time savings, and the summary features in particular remove a task everyone hates.
None of them is autonomous resolution. A system that writes the ticket note is not a system that fixed the laptop.
Gartner’s own framing is a decent buying filter here: use an assistant for retrieval, automation for routine workflows, and an agent only where a decision actually has to be made.
Most support tasks marketed as agentic need one of the first two. Asking a vendor which of the three they are selling, and what happens when their system is wrong, separates the products quickly.
So: whim, or necessity?
Necessity, for organizations where the information-and-entitlement pile is genuinely large, the knowledge base is accurate, and there is an owner accountable for measured resolution rather than deflection. In that shape, the case does not need a forecast to justify it; the arithmetic works on current volumes.
Whim, when it arrives as a headcount story before anyone has measured the ticket mix. That version has a predictable failure pattern: containment looks excellent in month two, satisfaction on complex issues drops in month four, and the program gets quietly rescoped in month nine. That is most of what sits inside the cancelled-project statistic.
The honest position is that this is not really a question about AI. It is a question about how much of your support work is information, and how much is physical state — and the second number is the one that sets your ceiling.
What gets more important, not less?
Which brings the conversation back to something unglamorous.
If AI handles the transactional tier, then the work that reaches a human is concentrated in the cases where somebody has to see and control a specific machine, often with a frustrated user who has already been through an automated attempt. The value of the support operation increasingly rests on how fast and how reliably that session starts and holds together.
That sets a plain requirement. The escalation path has to reach a session quickly, without asking a non-technical user to install and configure something while they are already annoyed, and it has to stay stable through the longer, more hands-on troubleshooting that the residue consists of.
HelpWire is one example of a tool built around that pattern rather than around the automation layer above it. A technician sends a connection link; the user opens it, downloads the small client app and runs it, and the session starts from there, with no account to create and no credentials to enter.
It is a download, not a deployment, which is the difference that matters when the handoff happens mid-frustration and the person on the other end has already spent twenty minutes with a bot.
Once the session is running, it is designed to avoid software-imposed interruptions such as timeouts and intrusive prompts, which matters when the remaining work is exactly the kind that takes forty minutes rather than four.
It does not resolve tickets on its own, and nothing about it is an AI story. It is the layer the AI story escalates into.
Three numbers to measure before you buy anything
If a stakeholder wants an answer on AI in support, produce these rather than a vendor comparison.
First, the share of last quarter’s tickets that were resolved without anyone accessing a device. That is the realistic ceiling on autonomous resolution in your environment, before any product is chosen.
Second, true resolution on whatever automation you already run — contacts closed by the system where the same user did not come back within 48 hours. If nobody can produce that figure, the deflection number in the current dashboard is decorative.
Third, median time from escalation to a working remote session. That is the number that gets worse when the easy tickets leave and nobody notices, and it is the one users actually experience.
An organization that knows those three numbers can have a short, unemotional conversation about AI in support. An organization that does not will end up having a long one about vendors.
