The Refund Request Arrived. Can Software Answer It?

Returns are the part of a shop that scales worst. Orders can double without anyone noticing. Refund requests cannot, because each one arrives as a small argument that somebody has to read, judge and answer, usually while doing something else.

So the appeal of handing them to software is obvious, and the software is good at it. The question is not whether it works. It is which of the decisions inside a returns process belong to you at all, because a meaningful share of them were settled by legislation before your policy page was written.

Sort every request into one of two piles

This is the only distinction that matters and it takes a second to apply. Either the outcome is determined by a right the customer holds, in which case there is nothing to decide, or it is determined by your own commercial policy, in which case decide it however you like, including automatically.

The trap is that both piles produce the same email. A customer writing to say the jumper does not suit them and a customer writing to say the jumper arrived with a hole use almost identical wording, and only one of those is a request you are free to decline.

Does an American shopper have a right to return an online order?

Generally not, and this surprises sellers and buyers in roughly equal measure. There is no broad federal right to change your mind about an ecommerce purchase, which means your published policy is close to the whole of the law for a United States shop.

The rule people are thinking of is the Federal Trade Commission's cooling off rule, and its own description of its scope is narrow: it concerns door to door sales, treats failure to give the required disclosures on sales above $25 as unfair and deceptive, and grants three business days to cancel. It is a rule about being sold something at your kitchen table by a person who turned up, not about buying something from a website.

The practical consequence is worth stating plainly. In the United States, a returns policy is a contract term you wrote, and automating decisions inside it is automating your own rules. That is a comfortable position for AI to occupy. What replaces statutory obligation is marketplace obligation, since the platforms impose their own return windows that frequently exceed anything the law requires, and a state may have its own disclosure rules about what happens if you publish no policy at all.

What does a European buyer get automatically?

Fourteen days to change their mind, with no reason required and no fault needed. It runs from the day the goods arrive rather than the day of purchase, and it exists whether or not your policy mentions it.

The European Union's own guidance for citizens on returns and refunds sets out the shape. The cooling off period is 14 days, starting from delivery for goods and from the agreement date for services, extending to the next working day if it would otherwise end on a non working one. The consumer normally pays return postage, unless you offered to cover it or failed to tell them before purchase that they would carry it. And the right does not apply to a defined list: made to order items, perishables, sealed media once opened, digital content once downloading has begun, dated travel and event bookings, and emergency repairs.

That exception list is the genuinely useful part for a shop, because it is where an automated system can be given real authority. A custom engraved item is outside the withdrawal right by category, not by your generosity. A model can apply that rule confidently, provided your product data marks which items are made to order, which is a data problem you solve once rather than a judgment it has to make every time.

How fast does the money have to go back?

Fourteen days, measured from a point that depends on how the goods travel. The United Kingdom regulations are precise about it and are a good working reference because they implement the same directive.

Regulation 34 of the Consumer Contracts Regulations 2013 requires the trader to reimburse all payments other than delivery charges. Where the trader has not offered to collect the goods, the deadline is the end of 14 days after the day the trader receives them back. Where collection was offered, it runs from the day the trader was told of the decision to cancel.

Two further details in that regulation deserve a place in your process. If the goods have lost value because the customer handled them beyond what was necessary to establish their nature and characteristics, the trader may recover that amount up to the contract price. And that right to deduct vanishes if the trader failed to provide the required cancellation information. Getting your policy page right is therefore not paperwork. It is the condition on which your ability to charge for damage depends.

Where does automation stop being safe?

At refusal. Approving a refund automatically is an operational efficiency. Refusing one automatically is a decision about somebody's money made without a person, and that is a different category with its own rules attached.

The Information Commissioner's Office guidance on rights related to automated decision making explains the structure. The restrictions apply to solely automated decisions producing legal or similarly significant effects, where solely automated means no meaningful human involvement at all. The moment a person genuinely participates, the strictest requirements fall away. Where they do apply, you need one of three bases, contractual necessity, legal authorisation or explicit consent, and you owe safeguards: information about the logic and consequences, a route to request human review, and a way to contest the decision.

Whether a refused refund clears the similarly significant threshold is not settled, and the examples the guidance gives, an automatically refused credit application and recruitment without human intervention, sit further up the scale than a returned jumper. A repeated pattern of automated refusals against the same customer, or a system that silently flags someone as a serial returner and declines everything they send, moves closer to it. The cautious design costs almost nothing: let the machine approve, and route every refusal to a person, even if that person spends four seconds on it.

What the model is genuinely good at here

Reading and routing, which is most of the work and none of the risk. A returns inbox is a classification problem dressed as correspondence, and automating it lowers the cost of each return without touching the count, which is a job for the product page changes that reduce a return rate.

Start with triage. Is this a change of mind, a fault, a wrong item sent, a delivery that never arrived or a question about the process. Those five categories have completely different downstream handling and a model sorts them accurately from the customer's own words, including when the customer uses the wrong term for their own situation, which is frequently.

Then extraction. Order number, item, date of delivery, whether the packaging is described as opened, whether a photograph is attached. Pulling structured fields out of a paragraph is the single most reliable thing these tools do, and it removes the part of the job that actually takes the time.

Then drafting. A reply that states the outcome, the next step and the expected timing, in your tone, ready for you to send or amend. Drafting is safe precisely because it ends with you reading it. The related discipline of turning repeated questions into published answers, so the request never arrives, is covered in the piece on building a help centre out of your own tickets.

What it should not do is state the customer's legal position. A sentence generated on the fly about what somebody is entitled to is a sentence you may be held to, and the model has no way of knowing which country's rules apply to this buyer. Keep entitlement language in fixed templates you wrote and the model selects between, rather than in prose it composes.

What does this cost, and what does it save?

Less than people expect on both sides. The saving in an automated returns process is time rather than money, and the time saved is concentrated in a part of the day that is worth more than the clock suggests.

Take a shop handling forty returns a month, which is roughly what four hundred orders produces in apparel and rather less in most other categories. Each one currently costs somewhere between four and ten minutes: reading the message, finding the order, deciding, writing back, and arranging the label. Call it six minutes, so four hours a month.

Automating triage, extraction and drafting does not eliminate those four hours. It converts most of them into review time, which runs at perhaps ninety seconds per request rather than six minutes. That is an hour a month instead of four. On its own, three hours a month is not a saving that changes anyone business.

What makes it worth doing is where those hours sat. Returns arrive unpredictably and interrupt whatever you were doing, and the cost of an interruption is not the six minutes, it is the twenty minutes of half attention either side of it. Batching the reviews into one slot a day recovers more than the arithmetic shows. That, rather than headcount, is the honest case for automating this particular job in a business of one or two people.

Should the customer talk to the machine directly?

For starting a return, yes. For arguing about one, no. The difference is whether the conversation has a defined set of outcomes before it begins.

A self service returns form that asks for the order number, offers the reasons your policy recognises and issues a label when the request qualifies is genuinely better than email for everyone involved. The customer gets an answer in thirty seconds instead of a day, and you get structured data instead of a paragraph. Nothing about that requires a conversational interface at all, and a plain form frequently beats a chat window for this job.

Where it goes wrong is the open ended chat that invites a customer to make their case to something that cannot agree with them. A refusal delivered by a machine reads as final and arbitrary in a way the same refusal from a named person does not, and the customer's next move is a chargeback or a public review rather than a reply. If the answer is no, the message should come from you, with a reason, and with a route to respond. That costs one email and it is the cheapest reputation insurance available.

The policy page is the part that does the work

Everything above depends on a written policy precise enough for software to apply. Most shop policies are not, and the gap shows up immediately once you try to automate against them.

The test is whether each rule has a number or a category rather than an adjective. Unworn is an adjective. Tags attached and returned within 30 days of delivery is a rule. Your policy needs the window in days, the condition in observable terms, who pays return postage, what happens to the original delivery charge, the exceptions by product category, and the remedy offered, whether refund, exchange or credit. AI is useful for drafting that document and useless as a substitute for it, a distinction we drew more fully in the piece on using AI to write shop policies.

Keep the rules in your own system rather than inside a vendor's settings screen. Returns logic touches product data, order history and payment records at the same time, and the shops that automate it successfully are the ones where those three live together. That is one of the arguments for running the storefront on code you control, which is the premise of how we approach building a shop.

Serial returners and the temptation to profile

Every shop with a few thousand orders eventually notices the same handful of customers returning most of what they buy. The instinct to have software flag and block them is strong, and it is the highest risk thing in this entire subject.

Three problems stack. The behaviour is legal, since a consumer exercising a statutory right repeatedly is exercising a statutory right. The detection is unreliable, because high return rates also describe careful shoppers buying two sizes, a practice your own size guide may be encouraging. And the decision is exactly the kind of profiling driven automated judgment about an individual that attracts the scrutiny described above.

The defensible version is to measure rather than to block. Look at return rates by product rather than by person, because a single item returned by forty percent of buyers is a product description problem you can fix, and fixing it helps everyone including you. Where an individual account genuinely looks like abuse rather than indecision, handle it as a person, in writing, with a reason. Chargeback exposure follows a similar logic and similar evidence requirements, which we set out separately in the piece on assembling evidence for a disputed payment.

Read that alongside the deduction rule and you have the whole design brief. The money goes back by default, on a clock, minus only what the law lets you keep, and only if you told the customer their rights before they bought. Software can execute all of that faithfully and quickly. It just cannot be the thing that decides what the rules are. Write those down, mark the exceptions in your product data, and the automation that follows is ordinary plumbing rather than a judgment call you have delegated to a machine.