Managing Online Returns and Replacements Without Losing Control of Orders
Make the path from request to return and closure traceable.
SqualiOnline editorial team · 2026-09-07
A return is an order coming back with no number, no delivery date, and no one waiting for it. That's why it gets lost: no one tracks it the way an outgoing order is tracked. This guide is meant to give the return path the same statuses, the same owners, and the same traceability as a sale.
The problem is almost never the single return. It's the case stuck halfway: the customer says they've shipped it, the warehouse shows nothing, accounting doesn't know whether to refund, and none of the three is wrong, because none of them is looking at the same data.
What to collect when the request comes in
The request should be opened with the information needed to decide, not with every possible piece of information. Asking too much stalls the customer; asking too little costs three emails.
- The order and the specific product, with the quantity: an order can contain several items and only one of them comes back.
- The reason, chosen from a short, closed list — not what I expected, defective, no longer needed, wrong size, our mistake — with a free-text field for anything else.
- The condition of the product and the packaging, and a photo when the reason is a defect or shipping damage.
- What the customer wants: refund, replacement, repair. Asking this upfront avoids a round of follow-up questions.
The reason chosen from a list is the only non-negotiable part. It's what will let you understand, months later, whether a product is coming back because it's poorly made or because the product page describes it poorly.
Three statuses that get confused
Most problems come from treating as a single thing three different moments, which can be weeks apart.
- Request received. The customer has written in. Nothing operational has happened yet, but the response clock starts here.
- Return authorized. Someone has decided the return can go ahead, under what conditions, and how the item should come back. From here, the customer knows what to do and the warehouse knows what to expect.
- Return verified. The package has arrived, been opened, its contents match, and it's been inspected. This is the only status that authorizes financial closure.
The flow, with an owner for each step
Every status needs three things: who moves it forward, what has to be true to move it forward, and what the customer sees at that moment. What follows is a sample structure, to be aligned with your own terms of sale.
| Status | Who moves it forward | Condition to move to the next | What the customer sees |
|---|---|---|---|
| Request received | Customer support | Complete data and case falling within the terms | Receipt confirmation with the case reference |
| Under review | Customer support, with the technician if there's a defect | Decision made: authorized, rejected, or alternative proposed | A holding message if the review takes time |
| Return authorized | Customer support | Instructions sent and reference communicated to the warehouse | How and where to ship, by when, with the reference to state |
| Awaiting return | Warehouse | Package arrived and matched to the case | Nothing, until it arrives |
| Return verified | Warehouse | Contents match and inspection carried out, with an outcome | Receipt confirmation and what happens now |
| Closed | Accounting | Refund issued or replacement shipped | Refund document, or tracking for the new shipment |
Two columns deserve attention. “Who moves it forward” must contain a role, not a person's name, otherwise the process stops when that person is on vacation. “What the customer sees” exists because most follow-up requests come from silence, not from delay.
Refund and replacement aren't the same path
A refund closes a case. A replacement opens a second one, and from that point on there are two things to track instead of one.
- A replacement depends on availability: if the product isn't in stock, the customer is waiting for something with no date anyone has told them. Decide in advance how long before it converts into a refund.
- The replacement unit needs to be reserved when the return is authorized, not when the old one comes back, otherwise it ends up sold to someone else in the meantime.
- The returned product needs to be classified: resellable, to be refurbished, to be discarded. If this decision has no owner, the goods sit on a counter and the system's stock availability is wrong.
Count the reasons, not just the units
The number of returns alone says nothing. The reasons, read alongside the product, tell you what to fix and where.
- A product that often comes back because “it wasn't what I expected” has a product page problem: missing measurements, materials, photos, or a size reference.
- A product that repeatedly comes back for the wrong size needs a size chart, not a discount.
- A reason that recurs only for one carrier or one area is a shipping or packaging problem, not a product one.
- An increase that follows a promotion tells you you're selling to the wrong audience.
A review every few months is enough, with two questions: which products come back most often, and which reason shows up first. These are the two data points that get something changed upstream, where the return is avoided instead of handled.
What this guide doesn't cover
This guide organizes the internal path: statuses, owners, traceability. What you're required to grant, under what terms, and with what disclosure obligations depends on the rules that apply to your case and on your terms of sale: that's a matter for a lawyer to check, and this guide doesn't replace one. The information to put on product pages to avoid returns, and the handling of paid, failed, or refunded orders, are covered separately.
Frequently asked questions
Do I need a dedicated form, or is email enough?
With few returns per month, email works, as long as there's a single place listing open cases with their status. A form becomes useful once cases start overlapping: it always collects the same information and assigns a reference that the warehouse and accounting can search for.
Who decides whether a return is acceptable?
The role needs to be named in advance, along with the cases that role can decide alone and the ones that get passed to someone else. Without this division, every doubtful case stalls waiting for an answer no one feels authorized to give.
How often should you review return reasons?
A review every few months is enough for most companies, with one exception: when a new product enters the catalog or a vendor changes, it's worth looking sooner, because that's when a problem can still be fixed at low cost.
Let's organize your post-purchase support process.
If you’d like to talk it through, the service that handles this is E-commerce.