Skip to main content
SEE IT FIRSTNov 17 · Everyone builds. IT approved.7 days, 17 hours, 13 minutes, 48 seconds remainingSave your spot
Sigma Computing
Fundamentals

Demand forecasting: methods, models and modern approaches

Michael Khmelik
Michael KhmelikEnterprise Solutions Engineer
November 9, 2026
13 min read
Demand forecasting: methods, models and modern approaches

Demand forecasting can generate reliable forecasts if the underlying data and assumptions align with the source data. Otherwise, it produces forecasts that no longer reflect the business. Yet, many S&OP teams still run the cycle in Excel. In a November 2025 survey of 164 practitioners, 81% named Excel or Google Sheets as their main tool, so a well-specified model often ends up as one of several versions of the same file by the time anyone acts on it.

This article covers how demand forecasting differs from demand planning and sales and operations planning (S&OP), the recurring failure modes of spreadsheet-based forecasting, what accurate forecasting requires today, and how AI agents extend the operating model.

Key takeaways

  • Forecasting methods are model-driven, where you set the structure, or data-driven, where the model fits a function. Simpler models have fewer ways to fail. Flexible ones need more data and more discipline.
  • Spreadsheet-based forecasting commonly fails in predictable ways. Versions multiply as files circulate, changes since the last forecast are hard to explain, and decision history gets lost.
  • AI agents can turn periodic forecasts into more continuous supervision. With configured triggers and guardrails, an agent monitors drift, re-runs the forecast when a threshold is crossed, proposes adjustments, and routes exceptions to a planner.

What is demand forecasting?

Demand forecasting is the practice of predicting future customer demand for a product or service using historical data, market signals, and statistical or machine learning models. Businesses use those predictions to estimate revenue, plan costs, and address operational questions such as staffing and production. How reliable a forecast needs to be depends on where it sits in the planning process and what it is for.

Demand forecasting, demand planning, and S&OP

Demand forecasting produces a forecast number, demand planning turns that number into an agreed demand plan, and S&OP reconciles that plan with supply and capacity. Integrated business planning extends S&OP into finance, portfolio, and strategy. Demand plans are usually built unconstrained first, because inventory and capacity limits belong to the supply side.

Forecast purpose determines the planning horizon

The purpose of the forecast sets the forecast horizon, and the horizon determines which signals matter and which methods dominate. Depending on the purpose, a team then chooses what it can do with the data available. Recent history carries most of the weight at short horizons. Further out, judgment matters when history is thin or a known event is missing from the model.

Demand forecasting supports three planning windows: execution, S&OP, and strategic planning. Short-term plans like production scheduling decides which job runs on which line. They would still use the demand planning but frequently have dedicated tools to manage this.

The window also sets how current the data has to be. An execution forecast reviewed weekly needs recent actuals, while a monthly S&OP cycle gets little from daily refreshes. At monthly cadences, the bigger risk is several versions of the forecast circulating at once.

Limitations of traditional demand forecasting

Traditional spreadsheet-based forecasting often drifts away from a single source of truth on predictable fronts: versions of the forecast multiply across files, changes since the last cycle are hard to explain, and the history of decisions behind the number is difficult to track.

Multiple versions of the truth

A spreadsheet-based forecast starts multiplying the moment it's shared. Planners keep their own copies, regional files get edited offline, and someone has to consolidate them. When forecasts roll up across product families, such as milk and ice cream, each file carries its own assumptions, and the consolidated number can match none of them exactly. Finance and planning teams then spend disproportionate time manually collecting, consolidating, and validating data. That lengthens forecast cycles and delays decisions the forecast should inform.

Forecast changes are hard to explain

With several versions in circulation, nobody can say why the number changed since last month. The monthly review turns on that question, and answering it takes last month's forecast, the assumptions behind it, and every adjustment since, in a form that can be compared. In a pile of spreadsheets, the prior version is often overwritten, renamed, or lost in consolidation, so the comparison falls back on memory.

Decision history is hard to track

Teams do review forecasts against actuals, usually in a regular demand review, but the record of what was decided rarely survives the meeting. Version history is often missing, override notes are often too thin to reuse, and teams rarely score the adjustment against the baseline or a naive forecast. Without that record, the team can't tell whether its adjustments helped, and the person who made the call leaves with the lessons.

Demand forecasting methods and their trade-offs

Forecasting methods tend to trade flexibility against the discipline they demand from the organization. A simple model has fewer parts that can fail, so it is easier to monitor and explain. A flexible model can fit patterns you did not specify. It demands clean data, monitoring, and someone who can explain it.

The right method also depends on how much usable history you have, how far out you need to forecast, and whether external drivers like price or promotions are known in advance. Use different methods across planning horizons, and expect the mix to shift as the planning window lengthens.

Quantitative and qualitative methods serve different situations

The choice between numbers and judgment often depends on how directly the available history applies. Most enterprises run a hybrid: a statistical baseline plus judgment that adds business knowledge the model doesn't have.

  1. Quantitative methods apply when numerical history applies directly and past behavior can reasonably be expected to continue. They give you a testable, reproducible starting point.
  2. When history doesn't apply directly, such as with a new product launch, teams use proxies, for example, a similar product launched earlier, and layer assumptions on top to adjust the number. Qualitative methods (Delphi panels, sales force composites, customer intention surveys, executive judgment) help shape those assumptions.
  3. Judgment calls enrich a statistical baseline with business knowledge the model didn't have when it was built. They can improve some forecasts, but they can also worsen others, especially when they push the baseline upward.

Use the numbers where they apply, use judgment to add what the numbers can't see, and measure whether the adjustments actually improve accuracy rather than assuming they do.

Model-driven methods

In a model-driven method, the analyst sets the structure and the data estimates the parameters. Forecasting already uses the word deterministic for a fixed trend. Time series methods such as exponential smoothing and ARIMA, and regression methods that bring in drivers like price and promotions, fall here: the analyst chooses the structure, and the data sets the parameters.

Planners can inspect that structure, explain it, and see why it misses. Pure time series methods rely on history alone. A history-only model cannot see a price or promotion it is not given. Regression in this family can, when those drivers are known ahead.

Data-driven methods

A data-driven model approximates a function. It shares signal across SKUs only when trained on many series at once, and it can take covariates.

Global models earn their cost on large related portfolios, and rarely on a few short series. Chronos, TimesFM, Moirai, and TimeGPT are the later set. Boosting is still the practical tool when promotions are known.

3 core requirements for accurate demand forecasting today

Forecast accuracy depends on the data and on the model. Three requirements separate forecasts that stay consistent with their source data from forecasts that drift: they calibrate against several data sources, test their assumptions, and run a business feedback loop on every iteration.

1. Calibrate forecasts against several data sources

Score actuals against the system forecast, and score the override against that forecast. A model that queries the warehouse directly can pull all of them from the same governed tables without anyone rebuilding the file, so the comparison reflects the business as it is now rather than the last pull.

2. Test and adjust assumptions with a measurable process

Treat an override as a testable step. Change one assumption, such as price or discount depth, then measure whether it cut error once actuals arrive. Forecast value-added measures that effect the change in an accuracy metric attributable to a specific step or participant in the process. Without it, override discussions can become contests of opinion rather than debates about accuracy.

3. Close the feedback loop from forecast back into the plan

Each iteration needs a business feedback loop. Actuals need to land in the same governed table as the projection, adjustments need a record of who made them and when. A material deviation should raise an exception. Most planning teams already review forecasts against actuals on a calendar cycle. The added step is a recorded outcome for each iteration: which assumptions missed, which adjustments helped, and what changes next.

The role of AI agents in demand forecasting

AI agents in demand forecasting can cover a layer that a model alone doesn't. An agent keeps a scheduled model current by watching surrounding signals and acting when conditions change. A good model then becomes a demand-planning function that stays current between refresh cycles.

An agent can be configured for four jobs. Note that these agents are good at recommending the changes, rather than running forecasts as a black-box:

  1. Monitor incoming demand signals against the model's assumptions and flag material deviations as they happen.
  2. Re-run the forecast when a configured threshold is crossed, rather than waiting for the next scheduled cycle.
  3. Propose adjustments to parameters, overrides, or safety stock, with the reasoning visible.
  4. Route exceptions to the right planner, with the context needed to decide, rather than dumping them in a queue.

AI agents are still early in enterprise deployment, and the sensible arrangement is human-in-the-loop so planners remain in control. A planner sets the drift threshold and schedule, defines what the agent may write, and approves consequential adjustments before they land. An AI update can include a short spike into the baseline, so limits on what an agent may write matter as much as the model.

How Sigma supports demand forecasting

A forecast stays consistent with its source data by running on that data instead of a copy. Sigma is an AI apps and analytics platform for building and scaling governed apps, dashboards, and agents on live cloud data warehouse data. It sits between your cloud data warehouse and the AI systems generating outputs from that data. It turns the artifacts those systems produce into production-ready software that inherits your existing governance.

For demand planning, Sigma can be the tool to build the forecast, define its assumptions, and override write-back on that warehouse data, with no export in between. Users can also build demand forecasting apps in Sigma.

Query warehouse data live from the workbook

Planners query live warehouse data directly from a workbook: formulas, pivots, and filters in the spreadsheet interface compile to SQL and execute inside Databricks, Snowflake, BigQuery, Amazon Redshift, and other supported warehouses. Common forecasting calculations, from simple Excel-like formulas to more complex variants such as Holt-Winters, can be expressed inside the workbook. They run against always-live data at warehouse scale, with row-level security inherited from the warehouse.

Write back scenarios and assumptions with input tables

Input tables let a planner enter a discount depth, a lead-time change, or an override quantity and write it back to the warehouse from the workbook. Input tables write new data to a separate schema. Original warehouse data is never overwritten, and changes appear in a tracked change record so overrides are auditable and reversible.

Configure Sigma agents to monitor forecasts continuously

A Sigma agent can monitor forecasts continuously once a builder configures it with plain-English instructions, the tables it can read, and the actions it can take. In a typical demand-planning setup, an agent can be configured to watch actuals against forecast, flag SKUs where the deviation crosses a defined threshold, draft a proposed adjustment with the reasoning attached, and route it to the responsible planner for approval before anything writes back. The planner sets the goal and the guardrails, and the agent carries the work forward between review cycles.

Build demand forecasting models with Sigma

Flexible models, from causal regression to gradient boosting, are hard to manage and need proper tooling.

Sigma is built to support that: it sits on live, governed warehouse data, can use advanced warehouse functionality, and lets planners express forecast logic in a spreadsheet-like interface. It overrides writeback with an audit trail, and agents help keep the model honest between cycles.

Run the next demand forecast on the warehouse your team already trusts, so it stays current after the first pull and the feedback loop closes faster. Request a demo to see Sigma running against live warehouse data, or try Sigma free and build against your own data.

FOLLOW SIGMA

Related articles

Activate your data warehouse

Stop buying a new tool for every workflow. Build it once on governed data, then scale it across the business.