Use case

Demand forecasting that shows the range, not just the number

Turn monthly product demand into a median plan and an 80% range, then use the band to decide capacity, purchasing and buffer stock.

Run the sample Put this in production

A demand plan is used by several teams at once: purchasing buys to it, operations staffs to it, finance models revenue from it. A single number forces each team to add its own informal buffer. An explicit range lets them agree on which band to plan against.

The example below is monthly unit demand with a seasonal peak. The same workflow works for a product family, a region, or a channel. Keep the series in the unit the decision is made in — units for purchasing, hours for staffing, revenue for finance — rather than mixing units in one column.

The sample series

The studio below is preloaded with this monthly unit demand series and a 6-step horizon. It is an illustrative example, not a real company’s data. Replace it with your own CSV to run the same workflow.

Show the CSV

month,units
2024-01-01,820
2024-02-01,790
2024-03-01,860
2024-04-01,910
2024-05-01,980
2024-06-01,1040
2024-07-01,1080
2024-08-01,1060
2024-09-01,990
2024-10-01,940
2024-11-01,1120
2024-12-01,1280
2025-01-01,870
2025-02-01,840
2025-03-01,920
2025-04-01,970
2025-05-01,1030
2025-06-01,1110
2025-07-01,1150
2025-08-01,1120
2025-09-01,1050
2025-10-01,1000
2025-11-01,1190
2025-12-01,1360

What to watch in the output

Read the band as a planning range

The 80% band is not a worst case. It is the range the model expects to contain the outcome four times out of five. If you need a 95% service level, add an explicit buffer on top of the high band.

Check the seasonal shape before trusting the peak

With only two annual cycles, the model has seen one repeated peak. A third cycle is stronger evidence. If the peak moves, the band will be wider — that is information, not a failure.

Keep the forecast unit stable

Do not switch between units, cases and revenue mid-series. A unit change looks like a demand shock and trains the model on a pattern that never happened.

Common mistakes

—Forecasting a product family and a single SKU in the same column. The family is smoother; the SKU has its own lifecycle.
—Ignoring capacity constraints. A forecast above plant capacity is a planning signal, not a production plan.
—Using the median as a target without a review cadence. Demand forecasts decay; rerun them on a schedule and compare the new band with the old one.

How to put it to work

1. Start with the sample. Run the preloaded series once so you see the output shape before you debug your own CSV.
2. Replace it with your history. Keep one timestamp column and one or more numeric columns. Mark outages and stockouts as empty cells, not zeros.
3. Backtest before you plan. Hold out the last few periods, compare the forecast with what happened, and check whether the actuals land inside the 80% band.
4. Move it into production. Use the REST API for a nightly job or an internal tool. One credit per successful call; failed calls are refunded.

FAQ

Is this a replacement for a demand-planning platform?

No. It is a fast, zero-shot forecast for a CSV series. It does not manage hierarchies, consensus planning, promotions or supplier constraints. It is useful when you need a defensible range quickly or want a second opinion on an existing plan.

Can I include price or marketing spend as a driver?

You can include up to eight numeric columns, but the model is not a causal engine. A correlated column can improve the pattern; it does not prove that changing price will move demand. Validate with a backtest before acting on a causal story.

How often should I rerun the forecast?

Monthly for a monthly plan, weekly for a weekly plan, and after any structural change such as a new channel, a price change or a supply disruption.

Need this as an API?

The same forecast is available as a metered REST endpoint with JSON and a downloadable quantile CSV.

See the API