The SKU that breaks the model
Picture a premium corporate gifting item. Call it a presentation set — high perceived value, priced around AED 2,400, the kind of thing bought as a gesture rather than a routine purchase.
Through most of the year it sells one or two units a month. Occasionally none. On a velocity ranking it sits near the bottom of the portfolio. Then Eid arrives and it sells twelve. Then National Day and it sells eighteen in a fortnight. Then the New Year corporate gifting window and it sells fifteen.
Sixty-four units for the year. Thirty-two of them — exactly half — inside four weeks.
Now watch what a conventional planning setup does with that SKU.
Step one: ABC misclassifies it
Classic ABC ranks SKUs by annual consumption value and cuts at roughly 80/15/5. Sixty-four units is a small number next to the fast-movers, so unless the value ranking is done carefully this item lands in C. And C-class carries a standard package of consequences: lower target service level, less frequent review, minimal safety stock, low forecasting attention, and often an explicit instruction to planners not to spend time on it.
Every one of those consequences is wrong for this SKU, and they are applied automatically.
Step two: the flat seasonal index erases the signal
Then the system computes a seasonal index. If that index is a single annual figure — or if seasonality is fitted across a whole category and applied uniformly — the calculation is effectively 64 ÷ 12 ≈ 5.3 units per month. That number is the worst possible answer, because it is wrong in both directions:
- In the eight quiet months it forecasts 5.3 against actual demand of 1–2. You carry stock that ages, occupies space and ties up AED 2,400 a unit.
- In the four event months it forecasts 5.3 against actual demand of 12, 8, 18 and 15. You stock out in every one of them.
The average is arithmetically correct and operationally useless. It describes a month that never happens.
The one-line version: an average is a bad description of a distribution with two modes. This SKU does not have a demand rate — it has an off state and an event state, and planning it as though it has a single rate guarantees you are wrong in every month of the year.
Step three: the loss is invisible in the KPI
Here is the part that makes this so persistent. A stockout on a C-class item barely registers. Line fill rate is dominated by the fast-movers. Unit-based service level metrics treat one missed gift set the same as one missed carton of a commodity item. So the reporting says the month went fine.
But in revenue terms, thirty-two missed units at AED 2,400 is roughly AED 77,000 of lost sales on a single SKU — and on gifting lines the gross margin percentage is usually well above the portfolio average, so the profit impact is disproportionately larger. Multiply that across every event-driven item in a gifting or seasonal range and the number stops being a rounding error.
Worse, these are not deferrable sales. Nobody buys a National Day gift in October. The demand does not queue — it evaporates, and frequently it walks to a competitor who had stock.
What is actually going on, in planning terms
Two distinct failures are being conflated, and separating them is what makes the problem solvable.
Failure 1 — Wrong classification axis
ABC measures importance by value. It says nothing about predictability. A SKU can be low-volume and highly predictable, or low-volume and violently lumpy. ABC cannot tell them apart, so it treats them identically.
Failure 2 — Wrong seasonality granularity
A seasonal index applied at portfolio or annual level assumes every SKU inside it shares one shape. Event-driven SKUs have a shape that is nothing like the category average, so the index actively destroys their signal.
The formal name for the demand pattern is lumpy demand — infrequent occurrence combined with high variability in size when it does occur. It is the hardest of the four standard demand classes to forecast, and it is precisely the class that conventional systems demote to the lowest tier of attention.
The fix, in four moves
1. Add a second axis: ABC × XYZ
ABC on its own is one-dimensional. Overlay an XYZ classification measuring demand variability — typically the coefficient of variation, σ ÷ μ:
X = CV < 0.5 stable and predictable
Y = 0.5–1.0 variable, often seasonal
Z = CV > 1.0 lumpy, event-driven, hard to forecast
Our SKU: μ = 5.3, σ ≈ 6.3 → CV ≈ 1.2 → Z
Now the SKU is a CZ item, not a C item — and CZ is a completely different management instruction from CX. A CX item genuinely can be left on autopilot with a low review frequency. A CZ item needs event-based planning and human attention precisely because the model cannot handle it. Same ABC letter, opposite treatment.
| X — stable | Y — seasonal | Z — lumpy / event | |
|---|---|---|---|
| A — high value | Automate, tight control | Seasonal profile + review | Plan every event manually |
| B — mid value | Automate | Seasonal profile | Event-based planning |
| C — low value | Autopilot, low review | Simple profile | ← our SKU lives here. Not autopilot. |
2. Move from an annual index to a monthly index, computed per category
Replace the single annual figure with twelve monthly indices, and — critically — fit them at the level of the smallest group that genuinely shares a demand shape. Gifting is not one category. Corporate gifting, personal gifting and seasonal confectionery peak on different events.
Flat approach: every month = 1.00 → forecast 5.3 every month
Monthly index: Jan 0.19 · Mar 2.26 · Sep 3.40 · Dec 2.83 · quiet months ~0.19–0.38
Forecast Sep = 5.3 × 3.40 ≈ 18 units — the spike is now in the plan
3. Plan the event, not the month
For a genuinely lumpy SKU, even a monthly index is coarse. National Day demand does not occupy September evenly — it occupies about ten days of it. Build the plan around an event calendar with a defined build-up window and a hard cut-off, and work backwards through lead time from the event date rather than the month boundary. If it is a 60-day import lane, the September event is a July purchasing decision.
4. Set service level by contribution, not by letter
The reason C-class items get a low service target is an assumption that a stockout is cheap. For a high-value, high-margin event SKU that assumption is simply false. Set the target from the economics — the margin lost on a missed sale against the cost of carrying the unit — rather than inheriting it from the ABC letter. In practice this usually justifies a materially higher service level for the event window only, and a low one for the rest of the year.
Before
C-class · flat index 5.3/month · standard C service level · monthly statistical review. Result: stocked out in all four events, carrying dead stock for eight months.
After
CZ item · monthly index by sub-category · event-anchored build-up plan · service level set by margin. Result: buffer sits where the demand is, and the quiet months hold almost nothing.
Where this breaks
You need enough event history. Two or three observations of one event is a thin basis for an index. Where history is short, borrow the shape from a comparable SKU in the same sub-category and scale it — an assumption you state openly rather than a number you pretend is measured.
Some events move. Eid shifts about eleven days earlier each Gregorian year, so a monthly index anchored to calendar months will drift out of alignment within a couple of years. Fixed-date events like National Day and New Year are stable; lunar events need to be indexed relative to the event date instead. That is a different mechanism and it is worth handling separately.
Chasing lumpy demand at SKU level can overfit. With single-digit monthly numbers, one unusual corporate order can look like seasonality. Fit the profile at sub-category level where the sample is larger, then apply it down to the SKU — more robust than fitting twelve parameters to sixty-four observations.
The upside is capped by shelf life and obsolescence. Event-specific packaging that misses its event is often worth very little afterwards. The higher service level is justified by margin, but only up to the point where the write-off risk on unsold event stock overtakes it. That trade-off deserves an explicit number, not an instinct.
The takeaway: the problem was never that the SKU was hard to forecast. It was that the system asked the wrong question. "How many does this sell per month?" has no useful answer for an event-driven item. "When does it sell, and how much in that window?" has a very good one — and the data to answer it was sitting in the history the whole time.
Work out what the buffer should actually be
Once the SKU is classified as CZ with an event-anchored profile, the next question is how much to hold in the build-up window. The safety stock and reorder point calculators take the variability directly.
Open the calculators →