AI in Customer Support: Deflection Is Not Resolution

AI in customer support works, and the number most teams use to prove it does not. Deflection rate rises whenever fewer people reach a human, including when you make the human harder to reach. Track four numbers together or you cannot tell a working rollout from a hidden one.

Our position at LeapForce is narrower than the usual advice. The decisive constraint on a support AI programme is not the model you pick and not the vendor. It is the quality of the knowledge base the model answers from, and the honesty of the measurement you run on top. A support organisation that fixes its corpus and its metrics can succeed with almost any competent model. One that fixes neither will fail with the best model available, and the failure will look like success on the dashboard for two or three quarters.

A commenter on Hacker News described the mechanism better than most vendor documentation. Writing in March 2024, u/Nursie traced a real loop at a pension provider: the support page pointed to a bot, the bot gave a phone number, the number told him to use his online account, and the account page said the action could not be completed online because he was overseas. His conclusion: "the aim is not to resolve problems, it's to stop people taking the time" of a human. Every step in that loop counted as a deflection.

The short answer: Deflection rate measures avoided human contact, not solved problems — so read it only alongside seven-day repeat-contact rate, median time-to-human, and CSAT split between contained and escalated conversations, and fix the knowledge base before you touch the model.

Last updated: July 31, 2026.

The Four-Number Read: each number alone can be moved without helping a customer; the set cannot.

What AI in customer support actually changes in a support organisation

AI in customer support is the use of language models to read, answer, route and summarise customer contacts, sitting in front of or beside the human queue. What it changes operationally is not the volume of work. It is the composition of the work that reaches people, and the set of things a support leader now has to measure, own and govern.

That distinction matters because most planning documents treat a support AI deployment as a capacity project: same tickets, fewer humans. It is closer to a triage redesign. The bot absorbs the shallow end of the distribution, the human queue inherits a harder mix, and a whole category of new work appears that did not exist before: corpus maintenance, escalation design, conversation review, and the ongoing job of deciding what the bot is allowed to say.

Gartner's own survey work puts numbers on that last part. In a survey of 265 service and support leaders conducted in April and May 2025, Gartner found that 77% of service and support leaders felt pressure from other senior executives to deploy AI, 75% reported increased AI budgets, and "the typical leader is planning to add five new full-time-equivalent (FTE) roles in the next 12 months to manage these investments." Five new roles to run the thing that was sold as a way to need fewer roles. That is not a contradiction. It is the composition change showing up in the org chart.

It is also worth separating the two deployment shapes, because they carry very different risk. A customer-facing surface answers the customer directly. Agent assist sits beside a human, drafting and summarising while the human stays accountable for what gets sent. Gartner predicted that by the end of 2025, 73% of customer service organisations would have implemented agent assist for their workforce, which makes it the more common shape by some distance and the one with no escape-hatch problem at all.

Three things are true at once, and holding all three is the whole discipline:

What AI in customer support is not

It is not a replacement decision, even when a vendor prices it as one. It is not a knowledge management project that happens to have a chat window, although the knowledge half dominates the outcome. And it is not primarily a model-selection exercise: the difference between a competent model and the current frontier model shows up far less in support answer quality than the difference between a maintained knowledge base and a stale one.

It also is not the same question as "how much authority does the agent get". That is a separate and genuinely important design problem — resolution limits, refund ceilings, escalation triggers — and we treat it separately in our earlier analysis of the read-say-do ladder for customer service automation. This article is about the organisation that adopts the thing: how it sequences the rollout, how it measures it honestly, and what happens to its people.

Deflection is the one metric you can improve by getting worse

Deflection rate is the share of customer contacts that end without a human agent handling them. It is the default headline metric for AI in customer service, it is the number that appears in board slides, and it has a structural flaw: it counts an outcome defined by absence. Nothing in the definition requires that the customer's problem was solved. A customer who gave up counts. A customer who found the contact route too confusing counts. A customer who came back tomorrow through a different channel counts twice, once as a deflection, once as a new contact.

That makes deflection the easiest support metric to move without doing anything useful. Remove the phone number from the help page and deflection rises. Put the human handoff behind three bot turns and deflection rises. Narrow the hours the chat queue is staffed and deflection rises. Every one of these is a legitimate-sounding "self-service optimisation" in a quarterly plan, and every one of them improves the number by degrading the service.

The gap between deflection and resolution is not small. Gartner's guidance on self-service states plainly that "the average self-service customer support success rate today is just 14%," and that improving that rate is "a significant or moderate priority for 90% of customer service and support leaders" surveyed. Read that against a typical reported deflection rate and the arithmetic is uncomfortable: a large share of what gets counted as deflected is not resolved. It is deferred.

None of this means deflection is a useless number. It is a genuine efficiency signal when you already know the customer got an answer. The failure is using it alone, and the failure is common because it is the only one of the four numbers that a vendor can show you in a demo.

The four ways a deflection rate gets inflated

Each of these is caught by exactly one of the other three numbers in the read. That is the design: deflection is not replaced, it is constrained.

The customer-side experience of a gamed funnel is well documented in public. On Hacker News in October 2025, u/pogue described a permanent account suspension with no route to appeal: "there's no one to follow up with," and the recovery paths that actually worked involved knowing someone inside the company or getting press coverage. That is the extreme end. But the mechanism is the ordinary one: a support surface optimised for contact avoidance rather than problem resolution, measured by a number that rewards exactly that.

The Four-Number Read

The Four-Number Read is the smallest set of metrics that cannot be gamed as a set. Track containment rate, seven-day repeat-contact rate, median time-to-human, and CSAT split between contained and escalated conversations. Any one of the four can be moved by a bad decision; moving all four in the right direction at once requires actually resolving more problems.

Here is each number, what it catches, and how it is defined precisely enough to compute.

The seven-day window is a choice, not a law. Use whatever window covers the natural re-contact cycle for your product. Three days for a consumer app with a fast billing cycle, fourteen for enterprise software where the customer needs a week to test the fix. What matters is that the window is fixed before the rollout and never changed afterwards, because moving the window is the single easiest way to make a repeat-contact rate improve.

Median time-to-human is the number that catches deliberate friction, and it is the one almost nobody instruments. It is not average queue time, and it is not first response time. It starts at the moment the customer signals they want a person, whether by typing "agent", clicking a handoff control, or expressing frustration your classifier picks up — and it ends when a human actually replies. If that median goes up while deflection goes up, you have not improved self-service. You have installed a maze.

Why the CSAT split is non-negotiable

Blended CSAT is the most misleading number in a support AI rollout, because the population being surveyed changes underneath it. If the bot handles the easy contacts and easy contacts were always the happiest, blended CSAT can rise while every individual customer's experience gets worse or stays the same. Splitting it removes the composition effect. Contained CSAT tells you whether the bot's answers are good. Escalated CSAT tells you whether the handoff and the human queue survived the change in mix.

The gap between the two is itself the diagnostic. A widening gap, with contained CSAT climbing while escalated CSAT falls, is the signature of an under-resourced human queue absorbing a harder ticket mix with the same headcount and the same handle-time targets.

What to do with the read

Score the four together, once a month, on one page. The decision rule is simple enough to state in a sentence: a containment rate is only credible when repeat-contact is flat or falling, time-to-human is flat or falling, and both CSAT lines are flat or rising. If containment rises and any of the other three moves the wrong way, the correct interpretation is that you moved work, not that you removed it.

Prerequisites before you turn anything on

Before the first customer conversation reaches an AI surface, five things need to be true. None of them are technical, all of them are the kind of thing that gets skipped because the pilot is scheduled, and each of them costs ten times more to retrofit than to establish.

1. A baseline for all four numbers, measured for at least one full month without AI. You cannot detect displacement without a pre-period. Most rollouts we see start measuring on the day the bot goes live, which makes every subsequent number uninterpretable.
2. A named owner for the knowledge corpus. Not a team, a person. The corpus is the product now; unowned content decays and the decay is invisible until a customer is told something false.
3. A written escape-hatch rule. One sentence stating how a customer reaches a person, from every surface the bot appears on, and a maximum number of bot turns before that route is offered unprompted.
4. A conversation review sample and a reviewer. A fixed percentage of contained conversations read by a human every week, chosen randomly, not chosen from the ones the bot flagged. Self-selected samples confirm whatever the bot already believes.
5. A retention and access decision for the transcripts. Who can read them, how long they are kept, and what the model provider is allowed to do with them. This is a decision to take before launch, not after the first security review; we set out the questions in our analysis of who keeps the transcript.

If you can only do one of the five, do the baseline. Everything downstream is an argument about numbers, and without a pre-period you have no standing in that argument.

Two objections come up every time we make this case, and both deserve straight answers. The first is that the contract is already signed and onboarding starts next week, so there is no time for a baseline month. The fix is that a baseline does not block procurement. Instrument the four numbers while the vendor onboards, and run shadow mode before any customer sees the agent; between them you get a pre-period and a quality signal without moving the launch date.

The second is that the vendor dashboard does not expose time-to-human, so it cannot be measured. That is common and it is a procurement requirement, not a technical limit. Ask, in writing, before signing: can the platform emit a timestamp for the customer's handoff request and a timestamp for the first human reply, in an export you control. If the answer is no, you are buying a system whose most gameable metric is the only one you can see.

The corpus ceiling: model upgrades move the answer within the ceiling, never above it.

The corpus ceiling sets your answer accuracy, not the model

An AI support agent cannot be more correct than the documents it retrieves from. If your refund policy page is eighteen months out of date, a better model produces a more fluent, more confident, more persuasive statement of the wrong policy. This is the corpus ceiling, and it is the single most reliable predictor of whether a support AI deployment produces good answers.

The academic work backs the shape of this. In Data Quality Challenges in Retrieval-Augmented Generation, published October 2025, Müller, Holstein, Bause, Satzger and Kühl interviewed 16 practitioners at leading IT service companies and derived 15 distinct data quality dimensions across the four processing stages of a retrieval-augmented system. Their finding that matters most to a support leader: the new dimensions "are concentrated in early RAG steps, suggesting the need for front-loaded quality management strategies," and quality problems "transform and propagate through the RAG pipeline."

Front-loaded. Not fixable later with a better model, not fixable with prompt engineering, not fixable by adding a reranker. The defects enter at extraction and transformation, the stage where your help centre articles, macros, internal wikis and policy PDFs become retrievable chunks — and everything downstream inherits them.

Gartner's channel research points the same way from a completely different angle. Reporting a survey of 265 customer service and support leaders conducted in April and May 2025, Gartner noted that "live chat, self-service portals, and knowledge management systems are solidifying their place as essential tools," and that leaders should focus on "optimizing knowledge management" — while AI agents themselves "remain outside the top 10 customer service technologies ranked by leaders now and in two years' time." The people running these functions rank the knowledge layer above the agent layer. They are right, and the reason is the ceiling.

The four corpus defects that produce bad answers

The last one is underrated. A support knowledge base written for humans who can scan is often structured badly for retrieval, because a human reader uses the page's headings to jump and a retriever does not. Splitting a long omnibus article into topic-level documents frequently improves answer accuracy more than any model change, and it costs a day.

Governing what the retriever can see is a control problem as much as a content problem — which documents are in scope, who can add one, and what happens when a document is retired. We set out that machinery in our earlier analysis of governing the retrieval layer.

A knowledge base audit you can run in one sitting

Take your top 30 contact reasons by volume from the last quarter. For each one, ask the three questions below and write down the answer. This takes an afternoon for a mid-size support organisation and it produces a defensible go or no-go for the whole programme.

1. Is there a document that answers this, in full, without the reader needing another document? Yes or no. Partial counts as no.
2. When was it last reviewed by someone who owns the policy it describes? A date. "Unknown" counts as more than a year.
3. If two documents cover it, do they agree? Read both. This is where most of the surprises are.

Score each contact reason green, amber or red, then look at the volume-weighted share of green. That percentage is roughly the ceiling on how much of your contact volume an AI support agent can answer correctly today, before you have spent anything on a model. If it is below half, the honest sequence is corpus work first and the AI surface second. Not because AI does not work, but because deploying onto a red corpus produces confident wrong answers at scale and burns the internal credibility you need for the second attempt.

The audit also produces something useful regardless: a prioritised content backlog ranked by contact volume, which is a better editorial roadmap than most support content teams have.

Rollout sequencing and the two phases everyone skips

Sequencing is where support AI programmes are won or lost, because the tempting order, deploy then measure then fix, puts the most expensive failure first. The order that works front-loads the two cheap phases that get cut when the launch date moves.

Our own gateway rollout model at LeapForce is stated as Observe first. Enforce second. Optimize third., and the same shape applies to a customer support deployment. Watch what actually happens before you constrain it; constrain before you tune; tune last, when you have a baseline worth tuning against.

Concretely, six phases:

Phases 1 and 2 are the skipped ones, and skipping them is why so many programmes cannot answer the simplest board question: did this help. Shadow mode in phase 3 is the cheapest quality measurement available. The AI produces a draft, a human agent decides whether to send it, and the acceptance rate is a direct, honest accuracy signal with zero customer risk. A shadow period that produces a 40% draft acceptance rate has told you something enormously valuable before a single customer was exposed.

The widening in phase 5 should be by contact reason, not by percentage of traffic. Percentage rollouts spread a corpus defect across every topic thinly; cohort rollouts contain it to one topic where the review sample will find it.

A worked Four-Number Read, assembled end to end

Below is a complete read for one quarter, assembled so you can copy the shape. The numbers are illustrative arithmetic, not a client result. They are here to show how the four interact and what a correct interpretation looks like, not to claim a benchmark.

Assume a support organisation handling 40,000 contacts a month, deploying an AI surface at the start of month one, with a measured baseline month zero.

A dashboard showing containment alone reads as a success story: 31% to 52% in three months. The full read says something else entirely. Repeat contact climbed eight points, so a growing share of "contained" conversations were not resolved. Time-to-human tripled, which means the escape hatch got harder to use as volume moved onto the AI surface, either by design or because the human queue was under-staffed for the escalations arriving. And the CSAT split shows the damage landing on escalated conversations, exactly where a harder ticket mix meets an unchanged human capacity plan.

The correct action here is not to turn the AI off. It is to stop widening, staff the escalation queue for the new mix, re-run the corpus audit on the contact reasons with the worst repeat-contact rate, and hold containment flat until time-to-human comes back under the baseline. Blended CSAT, incidentally, would have shown a mild 4.4 to 4.0 decline that most organisations would have explained away as seasonal.

The one-page format

Put the seven rows above on one page, monthly, with the baseline column always visible. The baseline column is the part that gets quietly dropped after two quarters, and dropping it is what makes displacement invisible. If your reporting tool cannot keep it, keep it in a spreadsheet.

What containment does to the human queue: less volume, a harder mix, and a different job.

What happens to the human team when the easy tickets disappear

The team's work changes shape before it changes size. When an AI surface absorbs password resets, order status and shipping questions, what remains in the human queue is the residue: multi-step problems, angry customers, edge cases the documentation never covered, and everything with a legal or financial consequence. Same people, harder day, and usually the same average-handle-time target.

This is the part of a support AI business case that is systematically under-modelled. The savings are calculated on tickets removed; the cost of the harder residual mix is not calculated at all. Three second-order effects show up within two quarters:

• Handle time rises and looks like a performance problem. It is not. It is composition. Judging agents against a pre-AI AHT target after the easy tickets left is a good way to lose your best people.
• The training ladder breaks. New agents historically learned the product on simple tickets. Those tickets are gone, so the first ticket a new hire touches is a hard one. Onboarding gets longer and more expensive, and the shortcut, hiring more senior, raises the wage floor.
• Burnout concentrates. A queue made entirely of difficult conversations, with no easy ones in between, is a materially worse job than the same queue was before. The recovery time that simple tickets used to provide is not a nice-to-have; it was load-balancing.

The labour-market picture is real but slower and less dramatic than the headlines suggest. The US Bureau of Labor Statistics projects employment of customer service representatives to decline 5 percent from 2024 to 2034, from 2,814,000 to 2,660,300, a fall of 153,700 positions over a decade. In the same period the BLS projects "about 341,700 openings for customer service representatives... each year, on average, over the decade," all of them from replacement need. The BLS attributes the decline to automation directly: "Self-service systems, social media, and mobile applications enable customers to do simple tasks without interacting with a representative."

A 5 percent decline over ten years alongside 341,700 annual openings is not the collapse the discourse describes. It is a slow contraction plus a large ongoing churn, which for a support leader means the practical problem is not mass redundancy. It is that the role you are hiring for has quietly become a different, more demanding role while the pay band and the job description stayed where they were.

The roles that appear

Meanwhile the programme creates work. Gartner's finding that the typical service leader plans to add five FTEs to manage AI investments matches what the phases above imply: someone owns the corpus, someone reads the review sample, someone designs and maintains escalation rules, someone runs the monthly read, and someone handles the vendor and model relationship. In smaller organisations these are fractions of existing jobs rather than new headcount, but they are not free, and pretending they are is how a business case survives approval and then fails in year two.

Klarna's public trajectory is the clearest available illustration of the whole arc. In February 2024 the company announced that its OpenAI-powered assistant had handled 2.3 million conversations in its first month — "two-thirds of Klarna's customer service chats," equivalent to "the work of 700 full-time agents" — with errands resolved "in less than 2 mins compared to 11 mins previously," a "25% drop in repeat inquiries," and satisfaction "on par with human agents." Those are real, primary-sourced, and genuinely impressive numbers, including a repeat-contact improvement, which is the hardest of the four to fake.

Fifteen months later the same company reversed. Reporting on 9 May 2025, Kristen Doerer of CX Dive quoted CEO Sebastian Siemiatkowski saying "Really investing in the quality of the human support is the way of the future for us," and "From a brand perspective, a company perspective... I just think it's so critical that you are clear to your customer that there will be always a human if you want." Klarna began recruiting customer service staff again, into a hybrid model where AI handles routine volume and specialists take the complex and emotionally loaded cases.

Read the two together and the lesson is not "AI support failed at Klarna." The metrics in 2024 were real. What the reversal says is that a containment number that good, sustained, still left something the company decided it could not do without, a guaranteed human route, and that the value of that route did not show up in any of the numbers being celebrated.

Telling improvement from displacement in CSAT

Improvement means the same customer with the same problem has a better experience. Displacement means the mix of customers being measured changed. The two look identical in a blended CSAT line, and distinguishing them is the single most useful analytical skill in running AI in customer service.

Four tests, in increasing order of effort:

The response-rate test deserves a note, because it catches a failure mode almost nobody instruments. Survey response is voluntary, and a customer who has given up on your support channel stops answering surveys before they stop being a customer. A CSAT score rising while the response rate falls is not good news; it is a shrinking, self-selecting sample. Plot them on the same axis and the pattern is obvious within a quarter.

There is also a channel effect worth planning for. Gartner's customer survey of 5,801 people conducted in January and February 2025 found that while 55% of service leaders were exploring customer-facing generative AI chatbots, "only 35% of customers who last interacted via phone are willing to adopt a GenAI digital assistant." Gartner's reading is that a good phone experience actively disincentivises AI adoption. Customers who have a working route do not want a new one. If your CSAT falls after launch and your phone channel was strong, that is a plausible explanation that has nothing to do with your model's answer quality.

The same Gartner release contains a finding support leaders should sit with: 60% of customer service agents fail to promote self-service to customers, and among those who do mention it, "25% make neutral comments, and 12% make explicitly negative remarks." Your own agents are a channel for adoption or against it, and they will read the rollout as a threat if nobody tells them otherwise. Agent promotion, Gartner found, was "associated with a doubling of the number of customers who are likely to adopt self-service next time."

Eight ways support AI programmes go wrong

Each of these is a specific, observable mistake with a specific fix. None of them are about model choice.

1. Measuring from launch day. No baseline means no interpretable result, forever. Fix: one month of pre-period, four numbers.
2. Deploying onto an unaudited corpus. Confident wrong answers at scale, and the internal credibility loss is permanent. Fix: the one-sitting audit, before procurement.
3. Reporting deflection alone. Rewards friction. Fix: the Four-Number Read, one page, monthly.
4. Blending CSAT. Hides displacement behind a composition effect. Fix: split by contained and escalated.
5. Keeping pre-AI handle-time targets. Punishes agents for inheriting a harder mix. Fix: re-baseline AHT by contact reason after each widening.
6. Reviewing only flagged conversations. The bot flags what it knows it got wrong; the dangerous ones are the confident errors. Fix: random sample, human reviewer, fixed weekly percentage.
7. Widening by traffic percentage instead of contact reason. Spreads defects thinly across every topic. Fix: cohort rollout by contact reason.
8. Leaving the escape hatch undesigned. Ends with a maze nobody intended to build, one reasonable optimisation at a time. Fix: a written rule, a maximum bot-turn count, and time-to-human on the monthly page.

The seventh and eighth are the ones that survive review boards, because both look like prudence. Rolling out to 10% of traffic sounds cautious. It is not. It is a way of guaranteeing that every contact reason gets a little bit of an untested system, and that your review sample is too thin anywhere to detect a pattern.

What this costs, and where the money actually goes

Vendor pricing for AI in customer support is usually quoted per resolution, per conversation, or per seat, and that quoted number is the smaller half of the real cost. The larger half is the internal work the phases above describe, and it is almost always paid in existing salaried time rather than in a line item, which is exactly why it disappears from business cases.

We are deliberately not publishing per-conversation price ranges here. Vendor pricing in this category changes faster than an article can track, quoted rates rarely survive contact with a real contract, and a stale number would be worse than none. Fetch current pricing from the vendors you are actually shortlisting, on the day you build the model, and price the four unbudgeted rows above at your own loaded salary cost.

The one costing rule worth stating: model the residual queue, not the removed tickets. The savings from removed tickets are real and easy to compute. The cost of the harder remaining mix, meaning longer handle times, longer onboarding, higher wage floor, higher attrition — is real, harder to compute, and lands in year two rather than year one. A business case that only has the first is not wrong, it is incomplete in a predictable direction.

When not to deploy AI in customer support at all

There are situations where the honest recommendation is to wait, and a support leader who can name them is more credible than one who cannot.

• Your knowledge base scores mostly red. Deploying onto a red corpus is not a faster route to a good outcome; it is a slower one, because it spends the credibility you need for the second attempt.
• Your contact volume is low enough that the maintenance work exceeds the saving. Below a few thousand contacts a month, the corpus, review and escalation work can plausibly cost more staff time than the deflected tickets returned. Run the arithmetic before assuming scale-independence.
• Your contact mix is dominated by regulated, high-consequence conversations. If most of your queue involves decisions with legal or financial consequences, the share the AI can safely handle is small enough that the programme is mostly overhead.
• You cannot staff a human escalation path. An AI surface with no credible route to a person is the failure mode this whole article is about. If the headcount for escalation is not there, deployment converts a slow support experience into an impossible one.
• You are inside a restructuring. A rollout measured against a shifting headcount baseline produces numbers nobody will trust afterwards, including you.

None of these are permanent. All of them are reasons to sequence differently, not to abandon the idea.

Where LeapForce fits, and where it does not

LeapForce does not sell a customer support desk, a helpdesk product, or a support chatbot, and nothing above should be read as steering you toward one. What we build is the layer underneath: one controlled place where an AI surface gets its model access, its connector permissions, its cost attribution and its audit record, so that when a support AI agent reads a ticket, retrieves a document and takes an action, there is a record of what it touched and what it was refused.

That matters for the specific problems this article describes. The corpus ceiling is a retrieval-governance problem before it is a content problem — which documents the retriever may see, who can add one, what happens when a document is retired. The review sample needs a trustworthy record of what the agent actually did, not a vendor dashboard's summary of it; that is the ground our observability and audit trails analysis covers. And the supervision question, how many AI surfaces one person can credibly review, is the subject of our work on supervision ratio rather than headcount. Our rollout stance, Observe first. Enforce second. Optimize third., is the same sequencing argument this article makes for support: instrument before you constrain, constrain before you tune.

Where this analysis is still uncertain

Several things in this piece are weaker than the confident register of most support AI content would suggest, and they are worth naming.

The four numbers are a judgement, not a validated instrument. We have argued that these four cannot be gamed as a set, and we believe that, but we are not aware of published research validating that specific combination against outcomes. A fifth number, whether cost per resolved contact or churn among contained customers, may well earn its place. Treat the Four-Number Read as a floor, not a finished measurement system.

The worked read is arithmetic, not evidence. The quarterly table is constructed to show how the four numbers interact. It is not a case study, no organisation produced those figures, and it should not be cited as a benchmark.

The corpus ceiling is well-supported in direction but not quantified. The Müller et al. finding establishes that quality defects concentrate early and propagate; it does not tell you that a 60% green corpus caps you at 60% correct answers. The audit percentage is a planning heuristic, and we would expect the real relationship to be non-linear.

Klarna's 2026 position could not be verified from a primary source. The February 2024 figures come from Klarna's own press release and the May 2025 reversal from CX Dive's reporting of a Bloomberg interview. Later characterisations of Klarna's hybrid model circulating in 2026 appear only in secondary vendor commentary, so we have not asserted them.

Our first-hand check was crude and we are reporting it as such. On 31 July 2026 we fetched eight major public help homepages to see whether a human contact route appeared in the delivered HTML. Four returned blocking responses to a plain request (403 or 400) and could not be assessed. Of the four that loaded, three exposed a human-contact string and one did not. That is a real measurement, and its honest conclusion is a negative one: time-to-human is not measurable from outside a company's funnel. Only the support organisation itself can instrument it, which is precisely why it so rarely gets instrumented. We ran no live customer-facing deployment of our own for this article.

No video accompanies this piece. We searched the YouTube Data API for conference material on support AI measurement and the shared key's daily search quota was exhausted, so no credible video could be selected. We would rather report that than embed something unvetted.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.