How to Cut Repeat Support Questions With an AI Chatbot
A support inbox answers a small number of question types repeatedly, and a long tail of one-offs. A chatbot handles the repeats well and the one-offs badly, so this guide is about identifying the repeats and moving them.
Time: a morning to audit, an afternoon to build. You need: Starter or above, and access to your support inbox.
1. Count the Questions Before You Build Anything#
Open the last hundred support conversations and tally what they were about. Write the list in the customer's words, not yours. "Where is my order" is the question; "order status enquiry" is a category name that will not help you write anything.
Keep the tally. Step 7 is the same tally taken again, and it is the only way to tell whether any of this worked.
2. Sort Them Into Three Piles#
| Pile | Handled by | Example |
|---|---|---|
| Answerable from what you already know | Knowledge base | "Do you deliver to Polokwane?" |
| Needs a live lookup | A workflow with an API call | "Where is my order?" |
| Needs judgement | A person, with a lead captured | "This arrived damaged, what now?" |
Classify the third pile strictly. A bot that tries to resolve a damaged delivery makes the customer angrier before they reach a person. Capture the details and hand over.
3. Write the First Pile as Documents#
Answer each question the way you would in a reply, then put them in the knowledge base grouped by topic. One document per topic, not one per question.
Use the words customers use. If they ask "can I collect instead", the document should contain the word "collect", not only "in-store pickup".
Write these as facts. Behavioural instructions such as "always apologise first" belong in the bot's personality setting. See knowledge is not instructions.
4. Build a Workflow for the Second Pile#
Order status is the usual first one.
| Node | Configuration |
|---|---|
| Trigger | Already on the canvas. |
| Form | order_number, email. |
| API Request | GET your order endpoint by order number. |
| Decision | Was the order found? |
| Message (true) | The status and expected date. |
| Message (false) | Say it could not be found, and offer to have someone check. |
Description:
Looks up the current status and expected delivery date of an existing order
using the customer's order number.
USE WHEN the customer asks where their order is, when it will arrive, or for
tracking on an order they have already placed.
DO NOT USE for questions about delivery times before ordering. Answer those
from the knowledge base.5. Collect What a Person Will Need#
For the third pile, the bot's job is to collect what a person needs and set an expectation:
- The order number or account reference.
- What happened, in the customer's words.
- A photo, where it helps. A Form node takes uploads up to 10 MB.
- When someone will reply.
That last one is what stops a second message asking whether anyone saw the first.
6. Put the Bot Where the Questions Arrive#
Support questions come from people who already bought, so put the widget on the pages they visit after buying: order confirmation, account pages, delivery information, and contact.
On the contact page especially, a Check my order status button that opens the chat with "Where is my order?" already sent catches people mid-email. The copyable button is on web controls.
7. Measure Whether It Worked#
Take the tally from step 1 again a month later. Two numbers matter:
- Support volume by question type. Did the types you moved go down? A total that has not moved while the mix has changed is still progress, because the team is answering harder questions.
- The execution log. Which workflows ran, and where runs stopped. Runs stopping at an API node point at a broken integration rather than a bot that cannot answer.
If a question type did not drop, the answer is usually in the knowledge base and phrased in your words rather than the customer's.
Common Questions#
How Much Support Volume Can a Chatbot Actually Deflect?#
The share made up of repeat, answerable questions, which is the number step 1 measures. Questions needing judgement or an apology should be routed to a person instead.
Will Customers Be Annoyed by a Bot?#
They are annoyed by a bot that will not let them reach a person. A bot that answers the easy question immediately, and captures details for the hard one with a clear "someone will reply today", tests better than a contact form.
Should the Bot Say It Is a Bot?#
Yes. Saying so up front, with what it can do, sets an expectation that the rest of the conversation can meet.
How Do I Stop the Bot Guessing at Things It Does Not Know?#
Give it the boundary explicitly. Documents cover what you know, workflows cover what needs looking up, and the bot's goal setting says what to do otherwise. An unwritten gap is where a confident wrong answer comes from.
What Should Happen Outside Business Hours?#
The same thing, with a different expectation set. The knowledge base answers at any hour, and the hand-off message should say when a person will reply rather than implying somebody is reading now.