SWAP

For most retailers, the returns process is an afterthought, a logistics problem handled through a mix of email, carrier portals and manual warehouse coordination. Customers start a return in a generic interface that looks nothing like the store they bought from, hear nothing between drop-off and refund, and contact support when the silence becomes worrying. The support cost of a badly managed return often exceeds the original margin on the sale.

SWAP's founders, headquartered in London, saw returns as a customer experience problem that had been treated purely as a logistics one. The retailers they worked with had no single view of return volume, reason codes or resolution status. That data sat in warehouse systems, carrier accounts and support inboxes, none of which talked to each other. The operational overhead was significant and the visibility was close to zero.

The platform was designed from the first day to serve multiple retailers from a single codebase. Each retailer gets a branded portal, with their logo, their colours and their domain, but the return processing logic underneath is shared. That meant the data model had to isolate each retailer's customers, orders and returns correctly from the start, and the branding layer had to be configurable without code changes between deployments.

The first retailer to go live needed their portal operational within two weeks of the build starting. There was no room to launch a single-tenant version and generalise it later. The multi-tenancy had to be correct before that first deployment, because the second retailer would be onboarded onto the same system, not a rewrite of it.

The customer-facing portal lets a buyer start a return, choose a reason, choose a resolution of refund or exchange, and receive a pre-paid label, all without contacting support. It is reached from a link in the post-purchase email, styled as the retailer's own store, and it carries the customer through to a confirmation that the return has been resolved. Status is visible at every step, which is the part the email-and-carrier process could never provide.

On the operations side, every return flows into a retailer dashboard with status tracking, reason code analytics and exception flagging for returns that need a human look. Stripe handles refund disbursement once a return is approved, and the approval is triggered automatically when the warehouse logs receipt of the item. An operations team sees exceptions, not the whole queue.

The reason code data proved valuable beyond operations. Analysing patterns across return reasons gave buying teams a view of product quality and fit issues that had never previously existed in one place, because the reasons had been scattered across inboxes and carrier forms.

An alternative was a single SWAP-branded returns portal used by every retailer. It is simpler to build, one interface to maintain and one brand to explain. The problem is what happens to the customer. Someone who bought from a store they trust and is then sent to an unfamiliar third-party site to give the item back loses confidence at the exact moment the relationship is fragile.

A return handled inside a portal that looks like the retailer's own store keeps the relationship intact. One that does not introduces friction and brand confusion, and some of that confusion turns into support tickets. The cost of building a configurable branding layer was justified by the retention effect on the retailer's side, which is the outcome retailers were actually paying for.

A customer opens the link in their order email, picks the item, gives a reason and chooses a refund or an exchange. A label is generated and they drop the parcel off. When the warehouse scans it in, receipt is logged, the return is approved and Stripe issues the refund. The customer sees each state change in the portal without writing to anyone.

The operations team opens the dashboard to review flagged exceptions and to read the reason code analytics, not to process refunds one by one. Nobody reconciles carrier emails against a spreadsheet, and nobody answers the question of where a return is, because the portal already has.

The platform has processed $9M in returns across SWAP's retailer clients. Support contact rates on returns handled through the portal dropped significantly compared with the previous email-and-carrier process, and operations teams have a single view of volume, reasons and resolution status.

Refunds trigger on warehouse receipt rather than waiting for manual processing. Because the branding layer and the tenant model were built as configuration rather than code, each new retailer joins the same platform with their own look and their own data kept apart from everyone else's.