One Order in Five Comes Back. Who Decides on the Refund?

American shoppers were expected to send back 849.9 billion dollars of merchandise in 2025, and 19.3 percent of everything sold online. Those two figures come from the same National Retail Federation release, and for a shop run by one or two people they translate into something much smaller and much more annoying: roughly one parcel in five comes back, and each one arrives as a message you have to read, judge and answer.

The question worth asking is not whether software can handle returns. It is which specific decisions inside a return can be made without you, and which ones will cost you money the first time a machine gets them wrong.

Most advice on this topic starts with software. Start instead with your last fifty returns, because the shape of that list decides everything that follows. Sort them by the reason the customer gave and you will almost always find the same distribution: a large group of ordinary, boring, obviously valid requests, a small group that need a human eye, and a handful that smell wrong.

What does a return queue actually contain?

Three groups, and they need three different treatments. The large boring group is where automation earns its money, the small ambiguous group is where it costs you money, and the suspicious tail is where it needs to stop and fetch you.

The boring group is bigger than most sellers expect. Wrong size, changed mind, ordered two colours to pick one, arrived after the event it was bought for. These have no evidence to weigh. The customer has a legal right to withdraw in most of Europe regardless of reason, so deliberating over them produces nothing except delay.

The ambiguous group is where judgement lives: the item that arrived damaged, the item described as not matching the listing, the return that arrives outside your window with a plausible explanation. Each of these is a small decision about evidence and goodwill, and each one is a place where a wrong automated answer turns a neutral customer into a public review.

Which return decisions can safely be automatic?

Classification, routing and settlement inside a policy you wrote. Not the policy itself, and not any decision that requires weighing one person's account against another's, because an automated exception to a written policy is exactly the promise a tribunal will hold you to.

The distinction matters because these get bundled together in product marketing. Reading a customer's free text sentence and deciding it means "size too small" is a language task, and language models are genuinely good at it. Deciding whether this particular customer, on their fourth return this quarter, should get their money back is a business judgement dressed as a classification, and it does not become safer because a model made it quickly.

Notice how little of that table needs a model at all. Two rows are pure rules on data you already store. The model earns its place in one row as a reader, and in one row as something that raises a flag for you rather than acting on it. This is the same shape we found looking at which support tickets are worth automating first: the win is in the repetitive middle, not in the hard cases that make good demos.

What does the law require before you set any rule?

A floor on speed and a floor on rights, and both are jurisdiction specific. Automating past either one turns an efficiency project into a compliance problem, so set the legal deadlines as hard constraints before you tune anything.

In the United States, the FTC's Mail, Internet, or Telephone Order Merchandise Rule requires shipment within the time you advertised, or within 30 days if you promised nothing. When you cannot ship in time you must seek the customer's consent to a delay, and a refund for a non credit payment must be sent within seven working days of the point at which the right to it vests. The same guidance notes that failing to keep records proving your systems and procedures creates a rebuttable presumption that you did not comply, which is a strong argument for logging every automated decision your shop makes.

In the European Union, the right of withdrawal gives a consumer 14 days from delivery to cancel without giving any justification. The buyer normally pays return postage, with two exceptions worth knowing: if you offered to cover it, or if you failed to tell them about the cost before they bought. Custom made goods, perishables, opened sealed media and several other categories sit outside the right entirely.

United Kingdom rules run on a similar clock with different mechanics. Government guidance gives the customer 14 days from receipt to tell you they are cancelling, another 14 days to send the item back, and gives you 14 days from receiving it to refund. You must also refund standard delivery if they paid it, and customers are entitled to handle goods as they would in a shop, which is the clause that decides most arguments about whether something was "used".

Is your return rate even the number you think it is?

Probably not, because three different denominators travel under the same name. Return rate by units, by orders and by revenue give you three answers from the same month, and the gap between them is where most bad decisions start, which is also why claims that virtual try on cuts returns are so hard to check.

By units, a customer who ordered three sizes and kept one has a 67 percent return rate. By orders, that same customer returned nothing, because the order converted. By revenue, it depends entirely on which size they kept. None of the three is wrong. The mistake is quoting one figure to yourself and then acting as though it described the other two.

Pick revenue as your headline number, because it is the one that pays wages, and keep the unit number beside it because it drives your reverse logistics cost. A shop with a low revenue return rate and a high unit return rate does not have a returns problem, it has a shipping and restocking problem, and the fix is a size guide rather than a stricter refund policy.

Track it per product too. Ecommerce returns concentrate hard: a handful of items usually account for most of the volume, and finding them is a sort operation you can do in a spreadsheet this afternoon. Any ai returns management effort that skips this step is optimising the handling of a problem it could have removed.

Returns and chargebacks are one conversation

A refused refund does not end the matter. It moves it to the card network, where you have less control, less time and a fee whatever the outcome. Treat your refund policy as the cheaper half of the same dispute.

The sequence is predictable. A customer asks, gets a slow or automated no, waits, and then calls their bank. You now defend the same facts to a third party using evidence you did not know you would need, and what a dispute response can and cannot be assembled from is decided by records made months earlier, against a refund deadline set by someone else. The cost is not just the disputed amount but the fee and the time, and a pattern of them affects how your processor sees you.

This is why an automated refund path should be biased towards yes on low value orders. Not because the customer is always right, but because the alternative route is more expensive than the item. Write the threshold down, apply it consistently, and keep the argument for the cases where the amount justifies having it.

Return fraud deserves the same clear head. The NRF figure of 9 percent means that 91 percent of returns are people doing an ordinary thing, and a process designed around the 9 percent will annoy the rest. Score for the tail, build for the majority.

Where does AI actually help in returns?

In four places, and only one of them is glamorous. Reading free text, triaging photographs, scoring risk, and predicting which orders are likely to come back before they ship.

Reading the reason. Customers do not pick your dropdown honestly. They pick whichever option gets the fastest approval and then explain themselves in the comment box. A model that reads the comment and assigns the real category gives you a returns report that reflects reality, which is the only version worth acting on.

Triaging photographs. Asking for a photo of a damaged item is standard. Having something look at every photo and separate obvious breakage from an image of an intact product is a genuine time saver, provided it routes the uncertain ones to you rather than guessing.

Scoring risk. The NRF release puts fraudulent returns at 9 percent of all returns, and reports that 85 percent of retailers surveyed already use AI to detect or prevent them. The tactics that grew fastest among retailers tracking them were overstated return quantities at 71 percent, empty box returns at 65 percent, and decoy returns of counterfeit items at 64 percent. A score is useful. A score that auto declines is how you lose a good customer, which is the same trap as the false decline problem on the payment side, where the blocked legitimate order costs far more than the fraud it prevented.

Predicting the return before it happens. This is the one that changes the business rather than the workflow. If you can see that a particular product, size or customer combination comes back half the time, the fix is upstream: better measurements, a clearer photo, a size note on the listing. Return prediction feeds the same data you need for stock forecasting that accounts for what comes back, since a unit in a returns pile is not a unit you can sell.

Is a returnless refund ever the right answer?

Yes, and it is arithmetic rather than generosity. When the cost of getting an item back and putting it into a sellable state exceeds what you could sell it for, asking for it back destroys value on both sides.

Work out your own threshold from your own numbers rather than copying a figure from a larger retailer. Add the return shipping label you would pay, the time it takes someone to open, inspect and restock, the packaging you replace, and the realistic resale price given it is now an open box item. Compare that total against the refund. Where the first number is bigger, keeping the item costs you more than not keeping it.

Two cautions. First, publish the threshold internally and never externally, because a published one is an instruction manual for abuse. Second, apply it per customer rather than per order. The same generous rule that is sensible once becomes a subscription if the same address triggers it monthly.

What breaks when you automate too much

The failure is rarely dramatic. It is a slow drift where the automated path becomes the only path, and every case that does not fit gets pushed through it anyway because there is nowhere else for it to go.

Watch for three symptoms. Approval rates that climb every month, which usually means the model learned that approving is what you always do. A rise in repeat returners at the same address, which means your scoring is descriptive rather than preventive. And support messages that begin by explaining why the automated answer was wrong, which is the clearest signal that your categories do not match the reasons people actually have.

There is a fourth symptom that only shows up in the accounts. If your processing time per return falls while your write off value rises, the automation is approving things it should have inspected. Speed and loss move in opposite directions in a healthy process, so watch them on the same chart rather than in separate reports.

The NRF figures give one more reason for restraint. Consumers surveyed said free returns were a major purchase consideration for 82 percent of them, and 76 percent preferred an instant refund or exchange. Returns policy is doing marketing work whether you designed it that way or not, and an automation that shaves a day off processing while adding friction to the request is a bad trade.

A returns policy you can write this week

Set it out in five lines and it will outlast any tool you buy.

Decide your window and make it at least the legal minimum for every country you ship to. Decide which reasons approve automatically and write them as a list, not as a vibe. Decide your value threshold under which you do not ask for the item back. Decide what a person always looks at, and keep "not as described" on that list permanently, because it is the only category that tells you a listing is wrong. Decide what you log for every decision, including the automated ones, since the FTC guidance makes the absence of that record a problem in itself.

Then measure one number for a quarter: the share of returns that reached a customer without any human touching them. If that number rises while your repeat purchase rate holds, the automation is working. If it rises while repeat purchases fall, you automated the wrong group.

None of this needs a returns platform. Most of it is a handful of rules, a model doing the reading, and a log. If you are building the storefront these rules live inside, keeping that logic in code you own rather than in a vendor's admin screen is what lets you change the threshold on a Tuesday afternoon, which is the argument for an AI built store whose code stays yours. The policy is the asset. The software is just where you type it.