Blog
/
Real-time inventory accuracy: why BOPIS fails without it

Real-time inventory accuracy: why BOPIS fails without it

Featured image

Walk into any retail conference and ask why BOPIS programs fail. You'll hear answers about customer experience, about staff training, about "the human element." Those things matter. But none of them are why BOPIS programs actually fail.

The real answer is mundane: most BOPIS programs oversell. The customer buys a product online and chooses pickup at a specific store. By the time the staff goes to pick the order, the item isn't on the shelf. It sold at the register an hour ago, or it was damaged and written off two days ago but never reflected in the system.

Every overselling incident creates a phone call, a refund, an apology, and a customer who probably won't come back. At scale, this is the difference between a program that lifts your business and a program that's a slow leak of customer trust.

The core fix isn't UX or training. It's inventory accuracy. And specifically, real-time inventory accuracy across every channel that can sell the same SKU.

Why this happens

In most retail setups, inventory is the source of truth in the point-of-sale system. Your POS knows what each store has. The job of an integration is to keep your e-commerce platform — usually Shopify — informed about what the POS knows.

The two most common methods for keeping Shopify informed are:

Manual update when your team remember. Hopefully every few days if they know what they're doing. Between updates, Shopify's inventory is stale.

Batch sync runs on a schedule. Every 5, 10, or 15 minutes, an integration pulls the current inventory from the POS and pushes it to Shopify. Between sync cycles, Shopify's inventory is stale.

Real-time sync is event-driven. When a sale happens at the POS, an event fires immediately, and Shopify is updated within seconds. There's no "between" — every change propagates as it happens.

The difference looks small on paper. In practice, it's everything.

The math of overselling

Consider a store selling a popular SKU. The store has 3 units on the shelf. Inventory syncs to Shopify every 15 minutes via a batch job.

10:00 — Sync runs. Shopify shows 3 units available.
10:01 — Customer buys 1 unit in-store. Store has 2 units. Shopify still shows 3.
10:04 — A BOPIS customer orders 2 units for pickup. Shopify allows it; the store now has 2 units in-store, 2 units committed to a BOPIS pickup. Net: store thinks it has 2 available; Shopify thinks it has 1.
10:08 — A second in-store customer buys the last 2 units. Store has 0 units. Shopify still shows 1.
10:10 — A second BOPIS customer orders 1 unit. Shopify allows it.

By 10:15, when the next sync runs and Shopify finally updates to 0, two BOPIS customers have orders for a product that doesn't physically exist. Both will get cancellation emails. Both will leave a negative impression.

This isn't a hypothetical edge case. For any moderately popular SKU, this happens multiple times a day under batch sync. The faster the inventory moves, the more frequent the overselling. The more channels selling the same SKU (Shopify, POS, marketplaces, social commerce), the worse it gets.

Real-time sync compresses that 15-minute drift window to a few seconds. The customer at 10:04 sees the correct number (2 available, after the 10:01 in-store sale). The window where overselling is possible drops by orders of magnitude.

The hidden latency: manual order routing

Inventory sync schedule isn't the only latency that can break BOPIS. Even with perfectly real-time inventory sync, BOPIS still fails if the order itself doesn't reach the right store in real time.

Many integrations require store staff to manually download or assign incoming BOPIS orders — pick from a queue, decide which store fulfills, mark it claimed. This sounds reasonable on paper. In practice, its even worse than batch sync.

When routing is manual:

  • An order placed at 10:04 might not be downloaded or assigned until 10:40, or 11:30, or whenever someone has a moment to check the queue.
  • During busy retail hours, the manual routing queue piles up. By the time staff catch up, customers are already calling to ask about pickup.
  • The "real-time inventory" promise becomes meaningless if the order itself sits unrouted for an hour while inventory keeps moving at the register.

In a single low-volume store, manual routing can work. In a multi-location operation during holiday season, it fails — and the failure looks exactly like the overselling scenario above, except the root cause isn't inventory drift, it's an unrouted order waiting on human attention.

Real BOPIS infrastructure automates both:

  1. Inventory sync — so what Shopify shows is what stores have, second-by-second.
  2. Order routing — so the moment a BOPIS order is placed, it's assigned to the right store and visible to staff in their existing fulfillment tools.

If either of these is manual, your BOPIS program is one busy day away from breaking. Maybe one hour.

What "real-time" actually means, technically speaking

Real-time inventory integrations listen for inventory changes in the POS and immediately propagate the change to Shopify (and any other connected channel — marketplaces, social commerce, ERP).

But it's more than that, because changes from Shopify also need to be sent to the POS for the inventory to be accurate. If one or the other falls behind, customers experience suffers.

Success requires:

  • The source platform to support real-time event emission (webhooks, API events, or similar)
  • The integration to subscribe to those events and react within seconds
  • The destination platform to accept inventory updates and orders via API at high frequency

Some POS systems handle this well. Some don't. The integration layer has to bridge whatever the POS can do with whatever the destination needs.

For BOPIS specifically, real-time matters because the entire customer experience depends on the website showing accurate stock at a specific location. Customers see "Pickup at Store A: In Stock" and trust that to mean they can drive to Store A and collect their item. If that statement was correct 15 minutes ago but is wrong now, you have an unhappy customer at the pickup counter.

Safety stock thresholds: when real-time isn't enough

Real-time sync handles the timing problem. But there's a second problem: even if your numbers are perfectly accurate, you can still oversell in another sense — by depleting in-store inventory to the point where walk-in customers can't buy.

Imagine you have 1 unit of a popular SKU at a store. A BOPIS customer orders it online before any walk-in customer sees it. The pickup is scheduled for tomorrow. For the next 24 hours, any walk-in customer who wants that item is told it's out of stock — even though it's technically there.

This is where safety stock thresholds come in. You configure each store with a buffer (e.g., "reserve the last 2 units for in-store demand only"). Any online order routed to that store can only fulfill from inventory above the buffer. The customer either gets routed to a different store with more stock, or the system shows the product as out of stock for online purchase at that location.

Safety stock is especially important during high-traffic periods (Black Friday, holiday season, new product drops). It's the difference between maintaining a healthy in-store sales floor and accidentally letting BOPIS gut your shelves.

Multi-channel competition

For most retailers, Shopify and the POS aren't the only places selling the same SKU. There's also:

  • Marketplaces (Amazon, eBay, Etsy)
  • Social commerce (Instagram, Facebook, TikTok Shop)
  • B2B/wholesale channels
  • Other Shopify storefronts (if you have multiple sites)

Every one of these channels selling the same physical inventory creates the same race-condition risk. Real-time sync needs to propagate across all of them. A real-time-Shopify, batch-sync-Amazon setup will oversell on Amazon.

The integration layer has to be the source of truth that broadcasts inventory changes to every connected channel, ideally within seconds of each change.

How Mortar handles real-time inventory sync

Mortar's inventory sync is real-time by default. When a sale happens at Lightspeed Retail (R-Series), Lightspeed Retail (X-Series), or Heartland Retail, the change propagates to Shopify within seconds. There's no batch job, no "sync every N minutes" setting.

And you don't replace your POS to get any of this. Mortar adds real-time inventory sync and the rest of the BOPIS infrastructure to the POS your team already uses. No migration, no retraining, no replatforming risk. Your store teams keep working in Lightspeed Retail or Heartland Retail; Mortar handles the integration with Shopify. The cost of switching a POS — months of implementation, staff retraining, data migration, business disruption — is often higher than the cost of the software itself. Mortar avoids all of it.

Specifically:

  • real-time architecture: every POS sale, inventory adjustment, return, and stock count is captured by Mortar and processesed immediately.
  • Safety stock thresholds per location: configure how much in-store inventory to reserve for walk-in demand at each store. Online orders can only consume inventory above the threshold.
  • Multiple Shopify sites supported: if you run separate Shopify storefronts (retail, wholesale, international), all of them stay in sync with the single POS source of truth.
  • Multi-location visibility: customers see real-time stock per location, so BOPIS choices reflect actual availability.
  • High-volume events: Mortar's architecture is built for traffic spikes — Black Friday, product drops, flash sales. Inventory stays accurate even at peak load.

The combined effect: Mortar stops overselling from being a recurring customer service issue.

See real-time inventory sync in action →

BOPIS is only going to matter more

What was a pandemic-era convenience is now baseline retail behavior. Customers filter for "pickup available today" the same way they filter for "free shipping."

The infrastructure underneath — real-time inventory, automatic routing, store-side workflow — is what separates BOPIS programs that scale from BOPIS programs that quietly become liabilities. Retailers who get the architecture right own this category. Retailers stuck on batch sync spend the next year explaining why their orders keep getting canceled.

Where to go next

See how Mortar's real-time inventory sync supports BOPIS →

Ready to connect your POS with Shopify?

Mortar syncs inventory, orders, and products between Lightspeed or Heartland Retail and Shopify in real time.

Start a Free Trial →