Why sales forecasting breaks on seasonal shifts
Manual planning usually looks like this: take last period's sales, multiply by a coefficient, and add a safety stock "just in case." While demand is steady, such a spreadsheet hits the target.
But seasonal demand fluctuations rarely repeat day for day — the peak shifts by two to three weeks, and the purchase arrives at the end of the surge, when the shelf is already empty.
The second source of misses is data lag. The actuals from the accounting system arrive as an export once a day or less often, some channels close with a delay of several days, and the purchasing and shipping decision is made before current movement is visible.
Product master data also diverges separately: in retail, on marketplaces, and in wholesale, the same product exists under different codes and in different units, so it is impossible to bring the channels into a single picture manually.
Promotions and new products break the history even more. A surge from a sale looks like stable growth in the data, it is carried into the future plan, and excess stock is purchased.
A new product arrives without a seasonal profile and without understanding which positions it will take from neighboring ones.
The cost of error is twofold: the warehouse fills up with what does not sell, while fast-moving positions run into shortages and lost revenue that cannot be recovered.
We explain how this is closed: where data enters the sales forecasting loop, how seasonal indices are calculated, and how the plan is reconciled with actuals.
What managed demand forecasting delivers: the effect in numbers
The effect of the model is visible not in training reports but in operational metrics: how often a fast-moving item runs out, how much working capital is frozen in the warehouse, and how evenly space and shifts are loaded.
Below are four dimensions by which we compare the state before and after launching sales forecasting.
Forecast accuracy on daily and weekly horizons
The model based on CatBoost calculates a forecast for each position separately, not by category average: shipment history, seasonality, promotion calendar, product availability on the shelf.
On the daily horizon, the error for fast-moving positions is reduced by about half — purchasing goes from the forecast, not from the average for the previous period.
Stockouts of fast-moving positions
Previously, a demand surge was detected after the fact — when the shelf was already empty and the delivery would arrive in a week.
An interval forecast estimate raises the signal in advance: the share of "out of stock" days for top items is reduced several times over, and lost demand does not turn into cancellations and switching to a competitor.
Frozen stock and inventory turnover
The flip side of manual planning is safety stock "just in case" across the entire assortment.
The model sets different stock depth for stable and volatile positions: inventory turnover accelerates, and the share of dead stock and goods that have outlived their season falls by a third.
Eliminated class of planning errors
A promotion, a price jump, a delivery delay — the manual plan breaks entirely and silently.
We test the forecast for stability and flag positions with high uncertainty for manual decision-making: the class of errors "the shift was noticed too late" goes away, and demand changes are visible weeks before a shortage.
Sales forecasting model formats: regression and ensembles
The choice of a sales forecasting model is dictated by the data structure, not the complexity of the algorithm: the length of history, the planning horizon, the number of series, and how often promotions, price changes, and new positions appear. Below are four real alternatives that are usually chosen between, with honest limitations for each.
| Option | When it fits | Limitations |
|---|---|---|
| Simple regression on lags and features | Stable trend, dozens of series, horizon within one deal cycle | Does not hold nonlinear "promo × channel" interactions, falls apart on rare events |
| Seasonal models (decomposition and exponential smoothing) | Pronounced weekly or annual seasonality, stable history for two seasons or more | Struggles with structural shifts and opening of new locations, parameters need manual retuning |
| Ensemble of models (gradient boosting on trees and on time series) | Hundreds and thousands of positions, dozens of features, frequent price and promo | Requires a feature store and drift monitoring: without it, error grows unnoticed, and explainability is lower |
| Hybrid approach: model plus expert rules | Launching new categories, lack of history, strict rules on minimum batch and warehouse limits | Rules need versioning and maintenance, and there is a risk of embedding expert opinion instead of data |
In practice, the option is not chosen "by eye": first we calculate a baseline forecast and a naive model as a reference point, then run the candidates on a rolling window and look at the error separately for top positions, new products, and promo weeks.
Often the result is an ensemble or a hybrid — but already with numbers showing exactly where the complex model beats the simple one.
How we implement a forecasting model: stages of work
Sales forecasting stops being useful when it is built in isolation from data and from the planning process.
Therefore the route begins not with algorithm selection but with an audit of sources, and ends with acceptance of forecast quality on your side — against agreed metrics, not promises.
- Data audit. We analyze the sources: accounting system, warehouse, web analytics, marketplace exports. We look at the depth of history, arrival delays, duplicates, gaps, and master data changes — we record what is missing and what will have to be restored.
- Schema and data mart. We agree on granularity (day or week, point of sale, product group), keys, and rules for recalculating history. We get a reproducible layer from which the model takes data identically on every run.
- Feature engineering. Seasonality and calendar lags, promotions, prices, availability, behavior of regular customers. We check each feature for stability across years and for the absence of data leakage from the future.
- Model training and validation. We split history by time, not randomly: otherwise validation quality turns out inflated. We compare the result with a simple baseline forecast and with current planning, and look at the error separately by horizons and product groups.
- Forecast deployment. Scheduled updates, output in a convenient loop — report, data mart, or direct transfer to your system. We immediately set up monitoring: actual vs. forecast deviation, degradation, seasonal shift.
- Acceptance and handover to operation. Retraining regulations, incident review, training for your team. Acceptance is based on forecast quality metrics fixed before work begins.
Each stage is closed with an artifact: a data schema, a feature set, a quality report, a regulation. If the audit shows that there is not enough data for an honest forecast, we will say so before the start, not after.
What you receive: artifacts and regulations
We hand over not a report with a chart but a working forecasting loop: from source descriptions to the regulation by which your team updates the model.
Each artifact has an owner and a version in the repository, and the scope is fixed at handover — the solution can be developed in-house or handed to another contractor without code archaeology.
- Data flow schema — which systems provide sales actuals, at what frequency, where cleaning and aggregation happen, and which fields are required at the model input.
- Metric dictionary — unified definitions of revenue, shipments, returns, and recognition period; we agree before the start so that the forecast and reporting calculate the same thing in the same way.
- Configured recalculation loop — the forecast is updated on schedule, a run log is maintained, and on failure an alert is sent indicating the failed step.
- Retraining regulation — triggers (quality drop, assortment or promotion calendar change), launch procedure, and acceptance criteria for a new model version.
- Drift control — comparison of the distribution of input data and the target variable with a reference period, and a "forecast vs. actual" report by product groups.
- Operations regulation — who owns the model, how to roll back to the previous version, what to do when quality degrades, and where to turn in case of an incident.
- Documentation and team training — feature descriptions, launch instructions, analysis of typical failures, and hands-on sessions with your analysts.
Case study: planning accuracy in retail before and after
A chain with three sales channels — retail locations, an online store, and marketplaces — planned supplies in spreadsheets.
The buyer took average sales for the previous period and manually adjusted them for promotions, while the reorder decision was made based on current stock and experience.
What it was like before implementation
The baseline was measured for two weeks across three groups of metrics: the share of positions in shortage, the volume of excess inventory, and planner labor costs.
At the start, shortages held at 11–14% of the assortment, inventory turnover reached 74 days, and two planners spent about 30 hours per week recalculating the plan.
What changed after
The model calculates demand at the "position — point — week" level, separately accounts for promotions, seasonality, and the delivery schedule, and recalculates daily.
The planner no longer builds the plan from scratch: they review only positions with a deviation above the threshold — that is 5–8% of the assortment. We made this transition for the Meridian network.
Over two quarters, shortages dropped to 4–6%, turnover was reduced to 51 days, on-time shipment accuracy grew from 82% to 96%, and write-offs due to expiration dates fell by almost half.
Planning labor costs — about 9 hours per week instead of 30; the freed-up time went to working with suppliers and local promotions.
How streaming recalculation differs from nightly batch processing
The difference is in when the forecast is calculated. With batch recalculation, a job once a day reads the entire sales history, retrains the model, and writes the result to the data mart — until the next run, the numbers do not change.
The forecast delay equals the schedule period, but the system load is predictable: the heavy recalculation runs at night, when only scheduled exports compete with it.
Streaming updates work on events: an order, return, or stock change enters a queue, and the model recalculates the forecast as they arrive.
The delay drops to minutes, but the load becomes steady and around the clock, and bias control is added to the model — otherwise streaming recalculation gradually drifts the forecast, and this is noticed only after a miss.
Streaming mode is justified where actions depend on the forecast: dynamic pricing, warehouse replenishment, shipment priority, filtering suspicious orders.
Where the decision is made once a week — purchasing plan, budget, production load — nightly batch recalculation is sufficient and cheaper to maintain.
In practice, a hybrid is more often deployed: at night the model is retrained on the full history, during the day the stream further trains it on fresh data and recalculates only the affected positions.
We assemble such a schedule in Apache Airflow — one loop is responsible for both batch recalculation and streaming updates, so the discrepancy between the data mart and the model does not accumulate.
Common technical concerns before the start
Before the start, we discuss not the choice of model but two questions: whether there is enough data and how the forecast will fit into the current accounting loop. Below are four concerns that most often slow down a project, and how we address them.
How much history is needed for the forecast to work?
For seasonal series, at least two full annual cycles are needed, preferably three: otherwise the trend is not separated from a one-off surge. With a short history, we connect external series — promotions, holidays — and start with a forecast by category, not by each position.
Data lies in different systems — is that a problem?
The problem is not fragmentation but the absence of a common key. We bring accounting, POS systems, warehouse, and online store into a single layer, and reduce product and location master data to one identifier.
We do not hide discrepancies but show them: a stock mismatch of a couple of percent usually explains part of the forecast error.
How to forecast new products with no history?
There is nothing to learn from a new SKU, so we transfer patterns from similar positions — by category, price segment, season, and shelf. For the first weeks, the forecast runs by group; then the weight of its own sales grows, and the model switches to the product's own history.
How to integrate the forecast into the accounting system?
We do not replace accounting: the forecast is returned to it as an export broken down by horizons and versions, so that any version can be recalculated and compared with actuals.
The planner remains in the familiar interface and sees the forecast, actual, and deviation side by side.
Let's discuss your task and come back with a work plan
So that the discussion of the task turns into an estimate of timelines rather than a retelling of general words, let's start with a conversation about your data and planning process.
It is important for us to understand which sources of sales history are available, at what detail, and what is already known about the future period: both the class of model and the scope of work depend on this.
- what exports exist now — depth of history, detail by locations and channels, completeness of data on returns and cancellations;
- what is known about the future period: schedule of promotions and discounts, deliveries, seasonal constraints, assortment changes;
- how the plan is built today, who uses it, and how often it is recalculated — the forecast horizon depends on this;
- which systems provide data and whether it can be collected on a schedule, without manual exports;
- which forecast error is critical: overestimation leads to warehouse overstock, underestimation leads to shortages and lost sales;
- who on the customer side is responsible for data, acceptance of the result, and further operation.
We come back with a work plan: a list of stages, timeline estimates for each, team composition, and data requirements that need to be closed before the start.
Separately, we describe model handover — documentation on features and quality metrics, training for your team, retraining procedure, and accuracy control after launch. Describe your task — we will come back with an estimate and plan.
