Returns took 11 hours a week and still refunded the wrong amounts

Representative build. This describes a system we build and the numbers typical for it, drawn from published benchmarks and our baseline model. Verified, client-signed studies will replace representative ones as permissions land.

The inbox that never empties

Ask an apparel brand where the day disappears and a surprising number point at the same place: the returns inbox. A customer wants to send something back. Someone reads the email, checks whether it is inside the window, looks up the order, decides if it is a refund or an exchange, works out the amount after any promo and shipping, issues a label, and later remembers to restock the item once it arrives. Then they do it again, forty times.

At a mid-seven-figure apparel brand, this is about eleven hours a week. It is not hard work. It is just relentless, and because a human is doing arithmetic under time pressure, some of those refunds are wrong.

What it costs, worked at one size

Take a brand doing roughly $8M a year with a small CX team. The four line items look like this:

Line item	Worked example
Labor	11 hrs/week x $38 loaded x 48 weeks = ~$20,100
Tools	A returns app used at a fraction of its capability, ~$1,400/yr
Errors & rework	Over-refunds, missed restocking fees, refunds outside policy: ~$18,500/yr
Opportunity	CX lead pulled off retention and VIP work: ~$7,000/yr

That comes to about $47,000 a year for one process. The errors line surprises people most. When the amount is computed by a tired person, the mistakes run one direction more than the other: customers rarely email to say they were refunded too much.

What we build

A returns pipeline on the brand’s own stack, so nothing leaves systems they already control:

• A self-serve intake where the customer starts the return, so the details arrive structured instead of as free text in an inbox.
• A policy engine that applies the actual rules: the window, final-sale items, the difference between a refund and an exchange, restocking fees where they apply.
• A refund calculator that gets the amount right every time, net of promos, partial discounts, and original shipping.
• An exceptions queue for the genuinely odd cases, so a person spends their time only where judgment is needed.
• A restock sync so approved returns update inventory automatically, instead of relying on someone to remember.

The first version runs on real return volume in about nine days, watched alongside the manual process for a week before anyone trusts it with money.

One honest complication

Apparel is not clean. A large share of “returns” are really size swaps, and a swap is not a refund with a new order bolted on; treated that way, it double-counts inventory and confuses the payment reconciliation. On builds like this we spend an extra few days modelling the exchange path properly, because getting it wrong is worse than the manual process it replaces. It is the kind of edge case the audit is meant to surface before a number is agreed, not after.

What changes

The eleven hours become about one, spent reviewing the exceptions queue. Wrong refunds drop by roughly 90%, because the amount is computed the same way every time. Restocking stops leaking, because it is no longer a thing a person has to remember on a busy afternoon. The CX lead gets most of a day a week back for the work that actually retains customers.

Why it generalizes

Every store’s return policy is different, but the shape is identical: intake, decide, calculate, label, restock. Once the engine exists, adapting it to the next brand’s rules is fast, which means a quicker build and a cleaner estimate for them. If your team starts the morning inside the returns inbox, that is a candidate worth measuring. See what it would save you; you keep the number either way.