Ecommerce Chatbot Reality Check: Order Status, Returns and Sizing

Three questions make up most of what an online store's inbox receives, in roughly this order of volume: where is my order, how do I send this back, and will the medium fit me. Every ecommerce chatbot pitch treats these as one problem — "automate your customer support" — when they need three different things from the software, and only one is fixed by writing better help content.

That distinction is the difference between a bot that resolves most of your inbound and one that politely apologises to 40% of your customers.

What an Ecommerce Chatbot Can Answer From Content Alone

Start with the honest boundary. A chatbot trained on your website answers questions whose answers are the same for everyone:

• Return window and condition rules
• Shipping costs, free-shipping thresholds, dispatch cut-off times
• Which countries you ship to and expected transit times
• Payment methods, EMI availability, COD rules
• Care instructions, materials, warranty terms

That list covers a real slice of volume. It is also the ceiling for a content-only deployment. Published containment benchmarks put scripted FAQ bots at roughly 25–45% of ecommerce conversations and answer-only AI agents at 40–60%. Bots that can also take an action — look up an order, start a return — land at 55–75%.

The reason for that jump is one query type.

Order Status Is Not a Content Problem

"Where is my order" — WISMO in the trade — is somewhere between 30% and 50% of an online store's ticket volume, climbing past half during sale periods. It is the single largest category of inbound for almost every retailer, and no amount of help-centre writing touches it, because the answer lives in your order system and changes hourly.

Be blunt about this: if most of your inbound is WISMO and your bot has no order integration, it will fall back on most conversations, and it will be right to. You have bought a bot that handles your smallest problem.

A working order-status flow needs three things.

A live connection to the store. The bot calls your platform's order endpoint and gets back fulfilment status, carrier, tracking number and expected date. On Shopify, Woo or a custom backend this is a standard read — the plumbing is not the hard part.

Verification before disclosure. This is the part teams skip. The bot must require two matching pieces of information — order number plus the email or postcode on that order — and the API confirms they belong together before anything is revealed. Order numbers are usually sequential, so a bot that accepts an order number alone will read out a stranger's delivery address to whoever types a number one higher than their own. That is a data breach, not a feature.

An answer that is more than a status string. "Fulfilled" means nothing to a customer. "Dispatched on the 16th via Delhivery, currently in Bengaluru, expected Thursday — here is the tracking link" resolves the conversation. The bot's real advantage over a tracking page is the follow-up: it is late, what happens now.

Query	Content-only bot	With order integration
"What's your return window?"	Answers	Answers
"Where is my order #10482?"	Falls back	Answers, with tracking
"It says delivered, I don't have it"	Falls back	Confirms status, opens claim
"Can I still cancel?"	Explains policy	Checks if it has shipped
"Change my delivery address"	Escalates	Escalates — correctly

That last row stays escalated on purpose. Reading order data is low risk; writing to it is not.

Returns: Automate the Request, Not the Judgement

Returns are the second-biggest category, and the temptation is to automate the whole flow. Split it instead, at the exception.

Roughly 20% of online orders come back, with apparel running 20–40%. At that volume the labour saving is real. But a return request is two things stitched together: a lookup ("is this in window and eligible?") and a decision ("do we make an exception?").

The lookup is safe to automate. Order date, item, condition rules, final-sale status — all facts the system already holds. If everything is inside policy, generating the label and the pickup slot is faster than a human doing the same clicks.

The decision is not safe to automate:

1. Out-of-window requests. Someone at day 32 of a 30-day window is asking for a favour. That is a retention decision with a rupee value attached, and it belongs to someone who can see the customer's history.
2. Damage and defect claims. These need photos, a judgement, and often a supplier conversation.
3. Final-sale and hygiene-excluded items. A bot enforcing this rule alone will be correct and will lose the customer. A person can offer store credit.
4. Serial returners. Bracketing — ordering three sizes to keep one — is mainstream now. Whether to keep serving a 90%-return customer is a business call, not a chatbot rule.

The pattern is the same one that runs through every support-automation decision: the bot handles the case where the answer is already determined, and hands over the moment someone is being asked to exercise discretion. We wrote about where that line sits more generally in the piece on cutting support tickets without cutting service.

Sizing: The One Where Bots Confidently Make Things Up

Fit is the most requested and most dangerous of the three. Sizing and fit account for around half of all apparel returns — some analyses put it higher — which makes a good pre-purchase answer worth more than the support time it saves. A customer who buys the right size never becomes a return, a refund, and two shipping legs you paid for.

The problem is that "what size am I?" has no answer in your data. You have garment measurements; the customer wants a recommendation. A language model bridges that gap by inventing one, fluently, because that is what it does when retrieval comes back thin.

So constrain it. A sizing-capable bot should answer with what the brand has actually measured:

• Garment measurements per size, in the units the customer asked in — chest, waist, length. If this table is not on the product page, the bot cannot help and neither can your PDP.
• Fit direction for the specific style. "This shirt runs slim through the chest; most customers size up" is a real answer if merchandising wrote it down.
• Model reference. "The model is 5'9\" and wears a medium."
• What reviewers reported. If you have structured review data on fit, aggregate it. If you only have free text, don't pretend.

And an explicit stop: no size recommendation from height and weight alone. The honest line — "I can give you the measurements for each size, but I'd rather not guess; here's how to check against something you already own" — beats a confident wrong guess on every metric that matters, including the return rate.

If your catalogue has no per-size measurements, a sizing bot is the wrong project. Fix the size charts first; the bot can only repeat what exists.

What This Looks Like in Practice

A store deploying all three, in order of return on effort:

Phase	What you connect	Volume addressed	Effort
1	Policy content: shipping, returns, payment, care	20–30%	Half a day
2	Order lookup with verification	+25–40%	Integration work
3	Return initiation for in-policy items	+5–10%	Integration + rules
4	Size charts and fit data on the PDP	Reduces returns, not tickets	Merchandising, ongoing

Most stores do phase 1, see a modest deflection number, and conclude chatbots do not work for ecommerce. It was modest because phase 2 is where the volume is. On Shopify the lookup is the shortest path — the Shopify setup reads order status directly, so the bulk of WISMO is handled the day it goes live, and the categories that always escalate are set in the agent settings.

When Not to Bother

Some stores should not deploy an ecommerce chatbot yet.

Very low order volume. Under a few hundred orders a month, the founder answering personally is faster and produces the knowledge you would need to configure a bot anyway. Automate once the answers turn repetitive, which is one of the signals worth watching for.

Catalogues that change faster than the content. If prices, stock and variants shift daily and nothing syncs them into the bot's knowledge, it will confidently quote last week's price.

Businesses whose real problem is upstream. If WISMO is 60% of your inbound because dispatch takes nine days and the tracking page is broken, a bot that explains the delay well is a bandage on a logistics problem. Fix the shipping notification emails first — a surprising share of WISMO exists because nobody told the customer anything after checkout.

High-consideration, low-volume products. Bespoke furniture, B2B equipment, anything with a quotation step. The enquiry is the sale. Route it to a person.

None of this makes the tooling less useful. It makes it useful in a narrower band, which is the only way automation earns trust — a principle we apply across everything at NoCubical.

Start With the Log, Not the Bot

Before configuring anything, export the last 500 support conversations and tag each one as policy, order status, returns, sizing, or other. That distribution tells you which phase above is worth your money and roughly what deflection to expect. Every store assumes its mix is unusual; most find WISMO is a third of it and the policy questions are the same eight questions.

Then build for that mix. A bot that answers a third of your inbound perfectly and hands over the rest cleanly beats one that attempts everything — and every plan, including the free tier, logs the questions it could not answer, which is how you find phase two.

Frequently Asked Questions