Floor stock vs backroom stock: the split that keeps shelves full

One pool of stock, two jobs — that's the quiet cause of most empty shelves in stores that aren't actually out of anything. The floor pool exists to be sold today; the backroom pool exists to refill the floor. When they're managed as one undifferentiated pile, the same failures repeat: the shelf drains while the backroom still looks full, counts turn up "missing" units that are really just in the wrong pool, and reorders trigger off a store-wide number that describes neither. The fix is a written split policy — a floor cap per SKU, one replenishment rhythm, separate count units, and min levels that treat the shelf as its own small store. Below is that policy, with the arithmetic to set it.

Two pools, two jobs

Same physical goods, same system location — the split lives in policy, not software, and that has consequences for counting further down.

What the backroom is for (and what it isn't)

The backroom is a buffer with a job description: hold enough units to keep the floor full between pulls, and no more. It is not overflow storage for every slow SKU you own, not a holding pen where returns wait indefinitely, and not a shadow floor where staff "find" units the system says are gone. A sorted, swept stockroom makes the split workable — but tidying is its own discipline, and the 10-minute reset routine lives in the retail stockroom organization guide; the recurring tiers — daily, weekly, monthly, with named owners — are the template in the warehouse cleaning schedule. What follows here is the policy layer above the tidy-up: caps, rhythm, counts, and levels.

Set a floor cap, then do the arithmetic

Take a midweight hiking sock, SOCK-MER-M-01, in an illustrative store with illustrative numbers:

• Facing count. The sock wall gives this SKU 6 facings, 4 deep: a floor cap of 24 units. The cap is physical — it's what the fixture can present — which is why it's set by the shelf, not by sales velocity. How deep a forward position should run before it needs refilling is its own sizing question — the pick face guide does that arithmetic per location; the cap here is the store-level ceiling above it.
• Floor demand. The SKU sells about 2.1 units a day (illustrative, from the last 90 days of POS sales). At that rate, a full cap is roughly 11 days of floor selling (24 ÷ 2.1 ≈ 11.4).
• Pull trigger. Replenish when the floor falls below half cap — 12 units here, about 5.7 days of selling before an empty facing appears. Half cap is the trigger, not empty, because a missed pull day should never be the thing that empties a facing.
• Backroom min level. The backroom must cover the gap between pulls plus the reorder pipeline: min = floor cap + 3 days of floor demand = 24 + (2.1 × 3 ≈ 6) = 30 units on hand, floor and backroom combined. When the store total hits 30, the buying list orders. When the floor hits 12, staff pull from the backroom.

The two triggers do different jobs, and confusing them is the classic failure mode: ordering at the floor trigger leaves the backroom hollow, and pulling from the backroom at the store trigger just moves the same 30 units around the room. And when it runs the other way — floor empty while the backroom still has stock — that's a split failure, not an ordering failure: the pull routine missed. Replenish the facing immediately, then fix the trigger and the window before touching reorder levels.

The replenishment rhythm

One pull window before opening, one sweep at close. That's the rhythm:

• Before opening (10 minutes). Walk the floor with the half-cap list. Any SKU below half cap gets pulled from backstock up to full cap, oldest received first, so packaging rotation doesn't leave the faded boxes in the back forever.
• At close (5 minutes). Facing recovery: push units forward on the fixture and note visibly low SKUs for tomorrow morning's list.
• Weekly. The buying list runs off store totals against min levels. The order math itself is the reorder point formula's territory — the reorder point formula guide covers the arithmetic — and the split policy's contribution is making sure the number feeding it means floor plus backroom, not one mystery pile.

The rhythm with numbers. An illustrative weekend on BIKE-LT-01, a front-light with a floor cap of 12 and a half-cap trigger of 6. The backroom starts Friday at 40.

• Friday close. Floor is at 10 after a normal weekday; the close sweep pushes facings forward and flags nothing. Store total: 10 + 40 = 50, well above the min level of 30 — no order.
• Saturday. Weekend rate on this SKU runs about 4 units (illustrative, same 90-day POS window). Floor ends the day at 10 − 4 = 6 — sitting at the trigger line, not below it. The rule is that the list gets written at close for tomorrow morning, not acted on mid-shift, so nothing happens yet.
• Sunday. Sunday sells 3. Floor: 6 − 3 = 3, below half cap. The close sweep writes it at the top of Monday's pull list: pull 12 − 3 = 9 units.
• Monday before opening. The runner pulls 9 from the backroom, oldest box first. Backroom: 40 − 9 = 31. Store total: 12 + 31 = 43 — still above the min level of 30, so Monday's buying list leaves this SKU alone.

Notice the order never fired even though the floor nearly emptied twice over the weekend. The backroom was doing its job the whole time, and the two triggers stayed out of each other's way: the pull covered the floor, the min level correctly declined to reorder.

Count units: what to count, and how often

The system sees one combined quantity per SKU, so the pools have to be counted separately for the split to stay real:

• Floor, weekly, facing by facing. The floor drifts fastest — customer handling, fitting-room returns, theft exposure. A facing-by-facing walk of the wall is 15 minutes for most fixtures and catches every drift that matters to a customer.
• Backroom, monthly, by cycle count. The backroom drifts slower and fails in bulk: a carton never opened, a return shelved unrecorded.
• Reconcile both against the system total. Floor count + backroom count should equal the system quantity. When it doesn't, the discrepancy is real and attributable to a specific pool — which beats the store-wide "34 units missing somewhere" hunt every time. The same two-count custody discipline applies when units move between your locations entirely: a store-to-store move is bracketed by counts at both ends, per the interstore transfer guide.

If you run POS, do the floor count at open before the first sale: applying a count mid-day erases that morning's sales, which is the most common self-inflicted count error (Shopify Help Center, accessed November 2026). The count methods themselves (full, cycle, spot) are covered in the counts guide.

Min levels when the system sees one location

Shopify records one available quantity per SKU at your location — it doesn't know your floor from your backroom (Shopify Help Center, accessed November 2026). So the split policy translates into the system like this: min levels are set on the store total (floor cap + days of cover), and the floor cap lives on paper, on the pull list posted in the stockroom. One native gap worth knowing: Shopify has no built-in low-stock email alert as of November 2026, so low-floor warnings come from saved views checked on rhythm or a Shopify Flow automation you build yourself (Shopify Help Center, accessed November 2026). The floor pool is small and fast, and it's the pool where a missed day is immediately visible to a customer standing in front of an empty facing. Empty facings sell against you: a shopper looking at a gap substitutes, waits, or leaves — and only some of the ones who leave come back.

Next step

Today, pick your ten fastest floor SKUs and write down two numbers for each: facing count and half-cap trigger. Post the pull list where the morning window will happen, and run the window — the split starts working the first day you do it. When those ten SKUs run low afterward, the order quantities come from the min levels, and the arithmetic for setting them is in the reorder point formula guide.