Support automation, and the part where you decide what not to automate
Deflection is not the goal. Answering the right questions well is the goal, and deflection is what happens when you do. This is a practical account of which questions those are, how grounded answering actually works, and the four ways teams get it wrong.
Every useful conversation about support automation starts here. Take a hundred recent tickets and put each one in a band; the right strategy falls out of the distribution.
Band 1 — Published facts
Typically the largest band
Opening hours
Delivery times
Refund window
How to change a plan
The answer already exists on a page. A human retyping it is pure waste, and a customer waiting nine hours for it is a bad experience for no reason.
Automate
Band 2 — Account-specific lookups
Second largest in most businesses
Where is my order
Is this in stock
When does my subscription renew
No page can hold the answer because it changes per person and per minute. An API tool lets the assistant read it live rather than guess.
Automate with a tool
Band 3 — Judgement calls
Small but expensive
Refund outside policy
Complaint
Contract question
Anything with a lawyer in it
Automating this band is where support automation earns its bad reputation. The assistant should recognise it, say so, and hand over cleanly.
Escalate
Band 4 — Genuinely novel
Rare, and the reason you have a team
A bug nobody has seen
An unusual integration
A situation with no precedent
These are the conversations worth a person’s full attention — which is exactly what you buy back by automating bands 1 and 2.
Human, always
Three things that make it work
Ground it in your own content
A model without your documentation is a confident stranger. Retrieval puts the relevant passages from your own pages in front of it before it writes, which converts an opinion into a reading.
Read the questions it could not answer, write the missing page, re-train the URL. This is the entire improvement process and it takes about half an hour a week.
Anyone quoting you a precise deflection percentage is quoting someone else's business. Fill this in with your own figures — it takes twenty minutes and it is the only version that means anything.
Questions that are repeat, published factsOften the majority of inbound volume
Time a human spends retyping one of thoseMinutes each, every time, forever
Time an assistant spendsUnder a second, at any hour, in any language
What the freed time is worthThe band 3 and 4 conversations that actually need a person
Four ways this goes wrong
Support automation has a poor reputation for reasons that are entirely avoidable. All four of these are decisions, not limitations of the technology.
01
Automating the judgement calls
One badly handled complaint costs more goodwill than a hundred correctly answered delivery questions earn. Keep band 3 human.
02
Hiding the way out
If a customer cannot reach a person, they will find your Twitter account instead. Always show the route.
03
Treating deflection as the KPI
Optimising for “fewer tickets” eventually means optimising for “harder to reach us”. Measure resolution and the unanswered-question list instead.
04
Launching and walking away
The value compounds through the weekly loop of reading gaps and writing content. An assistant nobody reviews plateaus in week three.
No, and framing it that way leads to bad decisions. It removes the repetitive band of work — the questions your website already answers — so the team spends its time on the conversations where judgement matters. Teams that automate well usually get better at support, not smaller.
How much volume can realistically be deflected?+
It depends almost entirely on how much of your volume is band 1 and band 2, and on how good your documentation is. Rather than trusting a headline percentage from anyone’s marketing, categorise a hundred of your own tickets into the four bands above. That number is your ceiling, and it is specific to you.
What is the first thing to automate?+
The single most-asked question you have. Train on the page that answers it, check the assistant gets it right, and go from there. Starting narrow means you find out quickly whether your content is good enough.
How do I stop it giving wrong answers?+
Ground it in your own content so answers are retrieved rather than recalled, keep answers citing their source so a mistake is traceable, and make it fall back rather than improvise. Most wrong answers turn out to be a wrong or ambiguous page — which is a bug you can fix.
How long before it pays for itself?+
The setup is measured in minutes rather than weeks, so the question is really about volume. If you answer the same forty questions every week, the arithmetic tends to work quickly. If your support is genuinely bespoke every time, it will not — and that is worth knowing before you start.
What about tone and brand?+
The system prompt is yours to write and Q&A pairs let you pin exact wording for the answers that matter most. An assistant that sounds nothing like your company is a prompt problem, not an inherent limitation.
Start with band 1 and one page
Train an assistant on the page that answers your most-asked question, and see whether it gets it right. Everything else follows from that.