Returns are the one e-commerce conversation where automation is most useful and most dangerous. Useful because the questions are relentless, repetitive and almost always answerable from a policy you have already written. Dangerous because the person asking is already unhappy, and a cheerful bot is how a return becomes a review.
The way through is to treat the flow as your policy, expressed as branches – and to be deliberate about the branch where the answer is no. That is the one that decides whether the customer comes back.
For the messaging rules underneath all of this, see e-commerce DM automation.
Key takeaways
- Automate the policy, not the decision. Eligibility questions are answerable; judgement calls are not.
- The refusal path deserves more care than the approval path, and usually gets less.
- Anything mentioning damage, a missing item or money should reach a person.
- Offering an exchange before a refund recovers revenue – as an option, never as an obstacle.
- The flow runs inside the messaging window, so it needs no templates and costs nothing within the free monthly allowance.
- A returns bot that cannot be escaped is worse than no returns bot.
What Can Safely Be Automated
The line is sharper than it looks: facts yes, decisions no.
Eligibility Is a Fact
Whether an order is inside the returns window is arithmetic. So is whether the item is in an excluded category, whether the customer has the receipt, and what the next step is. All of it is answerable instantly from the order and the policy, which is why it is the right thing to automate.
An order-number lookup makes this far better, because the flow can answer “you have eleven days left” instead of restating the policy – the same webhook described in order status automation.
Process Is a Fact
How to package it, which label to use, where to drop it, how long the refund takes once received. Nobody needs a human for any of that, and automating it removes the follow-up messages asking the same thing again.
Whether to Make an Exception Is Not
“It arrived two days after the window and it was a gift” is not a policy question. It is a judgement about a customer relationship, and it should reach somebody who can make it.
Automating that decision is how stores end up with the review that says the company is run by robots.
The Refusal Path
The branch everyone builds last and should build first.
Say No Once, Clearly
If the answer is no, say so in the first sentence, give the reason in the second, and offer what you can do in the third. Burying a refusal in apologetic padding reads as evasion and produces a second, angrier message.
“That order is outside the 30-day window, so we cannot refund it. We can send a replacement part free of charge, or put you through to someone who can look at it.” Three sentences, and the customer knows where they stand.
Always Offer the Human
Every refusal branch must end with a route to a person. Not because the answer will change, but because a refusal with no appeal is what people screenshot.
The handoff should carry the conversation with it so nobody is asked to explain twice – see handing off to a person.
Never Refuse on Thin Information
If the flow is not certain the order is ineligible, it must not say no. Uncertainty is a handoff, always. A wrong refusal costs far more than a human minute.
What Each Message Should Trigger
A rough triage you can build directly as branches.
| The customer says | Automate? | Because |
|---|---|---|
| How do I return this? | Yes, fully | Pure process, no judgement |
| Am I still in time? | Yes, with a lookup | Arithmetic on the order date |
| Can I exchange instead? | Yes, offer options | Policy, plus a revenue save |
| It arrived damaged | No – route to a person | Evidence, liability, goodwill |
| Part of my order is missing | No – route to a person | Needs investigation |
| I want to speak to someone | No – route immediately | They have already asked |
Everything above runs inside the messaging window, so no templates are involved and it draws on the free monthly service allowance.
Building the Flow
Build the no before the yes. It is the path that decides how this feels.
- Write the refusal message first. Three sentences: the answer, the reason, what you can do instead. If you cannot write it kindly, the flow is not ready.
- List the triggers that must never automate. Damaged, missing, broken, refund, complaint, legal, and anything resembling a request for a person. These route out immediately.
- Add the eligibility lookup. Order number in, days remaining out. It turns policy recitation into a specific answer.
- Offer the exchange as an option, never as a gate. Presenting exchange before refund is good business. Hiding the refund is how you earn a chargeback.
- Put the human route on every single branch. Including the happy ones. Especially the refusals.
- Read the escalations weekly for a month. They tell you which branch is missing. That is the whole optimisation loop.
The Revenue Case
Returns automation is usually sold as a cost saving. The bigger number is elsewhere.
Exchanges Keep the Money
A refund is revenue leaving. An exchange is revenue staying, and a surprising share of returns are a size or colour problem rather than a product problem. A flow that offers the alternative – with the real product card from your connected store – converts some of those.
It only works if the offer is genuine and the refund stays one tap away.
Speed Changes the Outcome
The same policy applied in forty seconds reads as service; applied in two days it reads as stalling. Most of the goodwill in returns is in the latency, not the terms.
What It Will Not Fix
If returns are high because the sizing is wrong or the photos flatter the product, no flow helps. Read what the returns actually say for a month – the reasons are usually three, and two of them are fixable on the product page.
Returns Are a Support Function Wearing a Retail Hat
Treating them as an e-commerce problem is why they are usually handled badly.
The Same Rules as Any Complaint
A return request has the shape of a support ticket: an unhappy person, a policy, and a decision. Everything known about handling those applies here – acknowledge quickly, be specific, never make someone repeat themselves, and escalate on uncertainty rather than on volume.
Which means the standards worth holding this flow to are support standards, not marketing ones. Customer support KPIs covers what to measure; the short version is resolution rate and time to first useful reply, never deflection.
Escalation Needs a Rule, Not a Judgement
Deciding case by case which returns reach a person produces inconsistency that customers notice and staff resent. Write the rule down: damage, missing items, anything over a value threshold, any second contact about the same order, and any explicit request for a human. Everything on that list routes out immediately, every time.
That list is itself the subject of support escalation rules, and it is worth agreeing before the flow goes live rather than after the first bad outcome.
Where the Real Saving Is
Not in the messages avoided. It is in the returns that never happen because a pre-purchase question got answered properly, and in the exchanges that replace refunds because the alternative was offered at the right moment.
If you want the honest version of what that is worth, it has to be measured against a baseline rather than asserted – reducing support costs with automation goes through how.
Answer the Returns Question in Forty Seconds
Most returns messages are the same three questions, asked by someone who is already slightly annoyed. Every hour they wait makes the conversation harder and the outcome worse.
DMpro answers eligibility and process instantly, offers the exchange with the real product attached, and routes anything involving damage, money or judgement straight to a person with the full conversation.
Conclusion
Returns automation works when it answers facts and refuses to make decisions. Eligibility, process and timelines are all answerable instantly. Whether to bend the policy for a particular person is not, and a flow that tries will eventually do real damage.
Build the refusal first – the answer, the reason, the alternative, and a route to a human on every branch. That is the path customers remember.
And read the escalations for a month after launch. They are the only reliable list of what your flow is missing.
Frequently asked questions
Should returns be handled by a bot?
Partly. Eligibility, process and timelines are facts and automate well. Anything involving damage, a missing item, money or a judgement call should go to a person.
What should an automated refusal say?
Three sentences: the answer, the reason, and what you can do instead – plus a route to a human. Burying a no in apologetic padding reads as evasion and produces a second, angrier message.
Can the flow tell a customer how long they have left?
Yes, with an order lookup. The flow takes the order number, calls your webhook and answers with the days remaining instead of restating the policy.
Does a returns flow need templates or opt-in?
No. The customer messaged you, so you are inside the messaging window. It also draws on the free monthly service message allowance, so for most stores it costs nothing.
Will offering exchanges annoy people?
Only if the refund is hidden behind it. Offered as a genuine option with the refund still one tap away, exchanges keep revenue that would otherwise leave – a good share of returns are a size or colour issue, not a product issue.
What if the flow is not sure whether the order qualifies?
Then it must not say no. Uncertainty is always a handoff – a wrong refusal costs far more than a minute of someone’s time.
