Open any merchant subreddit or the Shopify community forums and you will find the same quiet complaint about returns, written a hundred different ways. It is rarely about the money going back. It is about the work. Every return request has to be read, judged against a policy that lives mostly in someone's head, approved by hand, and then turned into a refund or, if you are willing to do the extra steps, into a brand new order for the size they actually wanted. None of it is hard. All of it is manual. And it never stops, because returns scale with sales.

That last part is what makes returns different from most support pains. A good week makes them worse. The more you sell, the more comes back, and the bigger the queue you wade through every morning. For a store doing real volume, returns stop being an occasional chore and become a standing line item on someone's day.

Returns are the one workflow that grows in exact proportion to your success. The better the month, the longer the queue. Anything you do by hand here, you have signed up to do forever.

How big the pile actually is

The volume is not a rounding error. Across online retail, roughly one in five orders comes back. The National Retail Federation's 2025 returns work pegs the ecommerce return rate at about 19 to 20 percent, and in apparel, where size and fit are a guess until the box arrives, it runs much higher, commonly 20 to 40 percent of orders. Around 45 percent of all returns trace back to sizing, fit, or colour. Hold onto that number, because it is the whole argument for exchanges.

A return that is really a sizing problem is not a customer who changed their mind. It is a customer who still wants the product, just in a medium. If you can hand them the medium, you keep the sale. If all you can do is refund, you lose it, and you pay for the privilege of losing it: return shipping, inspection, restocking, and the support time to push it all through.

What Shopify actually does, and where it stops

Shopify has native returns, and on paper it looks handled. A customer can request a return from their order page, you can generate a return label, and you can issue the refund from the admin. The trouble is in the gaps between those steps, and the gaps are where the work lives.

First, nothing auto-approves. Even with self-serve returns turned on, every request waits for you to manually approve or decline it. There is no native rule that says "if it is within thirty days and not a final-sale item, approve it." You are the rule, and you run it by hand, one request at a time. Shopify Flow, the usual escape hatch, cannot fully automate the approval either.

Second, and this is the one that costs real money, Shopify does not run true exchanges. A customer cannot request an exchange through self-serve returns, and you cannot write exchange-specific rules. To get someone a different size you generally refund or cancel the original order and create a new one by hand, or you bolt on a third-party app. Because the refund is the path of least resistance, the request that should have stayed a sale becomes money handed back.

Third, the policy controls are thin. Shopify lets you set return windows based on delivery date and product, and not much else. If your real policy depends on order tags, customer type, fulfilment date, or whether the item was discounted, the platform cannot express it, so you enforce it in your head while clicking through the queue. And refunds go back only to the original payment method, so offering store credit, which keeps the money in your store, is another manual workaround.

◆ DATA A single return is a bill paid five or six times: the support minutes to read and reply, the admin clicks to approve and refund, the return shipping, the inspection and restock, and the lost margin whenever a swap collapses into a refund. The refunded amount is just the line you happen to see. The rest is quietly billed to someone's afternoon.

Why the usual fixes don't hold

Once the queue starts to hurt, three coping strategies show up. Each buys a little relief and each breaks in a familiar way.

"Just process them faster." The plan is to keep the queue short by clearing it more often. It works on a slow week and falls apart right after a sale or a launch, which is exactly when returns spike, because that is when you shipped the most. Speed is not a process. It is a person volunteering to be the process.

"Push store credit in the replies." Nudging people toward credit or an exchange does retain revenue, and it is the right instinct. But done by hand it means writing the same persuasive reply over and over, then manually issuing the credit or building the replacement order, on top of everything else. The good idea dies of tedium.

A Shopify Flow rule. Flow is genuinely useful for reacting to structured events. A return request is not really one. It arrives as a sentence a person wrote, "the large was too big, can I swap for a medium," and the decision underneath it needs judgement: is it in window, is the item eligible, is this a serial returner, do we exchange or refund. Flow can tag and route, but it cannot read the request, weigh it against your policy, run the exchange, and settle the money. The trigger it would need does not exist, because the input was never a field. It was a paragraph.

What the automation actually has to do

The real job is not "let people start returns." It is "take a return request, decide it against our policy, turn it into the best outcome for the store, and settle everything, while flagging only the cases that genuinely need a human." That means reading natural language, checking the order's real state, and acting end to end. As a Dugong playbook, in plain prose, it reads like this: 

# trigger
When a customer asks to return or exchange an item

# steps
1. Match the message to the order and read what
   they want back, and why
2. Check eligibility: in window, not final-sale,
   item condition claimed, customer history
3. If it's a size or colour swap and the new
   variant is in stock → offer the exchange first
4. If they accept → create the replacement order,
   send the return label, settle any price difference
5. If they want money back and it meets policy →
   approve, offer store credit with a small bonus, else refund
6. Confirm in plain language: "Approved. Medium is
   on its way, return label attached, no charge."
7. If anything is off (out of window, high-value,
   repeat returner, item flagged) → hold it and queue it for me with
   the full context

Seven lines. The compiler fills in everything underneath: parsing the message, matching the order, reading return eligibility and fulfilment status through the Shopify API, creating the exchange order, generating the label, issuing credit or a refund, sending the confirmation, and routing the exceptions. The merchant never drew a flowchart for every return type. They described how they would want a sharp returns lead to work the queue, and let the compiler build what it takes.

◆ NOTE The goal is not to rubber-stamp every return. It is to clear the easy, in-policy majority automatically, the size swap, the unworn item inside the window, and to put a clear guardrail around the rest. Automate the safe cases and your team's attention is freed for the judgement calls: the repeat returner, the high-value claim, the item that came back damaged.

Why this is a compiler problem, not an app problem

There are excellent returns apps in the Shopify ecosystem, and for many stores they are the right call. But an app hands you its author's idea of a returns policy, exposed as a settings page. What most merchants actually want is to encode their policy: free exchanges for the first thirty days, store credit with a five percent bonus instead of a refund, no returns on final-sale items, always flag a third return from the same customer in a quarter, auto-approve anything under twenty dollars rather than pay to ship it back. Those are sentences, not toggles, and they are specific to how your store makes money.

A natural-language compiler is the unlock because returns were never really a forms problem. They were a judgement problem wearing a forms problem's clothes. Issuing the refund is the easy part. The hard part is everything around it: read the request, decide if it qualifies, choose exchange over refund when you can, settle the money, tell the customer, and know when to stop and ask a person. You can write that down in a paragraph. You could never maintain it as a sprawling rule tree with a branch for every edge case.

The workflow worth building this week

If your returns queue has become a standing item on someone's morning, this is the automation to build before any upsell or win-back flow, because it pays you twice: it removes the manual clicking, and it turns a chunk of refunds back into kept sales. It sits right next to two pains we have written about already. When the request is really a post-purchase change of mind, it overlaps with the order change that races your warehouse, and every return that resolves cleanly is one less "where is my order?" follow-up later.

Describe it the way you would brief a careful returns hire on day one: here is how to find the order, here is what we will and will not take back and for how long, here is when to offer an exchange or credit instead of a refund, here is how to settle the difference, and here is when to stop and flag it for me. That is the whole brief. The compiler does the reading, the approving, and the swapping. You keep your attention for the returns that truly need it. A smooth returns experience is also what brings people back: shoppers who have an easy return are far more likely to buy again, which is the quiet upside of getting this right.

◆ READING If this resonates, two companion pieces: our field study on the Shopify automations no one builds (where returns are under 1 percent of what merchants automate, despite scaling with every sale), and the dispatch on the overselling problem no one automates.

If you are a Shopify merchant who has built a returns playbook that finally tamed the queue, or you have a refund-instead-of-exchange story that still stings, the inbox is open: field-notes@dugong.live. We are collecting case studies for the next issue.