Ecommerce Chatbot Use Cases: The 12 Questions to Automate First

Most lists of ecommerce chatbot use cases are written from the vendor's side: "order tracking", "product recommendations", "cart recovery". Customers do not type any of those phrases. They type "where is my order", "can I still change the address", and "this arrived broken". This post takes the twelve questions that make up most of a store's inbound chat, in the customer's own words, and works out three things for each: what the bot needs to have, what it should say, and when it must stop and hand over.

It is written for whoever runs support at a store on Shopify, WooCommerce or similar, and assumes you have or are about to install an AI support agent (a chat assistant that answers from your own content and can call your store's systems). The examples use PepoChat, but the logic applies to any product that separates a knowledge base from live actions.

Why ecommerce chatbot use cases start with the order, not the product

Ecommerce support is unusual in one way: most questions are not about what you sell. They are about a specific order, and the answer lives in your store's database rather than in any document. That splits the twelve questions into two groups.

The first group is answered by a knowledge base, the private collection of pages, policies and documents your agent searches before every reply. Shipping destinations, return rules, sizing, payment methods and store locations belong here. If the page exists and is current, the bot can answer with no integration at all.

The second group needs an action: a call the agent makes to a live system, such as a Shopify or WooCommerce order lookup, before it replies. Order status, cancellations and invoices belong here. Actions raise an identity question, because the bot must not read one customer's order to another. In PepoChat an order lookup runs on whatever order number or email the visitor types, so several sections below come back to what that lookup returns.

The statistics support this ordering. eDesk's round-up of ecommerce customer service statistics cites Shopify data that 34% of product returns stem from a customer misunderstanding the return policy, and a Baymard finding that 42% of ecommerce sites fail to show a return policy link on product pages. Many of the questions below exist because the answer was never put in front of the customer.

1. "Where is my order?"

What the bot needs. A live order lookup, and a clear view of who can hear its answer. On Shopify's own order status page, customers must sign in, click the link in their shipping email, or "enter their order confirmation number and verify their email or phone number", as Shopify's order tracking documentation describes. PepoChat's order actions do not meet that bar. The Shopify action looks an order up by the number the visitor types, the WooCommerce actions take a typed number or email, and the widget's 6-digit email verification gates none of them. So keep each lookup's answer to what a stranger could hear without harm. PepoChat's Shopify action reads only the order name, date, payment status and fulfilment status; the WooCommerce lookup by number adds the total and payment method, so switch it off if order totals matter.

What it should say. The order's status and the date it was placed. Nothing more. PepoChat's prebuilt order actions return no carrier or tracking number, so for a tracking link the customer needs the shipping confirmation email or a person. Do not let the bot guess a delivery date from "usually 3–5 days" when the order data says "unfulfilled".

When it hands off. A parcel the customer says has not moved past your carrier's normal window, an order marked delivered that the customer says never arrived, or no order found for the number the customer gave (or, on WooCommerce, their email). The setup is in how to connect a support chatbot to Shopify order status.

Order-status questions peak in late November; the Black Friday customer support checklist dates each preparation step for the 2026 season.

2. "Can I change my shipping address?"

What the bot needs. A policy page stating your cut-off ("we can change an address until the order is marked fulfilled") and a quick route to a human. Neither Shopify nor WooCommerce gets an address-edit action in PepoChat, and that is deliberate: editing an order is a write with consequences, and action execution is at-least-once, so a rare duplicate run is possible.

What it should say. Whether a change is still possible given the order's status, and what the customer must provide: order number and the full new address. The bot collects both so the operator does not have to ask again.

When it hands off. Always, for the edit itself. If the order is already fulfilled, the bot should say so plainly and explain the carrier redirect option if you offer one, rather than escalating a request that cannot be met.

3. "Do you ship to…?"

What the bot needs. A page listing the countries you ship to, with delivery times, costs and any customs note. Keep it as one URL source so the weekly re-fetch picks up edits.

What it should say. Yes or no for the named destination, the transit time, the cost or how it is calculated, and who pays duties. For a country not on the list, the answer is "we don't currently ship there", not silence.

When it hands off. Rarely. A wholesale or freight enquiry is a sales conversation and belongs in the team inbox, the shared view where operators pick up conversations the agent escalates.

4. "How do returns work?"

What the bot needs. Your returns policy as a knowledge source, written so that every common variant is answered on the page: window, condition requirements, who pays return postage, refund method and timing, exclusions. If you sell into the EU, the policy must reflect the statutory floor. The EU's guidance states that for online purchases you "have the right to cancel and return your order within 14 days, for any reason and without a justification", with exceptions for personalised goods, opened sealed media and downloaded digital content, and notes the consumer "may need to pay for the cost of returning your purchase" (Your Europe: shopping consumer rights). Your policy can be more generous; it cannot be less.

What it should say. The steps in order, the window that applies to this customer's order if a lookup has given the bot the order date, and any category exclusion that applies.

When it hands off. Out-of-window exception requests, faulty items (a warranty claim with different rules), and anything that ends in a refund. Refunds move money; PepoChat's guidance is not to wire refunds or payments as actions because of at-least-once execution, so the bot explains and escalates.

Paste-ready return, shipping and refund wording that an AI support agent can quote is in our policy templates for chatbots.

5. "Is this in stock / when is it back?"

What the bot needs. This is the question where the honest answer is often "not yet". Live stock needs a live lookup, and PepoChat has no prebuilt inventory action. Option one is a custom action against your store's product endpoint, with an allow-list of response fields (say available and inventory_quantity) so the agent sees stock and nothing else. Option two is to skip live stock and put restock information in the knowledge base: "sold-out items show a 'notify me' button; most restocks take four to six weeks".

What it should say. With a lookup, the availability of the named variant and any restock date you track. Without one, how to get notified and the typical lead time. It should never say "yes, it's in stock" from a product page it crawled last week; crawled pages are snapshots, and stock is not.

When it hands off. Reservation or pre-order requests without a self-serve path, or a product the bot cannot find at all.

6. "Which size should I get?"

What the bot needs. Your size guide, ideally one per product category, plus fit notes from product descriptions ("runs small; order a size up"). Size charts are often images; PepoChat reads JPG, PNG and WebP, but a Markdown or HTML table retrieves more reliably, so convert the important ones.

What it should say. The measurement to take, the size that matches it, and the fit note. If a measurement falls between sizes, say so and state your exchange policy, because that is what decides the purchase.

When it hands off. Comparisons with another brand's sizing that you have not documented. A guess here creates the return it was supposed to prevent; the post on grounding and "I don't know" covers keeping the agent from filling that gap.

7. "Can I use this discount code?"

What the bot needs. A page of current public promotions with conditions: minimum spend, excluded categories, expiry, one per customer, whether codes stack. Cart-dependent validation would need a live action most stores will not build; the checkout already does that job.

What it should say. Whether a named public code is active and its conditions. For a code it cannot find: "I can't verify that code; if it was emailed to you, the checkout will tell you whether it applies". It must not promise a price. A confident "that gives you 20% off" that the checkout then refuses is a complaint you will hear about.

When it hands off. A personal code that is not working, or a goodwill discount request after a problem. Both need a human with permission to act.

8. "My package arrived damaged"

What the bot needs. A claims page (what to photograph, the reporting deadline, whether to keep the packaging) and the same order lookup as question 1, so the bot can confirm the order exists and its status. The prebuilt lookups do not list the items.

What it should say. A short, specific apology, the exact information you need (order number, which item, photos of item and packaging), and where to send the photos, since the chat is text. Then confirm a person will pick it up and roughly when.

When it hands off. Immediately after intake, every time. Damaged-goods claims involve replacements, refunds and carrier claims, all decisions and money movements. The bot's value is that the operator opens the conversation with the order already looked up and the details collected.

9. "Can I cancel my order?"

What the bot needs. Your cancellation cut-off as a policy page, and the order's current status from the live lookup. WooCommerce's order statuses documentation defines "Processing" as "Payment has been received (paid), and the stock has been reduced. The order is awaiting fulfillment", and "Completed" as "The order has been fulfilled and is complete". A processing order can usually be cancelled; a completed one becomes a return. Shopify's fulfilment statuses draw the same line.

What it should say. Whether the order is at a stage where cancellation is possible, and what happens next: "your order is still processing, so it can be cancelled; I've passed this to the team and you'll get a confirmation by email". If it has shipped, switch to the returns process rather than take a request that will fail.

When it hands off. For the cancellation itself, always, for the same reason as address changes. If volume justifies it, a custom action that flags the order for cancellation (a note, not a refund) is a reasonable middle ground, because a duplicate flag is harmless where a duplicate refund is not.

10. "Do you have a physical store?"

What the bot needs. A page with locations, opening hours, services per store (click-and-collect, in-store returns, fitting) and whether store stock differs from online. If you have no stores, say that on a page too, so the bot does not reach for a page about your warehouse and improvise.

What it should say. The nearest location to the place the customer named, today's hours, and whether online orders can be returned there.

When it hands off. Almost never. "Do you have the blue one in the Manchester branch" is a stock question in disguise and goes back to question 5.

11. "What payment methods do you accept?"

What the bot needs. A page listing cards, wallets, buy-now-pay-later providers, bank transfer, gift cards and per-country differences, plus the failure cases: what to do when a card is declined, and whether a pending authorisation on a failed order drops off.

What it should say. The list, the country note if the visitor said where they are, and for a declined card, the things to check before retrying. WooCommerce marks these orders "Failed", meaning the payment "failed or was declined, and no payment has been successfully made", which is worth saying in plain words because customers often assume they were charged.

When it hands off. A suspected double charge, a payment taken with no order, or a request to pay by a method you do not list. All three touch money and need a person with access to the payment provider.

12. "Can I get an invoice?"

What the bot needs. A page explaining where invoices live (confirmation email, account order page, or on request) and what a VAT invoice requires from a business customer. The order lookup lets the bot confirm the order exists; it does not return the customer's email or billing details, so the bot collects those.

What it should say. How to find or regenerate the invoice if your platform allows it, or the details you need to raise one: order number, company name, VAT number and billing address, collected in the chat.

When it hands off. When an invoice must be generated or amended by hand, or the billing entity on an existing order needs changing. The bot's contribution is a complete request rather than a partial one.

Summary: the 12 questions, their source of truth, and when to hand off

"Intake only" rows are still a win: the operator starts with a complete request and the order already looked up. And every handoff trigger is a rule you can write down, so it belongs in the agent's instructions, not its judgement.

How verification, actions and handoff fit together

Three mechanics make the twelve answers safe.

Order lookups answer whoever asks. A visitor starts anonymous unless you switch on lead capture, which can ask for details before the first message. Any visitor can verify their email with a 6-digit one-time code (10-minute expiry, five attempts), which unlocks meeting memory, bookings with the verified name and email, and an emailed transcript. Order actions are not on that list: they run on whatever order number or email the visitor types, and the agent is never told whether the visitor verified. A "when to use" line asking for the code makes the agent ask, but it cannot check that the visitor finished. So treat every order action's response as something a stranger could hear, keep its field list short, and switch off the WooCommerce lookup by number if order totals matter. That also keeps your data handling defensible if you sell into Europe; the GDPR post covers what a support bot stores and for how long.

Actions read; humans write. Every prebuilt ecommerce action in PepoChat is a read. Writes with money attached go to people, because of at-least-once execution and because a person is who the customer wants when money is involved. If you build a custom action, keep it idempotent, meaning it produces the same result whether it runs once or twice: "flag this order for review" qualifies, "refund this order" does not.

Handoff is a state, not an apology. When the agent escalates, the conversation moves to the escalated status in the team inbox with the full transcript and any email the visitor gave or verified, and the operator replies under their own name. The agent also escalates when the visitor asks for a person, or accepts its offer of the team after it finds nothing relevant. What good escalation looks like from the customer's side is the subject of human handoff for AI chatbots.

What to do next

Write the six knowledge base pages first (shipping destinations, returns, sizing, promotions, stores, payments), check the other questions a store's knowledge base needs, and add them as sources; the training guide shows the upload and crawl options. Then connect the order lookup following the Shopify and WooCommerce walkthrough and test questions 1, 8, 9 and 12 with a real order under your own email. Everything here runs on the free plan, which includes 200 AI replies a month and 5 knowledge sources with every feature enabled; the pricing page has the limits, the use cases page shows the ecommerce setup end to end, and you can start a free workspace without a card.