Build AI returns handling with a human in the loop

"Hi, I'd like to return the item I bought." Two customers can write exactly the same thing. One case the system can handle directly. The other needs a human. The difference does not show in the email.

This guide walks step by step through building AI returns handling where the human is built into the flow, what is often called human in the loop. You get the control chain's seven steps to follow: what is known about the purchase, what the law says, what the store itself has promised, and where the line is for when a human takes over. Good returns handling is as much about knowing when the system must not guess as about answering fast. If you are new to AI agents for customer service, start with our overview of AI agents for SMBs.

Why doesn't the difference show in the email?

The sentence "I want to return the item" can apply to an online purchase with a statutory right of withdrawal, an in-store purchase with a voluntary return policy, or a faulty item that needs a warranty claim. Which one applies is not decided by the wording of the email, but by where the purchase was made and when the item arrived.

Volumes make the mistakes expensive too. According to Kustom data for the period August 2025 to April 2026, 24.9 percent of fashion purchases in Swedish e-commerce are returned, against 5.9 percent for e-commerce as a whole. At that volume, a mistake scales exactly as fast as the benefit, regardless of whether the system approves the wrong return or denies a return the customer actually had a right to.

Customer service and returns tend to sit at the top when listing where an AI agent does the most good in a store, something we cover broadly in our article on AI agents for e-commerce. The rest of this guide goes deep on the returns flow itself, step by step.

How does the control chain fit together?

Returns handling built only for the easy case, an unopened item sent back on time, holds up fine until reality deviates. It is the exceptions that decide whether the system can be trusted, which is why the steps need to come in a fixed order.

The whole chain in one line:

The customer's question → facts → law → your own terms → follow-up question → automation or a human

We call this model the control chain. It is the same underlying flow we start from when we build automation flows for e-commerce businesses, whether the case involves returns, orders, or something else with rules at its core.

The chain breaks down into seven steps:

1. Confirm the facts about the purchase.
2. Check what the law says.
3. Check the store's own terms.
4. Find the missing piece of information.
5. Ask a narrow follow-up question.
6. Match the answer against a pre-approved rule.
7. Hand off when something doesn't add up.

The rest of the guide goes through each step in turn.

Step 1: what facts do you confirm first?

Before the answer can be determined, the system needs to know three things: who the customer is and which order is involved, which channel the purchase was made through, and exactly when the item arrived. Without these three, neither the law nor the store's own terms can be applied correctly.

• The right customer and order. Match against the order number or account details, never guess from a name in an email. An order number that does not match the customer's details is not a minor detail, it is a signal that either the wrong person is reaching out or something about the order already differs from what the system assumes.
• Channel. A distance purchase (online, phone, catalogue) or a purchase in a physical store decides whether a statutory right of withdrawal exists at all.
• Delivery date. The date that governs the deadline, not the purchase date.

Step 2: what does the law say?

For distance purchases, under Chapter 2, Section 10 of Sweden's Distance Contracts Act (distansavtalslagen), the customer has a statutory 14-day right of withdrawal. The deadline is counted under Chapter 2, Section 12 from the day the customer received the item in hand, not from the day of purchase. A system that gets this wrong can deny a valid return, or approve a return that has already expired.

A warranty claim is a different matter: the item being defective, governed by its own set of rules, Sweden's Consumer Sales Act (konsumentköplagen, 2022:260), with three years of liability for defects. A system that conflates withdrawal and a warranty claim, for example treating a defective item as an ordinary withdrawal return, risks giving the customer the wrong answer in both directions.

Genuine exceptions to the right of withdrawal

Under Chapter 2, Section 11, the right of withdrawal disappears entirely for certain items: broken seals on products that, for health or hygiene reasons, cannot reasonably be returned, custom-made items, and items that deteriorate or expire quickly. Which product categories are covered is decided in advance, when the rules are written. In operation, the rule is binary.

A value deduction instead of a lost right of withdrawal

This is where many go wrong: an item being used or unpacked does not automatically remove the right of withdrawal. Under Chapter 2, Section 15, the store can instead make a deduction for reduced value, lowering the refund rather than denying the return outright. That assumes the customer received correct information about the right of withdrawal before the purchase.

Sweden's Consumer Agency, Konsumentverket, explains the principle using shoes tried on indoors, and rulings on value deductions from Sweden's National Board for Consumer Disputes (ARN) give concrete examples of where the line is usually drawn. The difference between a value deduction and the genuine exceptions above is exactly the kind of judgment an AI solution must pull from a pre-approved rule, never from its own interpretation of the law.

Step 3: what have you promised the customer yourself?

If the customer buys in a physical store, no statutory right of withdrawal applies. A store return policy and exchange rights are entirely voluntary benefits, and it is the store itself that sets the terms. The system therefore needs to know exactly what your store promises, not just what the law requires.

The store may offer more than the law requires, for example a longer return window or returns without a stated reason, but never less. A term that is worse than the law has no effect against the consumer under Chapter 1, Section 3 of the Act, regardless of what the store's own terms say.

Step 4: what information is missing?

The system now has the facts about the purchase, the law, and the store's own terms, but one piece of information can still be missing. A common example under a return policy: the terms require unopened packaging, a rule the store itself set, not the law, and the customer has not said whether the packaging has been opened. Without an answer to that exact question, the case can be neither approved nor denied yet.

The system should then neither guess nor hand off immediately. The next step is to ask one concrete follow-up question, check the answer against the store's pre-approved rules, and move forward only if the answer is unambiguous.

Step 5: how do you ask the follow-up question?

A good follow-up question is narrowed to exactly the piece of information that is missing, never a general interrogation about the whole case. It is only asked when a single detail, for example whether packaging has been opened, decides which rule applies. The customer should be able to answer in seconds, not fill in a form.

An example of what that question can look like:

"Thanks! To check what applies to your return, we need to know whether the packaging has been opened."

The answer is then checked against the rule the store approved in advance, for example "unopened packaging required for this return policy." If the answer matches a clear rule, the case moves forward as a standard case. If the answer is ambiguous, or does not fit any pre-approved rule, the case goes to a human instead.

Keeping the question narrow matters. A 2022 Sifo survey for Nets found that 51 percent of Swedish consumers have at some point skipped a return because the process felt too complicated. A system that asks for one thing at a time, instead of a long form, lowers that friction without lowering accuracy.

The same pattern applies to other missing information, not just packaging. If a confirmed delivery date is missing, the system can instead ask when the parcel arrived, or request the tracking number that reveals it. Always ask about exactly the piece of information that is missing, never about everything at once.

Step 6: when does the case move forward automatically?

If the information is complete and the rule is clear, the case moves forward automatically, for example a distance purchase within 14 days with a confirmed delivery date and a straight answer to the follow-up question. The system needs no human when all the facts already point to the same pre-approved rule.

Customer A writes that they want to return an item. The order number matches, the purchase was made online six days ago, and the customer confirms the packaging is unopened. Everything matches a clear rule. The return is registered, the return label is sent, and the case is closed without a human ever having to open it.

Step 7: when does a human take over?

If the details are contradictory, fall outside a clear rule, or require judgment, the case goes to a human instead. Customer B writes exactly the same sentence as Customer A. The order number exists, but the purchase was made in a physical store with no registered return policy, and the customer claims an employee verbally promised a longer deadline.

No rule covers a verbal promise. The system cannot judge whose memory is correct, so the case goes to a human with the full picture already compiled: what is known, what is missing, and why it could not be resolved automatically.

This is also the difference between simply answering and actually acting. A system that only chats can explain how a return works. A system that registers the return, picks the right rule, and sends the confirmation acts instead of merely informing. We cover that distinction in detail in our comparison of AI agents and chatbots.

The line the AI can never move on its own

The point is not for the AI to freely interpret the law. The rules that govern the decision, the terms of the return policy, the exceptions, the thresholds, are pre-approved by a human in advance. The AI checks facts against those rules. As soon as a case requires its own judgment, a gray area the law or the terms do not cover directly, it is a human who decides, not the system.

That is the core of human in the loop: the human is not an emergency exit for when something has already gone wrong, but a built-in part of the flow with one clear responsibility, the judgment calls.

What tech stack do you need?

Returns handling built on the control chain rests on six components: a data source with orders, a language model called via API, an orchestration layer that ties the steps together, a rule engine for the store's terms, a handoff path to a human, and logging of every decision.

Six components, one by one

• The data source. The order system or e-commerce platform, for example Shopify or WooCommerce, is connected via its API. This is where the system pulls the order number, channel, and delivery date, the three facts Step 1 requires.
• The AI model. A language model called via API reads the email, interprets what the customer is asking for, and formulates the follow-up question. The model makes no decision on its own, it matches facts against rules.
• The orchestration. A no-code tool such as n8n ties the steps together without you writing everything from scratch, and suits most volumes. If you already have a development team and high volume, your own code can be the right path instead. The trade-off between building an AI agent yourself or hiring someone applies just as much here, driven by volume and in-house capacity, not by what sounds the most advanced.
• The rule engine. The store's rules, return policy terms, exceptions, thresholds, are stored as a versioned configuration outside the model itself. When we build flows like this, the rules never live in the prompt: they need to be readable, editable, and approvable without touching the AI. A versioned rule engine also makes it easy to show, after the fact, exactly which rule applied on the day a specific case was decided.
• The handoff path. A helpdesk system or a monitored mail queue receives escalated cases, with the full picture attached so the human does not have to start over.
• Logging and traceability. Every decision, automatic or human, is saved in a database with a table view on top for human review, for example Postgres and NocoDB. Here's what it looks like when we built the equivalent for order handling.

Returns handling touches personal data, order numbers, addresses, and payment information, the same demands on data access as any other AI handling of customer data. Our guide to AI and GDPR covers what it takes to keep that part in order from the start. What a build like this usually costs is in our cost guide for AI agents.

What needs to be in place before you build?

Three things need to be in place before the returns handling can be built: a source of order data that shows channel and delivery date, written and approved rules for the return policy and its exceptions, and a clear path for handing off cases to a human. Without these three, the system has nothing to check the customer's answer against.

• Order data with channel and delivery date, gathered in one place the system can read.
• Written, approved rules for the return policy, exceptions, and thresholds, not something decided case by case once the case already sits with the customer.
• A clear handoff path for cases where the information is not enough for an automatic decision.

Whether you build it yourself or hire someone, the groundwork is the same: write down the rules before you build the returns handling, not while it is already live.

Whoever takes over a handed-off case does not start from zero either. The groundwork is already compiled: what is known, what is missing, and where it stalled. The judgment call goes faster than if the case had been manual from the start.

Good automation is not about the AI making as many decisions as possible. It is about every case moving forward the right way: check what is known, ask about what is missing, and hand off when a human genuinely needs to make a judgment call. That is human in the loop in practice.

Frequently asked questions