Deflection is not the goal. Answering the right questions well is the goal, and deflection is what happens when you do. Ten real examples below — labelled by which kind of tool actually does each one, including the ones we do not — then the four bands of ticket that decide what is safe to automate at all.
Half of these are not our job, and they are marked as such. A survey that only listed what we happen to sell would not be much of a survey.
A visitor asks about delivery, returns, pricing or setup and gets the answer from your own pages, at 2am, without a ticket existing.
Typically handled by: A docs-trained assistant
“Where is my order”, “is this in stock”, “when does my subscription renew” — answered live by calling your own systems mid-conversation.
Typically handled by: An assistant with API tools
Answering the pre-sales question first, then collecting contact details in the conversation with the transcript attached.
Typically handled by: A chat assistant with lead capture
The bot recognises it is out of its depth, hands over, and the person picking it up can read what was already asked.
Typically handled by: A chat assistant with handover
Every question the assistant could not answer becomes a list. That list is the most valuable output of the whole exercise and almost nobody reads it.
Typically handled by: Chat analytics
Incoming tickets classified by topic, urgency or language and assigned to the right queue or agent automatically.
Typically handled by: A helpdesk or ticketing system
Agents inserting an approved answer in two keystrokes instead of retyping it, with variables filled in.
Typically handled by: A helpdesk
Automatic “we have got this” emails, SLA warnings and follow-ups so nobody is left wondering whether the message arrived.
Typically handled by: A helpdesk or email automation
Routing or resolving calls before they reach a person, and pushing simple requests to self-service.
Typically handled by: A contact-centre platform
Asking how it went once a conversation closes, and collecting the score somewhere you will actually look at it.
Typically handled by: A helpdesk or survey tool
Most teams end up running two tools: something that answers questions on the website, and a helpdesk that manages the queue behind it. They are different jobs and the products that do them well are rarely the same product.
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.
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.
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.
Automating this band is where support automation earns its bad reputation. The assistant should recognise it, say so, and hand over cleanly.
These are the conversations worth a person’s full attention — which is exactly what you buy back by automating bands 1 and 2.
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.
How retrieval worksWrite the refusals explicitly in the system prompt and keep handover on. An assistant that knows what it must not decide is more useful, not less.
Configuring handoverRead 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.
The metrics that matterAnyone 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.
Support automation has a poor reputation for reasons that are entirely avoidable. All four of these are decisions, not limitations of the technology.
One badly handled complaint costs more goodwill than a hundred correctly answered delivery questions earn. Keep band 3 human.
If a customer cannot reach a person, they will find your Twitter account instead. Always show the route.
Optimising for “fewer tickets” eventually means optimising for “harder to reach us”. Measure resolution and the unanswered-question list instead.
The value compounds through the weekly loop of reading gaps and writing content. An assistant nobody reviews plateaus in week three.
Customer service automation is using software to handle support tasks that would otherwise take a person — answering repeat questions, looking up an order, routing a ticket to the right queue, acknowledging a message, surveying after resolution. It is not one product. In practice most teams end up with two or three tools covering different parts of it, because the thing that answers website questions well is rarely the same thing that routes email.
The common ones are instant answers to published questions, live order and account lookups, lead capture inside a conversation, escalation to a human with context attached, ticket routing and triage, canned responses and macros, automatic acknowledgements and follow-ups, phone deflection through IVR, proactive messages, and post-resolution satisfaction surveys. The ten above are set out with a note on which kind of tool actually does each one — several of them are a helpdesk’s job rather than a chat assistant’s.
No, and the teams that try tend to undo it. Published facts and account lookups automate well. Judgement calls, complaints and anything genuinely novel do not — not because the technology cannot produce a reply, but because a confident wrong answer on a refund dispute costs more than the ticket ever would have. The realistic goal is that automation absorbs the repetitive volume so your people have time for the conversations that actually need them.
Anything where being wrong is expensive or upsetting: refunds outside policy, complaints, contract and legal questions, account security, anything involving a distressed customer, and any situation with no precedent. A good rule is that if you would want a named person accountable for the answer, it should not be automated. The four bands further up this page are a more complete version of that test.
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.
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.
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.
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.
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.
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.
Train an assistant on the page that answers your most-asked question, and see whether it gets it right. Everything else follows from that.
Start free