BORIS: Making Buy Online, Return In Store Work

Buy online, return in store looks like a small convenience feature on a checkout page, but for retailers with physical locations it is one of the highest-leverage moves in the entire returns playbook. It turns a return, an event that usually generates zero revenue and often erodes goodwill, into a chance to get a customer back inside a store. The math is compelling enough that most omnichannel retailers now offer some version of BORIS. The operational reality behind that toggle is not simple at all, and the retailers who get real value from it are the ones who treat BORIS as a systems problem, not just a checkout option.

Why retailers offer BORIS in the first place

The appeal starts with foot traffic. A customer who has to walk into a store to complete a return is a customer standing in your store, often with time to browse, and store associates trained to use that moment convert a meaningful share of BORIS visits into an upsell, an exchange for a different size, or a small additional purchase that never would have happened if the return had been mailed into a warehouse queue instead. Refunds also feel faster to the customer, because a store associate can process the return and issue store credit or a refund on the spot, instead of the customer waiting days for a warehouse to receive, inspect, and release a mailed-back item. None of that value shows up cleanly in a returns-cost spreadsheet, which is exactly why it tends to be underinvested in relative to how much it can move retention and basket size.

• Incremental foot traffic: a mailed return generates no store visit; a BORIS return puts the customer back on the sales floor.
• Upsell and exchange capture: an associate can offer a swap or a complementary item at the counter, something no packing slip can do.
• Faster perceived resolution: an in-person refund or store credit beats waiting on a warehouse to receive and grade a mailed parcel.
• Lower reverse freight: a return absorbed into existing store logistics and truck routes avoids paying for a dedicated parcel shipment back to a warehouse.

Where BORIS breaks down operationally

None of that upside is guaranteed. BORIS collapses two systems that were built and staffed separately, the point-of-sale system that runs the store and the e-commerce platform that runs online orders, and it asks them to behave as one in the sixty seconds a customer is standing at the counter. Retailers that roll BORIS out without addressing the seams underneath it tend to see the same four failure modes, over and over.

• Inventory desync: a POS system that does not talk to the e-commerce inventory ledger in near-real-time will let a returned item vanish from stock, get double-counted, or show as sellable in a channel where it was never actually received.
• Untrained staff on online SKUs: store associates who spend all day on in-store barcodes are often unfamiliar with online-only SKUs, bundle items, or promotional variants, and without a lookup flow built for that, the counter interaction stalls or the wrong item gets accepted.
• Missing or garbage reason codes: a return desk under time pressure defaults to a generic reason code rather than the specific one an online order needs for accurate analytics, which quietly degrades every downstream report on why customers are actually returning.
• Checkout-line congestion: BORIS returns compete for the same counter, the same queue, and the same staff as paying customers at checkout, and during peak hours a return that takes four extra minutes to look up an online order is a line-length problem, not just a service problem.

The reconciliation problem: making a store return match the online order

The hardest technical problem in BORIS is not the storefront experience. It is reconciling a return accepted at a physical register against an order that lives in an entirely separate online order-management system, and doing it fast enough that the refund fires exactly once. A customer hands an item to a store associate, the POS marks it received, and somewhere in the background that event has to find the original online order, confirm the item and quantity match, and trigger a single refund or store credit. Get the timing wrong and there are two realistic failure modes, both expensive: the refund fires twice, once from the POS and once from the e-commerce system reconciling later, or the return sits in a gap between the two systems and never triggers a refund at all, which turns into a support ticket and a lost customer rather than a completed return.

1. 1Emit a return event from the POS the moment an item is accepted, tagged with the original online order ID, not just a generic in-store return.
2. 2Route that event through a single reconciliation layer that both POS and e-commerce systems write to and read from, instead of letting each system update its own ledger independently.
3. 3Lock the order record the instant a store return event lands, so a webhook from the carrier or warehouse arriving late cannot trigger a second, duplicate refund.
4. 4Reconcile inventory and refund state in the same transaction, so a partial failure cannot leave stock corrected but the customer unrefunded, or vice versa.
5. 5Reflect the store-accepted return in the customer's order history within minutes, not at end-of-day batch close, so the customer sees confirmation before they leave the parking lot.

What done right actually looks like

The retailers who run BORIS well share a few concrete traits, and none of them are exotic. Inventory updates in near-real-time across POS and e-commerce rather than on a nightly batch job. Store associates have a simple, fast lookup tool for online orders that does not require memorizing SKUs. Reason-code capture is built into the same flow the associate already uses, not a separate step they skip under time pressure. And peak-hour BORIS traffic is either routed to a dedicated returns counter or scheduled against known online-order spikes, so it never directly competes with the checkout line for the same three registers.

Training the floor, not just the software

The best reconciliation architecture in the world still fails at the counter if the associate standing there was never trained on what an online return actually looks like. That means a short, specific onboarding on how to search an order by email or QR code, what to do when an item does not match what the system expects, and when to escalate rather than force an override. It also means giving staff visibility into the same order history a customer sees, so both sides of the counter are looking at the same information instead of the associate working blind. This matters even more once a retailer sells across multiple channels, where a return might have originated from a marketplace listing rather than the retailer's own site; the reconciliation logic covered in our guide to multichannel and marketplace returns applies just as directly to a BORIS counter as it does to a warehouse dock.

A BORIS return that reconciles instantly feels like magic to the customer and like plumbing to everyone else. That is exactly the point: the harder the systems work behind the counter, the less the customer should ever notice.

None of the backend reconciliation work replaces the need for the customer to have their own visibility into what happened. A customer who returns an item in store should still be able to check their order status online afterward and see it reflected accurately, the same expectation we describe in the case for a self-service returns portal, because a return that resolves instantly at the counter but takes three days to show up correctly online just relocates the trust problem instead of solving it. Retail industry groups such as NRF have tracked the growth of omnichannel fulfillment options like BORIS for years, and the throughline in that research is consistent: the format only pays off when the systems behind it are fast and consistent enough that the customer never has to reconcile the channels themselves.