Ecommerce AI Chatbot Examples: 7 Store Conversations to Copy

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Ecommerce AI Chatbot Examples: 7 Store Conversations to Copy.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Ecommerce AI Chatbot Examples: 7 Store Conversations to Copy.

Good ecommerce chatbot conversations are short and answer from facts the bot can see. For order tracking, it checks the order number and email, then gives the latest scan in plain words. For returns, it quotes the window and lists the steps. For product questions, it uses the size chart or stock data, and passes anger or damage to a person.

The seven conversations here, covering tracking, address changes, returns, sizing, stock, damaged parcels and escalation, are tool-neutral, and each comes with the instruction that produces it. Whatever chatbot you use, the quality comes from three things you supply: a written policy the bot can quote, a way to look up the customer's order, and a rule about when it stops and hands over. Everything else is wording, and wording is what you can copy here.

Follow me on Instagram@sagnikteaches

What every good conversation has in common

Read enough chatbot transcripts from small online stores and the good ones share a shape. The bot says what it is in the first line. It asks for one piece of information at a time, never a form. It answers with the specific fact (a status, a date, a rule) before it adds any friendliness. And it ends by saying what happens next, so the customer is never left wondering whether anyone is dealing with their problem.

Connect on LinkedInSagnik Bhattacharya

The bad ones also share a shape. They greet at length, ask three questions at once, answer a different question from the one asked, and apologise in a loop. The seven examples avoid all of that, and the instruction blocks show how.

Subscribe on YouTube@sagnikteaches

A shared instruction goes under every one of the conversations below. Put it at the top of your bot's setup once, then add the topic-specific block for each. Here is a filled-in version for an illustrative small homeware shop with a 30-day return window and a two-working-day dispatch promise.

You are the support assistant for [Shop name], a small online homeware shop.
Say in your first message that you are an automated assistant.
Rules:
1. Answer only from the policy text and order data supplied. If the answer is not there, say you do not know and offer to pass the question to the team.
2. Ask for one thing at a time. Never ask for card details, passwords or full addresses.
3. Keep replies under 60 words unless quoting policy.
4. Never promise a refund amount, an exception, a delivery date you cannot see or compensation. Quote the policy and offer the team.
5. Hand over to a person if the customer is angry, mentions a safety problem, a damaged or wrong item, a legal threat, a chargeback, or asks for a person.
6. When handing over, say what happens next and when the team replies (weekdays, within one working day).

Rule 4 matters most. A bot that invents an exception creates a promise the shop then has to honour or break, and both cost money. The weekly transcript check described at the end exists to catch this.

The Complete Excel Course with AI Integration thumbnail

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 now

1. Where is my order: a tracking conversation

This is usually the largest single topic in a small store's inbox, and the easiest to automate because the answer is a fact in your order system, not a judgement. The bot needs two inputs from the customer (order number and the email on the order) and one lookup. The two inputs together are the identity check: never show order details on an order number alone, because order numbers are guessable.

Customer: where is my order
Bot: Hi, I'm the automated assistant for [Shop name]. I can check that for you. What's your order number?
Customer: 10482
Bot: Thanks. And the email address you used at checkout?
Customer: [email address]
Bot: Found it. Order 10482 was dispatched on Tuesday with a tracked courier. The latest scan says "out for delivery" this morning. Here's the tracking link: [link]. If it hasn't arrived by 6pm, reply here and I'll pass it to the team.
Customer: ok thanks

What makes this work is that the bot read the status and repeated it in plain words rather than pasting a tracking number and leaving. It also set a time at which the customer should come back, which turns a vague worry into a concrete next step.

The instruction block for this topic:

TOPIC: order status.
Ask for the order number, then the email on the order. Only after both match, report: dispatch date, carrier, latest scan in plain words, tracking link.
If the order is unfulfilled, say it has not been dispatched yet and quote our dispatch promise (two working days).
If the latest scan is more than 5 days old, or the status is "returned to sender" or "delivery failed", do not guess: hand over to the team with the order number.
Never show another customer's details. If the email does not match, say you cannot find a match and offer the team.

Watch for two failures. First, bots that read "delivered" from the courier and tell a customer who says they have nothing that it was delivered: the right answer is an apology and a hand-over to the team, who can open a courier investigation. Second, a stale scan treated as news. A parcel showing "in transit" for nine days is a lost parcel, and the five-day rule in the block above catches it. The sibling tutorial on chatbot design flows shows how to draw these decisions as a flow before you write the instructions.

2. Change my address before it ships

Address changes are time-critical and risky: change the wrong thing after dispatch and the parcel goes to the old address. The conversation therefore starts by checking the one fact that decides the answer, whether the order has left the warehouse.

Customer: I put the wrong flat number on my order, can you change it
Bot: I can look into that. What's your order number and the email on the order?
Customer: 10517, [email address]
Bot: Thanks. Order 10517 hasn't been dispatched yet, so the team can still change it. I can't change addresses myself, so I'll pass this on now. Please type the full corrected delivery address in one message.
Customer: Flat 4B, 12 Example Road, Anytown, AB1 2CD
Bot: Got it. I've sent the corrected address to the team marked urgent. They reply on weekdays within one working day, and they'll confirm before dispatch. If this was over a weekend, your order will not go out until they've confirmed.

Notice what the bot did not do: it did not edit the address. Taking the address inside the chat is fine because the customer volunteers it for this purpose, but the change itself goes to a person who can check the order is still unfulfilled at that moment. An order that dispatches in the ten minutes between the bot's lookup and the team's edit is the classic failure, so the team's note should read "check not dispatched before editing".

The instruction block adds one more rule: if the order is already dispatched, the bot explains that the carrier may offer redirection or a collection point, and hands over with the tracking number. Do not have it promise redirection, because most carriers decide that case by case.

3. Start a return inside the policy window

Returns are where wording is worth the most money. A clear return conversation cuts back-and-forth emails, and a vague one produces disputes. The bot's job is to confirm eligibility from your written policy, collect the reason (because reasons feed your product decisions) and tell the customer exactly what to do next.

Customer: I want to send back the ceramic planter
Bot: Sure, I can help start that. What's your order number and email?
Customer: 10390, [email address]
Bot: Thanks. Your order arrived 9 days ago, which is inside our 30-day return window. The planter can come back as long as it's unused and in its original packaging. What's the reason for the return?
Customer: bit smaller than I thought
Bot: Understood, thank you. Here's what happens next: 1) Pack it in its original box. 2) Use the prepaid label I'm sending to your email. 3) Post it within 14 days. Your refund goes back to your original payment method within 5 working days of the parcel arriving and being checked. Anything else I can help with?

Two things in that exchange deserve notice. The bot stated the date arithmetic (nine days, inside thirty), so the customer can see why they qualify. And it gave the refund timing as a policy statement ("within 5 working days of the parcel arriving") rather than a date it cannot see. Your own timings will differ: fill them in from your policy, and have the bot quote them word for word.

TOPIC: returns.
Policy text (quote this, do not paraphrase numbers): [paste your return policy].
Check eligibility from the delivery date in the order data. If inside the window and the item is not in the excluded list [list], confirm eligibility, ask the reason in one question, then give numbered steps.
If outside the window, say so kindly, quote the window, and offer the team for exceptions. Do not offer an exception yourself.
If the item is faulty, damaged or wrong, switch to the damaged-item flow and hand over.
Record the reason as one of: too small, too large, changed mind, not as described, faulty, arrived late, other.

The fixed list of reasons at the end is a quiet win. Three months later you can count them, and "not as described" appearing for one product tells you the listing is wrong. If you want to go further, the tutorial on automating returns and refunds with clear rules covers what happens after the customer clicks the link, and the later one on finding repeat return abuse shows how the logged reasons become useful data.

4. A sizing question the bot must not guess

Pre-sale questions are where a chatbot earns money rather than saves it, because an answered question at the product page is a sale that would otherwise be an abandoned tab. Sizing is the hard case: a wrong answer causes a return, which costs the store the postage both ways. So the rule is to answer only from the size chart and written fit notes, and otherwise say what to measure.

Customer: I'm 5'9 and 12 stone, will the medium linen shirt fit
Bot: I can help. The medium linen shirt is cut as a relaxed fit. From our size chart, medium suits a chest of 38 to 40 inches. Do you know your chest measurement?
Customer: about 41
Bot: At 41 inches you sit between medium and large. Our fit note says the shirt runs roomy, so many customers in your position choose medium for a closer look and large for a loose one. Which look do you prefer?
Customer: loose
Bot: Then I'd go with large. Both sizes can be returned within 30 days if the fit isn't right, and the return label is free for exchanges.

This conversation only works because the shop wrote down a fit note ("runs roomy") and the bot was told to use it. Without the note the bot would invent one from general knowledge of shirts, which is how sizing bots earn a bad reputation. The block says so directly:

TOPIC: sizing and fit.
Use only the size chart and the product's fit note supplied. If there is no fit note for the product, say so and ask for the customer's measurements, then compare them with the chart numbers only.
Never infer fit from height or weight alone. Always mention the free-exchange policy if it exists.
If the customer is between sizes, offer both choices with the fit note and let them decide.

A small workwear shop with one size chart and no spare staff time is the clearest test of this: if the chart and the fit notes cannot answer the question, nobody will. For a shop with hundreds of products, the practical move is to write fit notes only for the twenty best sellers first. The tutorial on pre-sale questions that stall orders goes deeper on which questions to prepare.

5. Is it in stock, and when will it be back

"Do you have this in blue?" sounds simple and is the point where bots lie most. The bot either has live stock data or it does not. If it does, it answers from it. If it does not, it must say "I can't see live stock", and offer a back-in-stock alert rather than guess a restock date.

Customer: is the walnut side table back in stock
Bot: Let me check. The walnut side table is currently out of stock. I can't see a restock date, so I don't want to guess one. I can add your email to the back-in-stock list so you hear the moment it returns. Would you like that?
Customer: yes please
Bot: Done. You'll get one email when it's back, and nothing else from that list. Meanwhile, the oak version is in stock and ships in two working days. Want the link?
Customer: no thanks
Bot: No problem. Anything else I can help with?

Two details to copy. The bot said what the signup is for ("one email... and nothing else"), which is the consent wording you would want a regulator to see. And it offered the alternative once, then dropped it. A chatbot that keeps selling after a "no thanks" teaches customers to close the window.

If your bot has no stock access, the instruction becomes: "You cannot see stock. Say so, point to the product page's stock label, and offer the back-in-stock alert." Never let a bot read "ships in two days" from a static page and apply it to a variant that is sold out.

6. A damaged parcel, photos and a calm hand-over

Damage claims are not a topic for automation to resolve, but they are a topic for automation to collect. The bot's job is to get everything the team needs in one pass, so the first human reply can be the resolution rather than a request for photos.

Customer: my mug arrived smashed
Bot: I'm sorry about that. I'm an automated assistant, and I'll collect what the team needs so they can sort it quickly. What's your order number and email?
Customer: 10455, [email address]
Bot: Thanks. Please upload a photo of the broken item and one of the outer box, using the button below.
Customer: [uploads two photos]
Bot: Received both, thank you. I've sent them to the team marked "damaged on arrival". They reply on weekdays within one working day, and they'll offer you a replacement or refund. You don't need to send the parcel back until they've said so. Is there anything else I should add to the report?

This is the most important hand-over rule in the set: the bot did not say which resolution the customer would get. It said what the options are in general ("replacement or refund"), because the policy names both, and it said when a person would reply. If your policy gives a specific remedy, quote it. If it does not, stay general.

A shop that sells fragile goods should count these conversations. Ten damage reports on the same product in a month is a packaging problem, not a courier problem. The bot's log is the cheapest source for that count, and a short monthly summary request to an AI assistant will group them for you.

7. The angry customer and the bot that knows when to stop

Every bot needs one conversation where it does almost nothing. The customer is upset, possibly right, and the best the bot can do is get out of the way fast, carrying the context so the customer does not repeat themselves.

Customer: this is the third time I've written. Nobody replies. I want my money back and I'm disputing this with my bank
Bot: I'm sorry. That's not the service you should get. I'm an automated assistant, so I'm passing this to a person now, marked urgent, with your messages attached so you won't need to repeat anything. Can you confirm your order number so they can find it straight away?
Customer: 10201
Bot: Thank you. I've flagged order 10201 as an urgent complaint with a possible bank dispute. The team replies on weekdays within one working day, and a manager will see it first.

Notice what is absent. The bot did not argue, explain policy, offer a discount or ask the customer to calm down. It named the next step, repeated the commitment on timing and attached the history. The bot also recognised the words "disputing this with my bank" as a trigger: a chargeback has strict response deadlines, and the human needs to know quickly. The tutorial on a chargeback response template covers the written side from there.

TOPIC: escalation.
Triggers (any one): angry or abusive language, "third time", "complaint", "chargeback", "dispute", "bank", "solicitor", "refund now", a safety concern, a request for a person, or two failed attempts to answer the same question.
Action: apologise once, say you are an automated assistant, say a person will reply, state the working-day timing, attach the conversation, ask for the order number if not yet given.
Never defend the shop, never explain why the delay happened, never offer compensation.

Three more conversations worth adding once the first seven hold

The gift order is the first. A customer wants to send a present to someone else with a short card and no price on the packing slip. The bot cannot change anything, but it can explain what the checkout offers and collect the card text so nothing is lost. A good exchange runs: the customer asks, the bot says gift messages are entered at checkout in the note field, confirms that a gift receipt without prices is included if your shop does that (and says plainly if it does not), and reminds the customer that returns on a gift go to the buyer unless the policy says otherwise. The instruction is two lines long, and the value is that it stops the commonest late-evening question reaching your inbox in the morning.

The discount code is the second, and it is the one that needs the firmest rule. Customers ask "do you have a code" about every shop. A bot with no instruction either invents one or says no, and sometimes invents a percentage that has never existed. Give it the published offers only: the welcome code on the newsletter signup, the free-delivery threshold, any live sale. Tell it to quote them exactly and to say "that's all I can see running" otherwise. If the customer pushes for a price match against another seller, the answer is a hand-over, because a price match is a margin decision and belongs to a person.

The third is the wholesale or bulk enquiry. It looks like a pre-sale question, but a ten-unit order from a business has different economics and often needs a quote. The bot should collect three things only (what they want, how many, and by when), thank them and pass it on marked as a trade enquiry with the timing the team keeps. Never have it quote trade prices. A sample instruction: "If the customer wants more than five of one item, or says business, trade, wholesale or reseller, collect product, quantity and date wanted, then hand over. Do not state discounts."

Each of these has the same bones as the seven above: a single fact or a single collection task, one forbidden promise and one trigger for stepping aside. When a new topic appears in your inbox, ask those three questions of it before you write a word of the bot's reply, and you will usually find the answer is either "automate" or "hand over", with very little in between.

How to check a chatbot is behaving

A transcript review does the job without any special software. Once a week, pull twenty conversations at random from the bot's log, remove personal details, and read them with three questions: did it answer from a fact it could see, did it keep to the rules, and did it hand over when it should have? Mark each conversation pass or fail. Two fails in twenty means tighten one instruction. Five means switch the bot off for that topic until you fix it.

Here is a small sum to judge whether the effort pays. Say a shop gets 600 customer messages a month and 40% are order-status questions. That is 240 messages. If each takes a person three minutes, that is twelve hours a month. A bot that resolves two-thirds of them leaves eight hours saved a month, minus about an hour of transcript review. Your numbers will differ, but running the sum on your own inbox before choosing a tool stops you paying for capacity you do not need. The tutorial on what platforms charge per resolved chat gives the cost side to set against it.

You can also have an AI assistant do the first pass of the review. Paste in ten anonymised transcripts and ask:

Here are 10 chatbot conversations from our store. For each, answer: (1) Did the bot state anything not supported by the policy or order data? Quote it. (2) Did it hand over when a trigger word appeared? (3) Did it ask more than one question at a time? Give a table, then list the three wording changes that would fix the most failures.

A sample result might say that in four of ten conversations the bot stated a refund timing of "3 to 5 days" when the policy says "5 working days". That is a real wording fix: change the instruction to "quote the policy sentence exactly". Always read the quoted lines yourself, because the assistant checking the bot can also miss things.

Adapting the seven to your own store

Start with the two topics that dominate your inbox, not all seven. For most small stores that is order status and returns. Write the policy text first, in plain words, because the bot can only be as clear as the policy it quotes. If the policy contains the phrase "at our discretion", expect the bot to hesitate and hand over a lot, which is the right behaviour but a poor customer experience; fix the policy and the bot improves.

Then run a rehearsal. Ask a colleague or a friend to play ten customers using the worst messages from your real inbox (names removed): the angry one, the vague one, the one with two questions in it. Where the bot stumbles, add a line to the matching instruction block, not a new rule at the top. Short, topic-specific blocks are easier to fix than one long block, and they let you switch off a single topic if it misbehaves.

Finally, decide the hours. A bot that says "the team replies within one working day" at 11pm on a Friday must not imply Saturday. Put your real reply times into the instructions and put a line in the hand-over rule telling the bot to say "Monday" when it is a weekend. If you would rather map which of your topics are worth automating first with someone, that is what my AI implementation consultation covers, and you can reach it through the contact page.

For the first month, keep three numbers in a sheet, one row per week: conversations handled, hand-overs to the team, and customers who wrote again within 48 hours about the same order. The third is the honest one. A bot that closes a tracking question but leaves the customer emailing the next day has moved the work, not removed it. Illustratively, a week with 140 conversations, 35 hand-overs and 9 repeat contacts means the bot settled about 96 conversations outright (140 minus 35 minus 9), roughly two in three. If the repeat contacts cluster on one topic, read those transcripts first: the instruction block for that topic is usually missing a fact, such as the carrier's cut-off time or the address returns go to. Fix that one block, watch the next week's numbers, and only then add the next topic.

Questions before you copy these conversations

Do these scripts work in any chatbot tool?

Yes, because each one is plain wording plus an instruction block. Paste the instruction into whichever tool you use (a store's built-in assistant, a helpdesk bot or a custom build) and give it access to the same facts. Tools differ in how they look up orders, so test that part separately before launch.

How many past conversations do I need to start?

Thirty to fifty real customer messages is enough to find your top five topics. Export them from your inbox, remove names, emails and addresses, and ask an AI assistant to group them. Start with the two topics that make up most of the volume.

Should the bot say it is a bot?

Yes. Say it in the first message, plainly. Customers forgive a bot that is honest and quick, and dislike one that pretends to be a person. Some jurisdictions and platforms also require disclosure, so check the rules where your customers live.

What if the bot gives a wrong refund promise?

Prevent it with a hard rule: the bot may quote the written policy but never promise an exception, a refund amount outside the policy or a delivery date it cannot see. Review a sample of transcripts weekly and tighten the wording each time you find a breach.

Further reads

Sources: written from store-support practice and tool-neutral scripts; no vendor figures are quoted, so check your own legal cancellation periods and policy wording.

Want these conversations built around your own store?

On a 1:1 call we can go through your last month of customer messages, pick the two topics worth automating first and decide which of your current tools can run them.

Book a 1:1 call with me