# How to use AI for website customer support: what to automate first

> By Lawrence Dauchy, Founder, DFYe. Published 2026-07-05. 10 min read. Guides.
> Source: https://dfye.com/blog/how-to-use-ai-website-customer-support/
> Language: en

Not a strategy document. The specific questions worth handing over first, how to write the answers it will use, and what the handoff needs to not annoy people.

**TL;DR.** To use AI for website customer support, automate the questions that repeat and whose answers are already published: delivery times, returns, stock and sizing, and order status if it can reach your store. Write those answers as pages first, because retrieval can only find what exists. Then design the handoff before you switch anything on, because the handoff is what customers judge and it is the part that gets a tenth of the attention.

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](https://wordpress.org/plugins/ai-engine/), at **100,000 installs with a 4.9
rating across 864 reviews** on the
[plugin API](https://api.wordpress.org/plugins/info/1.2/), 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](https://gdpr-info.eu/art-22-gdpr/) 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](https://www.w3.org/WAI/standards-guidelines/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](/how-it-works/) and [the features page](/features/).

## 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](https://wordpress.org/plugins/tawkto-live-chat/) 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](/blog/ai-chatbot-website/), and the
interface half is in
[making a widget that fits your site](/blog/ai-widget-website/).

## Quick answers

### 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.

## Sources

- [AI Engine on the WordPress.org plugin directory](https://wordpress.org/plugins/ai-engine/)
- [WordPress.org plugin API, the install and rating figures](https://api.wordpress.org/plugins/info/1.2/)
- [Tawk.to on the WordPress.org plugin directory](https://wordpress.org/plugins/tawkto-live-chat/)
- [GDPR Article 22, automated individual decision-making](https://gdpr-info.eu/art-22-gdpr/)
- [W3C: WCAG, the accessibility standard a support channel has to meet](https://www.w3.org/WAI/standards-guidelines/wcag/)

---
*Published by [DFYe](https://dfye.com/). Free to read, index, quote and cite with attribution and a link.*