A sound returns process closes three loops: goods back into stock, money back to the customer, and a document recorded. How to build it so none of the three is forgotten.
Key takeaways
- All three loops must close together, or one of them is quietly forgotten.
- Returns are steady volume in an online store, so they need a process rather than case-by-case handling.
- An item re-enters stock only after inspection, not on receipt.
- Most returns-related enquiries come from lack of updates rather than from the return itself.
A return is not one event but three: goods coming back physically, money going back to the customer, and a document recorded in the books. A process that closes only two of the three produces the familiar faults - wrong stock, a double credit, or an item that came back and was never credited.
The three loops
| Loop | Who owns it | What breaks without it |
|---|---|---|
| Goods | Warehouse | Stock showing an item that is not there, or the reverse |
| Money | Bookkeeping / payments | A customer never credited, or credited twice |
| Document | Invoicing system | Books that do not match the physical movement |
That table is also the allocation of responsibility: each loop needs an owner, because a return that falls between two people is a return that stalls.
The flow that works
- The customer requests a return - by form, email or WhatsApp - and a numbered request is created.
- Approval and instructions - what to pack, how, and who collects.
- Collection or drop-off at a point, with tracking.
- Receipt at the warehouse - recorded as an inbound in "awaiting inspection" status, not as available stock.
- Inspection - sound, damaged, or not meeting the terms.
- Credit - full or partial, according to the inspection result.
- A credit document issued and sent to the customer.
- Stock updated by the inspection result - available, damaged, or written off.
Step 4 prevents the most common error: an item that came back broken, recorded as available stock, sold again, and producing a second return and an angry customer.
Why should returning be easy?
Because it happens either way. A store that makes returns hard does not get fewer returns - it gets more service enquiries, more chargebacks, and more negative reviews. The cost of a complicated return is higher than the cost of a simple one.
What is right is defining clear terms: how many days, in what condition, what is required. Clear terms reduce disputes; vague terms are what produce the difficult conversations.
What must be written in advance
- The time window for returns, and the date it runs from.
- The required item condition - original packaging, unused.
- Who pays for the return, and in which cases that differs.
- Where the money goes back - the original payment method, and how long that takes.
- What cannot be returned, if anything.
The fourth generates most enquiries: a customer credited to a card does not see it immediately, so one sentence explaining the timing saves a conversation on nearly every return.
How do you prevent returns in the first place?
A large share of returns come from an expectation that did not match reality, which means they can be reduced without changing the policy:
- Real photographs, not only manufacturer images.
- An accurate size chart, and where possible a recommendation based on measurements the customer enters.
- A description that includes what it is not - material, weight, what is not in the box.
- Reviews from previous customers, including the less flattering ones.
- A pre-dispatch notification that lets the customer change or cancel in time.
The last saves the most expensive return of all: the one made because the customer changed their mind after the parcel had already gone out.
It is also worth separating returns from exchanges. A customer who wants a different size is not asking for their money back - they are asking for service, and most stores handle them through the same return-then-reorder route. A dedicated exchange route, where the replacement goes out before or alongside the original coming back, shortens the process and preserves the sale. It requires a decision about risk - what happens if the original never returns - and in most cases that risk is smaller than the value of a customer who did not cancel.
Who owns the process
In a small business, returns usually fall between customer service and the warehouse, which is why they stall. The fix is not a new role but a definition: one person is accountable for every return request closing, even when the execution is split across several people. In practice that means one list of open returns that somebody reviews every couple of days.
The sign the process is not working is not a complaint but silence: returns sitting in "awaiting inspection" for a fortnight, simply because nobody defined when inspection happens. A short list reviewed each morning removes that almost entirely.
What to measure
Three numbers are enough: return rate as a share of orders, reasons from a short list, and time from receiving the item to issuing the credit. The third affects satisfaction more than anything else.
When analysing reasons, look by product rather than only in aggregate. One product with an unusually high return rate is telling you something specific - wrong measurements in the description, a misleading photo, or quality that does not match the price - and that is a targeted fix with more impact than any policy change.
What happens to stock after a return
This is where returns meet inventory management, which makes it a source of permanent discrepancies. A returned item can end up in three different states - available for sale, damaged, or written off - and each needs its own recorded movement. When every return enters as "available", system stock exceeds real stock, and it only surfaces at the count.
The logic is identical to what is described in inventory in a system versus a spreadsheet: a quantity change with no movement behind it is a number you cannot investigate. In returns it matters especially, because they are the only direction in which goods arrive without a purchase order.
How to update the customer so they never call
Most returns enquiries are not about the return but about not knowing: the customer sent it and has no idea whether it arrived, was inspected, or was credited. Four short messages eliminate nearly all of them - confirmation that the request was received with instructions, confirmation the item arrived, a message with the inspection result, and confirmation the credit was issued with an estimate of when it will appear.
It is the same pattern described in automatic tracking updates to the customer, running in the opposite direction. It is cheap to implement, because all four messages derive from statuses the process already has.
Sources
Frequently asked questions
How quickly should money be returned?
Operationally, as soon as possible after inspection - that is the metric the customer feels. Distinguish between when you issue the credit and when it appears for the customer, because the second depends on the card company, and it is worth saying so in advance.
What do we do with an item that came back damaged?
Photograph it before touching anything, and decide by the policy you defined - full credit, partial, or refusal. What matters is that the answer is consistent between cases, or every decision becomes a negotiation and customers compare notes.
Should the customer pay for return shipping?
That is a commercial decision depending on category and competition. More important than the answer is that it appears clearly before purchase rather than surfacing at the return, because the gap between expectation and reality is what generates complaints.
How do we handle a return from an order that had free shipping?
Decide this in advance: if the return drops the order below the threshold, do you deduct the shipping cost from the credit. Both approaches are legitimate, and the only real problem is not deciding - which leaves every case settled differently.
Keep reading
Related service
Inventory & Purchasing
SKU-level stock, reorder rules and an approval flow that leaves a record.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.
