AI in Customer Support: What Deflects and What Annoys

Support automation is bought on a deflection rate and lost on an escalation. The first number is easy to move without helping anyone; the second is where the customer decides what they think of you.

The metric that lies

Deflection is usually computed as: sessions that touched the assistant and did not create a ticket, divided by sessions that touched the assistant. Read that definition again with a customer in mind. Someone who asks twice, gets a paraphrase of the help centre both times, closes the tab and posts a review instead has been counted as a deflection. So has someone who gave up and phoned. The metric cannot tell resolution from abandonment, and abandonment is cheaper to produce.

A measure that does not have that hole is a reopen window: of the contacts the assistant closed, what share of the same customers opened a human ticket on the same subject within seventy-two hours. It needs identity resolution across channels and a subject match that is usually a coarse classifier over the ticket text, and it is worth the effort because it is falsifiable in the direction that matters. Pair it with two more: the share of assistant sessions that ended in an explicit request for a human, and, separately, contact rate per hundred orders — the top-line number automation is supposed to move and the one it can only move by actually resolving things.

Where the answers actually live

The published help centre is the corpus everyone reaches for first and it is rarely the authority. Support organisations answer from macros — the saved replies agents insert — and from the last year of resolved tickets, and those two contain the current policy, including the parts that were never written up. The help centre says returns are accepted within thirty days; the macro says the team grants an exception up to forty-five for a first-time customer.

Building the index from ticket history brings one hazard that is specific to this data shape: support threads carry internal notes on a separate channel from customer-visible replies, and they contain discount authority, fraud flags and blunt opinions about the customer. Those must be excluded at ingestion by channel, not by a prompt asking the model to be discreet. Threads also contain the customer’s own personal data, so the same retrieval index is a privacy surface — see PII in LLM logs and multi-tenant retrieval for the isolation this needs.

Two kinds of wrong, priced differently

Support questions split into two classes with completely different error economics, and treating them with one accuracy target is how projects go wrong.

• Informational. How do I reset it, where is my order, what does this error mean. A wrong answer costs a follow-up. Broad coverage is worth having and a slightly hedged answer is fine.
• Entitlement. Am I eligible for a refund, is this under warranty, will you waive the fee. A statement here is a commitment a customer will hold you to, and reasonably so. A wrong yes is a credit you did not intend to give; a wrong no is a churn event with a public review attached.

The design consequence is that entitlement questions should not be answered generatively at all. Route them: the model classifies the intent, extracts the order or policy reference, and a deterministic rules layer over the actual account state produces the answer. The model is allowed to phrase it. That is the same split claims handling uses, and it exists for the same reason: the authority is the policy wording, not a paraphrase of it.

The handoff is the product

Every assistant escalates. The quality of the escalation determines whether the customer remembers the automation as a filter or as an obstacle, and it is almost entirely an integration problem rather than a model one. A handoff worth building carries four things into the agent’s queue:

• The full transcript, above the fold. Not attached, not linked. If the agent has to open something, they will ask the customer to explain again, and that is the moment the whole programme is judged.
• The structured facts already collected — order id, account, verified identity, the intent classification. The customer has typed these once.
• What the assistant told them. Agents need to know what has already been promised before they contradict it.
• A priority adjustment. A customer who has already spent four minutes and asked twice is not a fresh contact. Queue them ahead of one.

And give the exit a name. A visible way to reach a human, offered after the second unsuccessful turn rather than hidden, costs a little deflection and buys the thing deflection was a proxy for. Human-in-the-loop design and teaching a model to abstain are the general versions of this problem.

The failure nobody notices: index drift

The characteristic production failure in support is not hallucination. It is a correct answer to last month’s policy. Shipping cutoffs change in December, a product is recalled, a fee is removed — the help centre is updated the same day, and the retrieval index is rebuilt on a schedule nobody remembers setting. For a week the assistant confidently quotes the old cutoff to every customer who asks, which is worse than having no assistant, because it is wrong at exactly the moment volume peaks.

Treat freshness as an operational target with an alert, the way index freshness describes: measure the lag between a source document changing and the index reflecting it, alert when it exceeds the window, and give the support content owners a way to force a rebuild for one document without filing a ticket with engineering. The people who know the policy changed are not the people who own the pipeline, and any design that requires them to talk on the day of a change will fail on the day of a change.