Why fashion demand forecasting fails at seasonal peaks
The seasonal sales peak in fashion fits into a few weeks, while collection purchasing is locked in months before it.
An error in the forecast here does not smooth out: unsold collection inventory goes to markdown, and lost sales on high-demand sizes cannot be recovered — the shelf is empty, and the customer has gone to a competitor.
The size grid turns the bet into a matrix: a miss in size distribution spoils the result even with the correct total volume.
The first bottleneck is sales history. New SKUs do not have it: a product lives for one season, there is nothing to repeat, and transferring the numbers of a similar model directly is dangerous — fit and color create variation that the average does not capture.
The second is promotions: discount weeks and sales distort the signal, and the model learns from demand that did not exist. If outliers are not cleaned, the forecast shifts toward the discount, and baseline demand is underestimated.
Next is data consistency. The hierarchy “category — model — color — size” is described differently in the accounting system, at the supplier, and in the planner’s files: different size codes, merged colors, diverging collection names.
Until the reference data is aligned, calculation at the size-grid level falls apart — the sum by sizes does not match the total by model. Manual transfer of numbers between tables adds row shift during copying, which surfaces only after delivery.
Each of these points breaks fashion demand forecasting in its own way, but they are cured by the same thing: data brought to a unified form and a model that accounts for seasonality, promotions, and uncertainty on new SKUs. Below we break down how this is closed.
The effect in numbers: plan accuracy, inventory, lost sales
We calculate the effect from one baseline: we compare the plan of past seasons with actuals by week, separately at the collection level and at the SKU level.
Planning accuracy by collection usually stays around 60–70%, while by SKU it drops to 40% — a manual plan levels groups and does not see local demand within the season.
After switching to managed planning, accuracy by collection reaches 85–90%, by SKU — 70–75%.
This is immediately visible in purchasing: unsold inventory is reduced from a quarter of the volume to 10–12%, and the depth of discount at the sale is limited to the first or second markdown stage instead of the final one.
Collection turnover accelerates — the product goes through the season rather than moving into the next one.
Lost sales are closed by speed of response. The plan is recalculated not once a quarter but on a weekly grid: a demand spike by SKU is captured within 5–7 days, replenishment and redistribution between warehouses land in the nearest delivery rather than the next season. For bestsellers, the share of lost sales falls severalfold — delay stops eating demand.
Separately, a class of errors in manual data transfer has been removed: we verify the item master against the GS1 reference, downloads run with integrity control and cross-checking of volumes by collection and SKU.
Discrepancies no longer surface mid-season — they are cut off at the input, before they enter the plan.
Design options: product hierarchy, recalculation frequency, horizon
The forecasting scheme is chosen not by “model accuracy” but by the level at which purchasing decisions are made.
If the plan is approved for the collection as a whole, a detailed forecast for each SKU only creates noise; if purchasing is by size, a single number will not suggest the structure.
The planning horizon (season or quarter) and recalculation frequency are configured separately: frequent recalculation catches demand shifts, but requires plan approval to keep up with it.
| Option | When it fits | Limitations |
|---|---|---|
| Single forecast by collection | Narrow assortment, purchasing decision made as a whole | Does not show distribution by models and sizes; an error in collection structure remains unnoticed |
| Flat forecast by SKU | Wide assortment with sales history for each item | Rare items without history produce a noisy series; the sum by SKUs diverges from the category plan |
| Two levels: category → model | Stable categories, plan approved at category level | Manual plan alignment between levels is needed; with different recalculation frequencies, the levels diverge |
| Full product hierarchy with forecast aggregation | Long horizon, purchasing by sizes and colors | More expensive to maintain, requires regular reconciliation: bottom-up forecast aggregation must match the top-down plan |
In practice, they start with two levels and add a third when the discrepancy between the sum by models and the category plan no longer fits within the acceptable range.
How implementation goes: from data audit to recalculation policy
Implementation of demand forecasting starts not with the model but with sales data: until it is clear what happened to collections in past seasons, any future accuracy is a random number. Therefore the steps proceed sequentially, and each relies on the result of the previous one.
- Sales data audit. We look at what actually exists: exports from the accounting system, POS, online store, and wholesale shipments. We mark gaps, duplicates, returns, and areas where the sale distorted history.
- History preparation. We build a unified schema: SKU, color, size, date, channel, price, and warehouse stock. We bring everything to one calendar and match it with deliveries and promo periods.
- Setup and training. The model learns on the prepared history, separately accounting for seasonality, new items, and products without prior history — launching a new collection is the riskiest case.
- Backtesting. The model “forecasts” an already past season where the answer is known. This shows behavior at peaks and sales, not an abstract metric.
- Deviation measurement. We break down the error by categories and SKUs: where demand was overestimated, where underestimated, and what cause stands behind it.
- Recalculation policy. We fix by which events and at what frequency the forecast is updated, who makes manual adjustments, and how they are accounted for later.
- Handover to the client’s team. We hand over the data schema, settings, instructions, and train employees so recalculation proceeds without our involvement.
After this, fashion collection demand forecasting becomes a repeatable process: the result is reproduced on a new season, and deviations are measured rather than discussed by taste.
Deliverables: models, policies, control panel
After launch, the client’s team is left not with a demonstration but with a working kit that planners use daily and that can be handed to a new engineer without verbal explanations.
We document in it everything that affects the forecast number: where data comes from, how promotions are accounted for, who can change what.
- Configured collection calculations: forecast by SKUs and sizes, scheduled retraining, separate models for new items and continuing lines.
- Data schema description: sales, warehouse, and receipt sources, matching rules, handling of gaps and duplicates.
- Rules for processing promotions and receipts: sales, promos, delivery date shifts, product substitution within a line.
- Control panel: accuracy for past periods, deviation from actuals, alert when the model diverges from reality.
- Planner instructions: how to read the forecast, enter a manual adjustment, and record its reason so it is accounted for later.
- Access rights matrix: roles — who only views, who adjusts, who changes calculation settings.
- Calculation documentation: metric logic, model versions, change log, rollback procedure to the previous one.
With such a kit, new collections are onboarded according to the policy by your team, not through us.
Case study: how unsold inventory was reduced in a seasonal collection
The women’s clothing chain Nordline purchased the season four to five months before sales started, relying on last year’s sales and buyers’ trend adjustments.
At the category level the forecast matched, but within the size-color matrix the error reached 40%: volume was spread “just in case,” and high-demand sizes went into shortage by the third month.
The bottleneck in planning was not average accuracy but the distribution of volume between SKUs and the size curve.
The forecast was built on weekly sales with features: category seasonality, weather series by region, promotion calendar, price, and availability history — so the model could distinguish “did not buy” from “was not on the shelf.” Size curves were moved into a separate layer, and the basics and fashion lines into separate models: they have different predictability and different safety stock.
Recalculation is weekly; the buyer sees an uncertainty interval and a replenishment plan, not a single number.
Over the season, the weighted average forecast error fell from 38% to 19%, and the share of items with an error above 30% fell from 46% to 18%. Unsold inventory at the end of the collection was reduced threefold, and lost sales due to missing high-demand sizes fell from 7% to 2%. The share of sales at full price increased, and markdown depth decreased.
The case is reproducible where there are at least two comparable seasons of sales and inventory history: without it, the model is no different from the buyer’s opinion; with it, planning becomes verifiable.
How does forecasting by collections differ from forecasting by SKUs?
The difference between the two planning levels is not in the horizon but in the nature of the signal. An SKU produces a short and noisy series: a few sales points, zeros for not-yet-launched combinations, spikes from promotions.
A collection aggregates history to a line or category, where seasonality and trend are read stably — therefore forecasting by collection is more accurate on a long horizon, while forecasting by SKUs is stronger on a short one.
The aggregated level covers decisions that cannot be made in parts: purchasing fabric and trims, line loading, the season plan as a whole. The detailed level is needed where the decision is local: size grid, allocation by channels and warehouses, reorder priority.
The two cannot be mixed in one series — the production plan will be overstated, and shortages will arise for specific SKUs.
A common aggregation mistake is to sum SKU forecasts up to the collection. Biases on individual series do not offset each other but accumulate, and a systematic overload appears at the aggregate.
The reverse path — decomposing the collection forecast by past shares — does not catch within-season shifts: a model that pulled sales gets the share of the previous period. Both options produce a plan that contradicts itself.
We align levels through reconciliation: base series are calculated in Prophet for each branch of the hierarchy, then brought to a reconciled form — bottom-up, top-down, or with weights by accumulated error.
The output is one set of numbers: the sum by SKUs equals the collection forecast, and the discrepancy stops surfacing at the shipment stage.
We keep two indicators under control — level consistency after reconciliation and accuracy at the aggregate: they show whether the overall plan was broken for the sake of local series.
Overproduction in problem groups is reduced severalfold, while for base lines the forecast deviation remains within boundaries at which purchasing does not go into stock.
Frequent technical questions: data, seasonality, retraining
Demand forecasting breaks not on mathematics but on data: short history, promo spikes, new SKUs without a single sale. Below are engineering answers to doubts that most often surface before the start.
What should be done if an SKU has only two or three seasons of sales?
Build a hierarchy: first a forecast at the category and style level, where there is enough history, then distribute it to the SKU by features — silhouette, color, price segment, sales channel. For completely new items, we connect transfer from similar SKUs of past seasons.
We output such a forecast as an interval, not a single number: the planner sees the width of the range and lays a buffer where the model is less confident.
Promotions and sales distort history — how is this accounted for?
Promo periods are marked with a separate feature and their effect is subtracted from the baseline so the model learns on “clean” demand. The spike itself is forecast separately — by discount depth, promotion length, and the category’s past response.
Without this separation, the model remembers a one-off sale as a new baseline and overstates the next season’s plan.
Accuracy dropped on live data — what is the order of actions?
We do not retrain immediately. First, the weekly error is broken down by layers: new SKUs, promo days, assortment changes, warehouse shortage — when there is demand but no product, and sales do not reflect real demand.
Most often the cause is precisely in the data, and fixing the export restores accuracy without touching the model.
How often is retraining needed, and how is the result controlled?
Regular updates run on a sliding window of the latest seasons, full retraining — before the purchasing campaign, plus unscheduled retraining when the assortment changes sharply.
Each update is tested on a holdout period: we run the model over past seasons and compare it with a simple benchmark of “same as last year.” If the updated version does not beat it, it does not go into production.
Let’s discuss the task: where to start and what to prepare
To make the conversation concrete, it is useful to collect in advance what you already have in accounting systems and planning tables.
This is not preparation for a tender: from this data, already at the first meeting we see which signals are sufficient for the model and which will have to be reconstructed from indirect sources.
Following the discussion of the task, we will return with an estimate and work plan — stages, team composition, and the timeline for the first verifiable version.
- Sales export by SKUs for 2–3 seasons: date, channel or location, quantity, discounted price. The longer the history, the more stably the model captures seasonality and spikes.
- Category structure and product hierarchy: how collection, model, color, and size are related. This determines at which level to build the forecast — by group or by each SKU.
- Season and launch calendar: dates of launches, receipts, sales, and promotions. Without it, demand growth cannot be distinguished from a one-off campaign.
- Current planning process: who decides the purchase volume and on what basis, what adjustments are made manually and why.
- Delivery data: lead times, multiples, and minimum order quantity constraints — the forecast must be executable, not ideal on paper.
- List of sources already in use: reports, planner files, exports from the accounting system. Describe the task in free form — we will clarify the rest on a call.
