AI Business Forecasting Dashboard

Before any pricing, the design point that matters most: a language model should not be producing the forecast. Numeric extrapolation is not what these models are good at, and a plausible-sounding number carries no confidence interval and no auditable method. The statistical model produces the figure; the language model explains it, adjusts for events you describe, and writes the narrative. That is what this demo does, and it is the right division of labour.

With that settled, here are the three routes for a mid-sized workload — 500 series, forecast weekly across a 52-week horizon, refreshed monthly — which is 26,000 forecast data points a month.

The forecasting mathematics has been free and open source for years. Prophet, ARIMA, exponential smoothing and the rest are mature, well-documented, and carry no licence cost. That is genuinely unusual — in most of these demos the build route trades money for engineering, but here the core capability is a free library and a moderate amount of statistical literacy.

So what does $52/month actually buy? Managed training, automated model selection across several algorithms, and not having to own the statistics yourself. That is a reasonable trade if nobody on the team wants to reason about seasonality and stationarity. It is a poor trade if someone does, because the same result is a free library away.

Note the tier structure. Amazon Forecast's first 100,000 data points a month are the most expensive ones at $2.00 per 1,000, falling a hundredfold to $0.02 above 50M. Small deployments pay the worst rate — which is the opposite of the usual assumption that managed services get cheaper at small scale.

The planning platforms are a different purchase entirely. They are not forecasting engines; they are the place where finance argues about the number, holds scenarios side by side and locks a version. None publishes list pricing, so no figure is quoted here.

Skills you need on hand

The part that is easy to underestimate: your accuracy ceiling is set by what you recorded, not by which model you pick. If promotions were never logged, no algorithm can attribute the spike or predict the next one. Teams routinely try three modelling approaches when the actual constraint is that nobody wrote down when the discount ran.

The specific trap worth naming: a stockout looks exactly like low demand. If you forecast from sales rather than demand, every period where you ran out teaches the model to expect less, so you order less, and run out again. This is censored demand, it is self-reinforcing, and it is invisible unless someone deliberately corrects for it.

Choose build when you have clean history, someone comfortable with the statistics, and the forecast feeds your own systems. The libraries are free and very good.

Choose a forecasting API when you want managed training and model selection and would rather not own the mathematics.

Choose a planning platform when the hard part is not producing the number but agreeing on it — multiple contributors, versioned scenarios, an audit trail, and a board pack at the end.

Timeline. A working forecast on clean data takes days. Getting the data clean, the events recorded and the hierarchy reconciling takes weeks to months, and that is the project.

Accuracy, stated honestly. Expect meaningful improvement over a naive baseline on series with real seasonality and enough history. Expect very little on short, sparse or intermittent series — new products, long-tail SKUs, anything with mostly zeros. Those are exactly the items people most want forecast, and they are the ones where statistical methods have least to offer.

Always measure against the naive baseline. Last period repeated, or last year's same period. A surprising number of forecasting projects never beat it, and without that comparison nobody finds out. If your model cannot beat "same as last year", it is not ready and no amount of tuning at the model layer will fix it.

Report the interval, not just the point. A forecast of 1,000 units is not actionable. A forecast of 1,000 with an 80% interval of 850–1,150 is, because it tells you what to hold. Systems that surface only the point estimate quietly encourage people to treat an estimate as a commitment.

Where it actually goes wrong

• Censored demand — forecasting from sales rather than demand, so stockouts train the model downward in a self-reinforcing loop.
• A one-off event is learned as seasonality. A single unusual month is absorbed as a recurring annual pattern and reappears in the forecast forever.
• Hierarchies that do not reconcile, so the sum of the parts contradicts the total and finance stops trusting all of it.
• A pipeline change silently alters the grain — daily becomes weekly, or a unit definition shifts — and accuracy degrades with nothing erroring.
• The forecast is never scored. No backtest, no error tracking, so nobody can say whether it works, and it drifts from useful to decorative without a moment where anyone notices.

The honest question to ask first: can you beat "same as last period" today, and do you know by how much? If you cannot answer that, start by measuring your current process against a naive baseline. It costs nothing, it takes an afternoon, and it will tell you whether you have a forecasting problem or a data-recording problem — which are solved very differently.