Retail seasonal planning off your own POS data

The buy that was committed before the season arrived

A 24-store grocery chain sized its holiday baking buy the way most operators do: last year's category total for the quarter, divided by thirteen weeks, plus a bit. The stores ran out of canned pumpkin and pie spice in the Thanksgiving week, backfilled at full cost in December, and were still marking down flour and foil pans in the second week of January. Nobody had forecast badly. Nobody had forecast the shape at all.

Retail seasonal planning is the work of turning the shape into numbers you can order against: a seasonal index built from the retailer's own point-of-sale history that says, week by week, how far above or below the underlying run rate the category actually runs. Three decisions come out of it, and only three. When to start building stock, which week the peak really lands in, and the week to stop ordering so the season does not follow you into January.

The index is not a forecast. It is a shape. You still need a level, and the level comes from the trend and whatever you know about next year's stores and distribution. Keeping those two separate is most of the discipline in this method, because a number that mixes them cannot be corrected when either one moves.

Building the seasonal index in five steps

Everything below runs on weekly POS at category level, three years back, on the retail calendar the chain reports on.

1. Fix the grain and the calendar. Category by retail week, not SKU by calendar week. SKU-level weeks in a mid-size chain carry too few units to hold a stable ratio, and calendar dates put the same holiday in different weeks in different years. Use the retail week number so week 45 means the same position in the year every time, and read the 4-5-4 calendar on why the 53rd week has to be handled explicitly rather than averaged in.

2. De-trend with a centred moving average. For each week, compute the centred 52-week moving average of the category's units: the 26 weeks either side plus the week itself. Then divide the actual week by that average. What you get is the ratio to moving average, and the division is what removes chain growth, new stores and category drift, which would otherwise be baked into the index and read as seasonality forever.

3. Average the ratios by week number, across years. Three years of ratios for week 45, averaged, is the raw index for week 45. Use the median instead of the mean if one of the three years contained an event you know about, such as a store closure or a supply gap.

4. Normalise so the 52 indices average 1.00. Divide each week's raw index by the mean of all 52. Skip this and the index carries a small level bias that silently rescales every order quantity you compute from it.

5. Strip your own promotions out, or label them. A category that got a front-page ad in week 44 two years running has a week-44 index that is partly a record of your ad. Build the index off baseline units where you can separate them, and where you cannot, flag the promoted weeks so nobody plans a base buy against a promoted history.

Worked example: thirteen weeks of holiday baking

Same 24-store chain, baking and baking spices, three years of weekly units. The table shows each year's ratio to its own centred moving average, then the averaged index.

One ratio worked all the way through, so the rest are checkable: in year 3 the chain sold 36,900 units of baking in week 45 against a centred 52-week average of 19,320 units a week, and 36,900 / 19,320 = 1.91.

Now put a level against it. The chain's de-trended run rate for the coming year is 19,800 units a week, which is the number that carries the growth, the store count and the distribution changes. Multiply through:

• Week 45, the peak: 1.91 x 19,800 = 37,818 units.
• Weeks 43 through 49, the season proper: the seven indices sum to 9.98, so 9.98 x 19,800 = 197,604 units. A flat plan across the same seven weeks buys 7 x 19,800 = 138,600. The season carries 59,004 units more than flat, or 42.6% above it, and that gap is the entire reason the stores ran out.
• Weeks 50 through 52, the exit: the three indices sum to 1.89, giving 37,422 units against a flat 59,400. Keep ordering at the flat rate through the exit and you buy 21,978 units nobody is going to want until next November.

That last line is the one that funds the whole exercise. The stockout in week 45 is the visible failure and the January markdown is the expensive one, and both come out of the same missing shape.

Reading the index: pre-build, peak week, exit

Three thresholds turn the table into dates.

The pre-build starts where the index crosses about 1.10, which here is week 43 at 1.16. That is when the shelf has to already be deep, not when the orders go in. Subtract the lead time to get the order date, and for a distributor-supplied grocery account that is typically two to four weeks. At three weeks, the order that fills week 43 is placed in week 40, when the index still reads 0.96 and every report on the manager's desk says the category is running normal. Committing the build while the data still looks flat is the uncomfortable part of retail seasonal planning, and it is unavoidable: the peak week cannot be influenced from inside the peak week.

The peak week is the maximum of the index, not the week with the holiday in it. Here it is week 45 at 1.91, the Thanksgiving week itself. In other categories it sits one or two weeks earlier, because the purchase happens before the occasion. Foil pans and baking spices peak in the same week as the meal; frozen turkeys do not. Reading the peak off the calendar instead of the index is how a category gets its display space in the week after it needed it.

The exit runs backwards from the same lead time. With a three-week lead, the last order that sells inside the season is placed in week 46 for week 49 delivery. Everything ordered in week 47 or later arrives into an index of 0.70 and below. The rule that comes out of this is blunt and worth writing on the order guide: stop ordering seasonal packs the moment the last in-season delivery is committed, and let the tail sell down from what is already on the floor.

For the single-event version of this read, including how much of a holiday spike is genuine incremental demand and how much is pull-forward from the weeks either side, see tentpole events. This page is the annual index those events sit inside.

Retail seasonal planning for seasons that are not holidays

Holiday seasons are the easy case because everyone knows the date. The seasons that get missed have no date on them at all, and they come in three shapes. The same chain and its convenience sister stores, same method:

The plateau is the one that gets over-ordered. A summer beverage season peaking at 1.28 looks unimpressive next to baking's 1.91, but it runs above 1.10 for fourteen weeks, so it carries far more incremental volume in total. Amplitude and duration are different questions and a season needs both numbers.

The step change is not seasonality at all, and treating it as such double-counts it. Foodservice breakfast at a convenience store rises when the local school year starts and mostly stays there, which is a level shift with a date. Two things follow: it belongs in the trend, not the index, and its date is store-specific, because school districts do not all start in the same week. Deriving the ramp week per store from that store's own POS is the only way to get it right, and it is one of the places store clusters earn their keep, since stores that share a ramp week behave the same way for the whole term.

Where retail seasonal planning goes wrong

Sizing the season off the peak week. Take week 45's 1.91 and apply it across the seven-week season and you buy 13.37 index-weeks against a true 9.98, which is 34% too much. The peak is one week. The season is a distribution.

Building the index on raw sales in a growing chain. A chain growing 11% a year that averages raw weekly units by week number gets an index that tilts upward across every year for reasons that have nothing to do with the season. The centred moving average in step 2 exists precisely to remove that, and skipping it is the single most common way this method fails quietly.

Aligning on dates instead of retail weeks. Easter moves between March and April. Thanksgiving moves within its week band. A 53rd week shifts every subsequent week's year-over-year partner. All three produce an index that is wrong in two adjacent weeks at once, one high and one low, which is harder to spot than being wrong in one.

Indexing a store that is too small to index. A single store's category week may carry a few hundred units, and the noise in that swamps the seasonal signal. Build the index at chain-by-category level and apply a store amplitude factor, which is one number per store per season rather than 52.

Indexing a new item. An item with no history has no index. Use the category's shape and the item's own level, and revisit after the first full season rather than pretending the first eight weeks told you anything about December.

Exiting on the index instead of the index minus lead time. Everyone understands they should stop ordering when the season ends. Far fewer move that date back by the lead time, and the difference is exactly the pile of seasonal stock that shows up in the January markdown report. Preventing that is cheaper than clearing it afterwards.

Expecting the index to know about the weather. A grilling or ice season indexed off three years gives you the average year. A cold, wet May is a real miss and the POS history will not warn you about it, because it is not in there. Use the index for the shape and hold judgment for the year.

Where Scout fits

The index above is a POS aggregation and a division: weekly units by category, a centred moving average, a ratio, an average across years, a normalisation. Scout computes that on the retailer's own connected POS, keeps it current as weeks land, and holds the level and the shape as separate numbers so the plan can be re-cut when either moves. The output that matters operationally is a small set of dates per category, per store cluster: build week, peak week, last in-season order week.

Two boundaries. Scout recommends order quantities and timing and flags over-ordering against them, and the purchasing system still transmits the purchase order: Scout does not raise or transmit purchase orders, hold an order guide, or carry an EDI connection to your suppliers. And the index is built from transactions, so it describes what sold and when. It carries no weather feed, no traffic or footfall panel, and nothing about who was shopping.

The short version

• A seasonal index is a shape, not a forecast. Build it from your own weekly POS as a ratio to a centred 52-week moving average, average the ratios by retail week across three years, and normalise so the 52 weeks mean 1.00.
• Keep the shape and the level separate. The index times the run rate is the plan, and either input can be corrected without rebuilding the other.
• One chain's holiday baking season ran 42.6% above a flat weekly plan across its seven core weeks, and 21,978 units below flat across the three weeks after it. Both halves cost money if you plan flat.
• Set the pre-build where the index crosses about 1.10, take the peak from the index rather than the calendar, and move the exit date back by the full lead time.
• Plateau seasons carry more volume than spike seasons at a lower peak, and a step change like back-to-school foodservice belongs in the trend, not the index.