A return comes in. The customer wants two items refunded and a third replaced with a different size. You open the return, confirm what arrived, click Process refund for the two refund items, click Send replacement for the third, pick the size from the variation dropdown. The return closes itself. You move on.
That’s the admin returns workflow: the full return lifecycle in one screen, with the right inspection action sitting next to whatever needs doing, and no jumping around.
The lifecycle every return moves through
A status pipeline, with each transition firing the matching customer email so they always know where things stand:
- Requested: customer has asked; you haven’t decided.
- Approved or Rejected: you’ve made the call.
- Shipped: the customer has posted the items back.
- Received: the items have arrived at your end.
- Inspected: you’ve checked condition and picked the final resolution per item.
- Refunded, Replacement sent, Restocked, Disposed: the resolution is done.
- Cancelled: pulled out of the pipeline.
Per-item resolution, including mixed returns
A single return can mix resolutions: two items refunded, one replaced, one disposed. The inspection screen shows action groups side by side when mixed resolutions are in play:
- Process refund for refund items, with the amount calculated on just those items’ values and any restocking fee applied. Fires through WooCommerce’s refund system without leaving the return screen.
- Send replacement for replacement items, with a variation picker for variable products and an optional stock decrement.
If the return is all-refund or all-replacement, the screen collapses to whichever group applies. Less to look at when there’s less to do.
Change a resolution mid-flow
A customer changes their mind, or the replacement they asked for is out of stock. Click Change resolution on the item, add a short note, and it moves to the other action group. With audit logging on, the change is recorded with who made it and when.
Auto-approve the obvious ones
Low-risk returns can approve themselves on submission, so staff only see the ones that need a human eye. Turn it on in settings and configure the conditions: max days since the order, max value on the return, first-return-only for this customer. Anything matching those conditions goes straight to Approved; anything else sits in Requested for a person to look at.
Restocking and restocking fees
The inspection dialog has a Restock items checkbox. Tick it; the items go back into the WooCommerce stock counter. The restocking fee policy is configured globally (no fee, a flat-dollar amount, or a percentage of returned value). Whatever you’ve set runs automatically on every refund.
If you’re weighing this up against a dedicated returns platform
AfterShip Returns Center, Loop, and Returnly all run mature returns workflows as external SaaS. The customer submits through a portal they host; the data syncs back to WooCommerce through an API; staff process inside their dashboard; pricing is typically per-return or a monthly tier. For high-volume DTC brands with dedicated returns-ops teams, they’re built for exactly that scale.
HQ keeps the whole flow inside your WooCommerce admin. Customer submits through your own site, staff process in the same admin they use for orders, the data never leaves your database. No separate login, no per-return SaaS fee, no sync surface to maintain. Scope is narrower; the tool fits inside the operation you already run.
If you process hundreds of returns a day with a dedicated team, a SaaS platform is probably the better tool. If you want returns to feel like a natural extension of the admin you already work in, HQ is built for that.
Already running a returns-request plugin?
WC Return Manager and similar plugins handle the customer-side request form well. The staff side tends to be thinner: a list of pending returns and not much beyond. HQ’s admin workflow covers the bits that matter once a return lands in your queue: inspection actions, mixed-resolution handling, the restocking checkbox, the fee policy, the per-status emails.
If an existing plugin is handling the request form the way you want, HQ runs alongside rather than replacing it. Keep the customer-facing form; add HQ for the staff workflow.
Why this earns its keep
Returns are where trust gets rebuilt or burnt down. A polished return experience (fast acknowledgement, clear updates, the right resolution without the customer having to repeat themselves) turns a disappointed customer into one who notices how well you handled it.
The admin workflow is built so that polish doesn’t depend on you remembering to add it. The screen does the work: the right actions sit next to the right items, the customer emails fire automatically, the audit trail (if it’s on) captures the lot. You just process the return.