Customer Service Automation: The Read-Say-Do Ladder

Customer service automation works when you sort the work by what the software is allowed to touch: read a customer's data, say something on the company's behalf

Customer service automation works when you sort the work by what the software is allowed to touch: read a customer's data, say something on the company's behalf, or do something that changes money or account state. Reading is safe to automate broadly. Saying is a legal commitment. Doing needs a named approver.

That split is our position, and it is not how most guides frame the question. The usual framing is channel-first — automate chat, then email, then voice — which sorts the work by where it arrives rather than by what goes wrong when it is wrong. A customer posting to Hacker News on 29 April 2026 shows the cost of getting that backwards: after a gifted subscription never arrived, they wrote that the vendor's AI agent had "still not offered me a refund. I may have to do a chargeback" (captainarab, Hacker News). The automation could talk fluently about the problem. It could not perform the one action that resolved it, and there was no human path behind it. The company did not save a contact; it converted a support ticket into a payment dispute.

The short answer: Automate reading freely, automate saying only where a wrong sentence is cheap to retract, and never let an automation move money or change an account without a named approver and a recorded reason, because a tribunal has already held that a chatbot's words bind the company that deployed it.

Last updated: July 30, 2026.

Three-tier ladder showing read, say and do permissions for support automation with the gate each tier needs

The Read-Say-Do ladder: sort every contact reason by what the automation touches, not by which channel it arrives on.

One disclosure before the argument. We have not run a controlled deployment of a support automation stack and measured its containment rate ourselves, so nothing below is presented as our own benchmark. Every number here is sourced to a named third party, fetched on 30 July 2026, and the cost model in the pricing section is a worked calculation from published list prices with its assumptions stated in the open. Reddit, the place support leads argue about this most candidly, blocked automated access during this research, so the practitioner voices quoted come from Hacker News, which skews toward engineers rather than support managers.

What Customer Service Automation Actually Is

Customer service automation is any software that handles part of a support interaction without a human doing it: intake, classification, routing, answering, acting, or recording. It is not one product. It is five or six mechanisms that happen to get sold together, and treating them as one purchase is where most programmes go wrong.

The pipeline underneath almost every vendor's marketing is the same:

StageWhat happensTypical mechanismWhat it touches
IntakeThe contact arrives and is capturedWeb widget, email parser, IVR, messaging APINothing yet
ClassificationIntent, urgency and language are identifiedIntent models, sentiment analysis, language detectionReads the message
RoutingThe ticket lands in the right queue or agentAutomated ticket routing, skills-based routingReads customer records
ResponseAn answer is composed and sentAI chatbots, macros, self-service knowledge base retrievalSays something on your behalf
ActionSomething changes in a system of recordRefund APIs, order edits, account changesMoves money or state
RecordThe interaction is logged for laterTicket history, transcripts, audit trailStores personal data

Two things follow from reading that table honestly. First, only two of the six stages carry serious downside: response and action. Intake, classification and routing are cheap to get wrong; a misrouted ticket costs a queue hop. Second, the record stage is where regulators look, and it is the stage most implementations bolt on last.

The category is also older and more mundane than the current agentic framing suggests. Interactive voice response (IVR) has been automating intake since the 1980s. A self-service knowledge base is automation. So is a macro. What changed between 2023 and 2026 is not that automation arrived but that the response stage became fluent enough to be believed. Fluency is exactly what turns a wrong answer into an expensive one.

The ladder in the next section applies whatever the channel. An omnichannel rollout with AI voice agents on the phone line, a messaging bot in the app and email triage behind both is three deployments of the same six stages, and the tiering question is identical in each. Voice adds one wrinkle worth pricing early: it costs more per action at every vendor that publishes a rate, and recording it drags consent and retention obligations along with it.

What it is not. Automated customer service is not deflection, though the two get conflated constantly. Deflection is a metric: the share of contacts that never reach a human. You can raise deflection by hiding the contact form, and plenty of teams have. Automation is a set of mechanisms; deflection is one possible outcome, and a bad proxy for whether the customer's problem was actually solved.

The Read-Say-Do Ladder

The Read-Say-Do ladder sorts every contact reason by the highest-privilege thing the automation needs in order to finish the job. Tier one reads data. Tier two composes a statement the customer will rely on. Tier three changes something outside the conversation. Each tier up multiplies the blast radius of a single bad output, and each tier needs a different control, not a better model.

TierThe automation…Worst realistic outcome of one bad outputControl that actually works
ReadRetrieves, summarises, classifies, routesA ticket sits in the wrong queue for an hourScoped, read-only access to the specific records needed
SayStates policy, prices, eligibility, timelines on your behalfA promise you are legally held to, at scaleGrounding in a versioned source, plus a recorded policy version per answer
DoRefunds, credits, cancellations, address and plan changesMoney leaves, or an account is altered, without authorisationA named human approver for the action class, with an audit record

The ladder is deliberately about permissions rather than confidence scores. Confidence thresholds are the usual industry answer — let the bot act when it is 95% sure — and they fail in the one situation that matters, because a jailbroken or manipulated model is confidently wrong. Permission boundaries do not care how sure the model is. This is the same distinction we drew in our earlier analysis of where write access separates an AI agent from a chatbot: the interesting line is not conversational quality, it is whether anything outside the conversation changes.

Why a ladder rather than a matrix: the tiers are cumulative. A tier-three automation always also reads and says, so it inherits every control from the tiers beneath it. That is the practical value of the model in a design review. You can point at a proposed automation, name its tier, and immediately enumerate the controls it owes.

Most teams get the ordering wrong in a specific and predictable way. They ship tier two first because it demos well, defer tier three because it looks scary, and never explicitly build tier one's access scoping because reading feels harmless. Then the incident that lands is a data one: the bot answered a stranger's question using the wrong customer's order history.

Tier One: Read — Automate This Broadly

Tier-one customer service automation reads and organises without stating anything to the customer or changing anything in a system of record. Intent classification, language detection, sentiment analysis, automated ticket routing, agent-assist summarisation and knowledge retrieval all live here. This tier is where the best-evidenced returns are, and it is systematically under-invested because it produces no demo moment.

The strongest evidence in the field for tier-one value is a field experiment, not a vendor case study. Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied the staggered rollout of a generative AI conversational assistant across 5,172 customer support agents and found access to AI assistance raised productivity — issues resolved per hour — by 15% on average, with the gains concentrated among newer staff: less-experienced and lower-skilled workers resolved roughly 30% more issues per hour, while the most experienced agents saw small speed gains and small quality declines (Brynjolfsson, Li and Raymond, "Generative AI at Work", published in the Quarterly Journal of Economics in 2025). The same study found customers were more polite and less likely to escalate to a manager.

Read that finding carefully, because it is usually cited as proof that AI replaces agents. It shows the opposite. The measured gain came from an assistant sitting behind a human who remained in the loop, and it was largest for the people a support organisation normally loses fastest, the new hires in their first months. Tier-one automation is a ramp-time intervention as much as a cost one.

What belongs in tier one, ranked by how safe it is to ship:

  • Classification and triage. Intent, product area, urgency, language. A wrong label costs a re-route.
  • Automated ticket routing. Skills-based assignment, load balancing, priority escalation on SLA risk. Same failure mode: a queue hop.
  • Summarisation for the agent. Conversation history, prior tickets, account state condensed before the agent opens the ticket. Never shown to the customer, so a hallucinated summary is caught by the person reading it.
  • Retrieval against a self-service knowledge base. Surfacing the right article to the agent, again with a human between the retrieval and the customer.
  • Sentiment analysis for prioritisation. Useful for queue ordering. Treat its outputs as a hint, not a fact about a person's emotional state, and be careful about storing an inferred emotional profile against a named customer.

The one control tier one genuinely needs is read scoping. An automation that answers order questions should be able to read orders, not payment instruments; a billing assistant should see invoice history, not support transcripts from an unrelated dispute. The default in most integrations is a service account with far wider access than the task requires, because that is the fastest path to a working demo. The Consumer Financial Protection Bureau flagged exactly this class of risk when it examined chatbots in banking, warning that institutions "risk violating legal obligations, eroding customer trust, and causing consumer harm when deploying chatbot technology" (CFPB issue spotlight, 6 June 2023). That report is now three years old and remains the most detailed regulator-authored examination of consumer-facing support bots in US financial services; its adoption figure, roughly 37% of the US population had interacted with a bank's chatbot in 2022, with all ten of the largest commercial banks using one — has certainly risen since.

There is a second, quieter tier-one risk: the customer pastes something into the chat that you did not want to hold. Card numbers, government IDs, health details, a photo of a document. Once it is in the transcript it is in your retention regime, your subject-access responses and your breach scope. Masking sensitive strings before they reach the model or the ticket store is a tier-one control, which is why we treat inline data-loss prevention at the gateway as part of the intake design rather than a later hardening step.

Tier Two: Say — Where Words Become Commitments

Tier two is the moment automated customer service stops being an internal efficiency and becomes an external representation. When an AI chatbot states a policy, a price, an eligibility rule or a timeline, that statement can bind the company. This is settled, not speculative.

In Moffatt v. Air Canada, decided by British Columbia's Civil Resolution Tribunal on 14 February 2024, a passenger booked flights after the airline's website chatbot told him he could apply retroactively for a bereavement fare within 90 days. The airline's actual published policy said the opposite. Air Canada argued it could not be held liable for what the chatbot said. The tribunal member's response is the most quoted line in the decision — the submission was "remarkable", and it "makes no difference whether the information comes from a static page or a chatbot". The tribunal found negligent misrepresentation and ordered the airline to pay $812.02 in damages and fees (Civil Resolution Tribunal, 2024 BCCRT 149).

The damages are trivial. The finding is not. Three parts of the reasoning matter for anyone designing tier-two automation:

  1. The company owns everything on its own surface. A chatbot is part of the website. There is no separate legal entity to blame.
  2. A link to the correct policy did not cure the wrong answer. The chatbot's reply had hyperlinked the accurate bereavement travel page. The tribunal asked why customers should have to double-check one part of a website against another.
  3. Reliance was found reasonable. The customer had no way of knowing which part of the site was authoritative.

That third point is what makes tier two structurally different from tier one. A misrouted ticket is invisible to the customer. A wrong policy statement is acted on by the customer, and the remedy is measured by what the reliance cost them.

Design rules for the Say tier:

  • Ground every policy-bearing answer in a versioned source, and log which version answered. If the refund window changes on 1 March, you need to be able to reconstruct what the automation was telling customers on 28 February. This is the single most commonly missing capability we see discussed, and it is not a model problem. It is a record-keeping one.
  • Separate answerable from quotable. "Our returns window is 30 days" is a policy statement. "Your specific order is outside the window" is an eligibility determination about a named customer. The second deserves a tighter gate than the first, because it is the one people escalate.
  • Never let the automation invent a remedy. Discretionary goodwill (a credit, an exception, a waived fee) is a tier-three action even when it is only being offered in words, because an offer creates the expectation and the dispute.
  • Write the disclosure in. From 2 August 2026, Article 50 of the EU AI Act requires providers to ensure that AI systems intended to interact directly with people inform them they are interacting with an AI system, unless that is obvious to a reasonably well-informed observer (EU AI Act, Article 50). That date is days away as this is published. A small, permanent, unmissable label costs nothing and removes an argument.

The regulatory direction is not subtle, and Gartner expects it to reshape volume rather than just paperwork: it forecasts that by 2028, regulatory changes related to AI will increase assisted service volume by 30%, as customers exercise a right to opt out of AI and request a human by default (Gartner, 26 January 2026). A support model whose economics depend on customers not asking for a person is a fragile one.

Tier Three: Do — The Money-Moving Tier

Tier three is where the automation changes something outside the conversation: issues a refund, cancels a subscription, edits an order, changes an address, resets access, applies a credit. This is the tier customers actually want automated. The Hacker News complaint that opens this article is a customer angry that the bot could not do the thing — and it is the tier where an ungated deployment is indefensible.

The security objection is well put by engineer Sean Goedecke, writing about which AI products work: give a support chatbot real refund powers and "thousands of people will immediately find the right way to jailbreak your chatbot into giving them money" (Goedecke, 16 November 2025). He is right about the threat and, we think, wrong about the conclusion he draws from it, which is that the tier is simply off-limits. The problem is not that the automation acts. The problem is that the action is authorised by a conversation.

Prompt injection is not a solved problem and will not be solved by better instructions, because the attacker controls the input channel by design — customer service is the one system whose entire purpose is accepting untrusted text from strangers. So the control has to sit outside the model. Three patterns work, in rough order of how much autonomy they concede:

PatternHow it worksBest forThe trade
Bounded actionThe automation may execute, but only inside hard limits it cannot argue its way past: value cap, frequency cap, eligibility precondition checked by codeHigh-volume, low-value, reversible actions — a $15 shipping refund on a delivered-late orderFast, but you must accept the capped loss as a cost of doing business
Prepared action with approvalThe automation assembles the action, states the reason, and a named human approves or rejects in one clickAnything discretionary, or above the capAdds latency and a human step; removes the entire jailbreak class
Draft onlyThe automation drafts; the agent performs the action in the system of recordLegally sensitive, regulated, or irreversible changesSlowest, highest assurance

The design question is not "can we trust the model" but "what is the loss if this action fires wrongly a hundred times before anyone notices". Bounded action with a value cap converts an unbounded risk into a budgeted one — the same reasoning we set out in our earlier analysis of when approval is real control rather than theatre, where the distinguishing test is whether the approver sees enough context to say no.

Two things that are not tier-three controls, despite being sold as them. A confidence threshold is not a control; it is a filter that a determined adversary is optimising against. And a post-hoc review sample is not a control either. Reviewing 2% of executed refunds next week tells you the size of a loss you have already taken. Both are useful diagnostics. Neither prevents the action.

What to do when your helpdesk vendor will not give you action-level scopes. This is the most common practical blocker, and it has a workable answer. Do not point the automation at the vendor's write API at all. Put your own thin endpoint in front of it, one endpoint per action class, each enforcing its own precondition and cap, and give the automation credentials for that endpoint only. You now own the gate even though you do not own the platform, and you get an action log the vendor does not have to provide. It is a week of engineering rather than a procurement fight, and it survives you changing helpdesk vendors.

What "irreversible" actually covers. Teams usually classify refunds correctly and then misclassify everything else. An address change on a physical order is irreversible once the parcel ships. A subscription cancellation on the last day of a billing period cannot be undone without a re-bill. A password or MFA reset performed for the wrong person is a full account compromise, and it is the classic target of social engineering, which an automated agent is worse at resisting than a trained human, because the human has an instinct that something feels off, and the model has a policy document.

The One-Sitting Diagnostic: Score Your Top 20 Contact Reasons

You can place every contact reason on the ladder in about ninety minutes, with a spreadsheet and someone who knows the support queue. This is the practical output of the model, and it replaces the usual scoping exercise where a vendor demos a chatbot and everyone argues about tone.

Step 1 — Pull your top 20 contact reasons by volume. Any helpdesk reports this. Twenty is a working number, not a rule: take enough reasons to cover roughly three-quarters of your volume, and if your tail is unusually long, take the top 30 and expect two sessions rather than one.

Step 2 — For each reason, answer four questions. Yes/no, no discussion, no "it depends":

  1. Does resolving this require reading anything beyond the ticket text?
  2. Does resolving this require stating a policy, price, eligibility or timeline?
  3. Does resolving this change money or account state?
  4. If we did it wrong 100 times before noticing, what would that cost: under $1,000, under $50,000, or unbounded?

Step 3 — Assign the tier. Question 3 yes means tier three. Question 2 yes and question 3 no means tier two. Only question 1 means tier one.

Step 4 — Assign the gate from the tier, and the cap from question 4. Tier one gets a read scope. Tier two gets a versioned source and a policy-version log. Tier three gets a value cap, an approver, or draft-only status depending on the answer to question 4.

Step 5 — Sequence by volume within tier, not across tiers. Ship every tier-one automation before the first tier-two one. This is the step teams skip, and skipping it is why so many pilots produce a fluent bot sitting on top of unscoped access.

Step 6 — Write down the four numbers you will judge it on, before launch. Deflection is the metric vendors report and the one that flatters everybody, because a customer who gave up is counted as deflected. Baseline these four instead, per contact reason, for the month before you switch anything on:

MetricWhy it beats deflectionWatch for
Containment with no repeat contact in 7 daysCounts problems solved, not conversations endedA rise here alongside falling CSAT means customers are giving up
First contact resolution, human and automated separatelyShows whether the automation is taking the easy work or the whole jobHuman FCR falling means you fed the queue only the hard residue
CSAT split by resolution pathThe Klarna failure mode shows up here firstAutomated CSAT above human CSAT usually means easy-case skew, not superiority
Escalation handle timeThe 85% of cost that automation does not removeLonger human handles are expected; sharply longer means poor context handoff

Response time and 24/7 availability are worth tracking too, but they are the metrics automation improves almost automatically, so they tell you least about whether it is working.

Here is the diagnostic filled in for a plausible mid-market e-commerce queue. The volumes are illustrative and the tiering is the point:

Contact reasonShare of volumeTierGateCap
Where is my order22%ReadOrder records only, no payment datan/a
Return policy question11%SayVersioned policy source, version loggedn/a
Am I eligible for a return9%SayEligibility computed by code, not stated by the modeln/a
Shipping delay refund under $258%DoBounded action, precondition: carrier scan shows late$25, 1 per order
Cancel my subscription7%DoBounded action, reversible within the period1 per account per month
Change delivery address6%DoPrepared action, approval if parcel has shippedn/a
Refund over $25 or goodwill credit5%DoPrepared action with named approverApprover's own limit
Password or account access reset4%DoDraft only, identity verification by a humann/a
Complaint about damage or injury3%SayRoute to human immediately, no automated responsen/a
Everything else25%MixedRoute to human, revisit next quartern/a

Two observations from filling this in. The read tier alone carries 22% of this queue's volume and is genuinely safe, and the read and say tiers together carry 42% before a single action is delegated. That is the shape of the opportunity: most of the achievable containment sits below the tier where anything can be spent. And the reasons customers find most infuriating to have automated badly (complaints, access resets, injury) cluster at the bottom, in low volume, which is exactly why they are so often left in scope by accident: they are too small to show up in the business case and too damaging to get wrong.

Below is a recorded conference session on agentic customer experience, useful if you want to see how a large platform vendor frames the same intake-to-action pipeline before you apply the tiering to your own queue.

Play video

What Customer Service Automation Actually Costs Per Conversation

Published list prices for AI support agents in mid-2026 sit between about $0.10 per action and $2.00 per conversation, and the automation licence is rarely the dominant cost. The escalation queue behind it is. Here are the real numbers, fetched from vendor pricing pages on 30 July 2026.

VendorUnitList priceWhat the unit means
Intercom (Fin)Per outcomeFrom $0.99Charged per resolved outcome; seats from $29/seat/month on the Essential plan (currently offered at $19)
Salesforce AgentforcePer conversation$2.00A 24-hour session between a customer and the agent
Salesforce AgentforcePer action$0.10 (20 Flex Credits)Credits sold at $500 per 100,000; voice actions cost 30 credits
ZendeskPer automated resolutionUsage-based, quotedBilled only where the AI agent resolved the request "without any escalation to a human agent"
ZendeskPer seat$19 (Support Team), $55 (Suite Team), $115 (Suite Professional), all per agent/month billed yearlyApproval workflows and custom agent roles sit in the Enterprise tier, quoted on request

Three things worth noticing before you model anything. Outcome-based and conversation-based pricing are not comparable units — a conversation that takes six actions costs $0.60 under Salesforce's credit model and $2.00 under its conversation model, and Salesforce states the two models cannot run in the same org. Zendesk's definition of an automated resolution is the most honest unit in the market precisely because it excludes escalations, which means the vendor bears the cost of a failed containment rather than you. And the governance features — approval workflows, custom agent roles — sit in the top tier at every vendor we priced, which is a budgeting fact worth surfacing early: the controls this article argues for are usually an upgrade, not an included feature.

A worked cost model. Assume 10,000 contacts a month and a 45% containment rate — the automation fully resolves 4,500, and 5,500 reach a person. For the human side we use the US Bureau of Labor Statistics figure for customer service representatives: median pay of $42,830 a year, or $20.59 an hour, as of May 2024 (BLS Occupational Outlook Handbook). Two assumptions are ours and are stated rather than measured: a 1.3× loading factor for benefits, tooling and management overhead, and six handled contacts per agent hour.

LineCalculationMonthly cost
Automated resolutions4,500 × $0.99$4,455
Loaded agent cost per hour$20.59 × 1.3$26.77
Human cost per contact$26.77 ÷ 6 contacts per hour$4.46
Escalated contacts5,500 × $4.46$24,530
Blended total$28,985
Blended cost per contact$28,985 ÷ 10,000$2.90
All-human baseline10,000 × $4.46$44,600 ($4.46 per contact)
Saving35%

The headline is a 35% reduction. The more useful number is that escalation labour is $24,530 of the $28,985. 85% of the automated model's cost is the queue behind the automation. Every conversation about improving support economics that focuses on the licence price is arguing about 15% of the bill.

Now vary the one input everybody guesses at:

Containment rateAutomation costEscalation costTotalCost per contactSaving vs all-human
30%$2,970$31,220$34,190$3.4223%
45%$4,455$24,530$28,985$2.9035%
60%$5,940$17,840$23,780$2.3847%
75%$7,425$11,150$18,575$1.8658%

What this model deliberately leaves out. Three one-off costs sit outside the per-contact numbers, and all three are real. Getting policy content into a versioned, authoritative source is a content project, usually the longest pole. Integration and access scoping is engineering time. And the plan upgrade that unlocks approval workflows is a line item at every vendor we priced, quoted rather than published, so put it in the RFP rather than discovering it after the pilot. A 35% run-rate saving with a six-month implementation is a different proposition from a 35% saving that starts in week three, and only you know which one you are buying.

Containment is the whole business case, which is why vendor claims about it deserve more scrutiny than claims about anything else. And containment is precisely what the tiering exercise governs: if 40% of your volume is tier one and you ship only tier one, you have most of the 45% row without touching anything that can commit or spend.

The currency check that changes the conclusion. In March 2025, Gartner predicted that by 2029 agentic AI would autonomously resolve 80% of common customer service issues without human intervention, cutting operational costs 30% (Gartner, 5 March 2025). Ten months later the same firm published a materially different forecast: by 2030, cost per resolution for generative AI will exceed $3 — higher than many B2C offshore human agents — driven by data centre costs, AI vendors pivoting from subsidised growth to profitability, and more complex use cases consuming more tokens. Gartner's Patrick Quinlan put it plainly: "Full automation will be prohibitively expensive for most organizations" (Gartner, 26 January 2026).

That reversal, from the same analyst house inside a single year, is the most important thing in this section. Anyone building a five-year business case on today's per-resolution price is extrapolating from a subsidised market. Model the sensitivity. At $3.00 per automated resolution instead of $0.99, the 45% containment scenario costs $13,500 plus $24,530, or $38,030 — $3.80 per contact. That is still cheaper than the all-human baseline of $4.46, but the saving collapses from 35% to 15%, and it is worse than what a 30% containment rate delivers at today's prices. A business case with that little headroom does not survive a pricing round.

Where the Human Queue Still Wins

The honest answer to "should we automate this" is no more often than the market admits, and the best-documented reversal in the category is worth reading in full rather than in headline form.

In February 2024, Klarna announced that its OpenAI-powered assistant had handled 2.3 million conversations in its first month — two-thirds of its customer service chats, "equivalent to the work of 700 full-time agents" — with a 25% drop in repeat inquiries, resolution times down from 11 minutes to under 2, and an estimated $40 million profit improvement for 2024 (Klarna press release, 27 February 2024). That press release became the single most cited artifact in support-automation marketing, and it is usually cited without the sequel.

By May 2025, CEO Sebastian Siemiatkowski was rebuilding human capacity, telling CX Dive that "really investing in the quality of the human support is the way of the future for us" and that it was critical to be clear to the customer "that there will be always a human if you want" (CX Dive, 9 May 2025). Klarna did not abandon the assistant. It stopped treating cost per contact as the objective function.

Both halves of that story are true simultaneously, and the lesson is not "AI support does not work". It is that containment and satisfaction are different metrics that trade against each other past a certain point, and that the point is discoverable only after you have deployed.

Contact types where a human queue still beats automation outright:

  • Anything with a distressed customer. Bereavement, fraud, medical, safety. The Air Canada case is, at its heart, a bereaved customer being given wrong information by software at the worst possible moment.
  • Anything where the customer is exercising a right. Disputes, chargebacks, data-subject requests, complaints escalating to a regulator. The CFPB specifically flagged chatbots failing to recognise when a consumer is invoking a right, because they match on words rather than intent.
  • Anything genuinely novel. The Brynjolfsson study found AI's gains were largest on relatively rare problems for human agents who lacked training on them. That is not the same as the automation handling novelty alone.
  • Anything where the customer has already failed once. A second contact on the same issue should route to a person by default. Repeat-contact routing is the cheapest satisfaction intervention available and almost nobody implements it.
  • High-value or long-tenure accounts, where the lifetime value of the relationship exceeds any plausible handling-cost saving by three orders of magnitude.

There is also a structural objection worth taking seriously. On Hacker News in June 2026, a commenter asked why an AI agent is needed to reach self-service at all: without a human at the other end, "I've basically relegated to solving the issue myself", and a refund could be done "with just a form" (mrweasel, Hacker News). For a large class of tier-three actions this is simply correct. A self-service refund form with clear eligibility rules is cheaper, more predictable, more accessible and less jailbreakable than a conversational agent doing the same job. Before you build a tier-three automation, check whether the honest answer is a button.

And the labour picture is not a story of automation quietly absorbing the work. BLS counts 2,814,000 customer service representative jobs in 2024 and projects a 5% decline to 2034, a fall of 153,700 positions. That is a real contraction, and it is nothing like the disappearance the 2024 press cycle implied.

The Governance Layer You Need Before Launch, Not After

Everything above resolves to four questions that are not about the model at all: who owns this automation, what can it reach, what did it do, and what did it cost. That layer is what we build at LeapForce, and it is the one honest connection between our product and this topic. We do not sell a support desk, a chatbot, or a customer service platform, and nothing here should be read as a recommendation to replace one.

Four controls carry most of the weight, and each maps to a tier:

  • Identity for the automation itself. A support agent that acts is a non-human identity with an owner, a scope and an expiry — not a shared API key in an integration config. When the person who built it leaves, ownership has to survive. We covered the mechanics in our analysis of owner, scope and expiry for AI agents.
  • Action-level scoping on connectors. Tier one needs read scopes narrower than the integration's defaults; tier three needs the refund action separable from the read-orders action. Scoping at the level of the action rather than the system is what makes a value cap enforceable (Connectors).
  • Human approval as a workflow step. The prepared-action pattern only works if approval is a real gate with real context, not a notification. That is a workflow property, not a model setting (Workflows).
  • An audit record that includes refusals. For a tribunal, a regulator or an internal post-mortem, the useful record is what the automation said, under which policy version, and what it was stopped from doing. Recording refusals as well as executions is what makes the log evidence rather than telemetry (Observability & Audit).

Our rollout model for the gateway that fronts these controls is "Observe first. Enforce second. Optimize third." Point traffic through in observe mode until you know what is actually happening, then turn on rules, then tune cost. Applied to support automation, observe-first means running the tiering diagnostic against your real queue and logging what the automation would have done for a fortnight before it is allowed to do anything. Per our published build-status convention, some of these capabilities are live today and others are in development or on the roadmap; the status labels on each product page are the authoritative source, not this article.

What We Would Still Get Wrong

The Read-Say-Do ladder is a design heuristic, not a proof, and there are places it is thin.

The Say/Do line is blurrier than the table suggests. An automation that tells a customer "I've submitted your refund request" has said something and started something. We class the offer as tier three when it creates an expectation, but reasonable people draw that line elsewhere, and in a live queue the distinction requires judgement calls the model cannot make for you.

We have not measured containment ourselves. The 45% figure in the cost model is a plausible mid-point chosen to make the sensitivity table legible, not a benchmark. Published containment claims range widely and are rarely comparable, because vendors count resolutions differently. Zendesk's exclusion of escalated contacts is stricter than most. Treat any single containment number, including ours, as an input to vary rather than a fact.

The cost model's two assumptions are contestable. A 1.3× loading factor is conservative for a US in-house team with benefits and low for one with heavy QA and management overhead; six contacts per agent hour is reasonable for chat and wrong for voice. Swap both for your own numbers before quoting the 35%.

The legal position is jurisdiction-specific. Moffatt is a British Columbia small-claims tribunal decision, not binding precedent in most places readers will be operating. Its reasoning has been widely discussed because it is intuitive, not because it is authoritative everywhere. Take local advice before relying on it either way.

We could not reach every source a reader might expect. Reddit's support-leadership communities and several vendor-published containment benchmarks were unreachable or unverifiable during this research, so they are excluded rather than paraphrased. Gartner, BLS and CFPB pages all required a fallback fetch route; their figures here were read from the live pages on 30 July 2026.

The biggest open question is pricing direction. If Gartner's January 2026 forecast is right and per-resolution costs rise past $3, the cost case for tier-three automation weakens sharply while the case for tier one, which is mostly classification and retrieval, the cheapest operations in the stack, barely moves. That would be an argument for exactly the sequencing this article recommends, but we would rather say plainly that we do not know how vendor pricing resolves than pretend the tiering was derived from it.

 FAQ

Frequently asked questions

No, and the best-documented attempt to do so was partially reversed. Klarna reported its AI assistant doing work equivalent to 700 full-time agents in early 2024, then rebuilt human capacity through 2025 after quality fell, with its CEO saying customers must always be able to reach a person. Automation reliably absorbs volume in the read tier and reliably fails on distress, disputes and novelty. Plan for a smaller, more senior queue handling harder work, not an empty one.

Published list prices in mid-2026 run from about $0.10 per action to $2.00 per conversation: Intercom charges from $0.99 per Fin outcome, Salesforce Agentforce lists $2 per conversation or $0.10 per action via Flex Credits, and Zendesk bills per automated resolution excluding escalations. But at a 45% containment rate the licence is roughly 15% of the true cost per contact. The escalation queue behind the automation is the other 85%. Model the queue before you negotiate the licence.

Everything in the read tier: intent classification, automated ticket routing, agent-assist summarisation and knowledge retrieval. These touch no money and make no statements to the customer, and in the illustrative queue in this article they cover 22% of volume on their own. They also produce the best-evidenced gain in the field. A study of 5,172 support agents found 15% more issues resolved per hour with AI assistance, rising to about 30% for less-experienced staff. Ship all of it before your first customer-facing AI chatbot.

It already has. In Moffatt v. Air Canada (2024 BCCRT 149), a tribunal held the airline liable for negligent misrepresentation after its chatbot described a bereavement-fare policy that did not exist, rejecting the argument that the chatbot was responsible for itself and noting it makes no difference whether information comes from a static page or a chatbot. A correct policy page linked inside the wrong answer did not cure it. Treat every policy-bearing sentence your automation emits as a company statement, and log which policy version produced it.

In the EU, yes, from 2 August 2026. Article 50 of the EU AI Act requires providers to ensure people interacting directly with an AI system are informed of that fact, unless it would be obvious to a reasonably well-informed observer. Outside the EU the rules vary by jurisdiction and sector, but the disclosure is close to costless and removes an entire category of complaint, so there is little reason to omit it anywhere.

Under a hard cap, yes; on its own judgement, no. Bounded action works where the amount is small, the precondition is checked by code rather than asserted by the model, and the loss from a hundred wrong firings is a number you have agreed to accept. A $25 shipping refund where the carrier scan already shows a late delivery, for example. Anything discretionary, anything above the cap, and anything irreversible should be prepared by the automation and approved by a named person.

You do not stop it in the prompt — customer service is the one system whose purpose is accepting untrusted text from strangers, so the attacker always controls the input. Put the control outside the model: value caps enforced in code, preconditions verified against systems of record, action-level scopes so the agent that reads orders cannot call the refund API at all, and a named approver for anything discretionary. A confidence threshold is not a control, because a manipulated model is confidently wrong.

Nobody can honestly give you a number, because vendors count resolutions differently and the answer depends almost entirely on the mix of your top 20 contact reasons. What you can do is bound it before buying: run the tiering diagnostic, add up the volume share of your read-tier reasons, and treat that as the floor you can reach without exposing anything that commits or spends. In the illustrative e-commerce queue in this article that floor is about 22%, and the safe ceiling before tier-three actions is around 42%.

The tiering diagnostic itself takes about ninety minutes. Read-tier automation is usually live within weeks because it needs integration work rather than policy decisions. The say tier is gated by something slower than technology: getting your policy content into a versioned, authoritative source that the automation can be grounded in, which in most organisations is a content project nobody has budgeted. The do tier is gated by approval design and, at most vendors, by an upgrade to the plan tier that includes approval workflows.

Usually because the pilot proved the wrong thing. A demo proves the automation can hold a conversation; rollout requires proving it cannot do damage, which needs access scoping, policy versioning, approval routing and an audit record that nobody built during the pilot. Run the observe phase first. Log what the automation would have said and done against real tickets for a fortnight without letting it act — and the rollout conversation becomes an evidence review rather than an argument.

For the read tier, yes: routing, triage and knowledge retrieval scale down cleanly and the per-outcome pricing models mean low volume costs little. For the do tier, small businesses face the same jailbreak and misstatement risk as large ones with far less capacity to absorb a bad month, and the approval workflows that contain that risk sit in higher plan tiers. The pragmatic small-business shape is aggressive tier-one automation, a small number of tightly capped tier-three actions, and a visible path to a human.

Six fields make later reconstruction possible: the full transcript, the identity of the automation and its version, the policy or knowledge source version that grounded each answer, every action attempted, every action refused and why, and the human approver where one was involved. The refusal log is the one most teams omit and the one that proves the control existed. Without the policy version you cannot answer the only question that matters after a Moffatt-style complaint: what were we telling customers that week?

Ready to Govern Your AI?

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

Thirty minutes · No pitch deck

Ready to turn AI experiments into measurable ROI?

Bring one outcome you'd like AI to move. We'll help you scope a pilot you can actually measure — and tell you honestly if it's not worth doing yet.

Comments