Returns automation: routing rules that scale

Every returns operation hits the same wall. At fifty returns a day, a human can look at each one, make a sensible call, and move on. At five hundred a day, that same human-in-the-loop model means you are hiring linearly with volume, decisions drift from one agent to the next, and the queue backs up the moment someone takes a holiday. The teams that scale returns without scaling headcount do one thing differently: they stop treating every return as a judgment call and start treating most of them as a rule.

A returns rules engine is not about removing humans. It is about spending human attention only where it earns its keep. The vast majority of returns are boringly legitimate, a wrong size on a low-value order from a good customer, and should be approved in milliseconds with no one watching. The small remainder, high-value items, suspicious patterns, edge-case legal situations, are exactly where a person should spend their time. Automation is how you separate the two at scale.

What a routing rule actually evaluates

A routing rule takes the facts of a return and decides what happens next: auto-approve, hold for review, offer instant credit, require the item back first, or deny. The art is in the inputs. A good rules engine reads four dimensions of every return, and combines them rather than looking at any one in isolation.

• Reason: why the item is coming back, from structured options like too small, damaged, or changed my mind, each of which implies a different downstream action.
• Value: the order and item value, because the cost of a wrong decision on a five-euro accessory is nothing next to a two-hundred-euro coat.
• Risk: the customer's history and behavioral signals, such as return rate, account age, and mismatched addresses.
• Legal basis: whether the return falls under a statutory withdrawal right or your own goodwill policy, which changes what you are actually allowed to do.

Any one of these on its own is a blunt instrument. Combined, they let you write rules that read like sentences: if the reason is fit, the value is under fifty euros, and the customer is low-risk, auto-approve and issue instant credit; if the value is over two hundred and the return rate is high, route to manual review.

Auto-approve the safe majority

The point of the engine is to shrink the manual queue to only the returns that genuinely need a human. In practice, a well-tuned rule set will auto-approve the clear majority of returns outright. These are the low-value, on-policy, low-risk cases where a review would cost more in labor than the item is worth and would almost always end in approval anyway. Reviewing them is pure waste.

Auto-approval is also where you gate instant credit. Offering instant store credit at the moment of return is a powerful retention move, but you only want to extend it automatically to customers and orders that clear your risk bar. The rules engine is what draws that line: safe profiles get instant credit the second they hit submit, while riskier ones get credit only after the item is received and inspected.

The goal is not to review more returns. It is to review fewer, and to make sure the ones you review are the ones that actually matter.

Routing risk to review instead of loss

The same engine that fast-tracks the safe majority is your first line of defense against abuse. Rather than manually hunting for bad actors, you encode the signals into routing conditions and let them surface automatically. A customer whose return rate is far above normal, an order with a serial-returner pattern, or a high-value item flagged as damaged all get pulled out of the auto-approve stream and into review.

This is where automation and return fraud prevention become the same system. You are not building a separate fraud tool; you are adding risk as one of the four dimensions your router already reads. The effect is that fraud controls scale automatically with volume, because they are rules, not a person eyeballing a spreadsheet.

Legal basis is a routing input, not an afterthought

In the EU, a return under the statutory withdrawal right is not the same as a return under your own goodwill policy, and the engine has to know the difference. Under the withdrawal right the customer is legally entitled to send the item back and receive their money, and your rules cannot deny that case the way they might deny an out-of-policy goodwill request. The European Commission's consumer rules on the right of withdrawal define that boundary, and encoding it as a routing input keeps you compliant automatically rather than hoping an agent remembers the law.

Treating legal basis as a first-class dimension also lets you handle the two cases with different economics. A goodwill return can be steered toward exchange or credit; a withdrawal return has to allow a refund, but you can still route it cleanly, apply the correct timelines, and log the basis for your records. The rule encodes the policy so no human has to re-derive it every time.

A routing matrix in practice

Concretely, a small set of conditions covers the overwhelming majority of return volume. Each row maps a combination of the four inputs to a single, deterministic action:

Six rules, and the manual queue is now a fraction of what it was. Everything not caught by a review condition flows straight through. The agents who remain spend their whole day on the genuine exceptions instead of rubber-stamping obvious approvals.

The rules engine feeds the flywheel

The final payoff is that every routed return is structured data. Because the engine records the reason, value, risk, legal basis, and the action taken, you accumulate a clean dataset of exactly what is coming back and why. That is the raw material for returns as a data flywheel: the same signals that route a return today sharpen product, sizing, and policy decisions tomorrow.

This is what separates automation that scales from automation that just moves the bottleneck. A rules engine tuned only for speed processes returns faster. A rules engine that captures structured decisions makes the whole operation smarter over time, lowering the return rate at the source while handling today's volume without adding a single head. That is the difference between automating a cost center and compounding an advantage.