Strategy
Popular SKUs sell out fast and take 7 to 14 days to restock through the conventional warehouse cycle. Peer-to-peer return forwarding can close this gap to 2 to 4 days by routing returns directly to waitlisted customers, recovering revenue that the conventional restocking cycle defers or loses.
Carl van Heijst
Co-founder, It Goes Forward · 12 Min Lesezeit · Zuletzt aktualisiert:
Übersetzung folgt. Wir zeigen die englische Version.
For most high-volume fashion retailers, the conversation about returns focuses on cost: how much each return takes out of margin, how the warehouse processing time eats into resaleability, how operational scale gets harder with rising return rates. These are real problems, and the standard answers (improved sizing, better photography, peer-to-peer routing) directly address them.
But there is a parallel problem on the orders side that gets less attention: the out-of-stock gap. A popular SKU sells out faster than expected. Customers join a waitlist or wishlist. The retailer receives returns of that SKU within days, but those returned items are not available to the waitlisted customers until they have gone through the conventional warehouse cycle: receipt, inspection, repackaging, restocking, often 7 to 14 days from the moment the customer initiated the return.
During that gap, the retailer is essentially holding inventory that customers want but cannot access. Waitlisted customers wait. Some lose interest and shop elsewhere. The retailer loses revenue that was, mechanically, already there.
This article covers a different application of peer-to-peer return forwarding: routing returned items directly to waitlisted customers, closing the out-of-stock gap from 7 to 14 days to often the same day. The mechanism is the same as standard Forwarding (peer-to-peer routing without warehouse processing), but the commercial framing is different. Instead of saving cost on returns, retailers recover revenue on out-of-stock SKUs.
The mechanism is the same as standard Forwarding (peer-to-peer routing), extended to handle waitlist-driven demand alongside incoming-order demand.
Popular SKUs in fashion have a predictable pattern. The item launches, sells well, sells out faster than the buying team forecast. Customers who arrive after stock-out either bounce or join a back-in-stock notification list. They have given a clear signal of intent (they want this specific item, in this specific size), but the retailer cannot fulfil their order yet.
Three things happen during the out-of-stock gap.
Revenue is deferred or lost entirely. Some waitlisted customers will buy when notified. Others lose interest, find an alternative elsewhere, or simply forget. Industry estimates suggest 30 to 50% of waitlisted customers ultimately convert if the wait is short, dropping below 20% when the wait extends past two weeks. The longer the gap, the more deferred revenue becomes lost revenue.
Inventory carrying cost continues. Items that have been ordered and are inbound, items in returns processing, and items in marked-down liquidation queues all consume operational capacity and finance cost while contributing zero revenue.
Customer experience suffers. A wishlisted customer who waits two weeks for a notification, then receives 'back in stock' only to find the item sold out again within hours of relisting, has a fundamentally worse experience than a customer who could have received the item the day a return came in.
For mid-priced fashion this is annoying but manageable. For high-volume retailers operating on tight margins and large catalogues, where individual SKUs see thousands of weekly orders, the out-of-stock gap is a structural revenue line that conventional restocking cycles leave on the table.
The conventional path from 'item returned' to 'item available to the next buyer' involves several steps, each with its own delay.
This sequence is rational for the conventional model. Each step does meaningful work: inspection catches damage and fraud, repackaging maintains presentation standards, warehouse processing maintains inventory hygiene. But the cumulative effect is a substantial delay between when a returned item could be useful to a waitlisted customer and when it actually becomes available.
For high-volume SKUs that sell out quickly, this delay is where the revenue gap lives.
The peer-to-peer return forwarding model removes the warehouse cycle from this picture. When a customer initiates a return, the system can check immediately whether a waitlisted customer is interested in that same SKU and size. If so, the item routes directly from the returning customer to the waitlisted customer.
The compressed timeline:
The gap closes from 10 to 14 days to 2 to 4 days. For waitlisted customers, the experience improves from 'wait two weeks, hope the size you want is back' to 'your wishlisted item is on the way.' For the retailer, revenue that would have been deferred or lost is captured immediately.
The commercial impact compounds with volume. A retailer running 5,000 monthly out-of-stock notifications, even if only 20% successfully match with returns within 48 hours, recovers 1,000 sales that would otherwise have been delayed or lost. At an average order value of €60, that is €60,000 of revenue per month that returns from being deferred to being current. The example is illustrative; actual match rates vary by SKU velocity, size distribution, and waitlist depth.
The matching algorithm in standard Forwarding evaluates returns against incoming orders. In the out-of-stock case, the algorithm extends to evaluate returns against waitlisted demand. The mechanics are similar.
SKU and size match. The returning item's SKU and size must exactly match what the waitlisted customer requested. Unlike standard Forwarding where flexibility on variant is sometimes acceptable, the waitlist case is strict: the customer joined the list for a specific item.
Condition standards. The item must meet the same condition standards as conventional Forwarding. The buyer rates on receipt; the sender's refund depends on a positive rating.
Geography. The algorithm prefers matches within the destination country to reduce cross-border logistics and customs complexity.
Waitlist queue management. If multiple customers are waitlisted for the same SKU and size, the algorithm needs to choose which one to notify first. Options include first-come-first-served (matches typical retailer wishlist logic), distance-optimised (matches the customer closest to the sender), or value-optimised (matches the customer with the strongest historical purchase behaviour). The right choice depends on the retailer's customer relationship priorities.
Decline handling. If the waitlisted customer declines the Forward offer (for any reason: they have already bought elsewhere, they no longer want the item, they prefer conventional restocking), the system moves to the next waitlisted customer or routes the return to the warehouse as fallback.
The matching logic in the out-of-stock case is more involved than the standard Forwarding case because the waitlist introduces additional dimensions (queue management, decline handling). Conversely, the matching is in some ways easier: the demand signal is explicit (the customer joined a waitlist) rather than inferred from incoming orders.
Several operational questions deserve explicit attention when deploying this use case in production.
Size mismatches. If a customer returns size M but the waitlisted customer requested size S, the items do not match. Strict size matching means some returns will not have a waitlisted match even when there is demand for other sizes of the same SKU.
Condition standards for resale. A waitlisted customer has not yet decided to buy a peer-to-peer item; they expressed interest in a regular product. Offering them a peer-to-peer match changes the value proposition. The retailer needs to decide whether to offer the waitlist match at the same price as warehouse-fulfilled items, at a discount (similar to standard Forwarding), or at full price with the peer-to-peer routing as a logistical detail. Each approach has trade-offs in customer expectations and operational complexity.
Multiple waitlisters for the same SKU and size. The algorithm picks one. The chosen customer accepts or declines. If they decline, the next waitlister is offered. Throughput depends on response time: if customers take days to respond, the operational benefit of the out-of-stock flip is partially eaten by the decision time.
Return condition uncertainty. Conventional warehouse processing inspects every returned item and rejects ones in poor condition. With direct peer-to-peer routing, the returning customer self-attests to condition, and the waitlisted buyer rates after receipt. The retailer must accept some condition uncertainty in exchange for the speed advantage. For most fashion categories this is acceptable. For luxury or technical items where condition is part of the value, the trade-off may not work.
Communication and expectations. A waitlisted customer who receives a notification needs to understand that the item is shipping from another customer, not from the warehouse. This is a different consumer experience from 'back in stock' and needs appropriate framing.
The out-of-stock Forwarding use case is most valuable in specific conditions.
High-volume SKUs where stock-outs are frequent. Items that sell out within hours or days of restocking generate the largest waitlist queues and benefit most from the gap closure. Categories include trending fast-fashion items, popular basics in specific colourways, and limited-edition collaborations.
Categories with predictable customer expectations. Buyers of mass-market fashion items understand item-as-described and discount-acceptable trade-offs. Buyers of premium or luxury items may be less accepting of peer-to-peer routing on items they expect from warehouse fulfilment.
Retailers with substantial waitlist or wishlist behaviour. If customers do not waitlist popular items, there is no queue to match against. The use case requires that demand expression mechanism to exist in the customer journey.
Retailers prepared to manage the additional operational dimension. Waitlist matching adds queue management, decline handling, and notification logic that do not exist in standard Forwarding. The operational benefit must justify the system complexity.
The use case is less valuable in three cases:
Retailers interested in this use case typically already have a productized waitlist or wishlist system. Implementation involves connecting the waitlist data to the Forwarding matching engine, plus designing the consumer-facing experience for both the returning customer (who sees that their return will go directly to a waitlisted customer) and the waitlisted customer (who sees that their wishlist match is available via peer-to-peer routing).
Practical implementation phases:
Retailers interested in this use case can contact us for a scoping conversation.
The conventional framing of Forwarding has focused on returns-side economics. The out-of-stock case adds an orders-side framing that may matter more for some retailers than the cost savings. For retailers where popular SKUs go out of stock frequently and waitlist behaviour is substantial, the structural revenue capture from closing the out-of-stock gap can exceed the structural cost savings from peer-to-peer routing alone.
The underlying mechanism is the same: a returned item routes directly from one customer to the next, bypassing the warehouse. The standard case matches a return to a fresh incoming order. The out-of-stock case matches a return to an existing waitlist entry (a customer who already expressed interest in that SKU and size). The commercial framing is the difference: standard Forwarding recovers cost on the returns side, the out-of-stock case recovers revenue on the orders side.
Yes, but the increment is small. The matching algorithm needs to treat waitlist entries as a demand signal alongside incoming orders, and the consumer-facing flow on the waitlisted-buyer side needs a small adjustment (the back-in-stock notification becomes an offer-to-purchase with a stated delivery window). The retailer's existing waitlist system is the main integration touchpoint. The ERP integration patterns covered in our ERP guide work identically.
Nothing changes from the standard Forwarding flow. If the size on the return does not match any active waitlist entry, the algorithm falls back to matching against incoming orders. If neither match exists within the matching window, the return follows the conventional warehouse path. The out-of-stock matching adds opportunity; it does not remove any of the existing fallbacks.
Yes. The peer-to-peer mechanism (matching, label generation, condition rating, refund flow) is productized, and the waitlist-driven matching extension handles waitlist demand alongside standard incoming-order matching. Retailers interested in this use case can contact us for a scoping conversation.
Nach dem Lesen
If popular-SKU stock-outs are a meaningful revenue gap for your business, we can talk through how the out-of-stock matching works and whether it would fit your operation. 30-minute call, no obligation.
An emerging return model routes returns directly from one customer to the next without warehouse processing. This article explains the mechanism, where it fits, where it does not, and how to evaluate it as one option among several.
Zuletzt aktualisiert:
The make-or-break technical question in any peer-to-peer routing evaluation: how does it actually integrate with the ERP? Three patterns work in practice across the major systems, none requiring custom development. A reference for IT directors and controllers.
Zuletzt aktualisiert:
Most retailers treat returns as a single category and optimise the aggregate. Returns actually segment into four groups by profitability: profitable, neutral, deeply unprofitable, and fraudulent. The operational response should differ by segment.
Zuletzt aktualisiert:
