Circular logistics is not reverse logistics with a rebrand

Brands scaling pre-loved, repair and exchange programmes are solving a marketing problem and a supply chain problem at the same time. The marketing problem is visible: sustainability credentials, customer retention, a second revenue line. The supply chain problem is less visible and that gap is where the operational pain lives.

Standard warehouse management and transport management systems were designed around a predictable flow. Goods arrive in a known condition, in known quantities, from known origins. They are put away, picked, packed and dispatched. The entire logic stack assumes a forward direction. Circular product models reverse that assumption and then compound it. Items arrive in unknown condition, from dispersed consumer locations, requiring individual assessment before any downstream decision is even possible. That is not a tweak to the existing process. It is a structurally different operation sitting inside or adjacent to, the existing one.

What condition grading actually demands from a system

The first point of failure is condition grading. A returned item in a pre-loved programme is not a standard SKU with a known specification. It is an object whose commercial value and next destination depend entirely on its physical state at the moment it arrives. That assessment requires a human decision and that human decision needs to be captured, routed and acted on in real time.

Most WMS platforms handle condition codes as a field. You can flag an item as A, B or C grade or as damaged. What they rarely handle well is the decision logic that flows from that grade. Does a B-grade item get refurbished in-house, sent to a third-party repairer, relisted immediately or liquidated? That routing logic is not a warehouse function. It is a multi-party orchestration problem involving the brand, potentially a repair partner, a recommerce platform and the return's origin region.

When the grading outcome determines the next leg of a multi-party journey, a WMS that stores the grade but cannot trigger the downstream workflow is only doing part of the job. The rest gets handled manually, in spreadsheets, in email threads or in phone calls. That is where the volume breaks down.

The grading interface problem

Grading is also a data-capture problem. If the person doing the assessment is working off a paper checklist or a generic field in a warehouse screen, the data quality degrades as throughput increases. Inconsistent grading across shifts, sites or third-party partners creates downstream errors: items listed at the wrong grade, incorrect refurbishment costs applied, wrong customer expectations set. At low volume, these are manageable. At the volume a scaling circular programme requires, they are a structural liability.

Multi-leg handling and why TMS struggles with it

A standard outbound shipment has a clear origin, a clear destination and a predictable service requirement. A circular item might travel from a consumer's home to a returns hub, then to a grading facility, then to a repairer, then back to a fulfilment centre, then to a new buyer. Each leg has different parties, different service levels, different cost structures and different data requirements.

TMS platforms are generally built around lane-based optimisation and carrier selection for forward flows. They handle multi-stop reasonably well when stops are known in advance. The circular model creates a different problem: the route is not fully known until a grading decision is made. The second and third legs of the journey are conditional on what happens at the first. That conditionality is not a standard TMS feature.

The result is that operators manage circular multi-leg flows by stitching together separate bookings, often on different systems, often with manual handoffs between them. Each stitch is a point where items get lost, delayed or misrouted. Each stitch also means data drops out of the tracking layer, leaving the brand and the customer without a coherent view of where the item is in its lifecycle.

Carrier fragmentation makes this worse. The carrier that handles consumer-to-hub returns is rarely the same carrier handling hub-to-repairer movements. Coordinating across those carrier relationships, with consistent data, under a single visibility layer, requires a marketplace layer that can hold multiple providers in a single orchestrated flow. That is not a capability most operators have assembled.

The inventory identity problem

Forward logistics treats inventory identity as stable. An item is a SKU, it has a barcode, it has a known specification. Circular logistics breaks that assumption almost immediately. Two units of the same product, returned the same day, may have completely different commercial futures depending on their condition. They cannot be managed as interchangeable units. Each one needs an individual identity that persists across every leg of its journey and every system that touches it.

Creating and maintaining that individual identity across a WMS, a TMS, a recommerce platform and a carrier tracking layer is not trivial. Most WMS platforms manage inventory at the SKU or batch level. Serialised tracking exists, but it is typically designed for high-value items with regulatory requirements, not for the volume throughput of a consumer pre-loved programme.

When individual identity breaks down, the practical consequences are serious. Items get relisted before refurbishment is complete. Refurbishment costs get attributed to the wrong unit. A customer buys a B-grade item and receives a C-grade one because the picking logic cannot distinguish between two units sitting in adjacent locations. These are not edge cases at volume. They are recurring failure modes.

Recommerce platforms and the integration gap

Many brands running circular programmes use a specialist recommerce platform for listing and customer-facing transactions. That platform needs accurate, real-time inventory data. If the WMS and the recommerce platform are not tightly integrated, the listing layer is always working off stale or manually updated data. Overselling, incorrect condition descriptions and unfulfilled orders follow. The customer experience problem quickly becomes a brand problem, which defeats the purpose of running the programme at all.

Why adoption fails on the operation, not the feature list

Technology vendors responding to the circular logistics opportunity tend to add features to existing platforms. A new condition-code field. An additional carrier integration. A reverse logistics module bolted onto a forward-flow WMS. These additions can look compelling in a product demonstration, where the demo follows a clean, linear path through a single system.

Operational reality is not a demo. The actual failure points are at the joins between systems, at the moments when a human has to make a decision that no platform has anticipated and at the points where one party's data does not reach the next party in time to be useful. A feature added to a single system does not fix a problem that spans four or five parties across two or three legs.

This is the adoption pattern that repeats across logistics technology more broadly: operators buy a capability, implement it within their existing system boundary and then find that the complexity they needed to resolve sits outside that boundary. The tool works as specified. The operation does not improve as expected. The gap is not the feature. The gap is the assumption that a single system, however capable, can hold a multi-party process together.

Circular logistics makes this visible faster than most forward-flow problems, because the multi-party, conditional, variable nature of reverse flows immediately stresses every assumption baked into a single-system implementation.

What building for circular at volume actually requires

Running a circular programme at genuine volume requires a different architecture. The grading decision needs to be connected to downstream routing logic in real time, not recorded in a field and acted on later. Each item needs a persistent individual identity that travels with it across systems and parties. The transport layer needs to handle conditional multi-leg flows, not just point-to-point bookings. And the whole operation needs a visibility layer that holds together across every party involved, not just within any single operator's system.

That architecture is a marketplace and orchestration problem. The marketplace element connects brands, grading facilities, repair partners, carriers and recommerce platforms in a single network where each party can transact and share data. The orchestration element holds the conditional logic: when a grade is confirmed, the next leg is triggered automatically, the right carrier is selected for that specific movement and the item's identity is maintained through the handoff.

FLOX operates as a multi-party logistics marketplace with orchestration depth. The two layers together are what make conditional, multi-leg flows manageable at volume, because the marketplace surfaces the parties and the orchestration connects the decisions. Circular product models expose the need for that combination clearly. The underlying need exists across any logistics operation where decisions are distributed across parties and flows are not simply linear.

Brands building circular programmes now are making infrastructure decisions that will determine whether those programmes scale or stall. The choice is not between systems with more features and systems with fewer features. It is between architectures that can hold multi-party, conditional complexity together and architectures that cannot.