A Returns Portal Instead of Tickets: Let Customers File Returns Themselves

Every return that lands in your inbox as an email is a form you never built. The customer types freely, you type back, and two days of waiting sit in between.

At mate that was our daily reality for a long time. A customer wrote "trousers too small, how do I send them back?", someone looked up the order, asked for the number, created a label and sent it afterwards. Five messages for a case the customer could have filed themselves in 90 seconds.

The returns portal is the answer to that. It is a flow you define, and there is no tool to buy. This article is about that flow: which fields the portal asks for, when it approves without a follow-up question, how the label gets created, what the customer hears and when, and which cases a human always checks. The full technical setup behind it, including refund logic and stock handling, is in our article on returns management. Here we stay on the surface your customer sees.

What separates a returns portal from a contact form

A contact form collects text. A returns portal collects decisions.

The difference sounds small and it is the whole point. No machine can reliably derive from a free-text field which product from which order is coming back. From three selection fields it can.

That is why our portal has no open message as a required field. It has fixed questions with fixed answer options. There is still a free-text field, as an addition, and no decision rests on it.

Second difference: the portal knows the order. It asks for the order number and email and checks both against Shopify. Only then does it show the items at all. The customer picks from what they actually bought, which is often something else than what they remember buying.

That saves you an entire class of follow-up questions. Wrong product names, mixed-up orders, expired windows: the portal catches all of it before a human reads it.

The flow in five steps

Here is the path a customer takes with us. It runs in under two minutes.

• Step 1: Identify. Order number plus email. No customer account required, and that matters. A login as a hurdle costs you more portal usage than it buys you in security.
• Step 2: Pick the item. The portal shows every line of the order with image and quantity. The customer ticks what is going back.
• Step 3: Pick the reason. A dropdown with fixed reasons. Ours: too big, too small, don't like it, damaged, wrong item, other reason.
• Step 4: Pick the outcome. Refund or exchange. For an exchange we ask for the desired variant right away.
• Step 5: Confirm. The customer sees a summary and confirms. After that everything happens without them.

One detail we learned late: the reason belongs after the item selection. Ask for the reason first and you get one reason for the whole order. Ask afterwards and you get a reason per item. That is the difference between "the order doesn't fit" and "size M runs small on this model".

The rules for automatic approval

Now comes the part that decides between calm and chaos. Which return goes through without a human?

We check five conditions. All five have to be true, otherwise the case goes to manual review.

The rest is an if-then chain in n8n. Nothing about it is clever, and that is deliberate. Rules you can explain in one sentence are also rules you can debug at eleven at night.

Two pieces of advice from experience. First: start strict. An automation that is too generous costs you goods, one that is too strict costs you minutes. Second: only loosen the rules with data. If you waved every manual review through for three months, the rule was too strict and can go.

What the approval does not trigger matters too. It refunds no money. It only creates the label and the claim. Money moves after goods receipt, otherwise you have built a system that invites abuse.

The label: create, send, follow up

As soon as the return is approved, the workflow calls the carrier API and creates a returns label. For us that is DHL, and the principle works the same with DPD, GLS or Hermes.

The label goes to the customer by email, with a PDF attached and a QR code in the body. Time from form submission to label in the inbox: around three minutes. Before it was 24 to 48 hours, because a human had to read the email.

That waiting time used to be our biggest driver of follow-up messages. "Where is my label?" is the returns version of "where is my parcel?". Both come out of the same gap: the customer started something and hears nothing. How to close that gap on the shipping side is in our article on WISMO requests.

Following up is part of the job. If there is no carrier scan after 14 days, the workflow sends a friendly reminder. After 21 days it closes the case and releases the reserved stock again. Without those two steps you collect dead records that distort your numbers.

Communication: what the customer hears and when

A portal without communication feels to the customer like a form that fell into a void. We send four messages, no more.

• Immediately: receipt confirmed, with a summary of the return.
• After approval: the label plus instructions on what goes in which parcel.
• On goods receipt: the parcel is here, the check is running.
• After the refund: the amount, the payment method and a note that the bank takes two to three days.

That last sentence matters more than it looks. Half of the questions after a refund arrive in the window between our payout and the credit landing in the account. Name the timeframe and the question disappears.

What we deliberately leave out: promotions in returns emails. The moment is wrong. If you want marketing here, it belongs in the exchange branch, and the refund branch stays clean. More on separating occasions properly is in our article on marketing automation.

When a human has to review

A portal should handle the volume, and some things stay off it. These cases always land on a desk with us.

• A "damaged" report. We ask for a photo in the portal and look at it ourselves. No rule set decides how generous we are.
• Serial returners. The workflow counts returns per customer over twelve months. Above a threshold the case goes to review.
• High order value. Above a fixed limit someone always looks at it. That limit is different for every brand.
• Window just missed. Two days late is a goodwill question, and no formula answers it.
• Wrong contents in the parcel. Only shows up at goods receipt and is always a single case.

Together those are a few percent of our returns. They cost most of the attention, and that is how it should be. The machine handles the repetition, the human decides the exception. That pattern holds far beyond returns, as our overview of customer service automation shows.

What the portal tells you about your product

The side effect turned out to be worth more to us than the time saved. Fixed reasons produce data you can analyse.

At mate around 60 percent of returns came in with the reason "size doesn't fit". That is a product and content problem, and no service process fixes it. We added a size chart with real measurements and a note on each item about whether it runs large or small.

Without the dropdown we would never have seen that in numbers. Free-text emails contain the same information, and nobody counts them.

The limits

A returns portal does not run itself, and it does not fit everywhere.

• Below two to three returns a day it does not pay off. The build costs you one to two weeks. At five returns a week you never make that back.
• Customised products fit poorly. Where every order is different, fixed reasons are an illusion.
• B2B with negotiated return terms does not fit. There every customer is their own contract.
• The portal does not lower your return rate. It lowers the effort per return. If you want fewer returns, work on the product, the photos and the size information.
• You need clean order data. If order numbers and email addresses do not match up reliably in your shop, step 1 already fails.

One more note: the first weeks are bumpy. You will sharpen rules, change wording and find edge cases you never thought of. Plan two hours a week for adjustments, or the start gets frustrating.

Conclusion

A returns portal replaces no decision. It only sorts which decisions reach you at all.

The customer gets their label in minutes instead of days. You get structured data instead of prose. And the cases that genuinely need judgement sit visibly at the top instead of buried between 40 standard requests.

If you are working out where to start with your processes: our overview of automating e-commerce processes helps you sort them. And if you would rather walk through the portal together than read up on it, get in touch with Flowhouse. We will show you our setup, even if you end up building it yourself.