Decomposition, Not Deflection
A new working paper on where automation belongs in Support, and where it doesn't.
Call it deflection rate, containment rate, AI resolution rate, automation coverage - pick your vendor’s preferred noun. If it goes up and to the right on a graph, leadership is pleased. Somewhere in the queue a human agent is looking at a conversation the dashboard already marked as a win, and knows better: the interaction may have ended, but the customer wasn’t helped. That’s a problem, and an unrecorded one at that.
I have a new working paper about exactly this, and about what happens when we take that problem seriously. It is called “Decomposition, Not Deflection: A Theory of the Automation Boundary in Customer Support”.
It has been deposited to SSRN and is currently in their verification queue, so it is not publicly available there yet. The moment it clears and goes live, I will post here with the link. Until then, here is what it argues.
Closure is not resolution, and the metric can’t tell them apart
When we’re talking about deflection rates, what we mean is the proportion of conversations that ended without a human getting involved. That typically means ‘closed’, and that would be fine if closure tracked ‘help’.
It does not, for a reason economists call Goodhart’s law: the moment you make a measure the target, it stops being a good measure.
A system built to close conversations will close them whether or not anything got fixed, and a fluent enough one will reproduce the surface features of a real resolution while doing it, down to the tidy sign-off that says the matter is settled.
So your deflection number can climb while the service it represents gets worse, with nothing in your reporting built to catch it.
“What percent can we automate?” is the wrong question
The way most automation solutions do their thing is by sorting whole conversations. Simple ones to the bot, complicated ones to a human. Tiering, triage, escalation thresholds, the whole machinery.
My Decomposition paper calls this the sorting frame, and the deflection metrics are its scoreboard. The question it quietly assumes (“what proportion of contacts can a system handle”) bakes in an error before you answer it, because it treats the whole conversation as a closed unit. It is not.
Automatability does not run along one dimension of difficulty with a cutoff you can set. It varies along three things at once:
Which of three kinds of work is in play: the informational lifting (getting the answer right and stating it clearly), the relational work (repairing the relationship when it frays), and the judgment work (knowing what the right thing to do here actually is)
How tractable the interaction is, meaning how far the real problem sits under the stated one and how much effort is needed to resolve it
The channel used, since a lean one like live chat carries less of the signals that more difficult work requires
So a single conversation contains parts that automate beautifully and parts that do not automate at all, at the same time.
You cannot put one automatability score on a whole conversation, because the conversation is the wrong unit to score. The right unit is the component inside it.
Three limits, and only one of them moves
The information-retrieval part of an interaction automates well and keeps improving as LLM models improve. That boundary genuinely moves goal posts over time, and the paper concedes it completely.
The relational part has a harder limit that doesn’t soften by throwing better models at it. When a customer reaches out for help, the thing that broke for them is only half of the problem. The other half is that they have been let down, and they want a sign that a real person grasped what happened to them specifically. A specific acknowledgement is that sign.
“I can see that you were charged twice for March, and this is the second time you’ve had to write in” proves that someone actually looked at the customer’s case.
The generic version does the reverse: “I understand your frustration” is the line everyone gets, so it reads as being processed rather than heard. On a bad day, that’s one more small insult stacked on the original problem.
A machine builds acknowledgment from patterns, so in the moments that most need real recognition it can only produce a smoother version of that generic line. It sounds caring, and at the same time it is not about this person asking to be seen.
The part with the deepest limit is where judgment is required. You build that ability by working the full range of the job for years, until you can tell when the policy answer is the wrong answer, when the stated request is hiding the real problem, and when the case in front of you is one that none of your scripts anticipated.
You can give a system every rule and pattern you have. Full access to your knowledge base, internal and external. What you cannot give it is that honed instinct. Problem is: cases that need it the most are exactly the ones where getting it wrong costs the customer (and the relationship to the brand/product/company) the most.
A rulebook works right up until the situation falls outside the rulebook, which is precisely when the customer needed a person.
Put the automation inside the interaction, not instead of it
Every hard conversation handled by a human runs on the same tank, and it is not a big one. You have a finite amount of focus and composure to spend, and a single interaction can drain it.
Every minute you spend hunting for the right answer, holding six tabs open, working out what the customer is actually asking, is focus you are not spending on the upset person on the other end. The informational work and the emotional work pull from the same reserve, and it drains as the conversation runs.
That would be manageable if the two failed separately, but they very much do not. Get the informational part wrong and it does not stay an informational problem. A wrong or half-right answer given to someone who is already annoyed becomes even angrier, and now you are doing two jobs at once: correcting the mistake and calming the person the mistake just created.
You are doing both from a tank the scramble already emptied. That is why a small slip early in a conversation can blow up the whole thing. The costs stack instead of adding up.
This is where the case for automation gets specific, and it is a case for putting the system inside the conversation, not in place of it. Let the system do the fetching: pull the account, surface the likely answer, draft the routine reply, so the person is not burning the tank on retrieval.
It does two things at once: it leaves more focus for the parts only a person can do, reading what the customer actually needs and making the call about what to do. And by getting the routine part right, it heads off the wrong answers that set off the pile-up in the first place.
Sorting does the exact opposite. Route whole conversations and the bot skims off every easy one, so what reaches your human agents are the hard cases and only the hard cases, back to back, with none of the simple tickets that used to space them out and let someone breathe. You have taken the most draining work in the queue and served it in an unbroken line.
Human-factors research has documented this for forty years. Bainbridge named it Ironies Of Automation in 1983, and it has recently been carried into work on generative AI.
The Ironies of Automation paper makes the argument that when you automate the routine parts of a job, leave the human the hard residual, strip out the routine practice that kept skill at the hard parts sharp, that results in a human operator more loaded and less prepared at exactly the moments that matter most.
The counterintuitive part is worth sitting with: the most successful automation, the kind that calls on the human most rarely, places the greatest demand on human skill.
Coverage and the criticality of the human rise together, not inversely. Which is why chasing a 100 percent automation rate is a category error. Pushing coverage toward totality does not approach full service. It maximizes the gap the ironies describe. More capable automation raises the stakes on human work.
‘Can‘ and ‘should’ are different questions
To quote Jurassic Park: we’ve spent so much time focusing on whether we can, that we didn’t stop to think if we should.
What can be automated and what should be are not the same question, and the first does not answer the second. A bot can close a password reset. That does not settle whether it should own every password reset with no human anywhere near it.
Here is why that matters, and it is not (just) sentimental: the judgment skill we need to correctly handle those cases that need them most gets built by working the whole range of the job, not just the hard end of it.
The easy tickets are where someone new learns the product, learns the systems, learns how customers actually phrase things, and learns the tells that a simple request is hiding a bigger one.
Strip all of that out and hand people nothing but the worst cases, and you have built a harder job that burns them out faster and that no one can learn their way into, because automation essentially pulled up the on-ramp. A team that only ever sees the nightmares cannot train a novice to handle them.
There is also a moral choice buried in all of this, and the technology does not make it for you. The same move (naming the skill this work takes and letting a system carry the routine part) can develop the people who do it or displace them, and at the start the two look the same.
Develop them, and the skill gets recognized: the job gets better, and the people who are good at it get paid for being good at it.
Displace them, and the bot quietly eats the easy tickets while the humans absorb more of the hard ones for the same money, with the savings landing on the company's side of the ledger.
Which version you build comes down to who runs the operation and what they built it for. The capability of the LLM has no vote.