It Goes Forward
Start a pilot

01How Forwarding works

A return becomes a sale, without your warehouse in the middle.

Forwarding intercepts a return the moment it's initiated, matches it with an incoming order for the same product (typically instantly at retail volumes), and ships it directly from the first customer to the second. One label, one parcel, no warehouse step. At Kuyichi the methodology saves up to 44% of warehouse returns. Live within a week.

Up to 44%

Warehouse returns eliminated

68%

Of users choose Forwarding when offered

< 1 week

Typical integration time

Warehouse reduction figure from independent research; full citation on /research. Eligibility varies by product category and return reason.

See the problem this solves

02The mechanism

The mechanism, in one picture

Conventional return

Customer buys
Outbound logistics
Customer returns
Return logistics
Warehouse handling
Outbound again
Item resold

Forwarding

Customer buys
Outbound logistics
Customer returns
Forwarding intercepts here
Ships directly to next buyer

Forwarding eliminates the warehouse round-trip. That's the entire mechanism.

03Four stages

Four stages, system-side

From the retailer's perspective, a Forward moves through four stages. The matching stage is the interesting one. Everything else is standard e-commerce plumbing.

Day 0Day 3Day 6Day 9
IntakeDay 0
MatchingDay 0 – 3
ShipmentDay 3 – 5
SettleDay 5 – 8

Total time from consumer clicking 'Forward' to per-Forward fee charged: typically 3 to 8 days. At high volumes, often faster.

  1. Intake and eligibility

    milliseconds

    Your return portal sends order and product data to our API the moment a consumer initiates a return. Our system checks eligibility in milliseconds: is the product category supported, is the return reason not 'damaged', does the consumer have any behavioural flags, do the configured discount ranges apply. If eligible, a listing is created and the Forward option appears in the return flow alongside conventional warehouse return.

    Handled by: your return portal + IGF eligibility engine

    Return initiated
    Eligibility check
    Listing created

    Forward offered

    Warehouse

    Conventional

  2. Matching

    instant to 3 days, configurable

    This is where the interesting work happens. Our algorithm evaluates every active Forward listing against every incoming order in real time. It scores each potential match on distance between sender and buyer, remaining matching window, expected buyer rating, and margin impact, then triggers a Forward only when the expected value exceeds the expected value of conventional warehouse return. If an incoming order for the product exists when the return is initiated (which at typical retail volumes is most of the time), the match is instant. The label is generated and shipped the same day. When no order exists yet, the listing waits up to a configurable window (3 days by default) for an incoming order to arrive. At very low volumes the window can extend further; we tune this together during onboarding. Most matches are made well within the window.

    Handled by: IGF matching algorithm (Markov Decision Process, methodology independently validated)

    Pending listings

    SKU-A
    SKU-B
    SKU-C

    Incoming orders

    SKU-A
    —
    SKU-C

    Match scored on distance, remaining window, expected buyer rating, and margin impact.

  3. Shipment

    1–3 business days

    Once matched, the consumer receives a shipping label generated against your existing carrier contract (DHL, PostNL, or others). The package ships directly from sender to buyer. Consumer addresses are never exposed between parties. The label carries only the carrier's routing information. The buyer receives the package with a tracking code from you, as they would with any other order. The sender's role ends at handoff.

    Handled by: IGF label generation + your carrier

    Consumer A
    Carrier
    Consumer B
    Address protection: sender and buyer never see each other's addresses.

  4. Refund and settlement

    triggered within 3 days of buyer receipt

    The buyer rates the item condition on receipt. A positive or neutral rating triggers the sender's refund automatically through your existing refund system. No rating within 3 days? Refund auto-released. Negative rating? Refund held pending review. Rare, with our live data showing 98% positive or neutral. The per-Forward fee is charged only when the refund is triggered, not before. No Forward, no charge.

    Handled by: IGF + your refund system

    Buyer rating
    Positive

    Refund auto-released

    Negative

    Held for review

04Edge cases

What happens when things don't go smoothly

When things go as expected (most of the time)

  • Incoming order exists at intake: instant match, shipment triggered same day
  • Match made within window: ships directly, buyer rates positive or neutral, refund released automatically
  • No rating within 3 days: auto-positive, refund released

When they don't (the rest of the time)

  • No match within the window: consumer notified, return defaults to conventional warehouse return automatically
  • Consumer doesn't ship within 3 days of label issuance: conventional warehouse return triggered for buyer's order, sender's return reverts to your warehouse process
  • Buyer rates negative: refund held, issue investigated, buyer has standard right of return (same as any normal purchase)
  • Carrier loses the package: buyer refunded, handled as a lost shipment under your carrier contract (standard process)
  • Buyer returns the Forwarded item: 21% return rate on Forwarded items vs ~38% industry average; when it happens, standard return flow

In every edge case, the default is your existing return flow. Forwarding is additive: it sits on top of your current return infrastructure and only triggers when all conditions are met. Nothing we do can break your current returns. If the match doesn't work out, the consumer returns to your warehouse as they would have anyway.

Concerned about a specific edge case we haven't covered? Read common concerns →

05Under the hood

Three mechanisms worth understanding

The matching algorithm: how the decision is made

At each incoming order, the algorithm evaluates every active Forward listing for the same product. It computes an expected value based on distance between sender and buyer, remaining matching window, expected buyer condition rating, and margin comparison against warehouse reclaim. A Forward is triggered only when the expected value exceeds the expected value of conventional warehouse return. The matching logic is based on independent research, developed with researchers at VU Amsterdam and Erasmus University Rotterdam, validating when a Forward is more economical than a warehouse return. It is a Markov Decision Process: formal, reproducible, auditable. No other Forwarding vendor has published their algorithm.

Read the research →

Match candidates

Listing A8.2
Listing B7.1
Listing C9.4

Highest score wins; Forward triggers only above margin threshold.

The discount engine: how you set the price

You configure discount ranges per price bracket. For example: items under €25 capped at €4.50 off, items €25–€75 capped at 10%, items above €75 capped at €15. The algorithm respects your ranges and generally sells at the lower end: enough to incentivise the buyer, not enough to sacrifice margin. You are never surprised by a discount level on your products. You can also exclude specific categories or SKUs from Forwarding entirely.

Price bracket €25 – €75

5%7% avg12%

You set the range. The algorithm picks the point within it.

Additive integration: how it fits your existing stack

Forwarding does not replace anything. It plugs into your existing return portal (Returnless, Bleckmann, or custom), your existing carriers (DHL, PostNL), your existing ERP or OMS (via webhooks). Returns that aren't Forwarded (because they're not eligible, the consumer chose warehouse, or no match was made) follow your current return flow unchanged. This is the single most important operational property: the downside risk is bounded by your existing return cost.

Integration stack

Forwarding layerIGF · additive
Return portalReturnless / Bleckmann / custom
Your existing returns flowUnchanged

06Integration

What integration actually involves

What your team does

  • Install the plugin (Shopify, Magento, BigCommerce, Salesforce CC) or implement the REST API (custom stacks): typically 1–5 days
  • Configure your discount ranges and matching window preferences: 30 minutes in our dashboard
  • Add the Forwarding option to your return portal: if using Returnless or Bleckmann, this is a checkbox
  • Test a few end-to-end Forwards in our sandbox environment: typically half a day

What we do

  • Provide full OpenAPI 3.1 specification and a dedicated sandbox
  • Support your integration actively via Slack during onboarding
  • Handle matching, label generation, consumer notifications
  • Send webhooks at every event (match made, label issued, buyer rated, refund triggered) so your ERP and OMS stay in sync
  • Monitor uptime (99.9%) and handle platform maintenance

Full integration documentation at /integrations. API reference at docs.itgoesforward.com. Or, if you want the open standard underneath, see /open-return: Apache 2.0, implement it yourself.

Integrations

Platforms, portals, carriers

API docs

OpenAPI 3.1 reference

OpenReturn

Apache 2.0 open protocol

07Common questions

Frequently asked questions

When is a match instant versus when does the consumer wait?

At typical retail volumes most matches are instant: an incoming order for the same product exists at the moment the return is initiated, and the label is issued the same day. When no order exists yet, the listing holds for the configured matching window (3 days by default) waiting for an incoming order. The matching window is an upper bound, not an expected wait time. At very high volumes the wait is rarely relevant; at very low volumes the listing may use the full window.

Can I configure the matching window?

Yes. The matching window is configurable per retailer between 1 and 14 days. The default is 3 days, which works for most categories. Time-sensitive categories (highly seasonal items) sometimes use 1 or 2 day windows. Evergreen categories can extend further to maximise match rates. We tune this together during onboarding based on your category mix and return volume.

What carriers do you work with?

DHL and PostNL are the primary carriers. The shipping label uses your existing carrier contract, we don't add a logistics markup. Additional carriers can be added on request; integration is straightforward via our carrier contract module.

How does the algorithm decide whether to Forward vs. send to warehouse?

It computes expected value of both paths (Forward vs. warehouse) and triggers a Forward only when the expected value is better. The calculation accounts for shipping distance, buyer rating risk, discount applied, and expected warehouse processing cost. If the warehouse path is expected to be more profitable, the item goes to your warehouse. You never lose money on a Forward.

Who controls the discount level for the buyer?

You do. You configure discount ranges per price bracket (minimum and maximum) and the algorithm respects them. It generally sells at the lower end of the range and never exceeds your configured maximum. You can exclude specific categories or SKUs from Forwarding entirely.

What information is shared between the two consumers?

None beyond the product itself. The sender never sees the buyer's name or address. The buyer never sees the sender's name or address. Shipping labels are generated by IGF and passed directly to the carrier: neither party sees the other's location. This is a core product design decision, not an afterthought.

What happens to our ERP, OMS, or WMS during all this?

We send webhooks at each event (match made, label issued, buyer rated, refund triggered). Your ERP or OMS receives these like any other event and updates inventory, fulfilment status, or accounting accordingly. There are documented implementations for Microsoft Dynamics 365 Business Central. For other systems, the adapter interface is generic.

What if the Forwarded item itself gets returned by the buyer?

21% return rate on Forwarded items, substantially lower than the industry average of ~38%. When a Forwarded item is returned, it goes to your warehouse via your conventional return flow. Or, if condition still qualifies and you have configured re-Forwarding, it can be Forwarded a second time to a new buyer.

Does Forwarding work cross-border?

Yes, and it's arguably more valuable cross-border. The algorithm prefers matches within the destination country, so an item returned in Germany is preferentially matched with a German buyer. This reduces cross-border logistics costs and duty exposure. Multi-market deployment is supported.

08What's next

The mechanism is the easy part.

Forwarding works. It's live at Kuyichi, the methodology is independently validated, and the worst case (no match) defaults to your existing return flow. The harder question is what it does for your specific return volume, product mix, and carrier contract. That's a 30-minute conversation, not a blog post. A 90-day pilot gives you real data: your actual adoption rate, your actual Forward rate, your actual net saving. Monthly contract, no lock-in. Most clients continue. A few discover Forwarding isn't the right fit for their category; we'd rather they find that out quickly than pretend otherwise.

Further reading

Go deeper on this topic

Seen enough?

Two honest ways to go from here.

Start a 90-day pilot →Calculate your savings

Or compare Forwarding to alternatives first: Comparison →