Managing the Order Return Process

When a return request comes in, there are five questions a store owner has to answer: is the request genuine, which items — and how much of each — are being returned, does the product need to come back physically, can the stock be resold, and when should the customer be told what. A well-built return process maps these five questions onto a clear status flow (REQUESTED → APPROVED → RECEIVED → REFUNDED) and assigns a clear owner to each step. This article walks through that flow, partial returns, return shipping, and customer communication.

What are the stages of the return process?

A return request moves through five possible statuses:

1. Requested (REQUESTED) — the customer or you opened the request; no decision has been made yet.
2. Approved (APPROVED) — the request has been accepted and you're waiting for the product to come back to the warehouse.
3. Received (RECEIVED) — the returned product has physically arrived.
4. Refunded (REFUNDED) — the payment has been returned to the customer and the request is closed.
5. Rejected (REJECTED) or Cancelled (CANCELLED) — a request can be rejected or cancelled at any stage; a rejection needs a clear reason communicated to the customer.

The important property of this flow is that it's one-way: once a request reaches Refunded, the payment has actually been refunded and the case is closed — that step can't be undone. That's why it's critical to confirm the product genuinely meets your return conditions before moving it from Received to Refunded, in particular.

How does a partial return work?

Not every item in an order has to be returned — a customer might return just one of three products, or send back only 1 of the 3 units they ordered of a single product. When you create the return, you enter the quantity being returned separately for each order line; the system subtracts whatever has already been returned and shows how many units are still eligible, so you can't accidentally return the same line twice.

Partial returns matter most on multi-item orders: instead of cancelling and recreating the whole order, returning only the problem item and leaving the rest untouched is simpler for both the customer and your operations.

How does the return reason shape customer communication?

The return reason isn't just a field to fill in — it's a signal for what action to take. The common reason categories are:

Reason	Typical action
Wrong item shipped	Operational error — review your fulfillment process
Item arrived damaged	Review your shipping/packaging process
Doesn't match description	Review the product page copy/images
Customer changed their mind	Usually a standard return, no further action needed
Quality issue	Review supplier/manufacturing quality
Other	Read the free-text field and assess manually

When you reject a request, the reason goes straight to the customer — so writing it clearly and courteously matters both for customer satisfaction and as a record you can point to if the customer disputes the decision later. A rejected request can't be reopened; the customer has to file a new one.

How do you manage the return shipment?

Once a return is approved, the product needs to physically come back to you. This usually starts with generating a return shipping label and getting it to the customer; the label and tracking number stay attached to the return record, so you can answer "is it on the way, or lost?" straight from the return record instead of chasing the tracking number through the carrier. When the product arrives, you move the request to Received — this is the last checkpoint before the refund is triggered, and it's where you confirm the item actually meets your return conditions (unused, original packaging, and so on).

How do you record inventory returns?

If a returned product is still sellable, it needs to go back into stock — otherwise the system keeps showing it as "sold" and your stock counts stop reflecting reality. Stock movements have a dedicated reason code for this (Return); when you post the returned quantity back to stock under that reason, the total stock for that product updates and the movement history keeps a record of where that stock increase came from. If the item arrived damaged and can't be resold, keeping it out of stock and logging a separate correction under "Damage" instead keeps your actual sellable stock accurate.

Why does SLA tracking matter?

Every step of a return is expected to move within a reasonable time — a request that sits in "Under review" for too long has a direct effect on customer satisfaction. Tracking a separate time budget for each step — request, approval, receipt — and surfacing requests that are close to or past that deadline keeps the return queue from silently piling up. In stores where more than one person handles returns, being able to answer "which request is overdue" instantly is the foundation of operational discipline.

How should you use return data to improve operations?

The return process isn't only there to close out requests — it's also a data source for spotting recurring problems. Looking regularly at the distribution of return reasons (is "Damaged" trending up in a given period? is "Doesn't match description" concentrated in a specific product group?) lets you trace the root cause — a shipping/packaging problem, misleading product page images or copy, or a dip in supplier quality. Tracking total refund amounts and the ratio of open/approved/rejected requests over time turns the return process from a pure customer-service cost into an early-warning system for product and operational quality.

Frequently asked questions

How long do I have to review a return request? In Türkiye, distance sales law grants consumers a statutory 14-day cayma hakkı (right of withdrawal). Beyond that legal minimum, you're expected to clearly publish your own store policy (for example, a 30-day return window) and respond to requests within a reasonable time, typically within a few business days. Check current legislation for the exact legal deadlines and how they apply to your store policy.

Does the customer have to pay for return shipping? That depends on the return reason and your store policy — if the item arrived faulty or damaged, the shipping cost is usually covered by the seller; if the customer simply changed their mind, your store policy should state clearly who covers the shipping cost.

Can a rejected return be reopened? No, a rejected request can't be reopened — the customer needs to file a new request with additional information. That's why writing a clear rejection reason makes it easier for the customer to understand what to do next.

Does a returned product automatically go back into stock? No, that's a manual decision — because the product may have arrived damaged. The correct approach is to post resellable items back to stock under the "Return" reason, and record damaged ones under a separate "Damage" entry that keeps them out of sellable stock.

Can more than one return request be opened for the same order line? No — the system keeps track of how much of a line has already been returned, and a new request can only be created for the remaining eligible quantity. That prevents the same line from being returned twice by mistake.

What should I do about a product with a high return rate? Start by looking at the distribution of return reasons — if "Doesn't match description" dominates, review the product page images and copy; if "Damaged" dominates, review your packaging/shipping process. Pulling the product from your catalog without identifying the reason first can mean losing revenue without ever fixing the root cause.

Where is this managed in Daras?

In Daras, all return requests appear in a single list on the Returns page; each request is listed with its RMA number, SLA status, and refund amount, and you can approve, reject, or mark it received either from that list or from the related order's detail page. To post resellable stock back, stock movements on the Inventory page use the "Return" reason.