Smart Replenishment for Supermarket Shelves
A major Chilean supermarket chain had no reliable view of what was actually sitting on its shelves at any given moment. I designed a system that calculated on-shelf stock in near real time and turned it into precise replenishment orders, what to restock, how much, and where, and then reused the same shelf-location data to plan more efficient picking and restocking routes.
Role: Designer and author of the initiative
The problem
A supermarket knows what it has in the building. What it usually cannot tell you is what is on the shelf right now, as opposed to sitting in the back room or already sold. That blind spot is expensive in both directions: shelves run empty while the system still shows stock (so no one reorders), and staff over-stack facings defensively to avoid being caught short, tying up space and pushing slow movers toward expiry. It also breaks e-commerce: pickers assembling online orders walk to a shelf the system promised and find nothing, then substitute a more expensive product and erode margin.
This was a measured pain, not a hunch. In May 2019 the chain's voice-of-customer scores put product availability at 68 and product variety at 71 (out of 100), the two lowest scores in the customer-experience set, and a store walk-through that June documented the whole catalogue of symptoms: out-of-stocks on the shelf, gondolas stacked over capacity, oversized replenishment runs blocking aisles during peak hours, and shoppers simply unable to find products.
What I designed
flowchart TD SAP["SAP item master
full in-store stock · near real time"] --> CALC SALES["Centralized sales database
units sold · near real time"] --> CALC APPDB[("Application database
setup · minimums · history
the brain")] --> CALC CALC["Available on-shelf stock
recomputed hourly"] --> MIN{"Below shelf
minimum?"} MIN -->|yes| ORDER["Replenishment order
what · how much · where"] ORDER --> APPUI["Replenisher app
scan EAN-13 / DUN-14 · pick · confirm"] APPUI --> CTRL["Control checkpoint
QR scan verifies only what was ordered left the back room"] CTRL --> SHELF["Shelf placement
QR at the gondola records exact location"] SHELF -. location data .-> ROUTE["Optimal picking & restocking routes"] SHELF -. confirmed quantity .-> APPDB
Three data sources reconcile into a single number, on-shelf stock, that drives a closed replenishment loop; every confirmed restock also records where the product physically is.
The core idea was to compute available on-shelf stock from three sources and recompute it every hour, so the floor always had a current number to act on:
- The full store stock from the SAP item master, refreshed each morning and integrated near real time.
- Units sold from the centralized point-of-sale database, decremented near real time so the available figure tracked sales through the day.
- The application's own database, the "brain," which held the starting position, each product's replenishment minimums, and the running history needed to separate what is on the shelf from what is still in the back room.
From those, the system derived the numbers that actually matter: available stock (store stock minus sales), on-shelf stock (last replenishment minus sales since), and back-room stock (the difference). That let it answer the questions a store manager could never answer before: which products are on the shelf but not in the back room, which are in the back room but missing from the shelf, and which are genuinely out of both.
How a replenishment cycle works
Instead of relying on a clerk noticing an empty facing, the loop is closed and self-triggering:
- A customer buys a product; the sale is decremented from on-shelf stock.
- When a product crosses its configured shelf minimum, the system generates a replenishment order specifying the exact quantity, expressed in both boxes and units, so a replenisher pulls neither too little nor too much.
- The replenisher opens the app, sees the store auto-detected and their own productivity figures, and works the order: each line shows the product, quantity, and its EAN-13 and DUN-14 barcodes. The phone camera scans each item during picking, and the round cannot be closed until every line is picked or explicitly marked missing.
- At a control checkpoint, a QR scan verifies that only what the order called for left the back room.
- At the shelf, the replenisher enters the quantity placed and scans a QR code on the gondola, which records exactly where the product went.
Replenishment rounds were designed to be configurable, every hour or two, with blackout windows during peak shopping, and deliberately staggered so restocking carts would not all hit the floor at once and block customers, one of the specific complaints the store walk-through had surfaced.
The location dividend
The part I find most interesting is a second-order effect. Because every restock recorded where a product was placed, the system accumulated a live map of product locations as a by-product of normal work. That map is exactly what you need to compute efficient routes through a store, so the same data that fixed shelf availability could also plan the shortest path for an e-commerce picker assembling an order or a replenisher working a round. The design objectives followed directly: shorter, right-sized replenishment runs, measurable replenisher productivity, fewer out-of-stocks, less expiry waste, tighter control over what leaves the back room, and a real stock figure for the e-commerce catalogue to sell against.
Why it mattered
This was part of the same operations suite as the in-store product locator, the product search system, and the order-fulfillment dashboard. They share a single thesis: the data needed to run a store well already exists, scattered across SAP, point-of-sale, e-commerce, and the shop floor itself, and the value is in reconciling it into one current number that a person standing in an aisle can act on. Smart Replenishment attacked the on-shelf-availability gap, and turned the act of fixing it into the location data that made the rest of the suite sharper.