To use AI for website customer support, automate the questions that repeat and whose answers are already published, and leave everything else alone. That is usually four things: delivery times, the returns policy, stock and sizing, and order status if the system can reach your store. The free option most people start from is AI Engine, at 100,000 installs with a 4.9 rating across 864 reviews on the plugin API, so the software is rarely the hard part.
The order you do this in decides whether anybody in your company ends up trusting it.
What should you automate first?
The questions you have answered more than ten times this month with the same words. Finding them takes an hour of reading your own inbox and is the only part of this that cannot be skipped.
| Question type | Why it is a good first candidate | What it needs from you |
|---|---|---|
| How long is delivery | Asked constantly, answer never varies | A page with a date, not a range |
| Can I return this | High anxiety, high volume, fixed answer | The window and the process, in one place |
| Is this in stock in my size | Blocks a purchase directly | Stock visible on the variant, or a lookup |
| Where is my order | The classic two-in-the-morning question | A connection to your store |
| When are you open | Trivial, and asked more than you think | One page, kept current |
Do not start from a list like that one. Start from your own inbox, because the shape of your questions is specific to what you sell and the differences matter. A shop selling technical parts gets compatibility questions that no template anticipates; a clothing shop gets sizing. Pull a month, group it, and let the top three groups decide.
The fourth row is the only one needing engineering rather than writing, and it is worth being clear that it is a separate project from the rest.
What should never be automated?
Anything requiring judgement, anything requiring authority, and anything where the customer’s real need is to be heard.
Judgement means questions whose answer depends on circumstances nobody wrote down. Whether this coat is warm enough for a particular trip. Whether this part fits a machine the customer described imprecisely. A retrieval system can quote the specification and cannot weigh it, and the ones that try produce the confident wrongness that gives the category its reputation.
Authority means exceptions. The goodwill gesture, the refund outside the window, the replacement sent before the return arrives. Those moments are why customers come back, and they require somebody allowed to depart from the policy.
And some contacts are not questions. A person writing because a gift arrived broken wants acknowledgement first. Answering that with an accurate summary of the returns procedure is technically correct and reads as contempt.
There is a legal edge too. Letting a system decide something about a person rather than look it up, an automatic refusal or cancellation, moves toward Article 22 territory where solely automated decisions carry extra obligations. Let it prepare the case and let a person press the button.
How do you write the answers it will use?
As pages for humans, with one fact in one place. This is where most of the quality comes from and it gets the least attention because it looks like writing rather than like configuration.
Three rules cover it.
One fact, one place. If your returns window appears on a policy page, a product page and an old blog post, retrieval will find all three and the model will pick one. Which one is not something you control. Search your own site for the phrase that matters most before you index anything; the result is usually uncomfortable.
The question as the heading. A section headed “Returns” retrieves worse than one headed “How long do I have to return something?”, because the second matches the shape of what people actually type. Write headings as questions and the passages underneath them become answers.
Short pages, not one long document. A single enormous FAQ file retrieves badly: a passage cut from the middle of it arrives without the context that made it make sense. Several focused pages beat one long one, every time, and they are better for readers too.
What does the handoff need?
More care than the model does, and it is the part customers judge you on.
| Handoff detail | Done badly | Done well |
|---|---|---|
| The transcript | The customer explains it all again | It arrives with the ticket |
| The route to a person | Hidden after three failures | Visible from the first message |
| Out of hours | “Someone will be right with you” at 2am | “We open at nine, here is what I can tell you now” |
| Who picks it up | An inbox nobody watches | A named person or a queue with an owner |
Row one produces the worst experience this category offers, and it is entirely avoidable. Somebody who has explained their problem to a bot and is then asked to explain it again has been made worse off than if you had no chat at all.
Row two is counterintuitive and worth trusting anyway. Hiding the escape raises your deflection number and lowers the thing that number is a proxy for. People who can see the exit usually do not take it.
Accessibility belongs here as well. If chat becomes your only route in, everybody who cannot use it comfortably is now further away, and a support channel carries the same obligations as the rest of the site under WCAG. Removing the email address because the bot covers most cases has a cost that does not appear in any dashboard.
How do you measure whether it is working?
With two numbers rather than one, because the popular number is misleading on its own.
Deflection counts a conversation as handled when the visitor stops talking, and people stop talking for two opposite reasons: they got what they needed, or they gave up. The figure cannot tell those apart and neither can the dashboard showing it.
Pair it with repeat contacts from the same person within twenty-four hours. That is cheap to collect and very hard to argue with. High deflection with high repeats means the queue moved rather than shrank. Low deflection with low repeats can be perfectly healthy, if the bot is handing over cleanly and people are getting answers.
Then read the conversations. Half an hour a week, twenty chosen at random rather than the escalated ones, because the escalated ones are already visible and the quietly wrong answers are not. Nothing else here matters as much as somebody doing that regularly. What our own version does when it falls below its confidence floor is on how it works and the features page.
Who owns it after launch?
Somebody has to, by name, and this is the question that decides whether the thing is still useful in six months.
A support bot is not a project you finish. It answers from your pages, and your pages go stale: the delivery cutoff changes for Christmas, a courier changes, a returns window is extended for a promotion and never changed back. Each of those makes the bot confidently wrong, silently, and nothing reports it because from the system’s point of view retrieval worked perfectly.
Three habits cover it and none of them is expensive.
Tie the page to the policy. When somebody decides the delivery cutoff moves, the same task includes editing the page. If that sounds obvious, check how your last policy change actually propagated; usually it reached the team and the customer emails and not the website.
Half an hour a week reading conversations. Twenty at random, not the escalated ones. This is where you find the answers that were wrong and unchallenged, and it is the only mechanism that catches drift.
A monthly check of the top five. Ask the five most common questions yourself and confirm the answers are still current. It takes five minutes and it is the cheapest insurance available.
Name the person. A responsibility shared between a marketing manager and whoever happens to notice is a responsibility nobody has, and the failure is invisible right up until a customer quotes your old returns window back at you.
When should you not automate support at all?
Three situations, and the first two are common enough that most small shops fall into one of them.
If you get fewer than roughly ten questions a week, answering them yourself is cheaper, warmer and faster than any setup. You will spend longer configuring than answering, and that stays true for longer than people expect. Human live chat remains a large market for exactly this reason: Tawk.to sits at 100,000 installs.
If your answers are not written down, automating is the wrong next step and writing is the right one. Three pages cover most of what a shop is asked, and writing them improves the site for every visitor who never opens a chat window.
And if your questions are mostly judgement, a shop competing on knowing its catalogue should not automate away the thing customers are paying for. Automate the delivery question so your people have time for the fit question.
For the category as a whole, start with what an AI chatbot for a website actually is, and the interface half is in making a widget that fits your site.
What people ask next
How do I use AI for website customer support?
Start with the questions that repeat and whose answers already exist on your site: delivery times, the returns policy, stock and sizing, and order status if the system can reach your store. Write those four as proper pages first, because retrieval can only find what exists. Then design the handoff to a person before you switch anything on, because that is the part customers actually judge.
Which support questions should I automate first?
The ones you have answered more than ten times this month with the same words. Pull a month of your support inbox and group it; the top three or four groups are your candidates, and they are usually delivery, returns and whether something is in stock or will fit. Automating anything before you have done that grouping is guessing at your own business.
How do I write content for an AI support bot?
As pages for humans, not as a bot script. One fact in one place, stated plainly, with the question as the heading so retrieval can match it. The common mistake is a giant FAQ document containing every answer, which retrieves badly because a passage cut from the middle of it has no context. Short focused pages beat one long one every time.
Will AI support annoy my customers?
It annoys them in three specific ways, all of which are choices: a window that opens by itself over what they were reading, no visible route to a person, and confident answers that turn out to be wrong. None of the three is a property of the technology. Fix them and most of the complaint about chatbots stops applying to yours.
How do I measure whether AI support is working?
Not with deflection rate on its own, because a conversation counts as deflected when somebody stops talking and people stop for two opposite reasons. Pair it with repeat contacts from the same person within a day, which is cheap to get and very hard to argue with. A high deflection rate alongside a high repeat rate means the queue moved rather than shrank.
Can AI answer questions about a specific order?
Only if something connects it to your store, and that connection is a deliberate piece of work rather than a setting. The safe pattern is a lookup in your own code that the system may request by name, so your code decides which order it is allowed to read. That indirection is why a bot can safely report an order status without being able to change one.
