In Customer Service, the Failure Mode Isn’t Accuracy. It’s Autonomy.
Ask what a wrong support answer costs and you get an average back: a few minutes, an apology, move on. But the damage is not distributed like an average. A bot that misquotes a delivery window costs one phone call. A bot that confirms a cancellation that never went through, or tells a customer a discontinued part fits their machine, produces a claim, a wrong shipment, or a post with a screenshot in it. Meanwhile the hundred answers it got right earned you nothing, because a fast correct answer is what people already assume they are owed.
So the expected value of autonomy starts negative and turns positive only once you have evidence — not a demo, not a vendor’s benchmark, evidence from your own queue. Which puts the honest answer up front: the model drafts, a human sends, and you stay there until your own tickets tell you to move. That is not timidity. It is the only setup in which being wrong is free.
Draft Mode Is Not Training Wheels — It’s the Only Evidence You’ll Get
Draft-for-agent gets treated as the embarrassing phase you endure before the real product. That is backwards. Every time an agent sends a generated draft unchanged, you have a labelled data point: the machine was right, in production, on a real ticket, judged by someone accountable for the answer. Every time an agent rewrites the second paragraph, you have a labelled correction, and the diff names the failure — a missing fact, a wrong tone, a policy the model has never seen. Six weeks of that, bucketed by category, is a better evaluation set than anything you could commission, and it costs nothing extra: your agents were going to answer those tickets anyway.
The automation decision then stops being a judgement call. You look at the edit rate per category. Order status: agents stopped touching the drafts weeks ago. Warranty scope: they rewrite half of them. So you automate order status and you do not automate warranty, and you can show why. That audit trail seems like paperwork right up until the morning someone asks why a machine told a customer that.
What is hard: draft mode has to be genuinely faster than not using it, or agents quietly ignore the drafts and your evidence is worthless. If the suggestion lands three seconds late, in a second browser tab, or without the order number filled in, agents start from scratch — and you conclude the model is bad when the integration is bad. Putting the draft inside the reply box your agents already live in, in Zendesk or Freshdesk or HubSpot Service Hub, is not a convenience. It is what makes the experiment valid.
Your Bot Is a Mirror of Your Documentation
A support model answering from its own weights is a liability; one answering from your documents is a product. That much is standard: retrieval puts your actual policies, manuals and past resolutions in front of the model and tells it to answer from those. The less standard sentence is the one that follows. Retrieval makes your documentation load-bearing, and most companies’ documentation cannot bear load.
Take an ordinary machine builder: a service FAQ last edited in 2019, a spare-parts list that is genuinely authoritative, and a wiki where a superseded wiring procedure and the current one sit two pages apart, neither dated. Point retrieval at that and the system does exactly what you asked. It finds the 2019 page, answers from it, and cites it. The answer is now wrong and carries a source link — worse than a plainly wrong answer, because the citation is what persuades your own agent to send it unchecked. Grounding does not make a system truthful. It makes it faithful to whatever you point it at, and the mechanism underneath does not care that the document was stale.
No source, no draft
Retrieval failure has to be a first-class outcome, not a quiet fallback into improvisation. If nothing in the corpus answers the ticket, the correct behaviour is to produce no draft and route the ticket to a person — not a helpful-sounding paragraph assembled from general knowledge. This is close to one line of code, and it removes most of the answers that would have embarrassed you, because “the model invented something” and “there was nothing to invent from” are usually the same event.
Curate a small corpus, not a big one
The instinct is to index everything: every PDF on the share drive, the whole wiki, ten years of tickets. Resist it. Forty documents someone owns and keeps current beat four thousand nobody maintains, because in a retrieval system an out-of-date document does not sit there harmlessly — it competes for the answer. Ownership is the recurring cost of a support bot and the line item every calculation forgets: a named person has to be responsible for the return-policy page being right this quarter. If nobody will take that job, AI is not your next problem to solve.
Escalate on Rules, Not on Confidence
The most common escalation design is a confidence threshold: the model rates its own certainty and hands off below some number. I would not build this, and I would argue against it if you asked me to. Language models are poorly calibrated — a fabricated answer and a correct one come out of the same process and can feel equally certain from the inside — so a threshold gates the riskiest decision in the system on the one signal the system is worst at producing.
Escalate on facts you already hold, evaluated before the model generates anything. Category: cancellations, withdrawals under the statutory 14-day right, complaints, anything touching a claim or money moving — never an automated answer, however easy it looks. Language: if your corpus is German and the ticket arrives in Turkish, you do not have a translation feature, you have an untested one. History and tone: a third message in the same thread, or a furious first one, goes to a person — a customer already failed twice is the wrong person to experiment on. Retrieval: no source, no draft.
Two rules are worth knowing by name rather than discovering later. Article 50 of the EU AI Act requires that people be told when they are interacting with an AI system unless that is obvious from context; those transparency obligations start applying on 2 August 2026. Article 22 GDPR gives people the right not to be subject to a decision based solely on automated processing where it has legal or similarly significant effects. Answering “where is my order” is not such a decision. Automatically refusing a goodwill claim is close enough to the line that I would keep it on the human side of the router. Which is the point: routing rules are a compliance artefact, and you cannot show a regulator a confidence score.
Sie, and the Register Nobody Configures
German formality gets treated as a checkbox: set Sie, done. And models do hold Sie reasonably well when you tell them to and show them examples — grammar is not where this goes wrong. It goes wrong one level up, in register.
Picture a regional insurer. A customer writes on day four of an unresolved water-damage claim. The model, shaped by a global corpus of relentlessly cheerful support copy, produces something grammatically flawless, correctly Sie-formed and tonally catastrophic: bright, briskly apologetic in the American register, with a “Vielen Dank für Ihre Geduld!” that reads as mockery to someone standing in a wet basement. Nobody will fault the grammar; everybody will notice the tone. This is a case a severity rule should have removed before generation — the escalation argument arriving from a second direction.
The other tell is provenance. If your prompt was written in English and the German is the model translating its own intent, you get German that is correct and foreign: Anglicisms, sentence rhythms that do not occur in German business correspondence, a reflexive “Wir entschuldigen uns für die Unannehmlichkeiten” where a German service desk would simply say what happens next and when. The fix is unglamorous. Write the prompt in German, and show the model ten replies your best agent actually sent. Ten real replies move tone further than any amount of adjective-stacking in a system prompt.
Measure Deflection Honestly
Deflection rate — the share of conversations that ended without a human — is the metric every vendor reports, and it is corrupted by construction, because it counts giving up as success. A customer who asks twice, gets nothing useful, closes the chat and phones a competitor is a deflection. So is a customer who was genuinely helped. The number cannot distinguish them, which makes it excellent for a slide and useless for a decision.
Measure resolution instead, over a window: of the tickets the bot handled alone, how many were followed within seven days by the same customer coming back — a new ticket, a call, a reply reopening the thread? That is one join between your helpdesk and your phone log, it is much harder to game, and it produces a number your agents will recognise as true.
Two more are worth having. Escalation quality: when a ticket does reach a human, does the agent inherit the context, or does the customer explain everything again? A bot that deflects well but resets every escalated conversation to zero transfers cost onto your angriest customers — the people with the most reason to talk about you in public. And the baseline, recorded before anything is built: median first response, median resolution time, what share of volume is the same five questions. Support is one of the few places AI reliably pays off, but only if you can say afterwards by how much — and “the bot replies in 30 seconds” compares to nothing.
Where Tippel Fits
Most of this article is about what not to do, which is an odd sales pitch, so let me be plain about the shape of the work. A support system worth having is mostly plumbing: drafts inside the tool your agents already use, a router wired to your real ticket categories, a decision about which forty documents are the corpus and who owns them, and the measurement built before the bot. The model is the easy part, and it gets easier every quarter.
The AI Readiness Check is a paid, timeboxed look at exactly that: your real tickets, your real documents, and an honest answer about which categories could be drafted well today and which ones your documentation cannot support yet. It ends in a go/no-go, the fee is credited if you build, and “your knowledge base is not ready” is an allowed outcome. If you would rather talk it through first, get in touch.