Skip to content

After a request comes in

The customer has submitted. From their side it’s done — they’re waiting on you now.

From yours, a sequence runs: everything gets checked again, the request is approved or held, a label may be created, replacement orders may be raised, and at some point money moves. Here’s the order, and the decisions you control.

The moment they submit, all the rules run again from scratch: are the items still on the order, is the quantity still free, is anything blocked, do the policies and workflows still allow it, are the swap and fee rules still satisfied.

This isn’t wasted work. Somebody can sit on your returns page for twenty minutes while a colleague changes a policy or another return claims the same item. The second check is what stops a request sneaking through on rules that no longer apply.

A request comes out as one of three things:

  • Approved — it moves forward.
  • Held for review — someone on your team has to look.
  • Refused — it can’t proceed.

Items are judged individually, so a single request can have some items approved and others held or refused.

Worth knowing: one held item holds the whole request, including the label. On a three-item return where one item needs checking, your customer can’t post anything until someone acts. That’s the most common cause of “why haven’t I got my label yet”.

If the item has to come back, a label can be generated and the customer gets instructions. From there your team can follow the parcel and inspect what arrives.

If it doesn’t — a keep-item return, or a warranty where you’ve said they can keep it — no label is created and the request moves on without any shipping step at all.

When someone’s swapping or getting a replacement, that order can be created at three different moments:

  • As soon as the request comes in
  • Once every item has been reviewed
  • Once the return has been fully processed

This one is worth deciding carefully. Creating it immediately gives the best experience and carries the most risk — you’re committing stock before anything has come back. Waiting until processing is safest and slowest. Pick based on what you sell and how often returns actually turn up.

If they spent their credit, those items are saved against the return, a draft order is created, and they’re invoiced if they owe anything on top.

The last decision, and the one most worth thinking about. Refunds and store credit can be processed:

  • Before the parcel is even in transit
  • Once it’s in transit
  • Once it’s been delivered to you
  • After someone has checked it and accepted it

Earlier is better for your customer and worse for you. Refunding before anything ships is the fastest experience available and means paying out for goods you may never see. Refunding after you’ve checked the item is safest, and will get you complaints about how long it takes.

Most shops choose in transit or delivered — the customer sees progress, and you have proof something is actually coming back.

My customer says they haven't got their label. Why?

Usually because part of the request is held for review, and a held item holds the whole thing. Open the request and see whether every item is approved.

Can I change a request after it's submitted?

Your team can act on it during review — adjust fees, change the outcome, approve or refuse individual items. What you can’t do is undo a refund once it’s issued.

When should I create the replacement order?

On approval if your items are inexpensive and returns reliably arrive. Wait until the return is processed for anything expensive, or if you get a lot of returns that never show up.

When should I refund?

On delivery, for most shops. In transit if you want returns to feel fast and can afford to lose the occasional item. After you’ve checked the item for expensive things, or if people are sending back empty boxes.

A customer changed something and now the request won't go through. Why?

Everything is re-checked at submission. If a policy changed, or another return claimed the same item while they were deciding, the request is rejected against the current rules rather than the ones they started with.