📦 Segmentation · Intermittent Demand

The C-Class Trap — When ABC Analysis and a Flat Seasonal Index Bury Your Best SKUs

✍ Vinayak Bhadani 📅 August 2026 ⏱ 9 min read 📍 Dubai, UAE

There is a class of SKU that standard planning systems handle badly and confidently: low unit velocity, high unit value, and demand concentrated into two or three calendar events a year. ABC analysis calls it a C item. A flat seasonal index smooths its peaks into nothing. The system then recommends carrying almost none of it — and it stocks out in the only weeks that ever mattered.

UNITS / MONTH 0 6 12 18 flat index = 64 ÷ 12 = 5.3/mo JanFeb Mar AprMay Jun JulAug Sep OctNov Dec Eid al-Fitr Eid al-Adha National Day New Year Actual demand Demand the flat index cannot see — 32 of 64 units Flat seasonal index

Figure 1. The same SKU, one year. The dashed line is what an annual-average seasonal index tells you to plan for. The hatched area is the demand that line is structurally incapable of seeing — half the year's volume, sitting in four weeks. Meanwhile the line over-forecasts eight quiet months, so the system is simultaneously holding stock you don't need and missing the sales you do.

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:

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, σ ÷ μ:

CV = σ(monthly demand) ÷ μ(monthly demand)
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 — stableY — seasonalZ — lumpy / event
A — high valueAutomate, tight controlSeasonal profile + reviewPlan every event manually
B — mid valueAutomateSeasonal profileEvent-based planning
C — low valueAutopilot, low reviewSimple 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.

Seasonal indexm = average demand in month m ÷ average monthly demand

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.

ABC AnalysisABC-XYZSeasonal IndexLumpy DemandInventory SegmentationGCC Retail

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 →

Vinayak Bhadani — Demand planning & S&OP in Dubai, building supply chain tooling for GCC operators. Every model here is public: the code and commit history are on GitHub.