Skip to content

See a demo

30 minutes with Sasha Zhang · video link on confirmation

Loading scheduler…

Retail allocation: splitting one buy by store

One buy, 62 stores, and a spreadsheet that divides by 62

A buyer at a 62-store operator commits to 1,800 units of a new hot sauce, and then the interesting question arrives: which stores get how many. The default answer is an even split, 29 a store, and the slightly more sophisticated default is a split weighted by each store's share of chain sales. Both are wrong for the same reason, and the retail allocation that comes out of either one produces two failure modes at once. Some stores run out in five weeks. Some are still holding the item at Thanksgiving.

Allocation is a separate decision from replenishment and it is worth being precise about the split, because the two are usually run by the same team and sometimes by the same system. Allocation is the up-front division of a committed buy across stores, before any of those stores has sold a single unit of the item. Replenishment is the ongoing reorder against observed demand, and the method for that is on retail replenishment guidance. The allocation decision is harder precisely because there is no demand history for this item at these stores. You are allocating on inference.

What retail allocation actually decides

Four decisions, and skipping any of them is how one of the two failure modes above gets built in:

DecisionThe questionConsequence of getting it wrong
Store selectionWhich stores get the item at allToken allocations to stores that cannot turn a pack
Quantity per storeHow many units each selected store receivesBackroom stock in some stores, stockouts in others
HoldbackHow much of the buy is not released on day oneNo units left to feed the stores that actually sell it
ReallocationWhen and how units move after the first readThe first guess becomes permanent, and then a markdown

The first three happen before the item ships. The fourth is where most of the recoverable money is, and it is the one that reliably does not happen, because by the time the data exists everyone has moved on to the next buy.

Step 1: score stores on the category, not the chain

A store's share of chain sales is the wrong denominator for a specific item. It says how big the store is. What you need is how big this item's category is at that store, which is a different ranking and often a very different one.

The score is two fields you already hold:

demand score = store share of chain sales x (store category index / 100)

The category index is the store's share of chain category sales divided by its share of chain sales, times 100. An index of 134 means the store does 34% more of this category than its overall size predicts. Normalize the scores so they sum to 100 across the fleet, and they convert directly into units.

Six of the 62 stores, with the arithmetic:

StoreClusterShare of chain salesCategory indexDemand score4-week demandShelf capacityReleased
1046Full-format, high2.4%1182.83433636
1118Full-format, high2.2%962.11323630
2207Full-format, std1.6%1342.14332424
2260Full-format, std1.7%550.94142412
3011Small format0.9%880.79121812
4004Seasonal / resort1.1%1521.67262424

Stores 2207 and 2260 are the pair to look at. They are a tenth of a point apart in chain sales, 1.6% against 1.7%, and a sales-weighted split gives them 24 units each. On the category they are not comparable at all: one indexes 134 on hot sauce and the other 55. The correct release is 24 and 12. Ship the sales-weighted answer instead and 2260 receives close to seven weeks of supply against a four-week cover window, while 4004, which indexes 152, is short by six units in a store that will sell out inside that window.

Three practical notes on the index. Use the narrowest category the data supports, because "condiments" hides exactly the variation you are trying to find. Use a trailing 52 weeks rather than 13, so the index is not a seasonal artifact. And where the item is genuinely new to the chain with no category analogue, the index has to come from a similar item chosen on shopper substitution rather than on where the hierarchy files it, which is the same cold-start problem pricing models have.

Step 2: convert the score into units, then let the constraints round it

The score gives a demand estimate. Three constraints turn it into a shippable quantity, applied in this order:

units = round_to_pack( min( demand over the cover window, shelf capacity ) )
        floored at minimum presentation

Cover window. Allocate the number of weeks of demand that has to last until replenishment takes over, which is the first review cycle plus lead time. Four weeks is typical for a new item on a weekly review. Allocating more than the cover window is not generosity, it is pre-loading the backroom.

Shelf capacity. The planogram gives the item a facing count and a depth, and that product is the ceiling. Units above it go to the backroom, and backroom units on a new item are close to worthless: staff do not know the item exists, the shelf reads empty, and the system says in stock. That is the mechanism behind a large share of phantom out-of-stocks, described on on-shelf availability.

Pack rounding and the presentation floor. The DC ships inner packs of six here, so every release is a multiple of six, and no store gets fewer than one inner pack. That floor is also the store-selection rule: a store projecting three units of four-week demand takes eight weeks to clear one inner pack and sixteen weeks to clear a case of twelve. Those stores should be excluded from the initial release and picked up later from the holdback if the item performs, not given a token pack that becomes a markdown.

Worked example: 1,800 units across 62 stores

The buy is 1,800 units. Hold back 15%, so 1,530 units are released on day one and 270 are retained. Chain-wide four-week demand for the item is projected at 1,530 units, which is what makes the cover window and the release quantity the same number.

ClusterStoresCategory demand shareRaw unitsShelf capacityUnits releasedAvg per store
Full-format, high1838%5813657632.0
Full-format, std2740%6122464824.0
Small format1217%2601821618.0
Seasonal / resort55%77249018.0
Total62100%1,5301,53024.7
Raw units (demand)Units released581576Full-format, high612648Full-format, std260216Small format7790Seasonal / resort
Constraints move units between clusters rather than removing them: 1,530 in, 1,530 out, and the 44 the small-format shelf cannot hold land where they can sell (worked example)

Raw units is the demand share applied to the 1,530: 581 + 612 + 260 + 77 = 1,530. Released is what survives capacity and pack rounding, and it also sums to 1,530, because units removed by a constraint do not evaporate.

The small-format cluster is the instructive row. Twelve stores that are only 12% of chain sales carry 17% of the category, so demand says 260 units. Their shelf holds 18, which caps them at 216. The 44 units they cannot hold go back into the pool, and they land in the standard full-format cluster, where average demand of 22.7 units per store was sitting just under a pack boundary and 24 is the honest round. The full-format high-volume cluster gives back five units on rounding and the resort cluster picks up thirteen.

Compare that against the two defaults. An even split ships 24 to every store, which puts 24 units into a small-format store with an 18-unit shelf, so six units per store go straight to the backroom in 12 stores. A sales-weighted split gets the clusters roughly right and gets the stores inside them wrong, which is the 2207-against-2260 problem repeated across all 62.

Step 3: hold back, and write down what releases it

The 270-unit holdback exists because the allocation above is built entirely on inference. Two weeks of real sell-through is better evidence than any index, and the holdback is what lets you act on it.

The release rule has to be written before the item ships, or the holdback becomes dead inventory in the DC. A rule that works:

  • Wait two full weeks of complete store-week data, not one.
  • Compute realized rate of sale against the rate the allocation projected.
  • Release to stores realizing above 125% of projection, in rank order.
  • Anything unreleased after week four goes to the top decile regardless, because a holdback held past the cover window is just a stockout with extra steps.

On this buy, 11 stores came back above 125 after two weeks. The 270 units split 24 apiece across them with a remainder of six, which went to the single strongest store, taking it to 30. Every one of those units landed in a store that had already proved it would sell them.

Fifteen percent is a reasonable default for a new item with a soft demand signal. Ten percent is enough for a repeat item with real history. Above about 20% and you are shipping so little on day one that the first two weeks stop being a fair test, which defeats the purpose of holding anything back.

Step 4: reallocate on two weeks of real data

Reallocation is the highest-return step and the one that gets skipped. After two to four weeks, some stores are at index 40 and some at 160, and the units are in the wrong places. Moving them is cheap compared to the alternatives, and the comparison is arithmetic rather than a matter of taste.

The item retails at $5.49 against a $3.09 cost, so each unit carries $2.40 of margin. A transfer that rides an existing DC backhaul costs roughly $0.30 a unit, which against $2.40 of margin at risk is an easy yes and needs no approval process. A dedicated courier run costing $18 to move 12 units is $1.50 a unit, and that only pays if the alternative was a markdown of at least 27.3% ($1.50 divided by $5.49). Work that threshold out once per lane and the reallocation decision stops being a debate.

Two rules keep it honest. Move from the bottom of the index distribution to the top, not from the largest absolute over-stock, because a big store holding 40 units and selling 10 a week does not have a problem. And do the move once, at week three or four, rather than continuously, because a store that keeps receiving and shipping the same item generates handling cost and inventory record errors that outlast the item.

If the reallocation window closes and units are still in the wrong stores, the decision becomes a price decision, and the timing and depth of it are on markdown optimization.

Where retail allocation goes wrong

Allocating on chain sales. The single most common error, and the one the 2207-against-2260 pair illustrates. Store size is a fine tiebreaker and a poor primary sort.

Ignoring shelf capacity. Units above the planogram capacity are backroom units, and backroom units on a new item are invisible to staff and to shoppers. The record says in stock, the shelf says otherwise, and the fix requires store-level inventory visibility to even see.

A token pack to every store. Ordering an inner pack into a store with three units of four-week demand feels fair and creates a guaranteed markdown. Exclude the store and revisit it from the holdback.

Holdback that never releases. A holdback with no written release rule and no owner sits in the DC until someone finds it during a cycle count. That is strictly worse than shipping it on day one.

Stale store grades. A remodel, a competitor opening, or a change in the store's foodservice program moves the category index materially, and grades set at implementation and never refreshed will keep allocating to a store that stopped being that store two years ago.

Confusing allocation with replenishment. After the cover window, this item is a replenishment problem with a demand history, and it should move onto the normal par levels and review cycles rather than being hand-allocated forever.

Treating the buy quantity as fixed evidence. The allocation cannot fix a buy that was too large. It can only decide where the excess sits. When the demand scores sum to materially less than the buy, that is worth saying out loud before the item ships rather than discovering it in the markdown review.

Where Scout fits

Scout builds the demand score from the chain's own POS: the category index per store on the narrowest category the data supports, over a trailing 52 weeks, refreshed rather than set once. It applies the cover window, the capacity ceiling and the pack rounding in that order and returns the store-by-store release quantity with the arithmetic visible, so an allocator can see why 2260 got 12 and 2207 got 24.

It also runs the two steps that usually do not happen. The holdback release list is computed from two weeks of realized rate of sale against projection. The reallocation candidates are ranked by units a transfer would move and scored against the markdown depth that transfer avoids, which is the comparison that decides whether the lane is worth running.

Two boundaries, stated plainly. Scout may hold the resulting balance, but the merchandising or purchasing system still transmits the allocation and the purchase order. And this whole method starts after the buy quantity exists: deciding how many units to commit against an open-to-buy budget is merchandise financial planning, which Scout does not do.

The short version

  • Retail allocation is the up-front split of a committed buy across stores, and it is a different decision from replenishment, which starts once the item has a demand history.
  • Score stores on the item's category index, not on their share of chain sales. Two stores a tenth of a point apart in size indexed 134 and 55 on the same category and correctly received 24 units and 12.
  • Apply the cover window, then the shelf capacity ceiling, then pack rounding, and let the units a constraint removes flow back into the pool. The 44 units the small-format cluster could not hold went to the stores that could.
  • Hold back 10 to 15%, write the release rule before the item ships, and reallocate once at week three or four while a transfer at $0.30 a unit is still cheaper than a markdown.

Want this as a Google Sheet?

Drop your email and we'll send the worked example.

Book a demo with your data