Demand sizing is the process of estimating how much of a product a store will need in a given time window. At its most basic, you take historical sales, apply a growth or seasonal factor, and arrive at a purchase quantity. The challenge in multi-store retail is deciding what unit of analysis to use: the chain as a whole, the region, or each individual location.
Most mid-size retailers default to chain-level sizing because it's the path of least resistance. One number, one order, one decision. But chain-level sizing systematically misrepresents what each store actually needs -- and the cost of that misrepresentation shows up in two places: stockouts at high-velocity locations and excess inventory at low-velocity ones.
What Chain-Level Sizing Actually Measures
When you run a chain-level forecast, you're asking: "How much does our entire chain sell of this SKU per week?" If Location A sells 20 units and Location B sells 5 units, the chain sells 25 units per week. Divide by 2 locations and the average is 12.5 units. Your forecast sends 12.5 units to each location.
The problem is obvious once stated plainly. Location A needs 20 units to stay stocked. It gets 12.5. It stockouts by mid-week. Location B needs 5 units to stay stocked. It gets 12.5. It accumulates 7.5 units of excess that either gets marked down, sits on the shelf tying up capital, or eventually gets transferred.
This isn't a theoretical edge case. In retail environments with meaningful location-to-location demand variation -- which describes most urban multi-location chains -- the chain average is almost never the right number for any individual store. It's a number that's wrong in the specific direction for each location in your portfolio.
Store-Level Demand Sizing: The Mechanics
Store-level demand sizing calculates a separate demand estimate for each location. Rather than pooling sales data and dividing by store count, it maintains an independent time-series model per location, per SKU. Each model tracks:
- Recent sell-through velocity (units sold per day over the last 4-8 weeks, weighted toward the more recent)
- Day-of-week patterns (many retail SKUs sell 2-3x more on weekends than weekdays)
- Trend direction (is velocity increasing, decreasing, or flat over recent weeks?)
- Seasonal signals if historical depth supports them
From these inputs, the model projects demand for the next replenishment window -- typically 7 or 14 days -- and calculates the order quantity needed to cover that projected demand plus a store-specific safety buffer.
The result is an order that's right for Location A (say, 22 units) and separately right for Location B (say, 6 units) -- because the calculation started with each store's actual sell-through, not the chain's average.
Why the Granularity Matters More Than the Method
There's a common assumption in retail that the quality of a forecast depends primarily on how sophisticated the underlying model is -- the complexity of the algorithm, the number of variables it considers, the depth of the training data. This assumption leads buyers to invest in enterprise forecasting software that promises accuracy at the chain level.
The granularity of the input data matters more than the sophistication of the model. A simple weighted moving average applied at the store level will almost always outperform a complex model applied at the chain level, because the store-level input contains the actual signal -- what this specific location, with its specific customer base, actually bought last week -- while the chain-level input has already destroyed that signal through aggregation.
This is not a critique of algorithmic sophistication. It's a point about what the algorithm is being asked to model. If the input is a chain average, even the best model is producing a chain-average forecast. If the input is per-store sell-through, even a simple model can produce a per-store forecast that's genuinely useful.
The Minimum Data Requirements
A reasonable question at this point is: how much data does store-level demand sizing actually need to produce a useful forecast? The answer is less than most buyers assume.
For a product with stable demand, 4-6 weeks of store-level daily sales data is enough to build a credible baseline forecast and set a starting safety stock level. For products with meaningful day-of-week variation, you need at least 2-3 full weeks to capture the weekly pattern. For seasonal products, you ideally want a prior year's sell-through from the same location, but a chain-level seasonal index applied to a store-level baseline is a reasonable approximation when that history isn't available.
The more common problem isn't insufficient data -- it's that the data exists in a POS system that was never connected to the buying workflow. Most multi-store retailers have months or years of per-store, per-SKU daily sales data sitting in their point-of-sale system. The data is there. It just isn't being used for forecasting because no one set up the pipeline from POS to the buying desk.
What Changes When You Get It Right
The most immediate effect of switching to store-level demand sizing is order accuracy. Buyers who have gone through this transition consistently describe a reduction in both stockouts and overstock situations, because the order quantity is now derived from what each store actually needs rather than what the chain average suggests.
The secondary effect is buyer time. When orders are generated from accurate per-store forecasts, the buyer spends less time manually reviewing and adjusting orders. The exceptions -- the SKUs where the forecast is off, the locations where something unusual happened -- stand out more clearly because the baseline is accurate. Manual review becomes exception management rather than wholesale order construction.
The tertiary effect, which takes longer to materialize, is inventory efficiency. When you're not routinely over-ordering to compensate for forecast uncertainty, average inventory levels come down. For a 6-location chain, even a modest reduction in per-location safety stock carries through to a meaningful reduction in working capital tied up in inventory.
The Practical Implementation Challenge
For buyers who manage this process in spreadsheets, store-level demand sizing isn't theoretically out of reach -- but maintaining even 12 SKUs across 6 locations means maintaining 72 independent forecasting models in your spreadsheet, updated weekly from POS exports. In practice, that's not sustainable alongside everything else a buyer is responsible for. The forecasting work crowds out vendor management, promotional planning, and category review.
The argument for automated store-level forecasting isn't that buyers can't do the calculation -- it's that doing it manually at the scale a functioning multi-store chain requires consumes too much of the buyer's week to leave room for the decisions that genuinely require human judgment. The calculation should be automated. The exceptions, overrides, and vendor negotiations should be where the buyer's attention goes.
