A compact returns‑routing SOP: a decision tree to send returns to vendor, repair, donate or restock

Most return desks in small apparel shops run on gut feeling. An item comes back, someone eyeballs it, and it either goes back on the rack, into a pile "to deal with later," or straight to the donation bin because nobody wanted to think about it. That pile is where money quietly dies. A sweater that could've gone back to the vendor for full credit sits for six weeks past the return window. A pair of jeans with a broken zipper — repairable for $4 — gets donated because the vendor window closed and repair felt like a hassle.

The problem isn't that owners don't care. Returns disposition is a routing decision, and routing decisions made inconsistently by whoever happens to be standing at the desk will always leak value. What you need is a small decision tree that sorts every returned item by two things — its condition and its SKU value — then assigns a destination, a label, and a deadline. That's the whole SOP. This post lays it out for a small retailer.

Why returns leak value in the first place

Returns get sorted by emotion, not by economics. An item in rough shape feels like garbage, so it gets tossed or donated even if the vendor would've taken it back. An item that looks fine goes straight to the floor even if it's a slow-moving SKU that'll just sit and eventually get marked down to nothing.

1. 1
   Vendor return authorizations (RAs) usually expire — often 30 to 60 days from receipt or from the original invoice.
2. 2
   Damaged-goods claims to suppliers have their own windows.
3. 3
   Repair costs go up the longer an item waits (the defect worsens, or you lose the season entirely).
4. 4
   Restock value drops as the season ages.

When there's no timeline attached to a returned item, it defaults to the slowest possible outcome. Nobody decides to let a vendor RA expire — it just happens because the item sat in a bin with no deadline on it. Not bad decisions, just no decisions.

If you haven't already looked into why items are coming back in the first place, that's worth doing in parallel. This SOP handles what to do with a return, but a simple returns analytics pack tells you which SKUs and sizes are generating the volume so you can shrink the problem upstream.

The two variables that decide everything: condition and SKU value

You don't need a complicated grading system. Two axes are enough.

1. 1
   Condition — sort into three buckets

2. 2
   - A / Sellable

   tags on or off, no visible wear, no damage. Can go back to the floor as-is.

3. 3
   - B / Recoverable

   minor issues. Missing button, loose seam, small stain that cleans, needs steaming or re-tagging. Fixable for a few dollars.

4. 4
   - C / Damaged

   structural damage, stains that won't lift, worn condition, missing critical components. Not sellable without significant cost.

SKU value — sort into two bands:

1. 1
   - High-value

   full-price or near-full-price items where recovery is worth real money. Usually your higher-margin denim, outerwear, dresses, footwear.

2. 2
   - Low-value

   basics, clearance-adjacent items, low-margin SKUs where the labor of repair or vendor return costs more than the item's recovery.

SKU value matters as much as condition because a $12 recovery on a basic tee isn't worth 20 minutes of staff time filling out an RA form. A $90 jacket with a fixable seam absolutely is. The whole point is to spend effort where the money is.

The decision tree

Run every returned item through this at the return desk, or in a daily batch.

1. 1
   1. Is it Condition A (sellable)? - Yes → RESTOCK. Re-tag if needed, check it's in-season and not a slow mover, put it back on the floor. If it's a slow-moving SKU heading toward markdown anyway, flag it for clearance instead of full-price restock. - **No → go to step 2.
2. 2
   2. Is it Condition B (recoverable) or C (damaged)? - Condition B → go to step 3. - **Condition C → go to step 4.
3. 3
   3. Condition B — is the SKU high-value? - High-value → REPAIR if repair cost is under ~30% of recovery value. Otherwise check vendor return eligibility. - Low-value → REPAIR only if it's a 2-minute fix (re-tag, steam, tighten a button). If not, route to DONATE.
4. 4
   4. Condition C — is there an active vendor RA window? - Yes → VENDOR RETURN. File the claim immediately. - No, and item is high-value → assess REPAIR one more time. If not economical, DONATE. - **No, and item is low-value → DONATE.

A quick visual of this decision tree can make it faster for staff to follow at the desk.

Four destinations: Restock, Repair, Vendor Return, Donate. Every item lands in exactly one, and every one carries a deadline.

Routing labels and timelines

The labels are what make this actually work when you're not the one standing at the desk. Print small colored tags or use a stamp — whatever's cheap. The point is that anyone can look at an item and know where it goes and by when.

The 48-hour rule on vendor returns is the single most important line in this whole SOP. That's the one with real money and a hard expiry. Everything else can slip a day or two without much cost. An RA that expires is gone — you eat the full loss on something the supplier would've credited back.

One practical detail: keep a physical staging area with four labeled bins matching the four destinations. Returns don't get "processed later" — they get dropped into a bin the moment they're graded. The manager clears the Orange and Yellow bins daily; the Gray bin clears weekly.

A quick recovery-value example

Say a shop processes around 60 returns in a slow month. Under the old eyeball system, a rough split might look like this: about 40 get restocked, and the remaining 20 mostly end up donated because sorting them felt like too much work.

Running those same 20 through the tree changes things. Maybe 6 are Condition C on high-value SKUs still inside the vendor window — filed as RAs, that's real credit back, somewhere in the $30–$70 range per item depending on the piece. Another 5 are Condition B fixes: a $60 dress with a loose hem costs $3 to repair and goes back at near full price. The rest genuinely belonged in the donate pile.

The math isn't dramatic per item, but it compounds. A handful of vendor credits and a few cheap repairs each month can add up to a few hundred dollars that used to walk out the door in the donation bin — and none of it required buying new inventory. It's recovery on stock you already paid for.

Where restock decisions overlap with markdown strategy

One trap worth flagging: don't reflexively restock every Condition A item at full price. A returned item that's technically sellable but belongs to a SKU already sitting slow is just going to age again on the floor. When you restock, check the SKU's velocity. If it's already drifting toward clearance, route it into your markdown flow instead of full-price floor space.

Returns routing and deadstock decisions touch each other here. If a returned item is part of a slow-moving group, the smarter move is usually to fold it into your existing markdown cadence rather than treat it like fresh inventory. The step-by-step decision flow for slow-moving SKUs pairs naturally with the Restock branch — think of returns as a feeder into that system rather than a separate problem.

When this SOP makes sense — and when it's overkill

When it makes sense:

1. 1
   You process more than a handful of returns a week and they pile up.
2. 2
   You sell a mix of full-price and clearance goods, so SKU value genuinely varies.
3. 3
   You've ever let a vendor return window expire without meaning to.
4. 4
   More than one person handles the return desk and consistency is a real issue.

When it's overkill:

1. 1
   You do only a few returns a month and you personally handle every one. At that volume the logic lives in your head fine.
2. 2
   Your vendors don't accept returns at all — then you only have three destinations and the SOP simplifies considerably.

Single-owner shops with very low return volume probably don't need the full four-bin setup. A simple "fix, floor, or donate" call takes ten seconds. Don't build process where there's no actual leak. The bins and labels earn their keep when volume and multiple hands make consistency the real problem.

Making it stick

The failure mode for any SOP like this is that it works for two weeks and then quietly dies. Returns start getting processed "later" again, the RA bin doesn't get cleared daily, and you're back to donating recoverable stock.

1. 1
   Grade at intake, not later. The moment a return hits the desk, it gets a label and a bin. No middle "to sort" pile.
2. 2
   Assign the RA bin to one person with a daily check. Vendor returns are the money bin; they can't depend on whoever happens to be around.
3. 3
   Review the donate bin weekly before it goes out. A quick second look catches the occasional high-value item that got miscategorized.
4. 4
   Track your split monthly. How many restock / repair / vendor / donate? If the donate share is creeping up, either grading is getting lazy or your return quality is genuinely declining — worth knowing which.

“

Assign the RA bin to one person with a daily check.

The whole thing hinges on knowing which vendor windows are still open and which SKUs are already moving slow. Whether you track that in your existing system or a simple shared sheet doesn't really matter — what matters is that the RA deadline and the SKU velocity are visible at the moment someone's making the routing call, not buried somewhere nobody checks.

Bottom line

Returns disposition for a small retailer isn't complicated once you stop treating each item as a one-off judgment call. Two variables — condition and value — feed four destinations, each with a label and a deadline. The biggest recovery win is almost always the 48-hour vendor-return rule, because that's the money with a hard clock on it. Build the bins, assign the owners, grade at intake, and the recovery value you've been quietly donating away starts staying in the business where it belongs.