Deflection, and Why It Is the Wrong Objective

Deflection rate is the share of contacts handled without reaching a human agent, and it is the metric the whole category is sold on. It is also the metric most likely to reward the wrong outcome.

The problem is what it cannot distinguish. A deflected contact could be a customer whose question was answered correctly and who is satisfied. It could equally be a customer who gave up, who found the answer elsewhere, who is now angry, or who will contact you again tomorrow through a different channel where the contact is counted separately.

All four look identical to the metric, because the metric measures absence: the person did not reach an agent. Absence is the one thing shared by success and abandonment.

The economics make this worse rather than better. Deflection has an obvious cost saving attached, which makes it easy to justify and easy to report upward. Resolution has a diffuse benefit that shows up in retention and word of mouth, on a lag, contaminated by everything else. So the measurable thing and the valuable thing point in different directions, and the measurable one wins by default.

The consequence is a specific and common failure: a support operation reports rising deflection and falling cost while customer satisfaction erodes, and the two numbers are read as unrelated because they sit in different reports.

What to measure instead is the subject of a later step. First it is worth being precise about what actually gets deflected well.

Support contacts sort by two properties, and the combination determines whether automation helps.

The first is whether the answer exists in your documentation. Informational questions about policy, process, product behaviour or account state have an answer sitting somewhere retrievable. Diagnostic questions, where the problem must be worked out, do not.

The second is emotional stakes. A customer asking about opening hours is in a different state from one whose payment failed before a deadline, and the same correct answer lands differently.

Low stakes with a documented answer is where automation belongs, and it is a large share of volume in most operations.

High stakes with a documented answer needs care: the answer is available and the delivery matters, so the tone and the escape route to a human are what determine the outcome.

Low stakes without a documented answer is where the system should say so and route, rather than improvising.

And high stakes without a documented answer is where a human belongs immediately, and any attempt to handle it automatically makes the situation worse.

The common error is treating volume as the sort key rather than these two, which puts automation exactly where it damages most.

Support is the function where hallucination has the most direct commercial consequence, and the reason is specific: a support answer is a statement by your company to a customer, and the customer will act on it.

What that means concretely. A model inventing a refund policy has created a commitment your organisation may be held to. One inventing a technical procedure has instructed a customer to do something that may break their configuration. One inventing a delivery date has made a promise. In several jurisdictions statements made by a company's support channel bind the company, and the fact that a model produced them is not a defence a customer needs to care about.

So the grounding requirement from the hallucinations cursus is not a quality preference here. Every factual claim in a support answer must come from a retrieved source, and where the corpus does not contain the answer, the system must say so rather than construct one.

Three design consequences.

Abstention must be a first-class behaviour, not an error state. A system that always answers is a system that will invent policy.

Citation should be internal at minimum, so an answer can be traced to the document that justified it when a customer disputes it.

And the corpus is the product. A support assistant is exactly as good as the documentation behind it, which means most of the work in a good deployment is documentation work, and organisations consistently budget for the model instead.

Every automated support system will encounter contacts it cannot handle. The quality of that transition determines the customer's overall experience more than the quality of the automation does.

What a bad handoff looks like, and it is the common case. The customer explains the problem to the bot. The bot fails. The customer is placed in a queue. An agent arrives with no context and asks the customer to explain the problem again. The customer, already frustrated by the failed automation, now repeats themselves to a person who appears not to have been listening.

That sequence is worse than having no automation at all, because it added effort and delay before delivering the same outcome. And it is the sequence most deployments produce by default, because the automation and the agent tooling are different systems.

What a good handoff requires. The full conversation transferred, so the agent sees what was tried. A summary the agent can read in seconds rather than a transcript they must scan. What the system already established, so it is not re-asked. And the customer told what is happening rather than left in silence.

And the escape route must be visible throughout. A customer who cannot find how to reach a human will not conclude the system is sufficient; they will conclude you are avoiding them, which is a specific and durable kind of damage.

The design principle: optimise the failure path first. It is the one that determines whether the deployment is experienced as help or obstruction.

Replacing deflection with metrics that distinguish resolution from abandonment.

Resolution rate, defined properly. The share of contacts where the customer's problem was actually solved, which requires knowing the outcome rather than the disposition. The practical proxy is the absence of a follow-up contact from the same customer about the same issue within a defined window, which is imperfect and far better than deflection.

Repeat contact rate. A customer contacting again within days about the same thing is the clearest available signal that the first contact did not resolve. This is the single most useful number in this lesson and it is frequently not tracked because it requires linking contacts.

Escalation rate and, more importantly, escalation quality. What proportion reach a human, and when they do, does the agent have the context.

Customer effort. How many exchanges to reach an outcome. Effort correlates better with loyalty than satisfaction does in the research on service experience, and automation that reduces cost while raising effort is a bad trade.

And abandonment: conversations that end without resolution or escalation. These are the deflected contacts that were failures, and separating them from successes is exactly what deflection cannot do.

The reporting rule: never report deflection without repeat contact rate beside it. The pair distinguishes a system that solved problems from one that made them harder to raise.

Support operations sit on the most underused corpus in most organisations, and the second use is more valuable than the first.

As a corpus. Historical tickets contain the answers to most recurring questions, phrased the way customers ask them. That is precisely what a retrieval system needs, and it is better than formal documentation in one specific way: it uses the customer's vocabulary rather than the company's, which closes the mismatch that causes retrieval to fail.

The caution is that historical answers include wrong ones, superseded policies and individual agents' improvisations. Feeding an unfiltered ticket archive into a retrieval corpus reproduces every error in it, confidently. So curation is required, and it is real work.

As a diagnosis. Clustering support contacts by theme reveals what the product actually gets wrong, and almost no organisation reads its support volume systematically for this. The top recurring contact reason is a product defect, a documentation gap, or a confusing interface, and every contact about it is a cost the product is imposing.

This is the higher-value use by a considerable margin. Deflecting a recurring question saves the contact cost. Fixing what causes it removes the contact entirely and improves the product for everyone who did not contact you, which is usually the larger group.

The uncomfortable implication for the function: a support operation optimising deflection is optimising how cheaply it absorbs a problem the organisation could fix.

Support is customer-facing, which brings obligations that internal deployments do not have.

Article 50 of the AI Act requires that systems intended to interact directly with people are designed so people are informed they are interacting with an AI system, unless it is obvious to a reasonably well-informed person. This applies from 2 August 2026. In practice, tell the customer, clearly, at the start.

Beyond the Act, three considerations.

Consumer protection. Statements made to a customer through your support channel are statements by your company, and misleading ones are regulated regardless of what produced them. This is the grounding requirement arriving as a legal rather than a quality matter.

Data protection. Support conversations contain personal data and frequently special category data, since customers explain their circumstances. Where those conversations are retained, used to train, or sent to a third-party provider, the analysis from the buying-AI cursus applies directly, and the retention of transcripts is often the largest unmanaged personal data store the function creates.

And accessibility. An automated channel that works poorly for people using assistive technology, or for non-native speakers, or for anyone whose situation does not fit the expected pattern, has narrowed access to support for exactly the people who may need it most. A visible human route is the mitigation.

The practical position: disclose clearly, ground every claim, retain deliberately, and keep the human path visible.

Replacing deflection as the goal changes what gets built.

If the objective is deflection, you build a system that handles as many contacts as possible without a human, and you tune it toward answering rather than escalating. The failure mode is a system that answers badly rather than escalating, because escalating counts against it.

If the objective is resolution at acceptable cost, you build something different. Automation handles what it handles well, abstains readily, escalates cleanly with context, and the measurement distinguishes solved from abandoned.

And if the objective is total contact reduction, which is the most ambitious framing, the support function feeds product and documentation with what it learns, so the recurring questions stop being asked. That is the highest-value version and it requires the function to have influence beyond its own operation, which is an organisational question rather than a technical one.

The three are not incompatible, and they lead to different investments. The first buys a chatbot. The second buys a chatbot plus a handoff and a measurement practice. The third buys those plus the analysis loop into product.

The recommendation for most operations: build for the second, invest in the third, and never report the first without the counterweight beside it. A support function that reduced contacts by fixing their causes has done something a deflection metric cannot even represent, since the contact never happened and therefore was never deflected.