Customer service

AI Chatbots for E-commerce: Orders, Returns and Cart Recovery

Online retail generates the most predictable contact volume of any sector — three questions, asked relentlessly, mostly at night. It is also the sector where a chatbot most obviously stops being a chatbot.

10 min read July 28, 2026

E-commerce support has an unusual property: it is almost entirely predictable. Across stores of very different sizes selling very different things, the contact collapses into the same short list — where is my order, can I return this, does it come in my size or my city. The wording varies. The questions barely do.

That predictability is why retail is where automation pays back fastest, and it is also why retail exposes the limit of a document-based assistant more quickly than any other sector. Most of these questions cannot be answered from a policy page, because the answer is a fact about one specific order.

The three questions

Where online-retail contact concentrates

Where is my order / when will it arrive

40%

Returns, refunds and exchanges

22%

Pre-purchase: sizing, stock, specification, compatibility

20%

Payment, invoice and pricing

10%

Complaints and everything else

The top two are the automation target and both need a system lookup. The third is the one that affects revenue rather than cost.

The shape retail contact reliably takes, not a published statistic. Classify a month of your own tickets — the proportions shift, the ranking rarely does.

Two things follow immediately. First, the largest block is a status question, which means the assistant is only useful if it can reach the system that knows. Second, the third block — the pre-purchase questions — is the one that changes revenue rather than cost, and it is consistently the one nobody prioritises.

Order status: the case that justifies the project

Nobody enjoys any part of a "where is my order" interaction. The customer is anxious and gets a queue. The agent is reading a screen aloud. Nothing about it requires judgement, expertise or authority, and it arrives at all hours because that is when people think about their parcels.

Answered by an assistant with a live lookup, it takes seconds, works at two in the morning, and is right — which is more than can be said for a tracking page that says "in transit" without explaining what that means for a customer in Abha.

This is read-only access: nothing is changed, so the risk is a wrong answer rather than a wrong action. That distinction is what makes it the correct first connection in almost every retail deployment — see what changes when software can act.

Worth remembering

Identify the customer before answering an order question, and identify them properly. An order number typed into a chat window is not authentication — it is a reference that a customer’s relative, or anyone who saw the confirmation email, also has.

Returns: policy plus record

Returns are the second block and they are structurally different, because a correct answer needs two things at once: what the policy says, and what is true of this order.

The policy half comes from your documents — window, condition, exclusions, who pays shipping, how a refund is issued and when it appears. The order half comes from the system: when it was delivered, what was in it, whether a return is already open. Answering "can I return this" without both produces the worst kind of wrong answer, because it sounds authoritative and creates an expectation you will have to break.

The point where a return is actually initiated is a write action, and it deserves the treatment write actions deserve: a limit, a clear confirmation of what is about to happen, and a record. Many stores sensibly stop the assistant just short of it — the assistant confirms eligibility, explains the process and prepares the request, and the customer presses the button.

Pre-purchase: the part that is not a cost centre

Support automation is nearly always framed as cost reduction, and in retail that framing undersells it. A customer asking whether a product fits, whether it is in stock, whether it works with something they already own, or whether it can arrive before Thursday is not a support ticket. They are trying to buy something and are stuck.

Unanswered, that question does not become a complaint. It becomes a closed tab, and it never appears in any support metric, which is precisely why it stays unprioritised. Handled well — accurately, in the customer’s language, immediately — it is the only part of the deployment that shows up in revenue rather than in cost avoided.

Recommendation deserves a caution. An assistant suggesting genuinely relevant alternatives when something is out of stock is useful. An assistant that pushes unrelated products because it was told to increase basket size is a nuisance that customers detect immediately, and it damages the credibility of every other answer it gives. Suggest when it helps the customer; stop there.

Abandoned carts, and doing it without becoming spam

Cart recovery is where messaging automation is most often overreached. The mechanics are easy and the judgement is not.

The useful version treats abandonment as a question rather than a lapse. People leave carts because shipping cost surprised them, because the delivery date was unclear, because a payment method they wanted was not offered, or because they wanted to check something and did not find it. A short, genuinely helpful follow-up that addresses the likely reason is welcome. A discount code fired at everyone who ever left a cart trains your customers to abandon carts.

On messaging channels this is also a permissions matter rather than a taste matter: proactive contact requires an opt-in you can evidence and, on WhatsApp specifically, pre-approved message formats and a live conversation window. The mechanics are in the WhatsApp guide, and they constrain what is possible more than most marketing plans assume.

Arabic, and the pattern of retail traffic

Retail is the sector where informal Arabic dominates most completely. Customers message from a phone, briefly, in dialect, mixing in English brand and product names — because brands are usually written in English even in an otherwise Arabic sentence. A system that handles formal Arabic and matches product names only in one script will fail on ordinary traffic while appearing to work in testing.

The same traffic is heavily out-of-hours and heavily weekend. Evening is when people shop and when they wonder where their parcel is, and there is nobody on the desk. That coverage — answering at all, rather than answering more cheaply — is usually the larger half of the value in retail, and it is worth reporting separately so it does not get lost inside a deflection percentage. More on the language question in why understanding Arabic is harder than generating it.

What to measure

Retail has better outcome data than most sectors, so use it rather than reporting message volumes.

Six numbers worth reporting monthly

1Contacts resolved without a personBy question type, not overall. "Order status" and "complaints" behave nothing alike and averaging them hides both.
2Out-of-hours conversations answeredVolume that previously received nothing. This is new service, not cost saved, and reporting it as a saving both overstates and undersells it.
3Repeat contacts on the same issueThe honest check on whether answers actually landed. A high deflection rate with high repeat contact means the customer gave up, not that they were helped.
4Pre-purchase conversations that convertedThe only number on this list that appears in revenue. Harder to attribute, worth the effort.
5Return requests started in chatMeasures whether the returns path is genuinely usable or whether people are still emailing.
6The unanswered listThe actual questions the assistant could not handle, read as text rather than as a percentage. This is the roadmap and it is free.

Item three is the one most often missing and the one that keeps the rest honest.

Set these up before launch. Reconstructing them from transcripts afterwards is possible and tedious.

Item six repays reading directly. Retailers routinely discover that a product page is missing a specification everyone asks about, that a delivery promise is being read differently from how it was meant, or that a size guide is wrong in Arabic only. Those are fixes worth more than the automation that surfaced them, and they come out of conversation analytics for free.

A sensible order to build it in

Policy answers first — returns, shipping, payment methods, warranty — because they need no integration and cover real volume immediately. Then order status, which is the largest single block and the first system connection. Then pre-purchase questions against your live catalogue, which is where revenue starts moving. Then, and only then, actions that change something: initiating a return, rescheduling a delivery.

That is the sequence Elbi is normally deployed in for retail, and the sector detail sits on the retail and e-commerce page. The reason for the order is not caution for its own sake: each stage produces the evidence that tells you whether the next one is worth doing, and the unanswered list from stage one is a better specification for stage two than any workshop.

Common questions

What should an e-commerce chatbot handle first?

Policy answers — returns, shipping, payment methods, warranty — because they need no integration and cover real volume from day one. Then order status, which is the single largest block of contact and the first system connection worth making. Pre-purchase questions come next, because that is where the assistant affects revenue rather than cost.

Can an AI chatbot check order status?

Only if it is connected to the system holding the order. No amount of model quality substitutes for the lookup. This is read-only access, so the worst outcome is a wrong answer rather than a wrong action, which is why it is the correct first integration in almost every retail deployment. Identify the customer properly first — an order number is a reference, not authentication.

Can a chatbot process returns and refunds?

It can confirm eligibility by combining your policy with the facts of that specific order, explain the process and prepare the request. Actually initiating the return changes something, so it deserves a limit, a clear confirmation and a record. Many stores sensibly stop the assistant just short of the final step and let the customer press the button.

Do AI chatbots help with abandoned carts?

Yes, if abandonment is treated as a question rather than a lapse. People leave carts because shipping cost surprised them, the delivery date was unclear, or a payment method was missing. A short follow-up addressing the likely reason is welcome; a discount code fired at everyone who left a cart trains customers to abandon carts. On messaging channels it also requires an opt-in you can evidence.

What should an online store measure?

Resolution without a person by question type rather than overall; out-of-hours conversations answered, reported as new service rather than as saving; repeat contacts on the same issue, which is the honest check on whether answers landed; pre-purchase conversations that converted; return requests started in chat; and the list of questions the assistant could not answer, read as text.