Most stores treat returns as an aftercare function. Something arrives back, someone processes the refund, the customer is satisfied or is not, and the matter closes.
That framing is why the expensive part goes unnoticed. A returned item is a unit of sellable stock sitting in your building, invisible to every system you own, while the demand that would have bought it is still live. The customer service cost is real and small. The inventory cost is larger and nobody measures it.
This guide covers the gap between an item arriving back and it being sellable again, what Shopify now does natively, the UK legal position, and where the whole thing stops being manageable.
The gap that costs the money
Follow one item.
A medium navy is returned. It arrives on a Monday. It sits in the returns area because Monday is busy. It gets inspected the following week, restocked on the Thursday, and is live on the site ten days after it walked back through the door.
Now overlay what else was happening during those ten days.
That variant was out of stock — which is frequently why it was returned, if the customer swapped to a different size and you had none. Forty people were on the back-in-stock list for it. Your advertising was running against the product because other variants were available. Someone searching for exactly that item found it unavailable and bought it elsewhere.
You owned the unit throughout. It was in your building. It was in saleable condition. It was worth nothing for ten days because no system knew it existed.
The cost is not the ten days of storage. It is ten days of a stockout you had the stock to prevent. And it compounds with everything else in this series: the ad spend from Guide 04 running against an item you could have supplied, the back-in-stock subscribers from Guide 06 waiting for stock that was already on site, the reorder point from Guide 03 firing a purchase order for units you already had.
Cutting return-to-resale from ten days to one is not a customer service improvement. It is an inventory recovery.
What does Shopify do natively for returns?
More than most comparison articles credit, and it has moved considerably in the last year.
- Self-serve returns, activated at Settings → Customer accounts. Customers request returns from their account; you approve or decline.
- Return rules at Settings → Policies: return windows, who pays return shipping, restocking fees, final-sale exclusions. These apply to manual returns from the admin even if self-serve is switched off.
- Return labels and shipment tracking.
- Exchanges processed from the admin, and store credit.
- Category-specific return reasons, available since January 2026 across admin, POS, self-serve returns and the Shop app.
- Cancellation requests, added June 2026, letting customers cancel before fulfilment.
- POS return rules for in-store returns.
Known limitations: customers cannot request an exchange through native self-serve returns, only a return, and there are no exchange-specific rules. There is no branded customer-facing portal. Per-market rules are in early access rather than generally available.
For a store under £1m, the native tooling is sufficient for the mechanics. What it does not do is close the gap described above — that is a warehouse process problem, not a software one.
What is the UK legal baseline for returns?
Most returns content is written for the US market and is misleading here. The following is a summary of the general position, not legal advice — verify against current guidance or take advice before setting policy.
Under the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, for goods sold at distance:
- The customer has 14 days from receiving the goods to cancel, for any reason, with no explanation required.
- They then have a further 14 days to send the goods back.
- You must refund the item price plus the basic outbound delivery cost within 14 days of receiving the goods back. If the customer paid for premium delivery, you may retain the difference between that and your standard rate.
- Return postage may be charged to the customer only if you told them so clearly before purchase. If you did not, you bear it. Sources vary in how they describe this and it is worth confirming for your own policy wording.
- Exclusions include personalised or bespoke goods, perishables, and items sealed for hygiene reasons once unsealed.
Separately, under the Consumer Rights Act 2015, faulty or misdescribed goods carry a 30-day right to reject with a full refund, and you cover return costs.
The trap worth flagging. Shopify's return rules let you configure a restocking fee. Within the statutory 14-day cancellation window, the Regulations require reimbursement of all payments received, which is generally understood to prohibit restocking, administration and handling fees. A UK merchant who switches that setting on without qualifying it may be operating an unlawful policy against exactly the returns most likely to occur.
If you offer a longer goodwill window beyond the statutory period — 30 or 60 days — different terms can apply to that additional portion, because it is your policy rather than the customer's statutory right. Keep the two clearly separated in your policy wording.
Return reasons are the most under-used data in a small store
Shopify captures a reason on every return and almost nobody reads them in aggregate.
Sort ninety days of returns by product, then by reason. The patterns that emerge are actionable in a way most analytics are not:
- One product with a high "too small" rate has a sizing problem. Add a size guide, or adjust the size chart, or change the product copy. This is a fix, not a trend.
- A high "not as described" rate is a photography or copy problem on that specific listing.
- "Damaged on arrival" concentrated on one product is a packaging problem.
- High returns concentrated on one variant may indicate a manufacturing inconsistency worth raising with the supplier.
Return rate is a vanity metric. Return reason by product is a work list. For a store at this size, three or four listing fixes identified this way will outperform most conversion optimisation work, and cost nothing.
What processing discipline do returns need?
The operational half, and it is mostly about removing decisions rather than adding tools.
Set a target and measure it. Return-to-resale time in hours, from arrival to live in Shopify. If you have never measured it, measure it for two weeks before changing anything. The number is usually worse than people expect.
Grade on arrival, in one pass. Resaleable, needs attention, not resaleable. Three outcomes, decided once, by whoever opens the parcel. Items that get set aside for a second look are the ones that sit for a fortnight.
Restock the resaleable immediately. Not at the end of the day, not when the refund is processed. The refund and the restock are separate actions and only one of them is time-critical to your inventory.
Prioritise by stock position, not by arrival order. A returned item whose variant is currently at zero should be processed first, every time. This is the single highest-value change in this guide and it requires no software: a list of currently out-of-stock variants, checked against what came back today.
Have a standing decision for non-resaleable stock. Repair, discount channel, or write off. Deciding case by case is how a corner of the unit fills up with items nobody will ever choose to deal with.
Exchange rather than refund, where you honestly can
An exchange retains the revenue and moves stock. A refund does neither. Native Shopify handles exchanges from the admin, though not through self-serve.
Two cautions. Pushing exchanges too hard on customers who want a refund damages the relationship and, within the statutory window, they are entitled to the refund regardless of what your portal offers. And an exchange is only genuinely better if the replacement is in stock — offering an exchange for something unavailable creates a second problem out of a first.
When does a returns platform earn its fee?
Loop, ReturnGO, AfterShip and the rest are good products built for higher volume than a sub-£1m store generates. Entry pricing plus per-return fees means the software cost per return at twenty returns a month is substantial before it has done anything.
The economics turn when recovered revenue from automated exchanges exceeds the platform cost, which in practice tends to be somewhere around 100–200 returns a month. Below that, native returns plus a clear policy page will serve, and AfterShip has a usable low-cost tier if you want a branded portal sooner.
Buying a platform will not fix return-to-resale time. That gap is in your building, not in your software.
The App Ceiling
This section appears in every one of The Operational Guides. It describes where the advice above stops working.
Everything above holds to roughly £1m–£1.5m in annual revenue. Past that point the constraint changes, and it changes in a way that adding further apps does not address.
Apps are built to be sold to many stores. That is what makes them affordable, and it is also what limits them: an app can only act on the data inside its own boundary. Your forecasting tool does not know what your ad platform is spending. Your ad platform does not know what is out of stock. Your back-in-stock tool does not know what your supplier lead times are. Each app is correct within its own scope and blind outside it.
Below roughly £1m, a person bridges those gaps. Someone looks at the stock report, notices a line is running low, and adjusts. The bridging is invisible because it is absorbed into the founder's day.
Above roughly £1m, three things happen at once. SKU count rises, so there is more to bridge. Order volume rises, so the consequence of missing something rises with it. And the founder's time is now spent on growth rather than operations, so the bridging stops happening reliably. Nothing breaks visibly. Revenue keeps climbing. What changes is that a percentage of it begins to leak in places nobody is looking — advertising spend running against unavailable variants, stock accumulating in the wrong location, returns sitting unprocessed for a week and a half while the item they contain is out of stock and being advertised.
That is not an app problem, and no app solves it, because the solution has to sit between systems rather than inside one. It requires something built for your specific stack, your specific SKU structure, and your specific supplier terms.
Returns are where every thread in this series meets. The returned unit is inventory, so it belongs to forecasting. Its variant may be out of stock, so it belongs to advertising. People are waiting for it, so it belongs to messaging. It arrived at one location and the demand may be at another, so it belongs to allocation. Your returns platform knows only that a parcel came back. Prioritising the queue by stock position — the change that recovers the most money — requires knowing all four things at once, and no returns app is built to know any of them.
Where to start
Measure return-to-resale time in hours for two weeks. Do nothing else first.
Then make one change: before processing today's returns, check which of those variants are currently at zero, and do those first. It costs nothing, it needs no software, and it converts dead stock in your building into stock you can sell to people who are actively waiting for it.