Multi-Location Inventory and BOPIS, Done Right

The promise and the failure mode

Buy-online-pickup-in-store (BOPIS) is one of the highest-converting offers in retail. Customers get their item today without a shipping fee, and you turn a web visitor into a foot-traffic visit who often buys something else while they're there. Curbside pickup added a contactless variant that stuck.

The promise is simple. The failure mode is brutal: a customer drives to your store for a pickup, and the item isn't actually there. That single broken promise costs you the order, the trust, and usually a review. BOPIS done badly is worse than no BOPIS at all.

The root cause is almost always the same — inventory that isn't tracked per location, or that's tracked but not decremented atomically when two channels hit the same unit at once.

One number per SKU is not enough

The mistake most stores start with is a single global stock number per product. You have 12 hoodies. A customer in the web checkout buys one. A walk-in at your downtown register buys one. Your warehouse ships one to a marketplace order. Which location does each unit come from?

If you only know "12," you can't answer the BOPIS question — do you have this item at the store this customer chose? — and you can't promise same-day pickup honestly. Per-location stock means each Location has its own on-hand count, and the storefront only offers pickup at locations that actually have the item.

In BestWebby, every Location keeps its own inventory pool. A pickup offer for a product at a given store is only shown when that store's on-hand count is positive. Ship-from-store and pickup fulfilment draw down the selling location's stock specifically, so the count for that store stays honest.

The race condition that creates oversells

Even with per-location counts, there's a subtler bug: two orders for the last unit arriving at the same instant. If your system reads the stock (1 available), then writes the new value (0), and two requests interleave that read-modify-write, you sell the same unit twice.

The fix is an atomic conditional decrement: instead of "read then write," you issue a single database update that says decrement this location's stock by N only if at least N is available, and you check that exactly one row was updated. If the row count is zero, the unit was already gone, and that order is rejected cleanly before any money moves.

This is how every stock decrement works in BestWebby — at the storefront, at the POS register, and on BOPIS assignment. There is no window where two buyers can claim the same physical unit. Overselling at the last unit is the single most common inventory complaint in retail, and an atomic decrement eliminates the entire category.

Designing the BOPIS flow itself

Accurate stock is the foundation. A good pickup experience needs a few more moving parts:

Honest availability at the product page. Show pickup availability per store, in real time, before the customer commits. "Ready in 2 hours at Downtown" is a promise; only make it where stock supports it.

A clear ready-for-pickup signal. When staff have set the order aside, mark it ready and notify the customer. BestWebby sends a pickup-ready email only when a customer email exists — it never fakes a notification, so "ready" always means ready.

A staff pick list. Your store team needs a queue of orders to assemble, tied to the specific location, with the items and bin locations. Treat it as an operational task, not an afterthought buried in the order list.

A grace window and re-stock rule. If a customer doesn't collect within your window, the units should return to sellable stock automatically so they're not stranded. Decide the window up front.

Ship-from-store: your network is a fulfillment network

The same per-location engine that powers pickup also powers ship-from-store. When a web order comes in, you can assign it to whichever location has the stock and is closest to the customer — turning every store into a micro-warehouse. This cuts shipping time and zones, and it moves slow-selling local stock before you have to mark it down.

The routing decision — which location fulfils an order — should consider on-hand stock first (don't route to a store that can't fulfil), then proximity, then your own staffing realities. Start simple: route to the location with stock nearest the customer, and refine from there.

A practical rollout order

If you're standing this up from scratch, do it in this sequence:

1. Get per-location stock accurate first. Count each location, set its on-hand, and reconcile against your POS. BOPIS on top of wrong counts just automates broken promises.
2. Turn on pickup at one location. Prove the flow — availability display, ready notification, staff pick list — at a single store before scaling.
3. Add ship-from-store once your counts are trustworthy and staff are comfortable with the pick workflow.
4. Layer routing rules last, when you have multiple locations and real order volume to optimize against.

The takeaway

BOPIS isn't a checkbox; it's a stock-accuracy discipline with a customer promise attached. Get per-location counts right, decrement them atomically so you never sell the last unit twice, and only show pickup where it's genuinely available. Do that, and same-day pickup becomes one of the most profitable, highest-trust offers you run.