Handling returns and exchanges on WhatsApp
A return conversation is short, predictable and repetitive — which is exactly what automation is for.
A returns flow collects the order number, the reason and any photograph in one conversation, logs the request where your team works, and tells the customer what happens next. It is one of the easiest ecommerce flows to automate, because the conversation is short, predictable and almost identical every time.
It is also one of the most valuable, because a return handled well is a customer retained and a return handled slowly is a public review.
What the flow collects
- The order number. Free text, saved to a contact field.
- The reason, from a list — wrong size, damaged or faulty, not as expected, changed mind.
- A photograph, where the reason is damage or the wrong item.
- What they want — refund, exchange, or store credit.
Four questions, all answerable in under a minute, and every one of them something your team would otherwise have to ask by hand.
Ask what they want, not just why
The fourth question is the one most flows omit and the one with commercial consequence. A customer whose item did not fit often wants a different size, not their money back — but if the only option offered is "return", that is what they ask for.
| Reason | Likely best outcome | Offer it |
|---|---|---|
| Wrong size | Exchange | Offer the swap first |
| Not as expected | Refund, sometimes exchange | Offer both |
| Damaged or faulty | Replacement | Offer replacement, apologise properly |
| Changed mind | Refund | Do not push — it damages goodwill |
The first row is where the revenue is. Offering an exchange as the default for a sizing problem converts a share of refunds into kept sales, and it is a better outcome for the customer too.
Handling the photograph
A keyword condition cannot read an image, so a flow cannot judge whether a photo shows damage. What it can do is detect that an attachment arrived, using the message-type condition, and route it to a person along with everything already collected.
That is the right division. Deciding whether something is damaged is a human judgement; collecting the order number, the reason and the photograph beforehand is not, and doing it automatically saves your colleague the entire back-and-forth.
Where the request goes
Somewhere your team already works, which for most stores means a Google Sheet. A row per request with the order number, reason, requested outcome and phone number turns returns from a scattered set of chats into a list someone can process.
Wire the failure branch to a handover, because a sheet that is unreachable should produce a person rather than silence. Mechanics are in using a Google Sheet as your automation's database.
Create the contact fields first. Anything the flow saves — order number, return reason — must be defined under Settings → Contact Attributes or the save silently does nothing and the value reads back empty. See saving customer answers to contact fields.
Catching the request in the first place
The keyword list decides whether any of this runs. Start with: return, refund, exchange, send it back, wrong item, damaged, faulty, doesn't fit, does not fit, too small, too big.
Then add how your customers write. In South Asian and Gulf markets that means transliterated phrasings, which contain no English keyword at all — handling Roman Urdu and Hinglish covers building those lists. If the flow shows zero runs in its activity view, this is the cause.
What to say about timing
Be specific and be accurate. "Our team will review this and reply here within one working day" is better than "shortly", and far better than a promise you will miss. Returns are already a moment of low goodwill; a missed timing promise is what turns it into a complaint.
And edit the promise to match your real policy rather than leaving whatever a template said. The commonest defect in an installed returns flow is a turnaround time nobody checked.
What it costs
Nothing. The customer messaged you, so the whole conversation sits inside the 24-hour customer service window, and Meta's pricing documentation confirms service conversations have been free and unlimited since 1 November 2024.
The only charged case is following up more than a day later, once the window has closed — which needs an approved template. If your returns process takes longer than that, keep one utility template approved for updating the customer.
Prevention is worth more than process
The cheapest return is the one that does not happen, and in apparel and footwear most returns are sizing. A pre-purchase flow that answers fit questions properly removes more cost than any returns automation recovers.
That is a knowledge-base job — measurements, fit notes, how a particular item runs — and it is covered in AI answers from your own website. Build the returns flow because returns will happen; build the sizing answers because they reduce how often.
A build checklist
- Contact fields created for order number and reason.
- Keyword list built from real inbox messages.
- Reason offered as a list, not free text.
- An exchange offered where the reason suggests it.
- Attachments routed to a person.
- The request logged where your team works.
- The timing promise matches your actual policy.
- A handover on every failure path.
How many templates this needs
Usually none. A returns conversation starts because the customer messaged you, so the whole flow runs on free text inside the 24-hour customer service window — no approval queue, no per-message charge.
You only need a template if your returns process routinely takes longer than a day and you want to update the customer afterwards. One utility template covers that, and it stays well within the 250-template ceiling Meta documents for an unverified business portfolio, rising to 6,000 once verified — see its template documentation.
What to log, and why the format matters
Four columns are enough: order number, reason, requested outcome, and phone number in international format. That last detail prevents the same customer appearing as two rows, which is what makes a returns log unusable after a month.
Add a status column your team updates by hand — received, approved, refunded — and the sheet becomes the whole returns process rather than just an intake record. It also doubles as the source for answering "where is my refund?", which is the follow-up question this flow generates.
Turning a return into a retained customer
The return itself is usually not the moment you lose someone — the handling is. Three things separate a return that costs you a customer from one that keeps them:
- Speed of acknowledgement. The flow replies instantly, which is already better than most stores manage, and it is the part the customer remembers.
- Not making them repeat themselves. If the flow collected the order number and reason, your colleague should open the chat already knowing. A customer asked the same question twice concludes nobody is reading.
- An honest timeframe, met. "Within one working day" and then replying within one working day does more for retention than any apology wording.
What the flow tells you about your products
Because the reason is captured as a list rather than free text, a month of returns becomes a table you can read. That is a product signal most small stores never collect.
If one item generates disproportionate "wrong size" returns, the fix is a sizing note on the product page, not a better returns flow. If one supplier's items generate "damaged", that is a packaging conversation. The automation pays for itself twice: once in handling time, and once in telling you what to change upstream.
A quick win before you build anything
Read the last thirty return conversations in your inbox and count the reasons. Whichever dominates is the one to design around — and there is a reasonable chance you already know the answer and have been treating it as unavoidable.
Exchanges are a different flow, not a branch
Worth separating in your head even if they start in the same conversation. A refund ends the relationship with that order; an exchange continues it, which means a second delivery, a second address to confirm and a second chance to get it wrong.
Practically that means the exchange path should hand over to a person sooner than the refund path does, because someone needs to confirm stock in the replacement size before promising it. Promising an exchange you cannot fulfil converts a recoverable return into a complaint.
Where this sits among your flows
Build it after the order and shipping flows, which handle far more volume, and after order-status answering, which removes the single most repeated question. A returns flow is worth having, but it fires on a minority of orders — so it earns its place once the high-volume conversations are already handled.
The sequencing for a store starting from nothing is in WhatsApp automation for Shopify.
One last note on tone. A returns conversation is the one moment a customer is already slightly unhappy with you, so the flow should be shorter and warmer than your others — fewer questions, no upsell, and a person available quickly. Everything that would be efficient elsewhere reads as obstruction here.
Frequently asked questions
Can a WhatsApp flow handle returns automatically?
It can collect the order number, reason, photograph and desired outcome, log the request and set expectations. Deciding whether an item is genuinely damaged is a human judgement, so the flow routes that to a person.
Can the bot look at a photo of a damaged item?
A keyword condition cannot read images. The flow can detect that an attachment arrived using the message-type condition and route it to a person with everything already collected.
Should I offer an exchange instead of a refund?
Where the reason suggests it — sizing especially. Offering an exchange first converts a share of refunds into kept sales and is often what the customer actually wanted.
Does a returns flow cost anything to run?
No. The customer messaged you, so the conversation sits inside the free 24-hour service window. Only a follow-up more than a day later needs a charged template.