Support Deflection Is Not Enough. Customers Need Resolution.

Deflection is a cost metric. It measures whether a customer reached a human agent or not.

Resolution is a customer metric. It measures whether the customer actually got their answer.

These two things are frequently confused, and the confusion has consequences. A customer who hits a wall of FAQ articles, finds nothing useful, and quietly gives up has been deflected. They have not been helped. In the deflection column, they are a success. In the resolution column, they are a customer who still has an unresolved problem, and now also a customer who noticed that your support system was designed to avoid them.

What is wrong with measuring support deflection?

Deflection counts tickets that were not filed. It cannot tell the difference between a customer who was helped and a customer who gave up.

The incentive structure around support deflection is understandable. Agent time is expensive. Ticket volume is a real operational burden. If a self-service article can handle a question that would otherwise have taken 12 minutes of agent time, that is a genuine win.

The problem is that the metric is binary: the customer either opened a ticket or they did not. Whether they left with their problem solved is not in the denominator. So the optimization drifts toward "fewer tickets" rather than "more customers helped," and those are not the same direction.

Deflection without resolution looks like: three suggested articles, none of which match the customer's actual situation. A search that returns results but not answers. A bot that collects information and then hands off to a queue. The customer gave up before escalating. Ticket volume: unchanged. Customer satisfaction: quietly declining.

As "What Our Clients Actually Wanted All Along" describes, customers are not asking for a frictionless process. They are asking for their problem to be solved. Deflection without resolution is a frictionless dead end.

What does deflection look like in practice?

A visitor reads the help centre, does not find the answer, does not open a ticket, and leaves. Deflection metrics record that as a success.

Here is a specific scenario. A telecom customer got a bill with a charge they did not recognize. They go to the support page and search "unexpected charge." Three articles come back. The first is about international roaming. The second is about plan changes. The third is a general billing FAQ. None of them address their situation. They click "Contact Us." They are routed to a phone queue with an estimated wait time of 45 minutes. They either wait, which costs the company agent time, or they hang up, which means the problem is still unresolved. Neither outcome is good.

Now consider what could have happened earlier. Before the customer started clicking through irrelevant articles, before they hit the "Contact Us" button, there was a moment when the behavior was already readable: they searched, found nothing useful, and kept scrolling. Pulse detects the unsuccessful search pattern and asks: "What are you trying to sort out?"

The options: Unexpected charge / Service issue / Account change / Technical problem.

They pick "Unexpected charge." Pulse routes them to the specific approved explanation for common unexpected charges, with a direct path to dispute one if it does not match. The customer gets their answer. The ticket never opens.

What is the difference between resolution and containment?

Containment keeps the customer out of the queue. Resolution means the thing they needed actually happened. Only one of those shows up in a satisfied customer.

There is a version of self-service that looks like resolution but is actually just containment. The customer is given so many steps, so many article choices, so many "did this help?" checkboxes that they eventually stop interacting, and the system logs it as a resolved case.

It is worth being honest that this happens. It is also worth naming that customers who experienced it usually know it happened, even if they did not complain. The next time they have a support need, they will think twice before engaging with the self-service system. Or they will skip it entirely and go straight to the phone queue, which defeats the entire cost structure.

Real resolution means the customer left with their question answered. The test is simple: could they move forward after the interaction, or could they not?

How do you resolve an issue before it becomes a ticket?

Detect the struggle in the flow where it starts, ask what is unclear, and answer it there rather than waiting for the customer to find the help centre.

The most valuable place to operate is not the support page, after the customer has already hit a wall. It is earlier, when the customer is starting to struggle but has not yet committed to the escalation path.

"Your Analytics Are Lying to You" makes this point about the limits of downstream data: by the time a ticket opens, the journey is already over. The interesting moment is earlier.

A customer who is reading a support page, running searches, clicking articles that do not match, and starting to show signs of frustration is a customer who is about to escalate. The behavioral signal is there. The window to intervene with a relevant question is short but real.

That intervention does not require an agent. It requires one diagnostic question, routed to the right pre-approved answer. The customer gets help. The ticket does not open. And unlike deflection-without-resolution, the customer actually leaves with their problem addressed.

What should you measure instead of deflection?

Whether the task the customer came to do was completed, and whether the same issue recurs for other customers at the same point.

Two measurements matter here. The first is support ticket rate for customers who engaged with a Pulse intervention versus those who did not. A meaningful gap there tells you how much of your ticket volume was addressable at the self-service layer, if the self-service layer had known what to surface.

The second is task completion: did the customer find what they were looking for? This is harder to measure but more honest. It requires asking, briefly, at the end of the interaction. A simple "Did that answer your question?" with a yes/no, combined with tracking what happened next, gets you most of the way there.

Deflection metrics will keep going up as long as fewer customers reach agents. Resolution metrics only go up when customers actually get their answers. The goal is both.

Frequently asked questions

How do I reduce support tickets from my website?

Resolve the issue where it happens rather than routing people to a help centre. A ticket avoided because the customer got what they needed is a genuine reduction; one avoided because they gave up is not.

What is the difference between deflection and resolution?

Deflection measures tickets not filed. Resolution measures problems actually solved. A customer who leaves frustrated counts as deflection and as a loss.

Is a knowledge base enough to reduce support volume?

Only for customers who look for it, find the right article, and understand it. Those who fail at any of those steps do not file a ticket either, which flatters the metric.

How do you know whether deflection is working?

Look at task completion rather than ticket volume. If tickets fall while completion also falls, the deflection is people giving up.

Can support issues be resolved before a customer asks?

Frequently, yes. Most support contacts follow a visible period of struggle in the flow itself, which is early enough to detect and answer.

Deflection is the core promise of a neighbouring category. See digital adoption platform for what those tools do and who they are built for.