"Our returns process was all manual"
That's Nikolas Callas, Director of Operations at the footwear brand Marc Nolan, describing what returns looked like before they automated the process:
"Our returns process was all manual. In the beginning, we were communicating with customers about their returns via phone, email, text, or through social channels. We also had to manually create labels and send them through each of these channels."
There was no tracking, no analytics, just spreadsheets. Callas put the result plainly: "We were working in the dark with our customers, hoping they received the shoes that they wanted in exchange or got their money back on time. It was very rough." (Source: AfterShip's Marc Nolan customer story, archived here.)
I'm quoting an operations lead, not a founder, because that's the verified quote I could find, and it's a better data point than a founder's paraphrase of the same problem: whoever owns the process day to day usually describes it more precisely than whoever owns the P&L. What Callas describes matches a pattern I've seen repeated, unattributed, across founder interviews and forum threads on returns handling, but I haven't verified a second sourced account naming numbers the way Callas did, so treat it as a directional pattern rather than an independently confirmed one: a return process built on people checking things by hand, across too many channels, with no record of what happened until someone goes looking for it.
Why every return depends on someone getting it right
A return request is really several decisions, stacked. Is the order inside the return window? Was the item purchased at full price or a final-sale promotion that excludes returns? Is this a first return from this customer or the fifth this month? Does the SKU qualify for exchange, refund, or store credit only? None of that is hard to check individually. It's hard to check consistently, at volume, by a person who's also answering five other tickets that hour.
Damage claims are the same problem with more steps bolted on. A customer has to describe what's wrong, usually attach photos, and then wait for someone to actually look at them; furniture and other bulky goods make this worse because the item is expensive enough that nobody wants to approve a replacement on a rushed read of two blurry pictures. That review sits in a queue. Then it needs a decision: full replacement, partial refund, request better photos. Then, often, a follow-up call because the customer wants to know what's happening and the honest answer is "still waiting on someone to look at it."
Here's the part that's easy to miss: the sale already happened. The company already spent money to acquire this customer and already delivered a product. A slow, opaque return process doesn't just cost the (usually much smaller) cost of the return itself, it puts the entire relationship at risk on top of it. Callas's line about "working in the dark" is the tell: when a company can't see its own return pipeline, it can't reassure a customer who's asking a completely reasonable question: where's my exchange?
What a solution could look like
There's a real range of options here, and none of them is free of tradeoffs.
A returns-management SaaS platform (Loop, AfterShip Returns, Return Prime, and others in that category) gives you a self-serve portal, automatic label generation, and policy rules configured through a dashboard. This solves the "all manual, all on spreadsheets" problem well, fast to set up, and it's the right call for a lot of brands. The tradeoff is that you're bounded by whatever logic the platform's rules engine supports. Anything genuinely custom to your business (a loyalty-tier exception, a bundle-specific rule, a warehouse-specific routing decision) either doesn't fit cleanly or needs a workaround.
A manual, email-based process is what most brands start with and what Marc Nolan describes above. It's cheap to run at low volume and it's the first thing that breaks as volume grows, because it depends entirely on a person being available, paying attention, and applying the policy the same way every time.
A rigid, no-exceptions auto-approval bot is the opposite failure mode. It's fast and it feels automated, but if it can't tell the difference between a legitimate size exchange and a customer who's returned twelve items this quarter, it either approves things it shouldn't or gets so conservative it stops being useful. Speed without judgment just moves the risk somewhere else.
A custom policy-check-plus-label automation, with a person in the loop only for ambiguous cases, is the approach that actually holds up: fast on the cases that are genuinely simple, and honest about which cases aren't.
The system I'd build
Here's how I'd actually build this, for a brand whose order and inventory data lives somewhere queryable (Shopify, a WMS, whatever the source of truth is).
The request comes in through a form or a support channel and the first thing the system does is pull the order: purchase date, price paid, promotion flags, SKU, and the customer's return history. This is the same principle I use in support automation generally: ground every decision in the actual data before anything acts on it, not on what the policy usually says.
From there, a policy-check step runs the request against the brand's actual rules. Inside the window, full price, first return this quarter, standard SKU? That's a straightforward approval. The label or replacement order generates automatically and goes out same day, no queue, no person needed to notice the request and act on it.
Damage claims get one more step: the photos still need a look, but instead of a queue that someone works through in batches, the system flags high-value items and unclear photos for priority human review, and auto-approves the cases where the damage is obvious and the item value is low enough that a fast replacement is cheaper than a review cycle. That threshold is a business decision, not a technical one, and it's worth setting deliberately rather than defaulting to "review everything."
Stock updates happen on scan-back, not on approval. The moment the returned item is physically scanned into the warehouse, inventory reflects it. This matters more than it sounds: approving a return doesn't mean the item is back, and treating those as the same event is how brands oversell stock that's still in transit.
Everything that doesn't clear the policy check cleanly (return outside the window, repeat-return pattern, high-value damage claim, anything the rules don't explicitly cover) routes to a person, with the order history and the reason it got flagged attached. Same principle as the confidence gate in a support-triage system: the automation's job is to handle the clear cases fast and be honest about what it's not sure of, not to handle everything.
What this doesn't fix
This is where I'd push back on my own pitch, because the failure modes are real.
Return fraud is the sharpest one. If the policy check is tuned too permissively, especially on repeat-return patterns, automating the approval step just automates the abuse too, faster than a human ever could. The rules need to actually catch the behavior that matters (return frequency, wardrobing patterns, mismatched serials on high-value items), not just check the return window.
Damage claims often need real human judgment that a rules engine can't replace. A photo of a scratched table leg might be a shipping-damage claim or it might not be; the auto-approve threshold has to stay conservative enough that it's not quietly approving disputes it shouldn't.
The whole system depends on clean order and inventory data. If SKUs are mismapped, if the WMS lags behind what's actually on the shelf, or if promotion flags aren't tracked consistently, the policy check inherits every one of those gaps and makes wrong decisions faster than a person would have.
And none of this touches the underlying reason returns are happening in the first place. If a product runs small, or a piece of furniture keeps arriving damaged because of packaging, automating the return process makes the return faster, it doesn't make the return unnecessary. A brand with an unusually high return rate has a product or fulfilment problem to fix, and a faster returns process can quietly mask that instead of surfacing it.
How this actually gets built
The shape, in practice: an intake layer that captures the request and pulls the order record; a policy-check layer that runs the eligibility rules against that data and outputs approve, deny, or escalate; a fulfilment layer that generates the label or replacement order for anything approved; a stock-update trigger tied to the physical scan-back event, not the approval event; and an escalation queue that carries the flagged reason along with the order context, so whoever reviews it isn't starting from zero.
The policy-check logic is worth building as its own layer rather than burying it inside whatever tool handles labels, because the rules change more often than the label-generation mechanics do (a new promotion, a new exception, a seasonal policy adjustment), and you want to be able to update the rules without touching the parts of the system that are working fine.
The cost of the pain, and the cited improvement
The clearest number I can point to on this: automating the approval-and-label steps of returns processing cuts processing time by 50%, per AfterShip's research, compiled in Opensend's return-processing statistics roundup. AfterShip did the underlying research; Opensend compiled it into their statistics roundup. Worth keeping that distinction straight, since it's easy to credit the wrong party.
The pattern shows up in both directions I described above: fashion and apparel brands dealing with size exchanges, and home goods brands handling damage claims on furniture. The trigger is different (wrong size versus damaged in transit), but the fix is the same shape: automate the policy check and the label, keep a person in the loop only for the cases that genuinely need judgment.