60% Auto-Resolved: Inside a Manufacturer's Support Missions

Support leaders have spent a decade reporting deflection — the percentage of tickets that never reached a human. It flatters the dashboard and tells you almost nothing. The number that matters is smaller, harder to fake, and quietly changing what a support organization is capable of: the share of problems that were actually solved.

A customer of a Fortune 500 electronics manufacturer opens a case at eleven at night because a rack of networking hardware in their data center is throwing a specific error code after a firmware update, and the maintenance window they have to fix it closes at two. In the old arrangement, that case would land in a queue, wait for a first-shift agent to triage it in the morning, bounce to a second-tier specialist who actually understood the firmware, and resolve sometime the following afternoon — long after the window had shut and the customer had spent the night improvising. In the arrangement the manufacturer runs now, the case is read the moment it arrives, matched against the known interaction between that firmware version and that hardware revision, checked against the customer's own configuration pulled from the account record, and answered with the exact rollback sequence and a link to the patched build — resolved, closed, and confirmed working, before anyone on the support team has woken up. That case is one of the sixty percent.

The phrase the manufacturer uses on its internal slides is "sixty percent auto-resolved," and it is worth being precise about what that number is and, more importantly, what it is not. It is not a deflection rate, which is the metric the industry has leaned on for years and which measures something closer to avoidance than to help — a customer who gave up, a ticket routed into a knowledge-base article and marked solved whether or not it solved anything, a chatbot that answered a different question than the one asked and counted the interaction as contained. Deflection is a measure of how many people you kept away from your support team. Resolution is a measure of how many people's problems went away. Those are not the same thing, and for most of the history of automated support the gap between them has been where customer trust quietly went to die.

Auto-resolved has to mean the problem is actually gone

The distinction turns on a question that is easy to state and was, until recently, very hard to satisfy: did the customer get the outcome they came for, or did they merely get an answer? A genuine resolution in a support context like this one is not the retrieval of a document that is topically related to the customer's problem. It is the completion of the work the customer would otherwise have had to do — reading the error, understanding what it means against this customer's specific hardware and firmware and history, determining the fix, verifying that the fix is safe for their configuration, walking them through it or executing it directly, and confirming that the thing they complained about has stopped happening. Every one of those steps involves judgment and context, which is exactly why the older generation of support automation could not do them and settled for deflection instead. A decision tree can route a ticket; it cannot reason about whether a rollback is safe on a board revision the customer never mentioned.

What makes the sixty percent real rather than cosmetic is that the manufacturer built its support on AI Missions rather than on a chatbot bolted to a help center. A Mission, in this architecture, is not a script with branches but a piece of work owned end to end by a Reasoning Core that can pull the threads together — reading the incoming case as Observations, drawing on Enterprise Knowledge that spans the product documentation, the firmware release notes, the history of every prior case, and the customer's own account and configuration, reaching into the manufacturer's systems through the Model Context Protocol to check entitlements, order status, and device telemetry, and then deciding what resolution actually requires. When the answer is a known-good fix that is safe for this customer's setup, the Mission executes it and closes the case. The resolution counts in the sixty percent because the problem is gone, not because the customer was successfully kept at arm's length, and the difference is auditable: the case is either recurring or it is not.

This is precisely the line that most of the market has failed to walk, and the failure is well documented. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, pointing among other things to what it calls "agent washing" — older chatbots and rule engines relabeled as autonomous without any change in what they can do underneath. In support specifically, agent washing has a very particular smell: a deflection number presented as a resolution number, an escalating volume of "contained" tickets that reopen within a week, a satisfaction score that sags every time the automation touches anything that was not a password reset. A support program that cannot tell the difference between deflecting a customer and resolving their problem will report an impressive figure and slowly erode the relationship the figure was supposed to protect. The sixty percent only means something because the manufacturer measured resolution and could prove it.

The other forty percent is where the design actually shows

It would be easy to read a headline like "sixty percent auto-resolved" as a story about the sixty percent, and to assume the remaining forty is simply the old world — the hard cases, thrown back over the wall to human agents who handle them the way they always did. That reading gets the architecture exactly backwards, and it misses the part that matters most to the people who work in support. The forty percent that a human resolves does not bypass the Mission. It runs through the same Mission, which does everything short of the final judgment before a person is ever involved, so that the human who picks up the case does not start from a blank ticket and a customer's frustrated first sentence. They start from a problem that has already been triaged, contextualized, and pre-investigated.

Consider what that means concretely for a case the Mission decides it should not close on its own — say, a hardware fault that appears to be a manufacturing defect and therefore touches warranty, replacement logistics, and a customer relationship that a human should own. By the time it reaches an agent, the Mission has already read the case and classified it, gathered the customer's configuration and entitlement status, pulled the device telemetry and the relevant history of similar faults on that product line, identified the likely root cause and noted the two pieces of evidence that point to it, and drafted the replacement path with the parts and lead times already checked against inventory. The Human-in-the-Loop is wired in at the decision, not at the data entry. The agent's job collapses from an hour of reconstruction to a few minutes of judgment: confirm the diagnosis, approve the replacement, decide how to handle the customer. The specialist agents did the coordination; the human did the thing only a human should do.

This is the reframing that a growing number of operators mean when they describe the shift toward an autonomous enterprise: not a system that handles the easy tickets and abandons the hard ones, but a single operating layer that carries every case as far as it can and then hands the human a decision rather than a chore. The escalated forty percent resolves faster than the old hundred percent used to, because the part of the work that consumed the agent's day — the reading, the routing, the pulling of context from six systems that do not share a memory, the reconstruction of what happened — was already done by the time they arrived. The manufacturer's second-tier specialists spend their hours on genuine engineering judgment and genuine customer relationships now, because the Mission absorbed everything underneath those two things. The people did not get replaced. They got promoted out of the coordination work that was never really their job.

Measure the resolution, not the deflection

What all of this changes is the number a support organization should put on the board, and the change is more consequential than it looks. For as long as support has been automated, the industry has optimized deflection because deflection was the thing the technology could deliver — keep the customer away from the team, and count the win. But deflection is a measure of a support organization's convenience, and resolution is a measure of its usefulness, and the two diverge exactly when a customer needs help most. A Mission-based support operation inverts the incentive, because it can only claim a resolution when the problem is actually gone, and it routes everything it cannot honestly resolve into the same pipeline that arrives at a human pre-investigated rather than pretending it was contained.

So the mental model worth carrying away is not "automation handles sixty percent of support." It is that a well-built support Mission erases the distinction between the automated cases and the human ones, because both run through the same reasoning, the same context, the same gathered evidence — and the only thing that differs is whether the final step was a fix the system could safely execute or a judgment it was right to hand to a person. The sixty percent is not the ceiling of what the automation touched. It is the floor of what it resolved outright, on top of a forty percent it carried nearly all the way. A manufacturer that understands this will stop bragging about how many customers it kept away from its support team and start measuring the only thing the customer ever cared about, which is whether, by the end of the interaction, the thing that was broken still was.