'Returns Management Automation: Portal, Rules, Labels, Refunds'

Nobody likes returns. Customers don't, you don't. They are part of e-commerce anyway. The only question is how much time they eat.

At our brand mate the return rate sat at 8 to 10 percent. At 100 orders a day that is 8 to 10 returns, each with 20 to 30 minutes of manual work: read the request, create the label, send it, check the goods on arrival, refund, correct the stock level. That added up to 3 to 5 hours a day, for returns alone.

Today it is around 5 minutes a day. The system behind it has four building blocks: a returns portal, approval rules, automatic carrier labels and refund logic. Here is each block in detail, plus the line where automation has to stop.

Block 1: The returns portal

The most important step happens before any technology: customers stop writing emails. They use a self-service form on the website.

The portal asks for three things:

Two effects. First: the request arrives structured, so a machine can process it. A free-text email cannot be processed reliably. Second: the portal takes noticeable load off the inbox, because the returns emails disappear. What is left in the inbox gets pre-sorted by AI at our brands, and that setup is described in our article on pre-sorting support emails.

The dropdown reasons turn out to be worth a lot on their own: 60 percent of our returns came in under "size doesn't fit". That is a product problem, and no service process fixes it. Without structured data we would never have seen it.

Block 2: The approval rules

This is where it is decided whether your system really runs on its own. The core question: which return gets approved without a human?

Our rules, as simple if-then logic in n8n:

With those rules the large majority of our cases run through completely automatically. The rest produces a Slack message, we look at it and decide. That takes minutes, not hours.

One thing matters: start strict and loosen the rules with data. An automation that is too generous costs more than one that is too strict.

Block 3: The carrier label

As soon as a return is approved, n8n creates a returns label via the API of the DHL business customer portal and sends it to the customer by email. Manual time: zero.

The difference for the customer is huge. Before, they waited 24 to 48 hours for their label, because a human had to read the email first. Today the label arrives after about 3 minutes. That waiting time is exactly what generates the next request: "where is my label?" It is the same mechanic as WISMO requests, which make up around 40 percent of the support volume. How to get rid of those is covered in our article on WISMO automation.

The principle works with any carrier that offers a label API: DHL, DPD, GLS, Hermes. If you need the groundwork, our introduction to APIs in e-commerce helps.

Block 4: The refund logic

The last block hangs off goods receipt. When the return arrives at the fulfilment partner, we get an API notification. The workflow checks the original request and branches:

We built in one rule deliberately: we refund only once the goods are back with us. An instant refund on form submission feels customer friendly and opens the door to abuse. The 1 to 3 days of shipping time are the price for a system that does not get exploited.

The numbers

MetricBeforeAfter
Time spent per day3 to 5 hoursaround 5 minutes
Label with the customer24 to 48 hoursaround 3 minutes
Refund after goods receipt3 to 5 daysunder 24 hours

Then there is the quality side: incorrectly calculated refunds have become rare. The returns hours we saved are part of the 33 to 46 hours a week we gain across all three brands through automation.

The limit: fraud cases stay manual

A fully automatic returns system invites abuse. So there are cases that must never run through automatically.

These cases are rare, maybe 1 to 2 percent. But they get expensive when the automation waves them through. The rule: the machine handles the volume, the human decides the exceptions.

Who this pays off for

Good fit: product brands with standardised items, from around 50 orders a day, with a return rate that noticeably costs time.

Weaker fit: heavily customised products, B2B with complex return terms, or shops with fewer than 2 to 3 returns a day. There the build costs more than the benefit. Do the maths first, our article on the cost of automation shows how.

Want to see the setup in detail? Get in touch or write directly to benedikt@flowhouse.ai.