Design the chatbot on paper before you touch a platform. For each of the three flows, write what the customer asks, what facts the bot may use, what it may offer, and the exact moment it hands over to you. Then test it against ten real past tickets before any customer sees it.
The platforms differ and change often, but the design work is the same everywhere and it belongs to the owner, because only you know what you will honour. A bot built around a vendor's default flow will cheerfully promise things your store does not do. The sections below give you the maps, the wording rules, the escalation triggers and the test.
Start from your tickets, not from the tool
Open the last 100 customer messages and sort them. A store with 100 tickets a month might find 38 about order status, 22 about returns and exchanges, 15 about size and fit, 10 about delivery problems, 8 about product questions and 7 about everything else. Those first three groups are your first three flows: they are frequent, mostly repeatable, and the answers live in facts you already hold.
Do not start with the fancy cases. A bot that answers 75 of the 100 messages correctly and hands the rest to you quickly is a success. One that tries to handle all 100 and gets 20 wrong damages trust faster than the 75 correct answers repair it. If you want a library of finished conversations to adapt later, seven store conversations to copy is the companion.
What every flow needs written down
For each flow, fill in the same six fields. A page per flow is plenty.
- Trigger. The kinds of message that start it, in the words customers use ("where is my parcel", "has it shipped").
- Facts the bot may use. Policy text, size chart, carrier names, order data it can look up. Nothing else.
- What it asks. The minimum details needed, in order.
- What it may offer. Information, links, forms. Not money, not exceptions.
- Escalation triggers. The words and situations that end the bot's turn.
- The handover note. What the bot writes for you so the customer does not repeat themselves.
The fifth field is the one that protects you, and it gets its own section further down.

The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowFlow one: order status
This is the easiest flow to build well, and the one customers use most. Its risk is not wrong wording, it is showing order details to the wrong person.
The map
- Customer asks about an order.
- Bot asks for the order number and the email address used at checkout.
- Bot checks both match (through your platform's order lookup, if the chatbot can reach it) before saying anything about the order.
- If they match, bot gives status in plain words: paid, packed, with the carrier, delivered, plus the tracking link and the carrier's own estimate if one exists.
- If they do not match, bot says it cannot find the order with those details and offers a handover. It never says which detail was wrong.
- If the status is "delivered" and the customer says it has not arrived, hand over with a note.
What the bot must not do
It must not guess delivery dates. If your system shows "in transit", the bot says "with the carrier" and gives the carrier's tracking link; it does not say "it should arrive Thursday" unless the data says so. It must not read out a full address; say "to the address on the order" without repeating it, and offer a handover if the customer needs to change it. For more on the boundary between answering and acting, see whether an AI chatbot can handle order tracking and returns.
A filled-in example
Customer: where's my order 10482
Bot: I can look that up. What email address did you use at checkout?
Customer: [customer email]
Bot: Thanks. Order 10482 was packed on Monday and handed to the carrier on Tuesday. Here is the tracking link: [link]. The carrier's page shows the latest scan.
Customer: it says delivered but there's nothing here
Bot: I'm sorry, that's worrying. I'm passing this to [your name] with your order details so you don't have to explain it again. You'll hear from us by [time you commit to].
The final line matters. Promise a reply time only if you can keep it; otherwise say "as soon as we can" and send a short message the moment you read it. The handover note the bot writes for you in that case might read: "Order 10482, tracking shows delivered, customer says not received, verified by email match. Check proof of delivery with carrier."
Flow two: returns
This is the flow where an unconstrained bot does most damage, because customers are asking for money. The design rule is that the bot gathers and explains; you decide.
The map
- Bot asks what the customer wants to do (return, exchange, report a fault, change of mind).
- Bot checks the order as in flow one, and reads the delivery date from the system.
- Bot states the relevant rule in your own words, quoting only your approved policy text: the time limit, the condition the item must be in, who pays the postage.
- If the order is inside the window and the item is the type your policy accepts, bot collects the reason and, for faults, a photo, and offers the returns form or the next step you have defined.
- If the order is outside the window, or the item is excluded, bot states the policy once and hands over. It does not argue and it does not make exceptions.
- Faulty, damaged or wrong item: bot collects evidence and hands over. Refund and replacement decisions are yours.
The words the bot never says
"Your refund has been approved", "I'll refund you now", "we'll make an exception", "you're entitled to". It may say "I've passed this to the team to review", and "refunds usually reach your account within [your stated time] once approved". Put the forbidden phrases in your instructions, and test them by trying to talk the bot into them in the test stage. Our tutorial on guardrails that stop AI promising what you do not offer shows how that testing works.
A filled-in example
Customer: I want to return the blue jacket, it doesn't fit
Bot: Happy to help. What's your order number and checkout email?
[verified]
Bot: Thanks. The jacket was delivered 9 days ago. Our policy allows returns of unworn items within 30 days, with the labels attached. You'd cover the return postage. Would you like the returns form, or would you prefer to swap it for another size?
Customer: swap for a large
Bot: I'll note a size swap to Large. I've passed it to the team to confirm stock and send you the next step. You'll hear back within [your time].
Two things to notice. The bot gave the policy facts straight from approved text, and it did not confirm that the large is in stock, because it cannot see stock unless you connect it. If it can, say so in the flow; if it cannot, the handover covers it.
Flow three: sizing
Sizing questions are different, because the answer is a judgement, not a lookup. A bot cannot see the customer and should not pretend to. What it can do is state your size chart accurately, ask a few questions and give a cautious suggestion with a route to a person.
The map
- Bot identifies the product, since fit differs by garment.
- Bot asks for the measurements your chart uses (for example chest and waist, or foot length) or for a size they usually take in a named reference garment from your own range.
- Bot looks up the chart for that product and says which size matches, quoting the numbers.
- If the customer is between sizes, the bot states your rule: "This jacket fits close to the body; people between sizes often go up one." Only include that if you have evidence from your own returns, not a general belief.
- Bot reminds them of the returns policy for sizing, since that lowers the risk of buying, and offers a human if they want to talk it through.
What the bot must not do
It must not say anything about a body ("that will suit your shape"), give health or medical guidance for items like support garments, or promise a fit. It states measurements and rules. Our guide to a clothing store chatbot's size and fit questions covers this in depth.
A filled-in example
Customer: what size jacket for chest 102 cm?
Bot: For this shell jacket, our chart shows Medium fits a chest of 96 to 101 cm and Large fits 102 to 107 cm. At 102 cm you're at the start of Large. The jacket is cut close, so if you like layers underneath, Large is the safer choice. Returns for size are accepted within 30 days if unworn. Would you like to speak to someone about fit?
The jacket, sizes and ranges here are made up for illustration. The pattern to keep: quote the chart numbers, say how the cut runs only if it is true of the product, and restate the sizing return option.
Tone: write it down so the AI does not choose
An AI chatbot has a default voice, usually breezy and over-apologetic. Set a voice in four lines and give two sample replies it must match.
Voice: warm, brief, plain. Short sentences. No exclamation marks, no emojis, no "I understand your frustration" boilerplate.
Always: say what you will do next and by when.
Never: apologise more than once, blame the customer, or use legal-sounding language.
Sign-off: none in chat; "[Store name] team" on handover messages.
Before and after, for a late parcel: Before "I sincerely apologise for any inconvenience this may have caused and understand how frustrating this must be!" After "Sorry about the wait. The carrier shows it left their depot this morning. I've asked the team to check with them, and you'll hear from us by tomorrow midday." The second states a fact and an action and keeps its promise within what you can do.
Escalation triggers: when the bot stops talking
An escalation trigger is a rule that ends the bot's turn and hands the chat to a person. Write them down as a list the bot treats as absolute. A sound starting set:
- Money decisions. Any request for a refund, compensation, price match or exception once the policy has been stated.
- Anger. Swearing, threats, capital letters, "this is a scam", or the customer asking for a person.
- Safety and health. A skin reaction, an injury, a product that overheated, a child's item that broke.
- Legal words. "Solicitor", "lawyer", "regulator", "consumer rights", "chargeback", "report you".
- Failure to verify. Two failed order lookups.
- Looping. The same question twice, or three bot replies without progress.
- Delivered but not received, and missing items. These need a person to check with the carrier or packer.
- Anything outside the three flows that the approved facts do not cover.
Each trigger needs a defined handover: who receives it, in what channel, within what time, and with what summary. Our tutorial on chatbot handover to a human covers the mechanics. Decide in the same design session how the bot's first message tells customers they are chatting with a bot, not a person. Offer the human early rather than late; a visible "talk to a person" option lowers the heat in every difficult chat.
Turn the maps into instructions with AI's help
Once the three flows are drafted on paper, an assistant can turn them into the instruction text a chatbot platform wants, and can help spot gaps. Use a general chat assistant for that drafting, not the live bot.
I run a small online store. Below are three chatbot flows (order status, returns, sizing), my policy text, my size chart and my tone rules. Turn them into one set of instructions for a customer-service chatbot.
Requirements:
- Use ONLY the policy text and chart I paste. If a question needs anything else, the bot must say it will pass the chat to the team.
- List hard rules: never approve refunds, never state delivery dates not in the order data, never reveal order details before the order number and email match.
- List the escalation triggers exactly as I give them and the handover note format.
- Include five test questions per flow that try to make the bot break a rule, with the correct behaviour for each.
- Point out anything in my flows that is ambiguous or contradicts my policy text.
[paste flows, policy, size chart, tone rules]
The last requirement is the one with the most value. An assistant reading your own materials will often notice that your returns text says 30 days in one place and 28 in another, or that the size chart for one product lacks a size. Fix the source, then paste the instructions into the platform.
The test: ten real past tickets
Before launch, pick ten past tickets that cover the three flows and the edge cases: say three order status (including one delivered-but-missing), three returns (one outside the window, one faulty, one change of mind), two sizing and two difficult ones (an angry customer, an off-topic question). Replay each in the bot's test window, typing the customer's message as written, and score it on a sheet.
| Ticket | Correct facts | Right tone | Rules kept | Handover right | Notes |
|---|---|---|---|---|---|
| 1 Where is my order (verified) | Yes | Yes | Yes | n/a | Good |
| 2 Delivered, not received | Yes | Yes | Yes | Yes | Note included photo request |
| 3 Return outside 30 days | Yes | Slightly stiff | Yes | Yes | Soften wording |
| 4 Faulty item, demands refund now | Yes | Yes | No | No | Said "I'll refund you"; fix the rule |
| 5 Size between two | Partly | Yes | Yes | n/a | Quoted the wrong chart range |
The row that matters is number four. Any "rules kept" failure is a blocker: fix the instruction, rerun that ticket and two others of the same type, and only then continue. A table with three small tone issues and no rule failures is ready for a limited launch. A single invented fact or promise means not yet.
Trying to break it before customers do
After the ten tickets, spend twenty minutes attacking the bot. Ask it to refund an order. Claim you are the owner. Paste an order number with a wrong email and see what it reveals. Tell it you are angry. Ask about something it should not know, such as another customer's order, a discount code, or the weather. Ask it to ignore its instructions. Write down each failure, and add a rule or a trigger for it.
Some failures cannot be fixed by instructions alone, such as a bot that can read order details without a check because the platform's connection is too broad. That is a configuration question for the platform's help page and, for sensitive data, the vendor's privacy terms. If the vendor cannot tell you how verification works, pick a different vendor.
The handover note: a template to fill
A handover that arrives as a raw transcript wastes the minute you saved. Give the bot a fixed note format and test that it fills every field. A filled example:
- Reason for handover: returns, outside the 30-day window by 4 days.
- Order: 10482, verified by order number and email.
- Customer wants: a refund for the blue jacket, says it never fitted.
- Already told: the 30-day policy and that exceptions are decided by the team.
- Mood: polite but disappointed.
- Next step for the team: decide whether to offer an exchange or store credit; reply by email within one working day.
The "already told" line saves the most grief. Without it you may repeat the policy and sound dismissive, or contradict the bot. If the note is missing a field in more than one test conversation, fix the instruction before launch.
What to leave for a fourth flow
Product questions (does it work with this, what is it made of, is it in stock) tempt owners to add a flow early. Wait. They draw on the widest set of facts, so they have the highest chance of the bot inventing an answer. After a month of real chats, look at which product questions repeat. For each, add the answer to the approved facts and a rule that anything not in those facts goes to a person.
A flow that looked fine and cost a weekend
Picture a small shop that launched its returns flow on a Friday. The policy page said 30 days, but the bot's instructions, copied months earlier, said 60. By Sunday evening eleven customers had been told they could return items up to 60 days after delivery, and several had replied with thanks. The owner then had to decide whether to honour what the bot had said, and in the end did so for those eleven because the store had said it in its own chat.
The cause was a policy held in two places. The fix: one source of truth for policy text, a reminder in the calendar to refresh the bot whenever policy changes, and a weekly spot-check of five conversations. The ten-ticket test would have caught it if a ticket outside 30 days but inside 60 had been in the set. Add one boundary ticket per rule to your test set.
Launch small, then read everything
- Days 1 to 7. Show the bot to a fifth of visitors if your platform can split traffic that way, or only during hours you are online to take handovers. Read every conversation. Fix rule failures at once.
- Days 8 to 30. Read a sample of ten a day. Track three numbers: share of chats resolved without a handover, share of handovers that arrived with a usable note, and customer complaints that mention the bot.
- Monthly. Add the three most common unhandled questions as new flow text or as FAQ entries (see building the FAQ your chatbot needs), and retire any flow nobody uses.
A bot is a small piece of customer service staff and needs the same attention: a brief, a first week of supervision and regular review. If you would like to design the flows with someone against your real tickets before choosing a platform, that is part of my AI implementation consultation; the details are on the contact page.
Questions before you design the flows
Do I need to design flows if the chatbot is AI-powered?
Yes. A modern chatbot can improvise, which is the problem: it may improvise a refund promise. A flow tells it what to ask, which facts it may use, what it may offer and when to hand over. You write that once and the AI handles the wording around it.
How many flows should I start with?
Three: order status, returns and sizing, because they cover most store tickets. Add a fourth only after a month of real conversations shows a gap. A bot with five carefully built flows beats one with twenty thin ones.
What should the bot never do?
Never approve refunds, quote delivery dates it cannot see in the order system, give medical or safety advice, discuss payment problems in detail, or answer anything about an order without verifying who is asking. List these as hard rules in your instructions and in the escalation triggers.
How do I know the bot is ready to go live?
Take ten real past tickets, replay each as a conversation, and score the bot on accuracy, tone and correct handover. If it passes nine without an invented fact, turn it on for a small share of visitors first and read every conversation for the first week.
Further reads
- Should You Build or Buy an AI Chatbot for Customer Service? — Whether to build or buy once the flows are drafted.
- How to Spot Patterns in Complaints, Returns, and Defects With AI — Spot patterns in complaints and returns to improve the flows.
- Best AI Chatbots for Small Shopify Stores (2026) — Which chatbots suit a small Shopify store.
- WooCommerce AI Agent: Which Chatbot Fits a Small Store? — Chatbot options for a small WooCommerce store.
- 9 AI Chatbot Mistakes That Lose Small Businesses Customers — The mistakes that lose customers, to test your design against.
- E-Commerce AI Tools: 8 Jobs a Small Online Store Can Hand Over — Where support sits among the other jobs a store can hand over.
- Ecommerce AI Chatbot Platforms: What Each Charges per Resolved Chat — What each platform charges per resolved chat once the flows run.
- AI Size Recommendation for a Clothing Brand From Charts and Returns — Use returns data to sharpen the sizing flow's advice.
- AI Fit Shoes Plugin: Can a Size Finder Cut Returns for a Shoe Shop? — How shoe size finders work, what data they need, and a before-and-after method to test whether one cuts your returns before you pay.
- AI Online Shopping Solutions for a Small Store: Chat, Quiz or Search? — Compare AI chat, recommendation quizzes, and smart search for small stores, with costs, decision rules, and a 20-question test.
- AI Voice Agent for Ecommerce: Cost per Order-Status Call — Cost per order-status call from listed per-minute prices, set against a part-time hire, with lookup limits and handover rules.
- Can You Automate a B2B SaaS Business With AI? What to Hand Over First — A risk-ranked order for handing small B2B SaaS jobs to AI: support drafts first, onboarding next, billing chases last.
- Candle Troubleshooting Replies: Tunnelling, Sooting, Weak Scent — Cause lists, care wording, replacement rules and reply templates for tunnelling, sooting and weak scent, drafted with AI.
- ChatGPT Chatbot for Sales: Qualify Website Leads Without Losing Them — Four qualifying questions, a handover rule, a lead log and a cost comparison of ready-made bots against a build-your-own.
- Clothing Product Descriptions: A Checklist of Fabric, Fit and Care Errors — Fibre percentages, fit words, care symbols, model height and size charts: the details AI invents in clothing copy, and how to check each one.
- Dropshipping Returns and Refunds: Policy Wording and AI Replies — A dropshipping store owner's guide to supplier refund terms, refund-only limits, policy wording and AI-drafted customer replies.
- PayPal Dispute Response for Sellers: Evidence Pack Drafted With AI — A seller-side PayPal dispute response: evidence by dispute reason, a reply template and AI prompts that keep the pack honest.
- Peak Season Ecommerce Checklist: Stock, Support and Shipping — A seven-day plan and checklist for a small online store: stock cover, carrier cut-offs, support macros, ad budget and returns wording, built with AI.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: no vendor features or prices are stated; check order lookup, verification and handover features on your own platform's help pages for your plan. Flows, tickets, products and figures in the examples are illustrative.