Customer service automation: deflection is not resolution

The metric most customer service automations are judged on — the share of contacts handled without an agent — measures containment, not resolution. The two diverge every time a customer is contained, leaves without an answer, and comes back a day later through a different channel, which the first number records as a success.

Below: why containment flatters, what resolution actually requires, designing the handover, which requests to automate first, and what to measure.

Automating customer service has a straightforward business case and an unusually high rate of quiet failure. The case is real; the failure comes from measuring the wrong thing and finding out eighteen months later.

The distinction that decides the outcome is between a contact that was handled and a contact that was avoided.

Everything below follows from taking that distinction seriously at design time rather than discovering it in a customer satisfaction review. None of it requires a different technology from the one already being evaluated — it requires deciding what the automation is for before deciding what it will be measured on.

Why containment flatters

A contact that ends without reaching an agent counts as contained regardless of why it ended. The customer whose question was answered and the customer who gave up produce the same number.

The second group does not disappear. They call, they write from a different address, they open a complaint, or they leave — and in every case except the last, the organisation pays twice for the same request while the dashboard shows an improvement.

This is why containment should never be reported alone. Paired with repeat-contact rate within a week, it becomes informative; on its own it is a number that can be improved by making the automated path harder to escape.

What resolution actually requires

Three things, and the first is the one usually missing: access to the systems that hold the answer. An assistant that can explain a policy but cannot see the customer's order status is answering a different question from the one being asked.

The second is permission to act. Resolving a request often means changing something — a date, an address, a plan — and an automation with read-only access can only ever route.

The third is knowing when to stop. A request that has not resolved in two exchanges is usually not going to, and the design decision is whether the third exchange is another attempt or a handover.

Designing the handover

The handover is where most of the customer-visible damage happens. An automated attempt that ends by asking the customer to repeat everything to an agent has cost time rather than saved it, and it is the interaction people remember.

What the agent needs on arrival: what the customer asked, what the automation already tried, and what it already knows about the account. Passed correctly, the automated attempt shortens the agent conversation even when it failed — which is the point.

The trigger matters as much as the payload. Explicit request, repeated rephrasing of the same question, detected frustration, or a topic on a defined escalation list — any of these should route immediately, without a further attempt.

Which requests to automate first

The ones that are high volume, have a definite answer, and need data the automation can actually reach. Order status, balance queries, appointment changes, document requests, service availability by address.

The ones to leave: anything where the answer depends on judgement, anything with a commercial consequence the customer might dispute, and anything where the customer is already unhappy. In that last case the contact is not really about the stated request.

The screening question that works better than a category list is whether an agent could resolve it without consulting anyone. If they could, it is a candidate; if they routinely ask a colleague, the automation will not do better.

Applied honestly, that question usually shortens the first release considerably, and it is worth letting it. A narrow assistant that resolves four request types completely earns more trust than a broad one that half-answers twenty.

The language question in the region

A detail that is easy to underestimate: customers in Colombia and Mexico do not phrase the same request the same way, and neither matches the phrasing in the training material that usually arrives with a platform.

Vocabulary differs for everyday things — billing terms, address formats, the words used for a plan or an instalment — and formality expectations differ too. An assistant tuned on one market reads as slightly wrong in the other, which erodes trust before any functional failure occurs.

The fix is unglamorous: build the initial intent set from real transcripts from each market rather than from a generic catalogue, and review the misclassified contacts monthly for the first quarter.

The cost of getting it wrong is not symmetric

A contact that should have been automated and reached an agent costs a few minutes of agent time. A contact that should have reached an agent and was automated can cost the customer.

That asymmetry should shape every threshold in the design. When the assistant is uncertain whether it understood, transferring is the cheap error and guessing is the expensive one — and most default configurations are tuned the other way, because containment is what gets reported.

It also shapes what gets automated at all. A request where a wrong answer is merely unhelpful is a different risk from one where a wrong answer changes a balance, cancels a service, or tells someone their claim was denied.

What the agents should be doing instead

The productive framing is not fewer agents. It is agents spending their time on contacts that need a person, which is a smaller set than the one they handle today and a more demanding one.

That has a consequence teams rarely plan for: average handling time goes up after a successful automation, because the easy contacts left. A programme reporting handling time as a target will look like it failed at exactly the moment it worked.

Setting that expectation before launch costs one conversation. Not setting it produces a quarter of arguing about a metric that is behaving exactly as it should.

What to measure

Resolution rate — contacts closed with no further contact from the same customer within seven days. Repeat-contact rate, which is its complement and catches the failures containment hides. Handover quality, measured as agent handling time on transferred contacts against the baseline.

And the one that is usually missing: satisfaction measured separately for automated and agent-handled contacts. A blended figure conceals exactly the comparison the programme needs.

These four together are hard to game. Containment alone is trivially gameable, and it is gamed by design decisions nobody intended as gaming — an escape route made slightly less obvious, a clarifying question added before a transfer.

Where to start

With the contact reasons already recorded, ranked by volume, and an honest read of which of them an agent resolves without consulting anyone.

A process automation assessment establishes that ranking and what system access each candidate needs, so the automation plan starts from requests that can actually be resolved rather than merely deflected.

Frequently asked questions

What is the difference between containment and resolution?

Containment counts contacts that ended without an agent, including customers who gave up. Resolution counts contacts closed with no further contact from the same customer, and the two diverge exactly where the automation is failing.

What does an automation need to resolve a request?

Access to the systems holding the answer, permission to change something rather than only read, and a rule for when to stop trying and hand over.

What makes a good handover?

Passing what the customer asked, what was already tried, and what is known about the account. Done properly the failed attempt still shortens the agent conversation; done badly it costs the customer time.

Which requests should be automated first?

High volume, definite answer, data the automation can reach — order status, balances, appointment changes. The test is whether an agent resolves it without consulting anyone.

Why does the region matter for a service assistant?

Customers in Colombia and Mexico phrase the same request differently and expect different formality. Building the intent set from real transcripts per market avoids an assistant that reads as slightly wrong.

What should be measured instead of containment?

Resolution rate at seven days, repeat-contact rate, agent handling time on transferred contacts, and satisfaction reported separately for automated and agent-handled contacts.