The problem
Demand forecasting in an ERP traditionally requires a separate forecasting model: time-series ARIMA, exponential smoothing, or a more sophisticated ML pipeline that someone has to train, deploy, and retrain quarterly. The cost of building that pipeline is what keeps demand forecast as a specialist feature in a corner of the ERP, not an everyday tool. Smaller-scale teams either go without — and overstock or stockout — or buy a separate demand-forecast SaaS that does not integrate cleanly with the operational data already in the ERP.
The data the forecast needs is already in the ERP: monthly units_sold history, seasonality, supplier lead times, project pipeline. The conditional structure is there. What is missing is a way to predict units_sold without buying a separate model and retraining it monthly.
How it works
Aito's _estimate on the monthly demand table returns units_sold conditioned on the SKU, the season, and what the product sold in the same month last year, as a band. Seasonality comes from the history itself — there is no separate seasonal decomposition step — and the why lists the past months the estimate weighted. The forecast updates live as new sales land; no retraining schedule, no batch job, no quarterly tuning.
The ERP demo holds out the last six months and shows every forecast next to what actually sold and next to the two forecasts a buyer already has: same month last year, and the trailing three-month average. It is 15–42% closer than the trailing average and roughly on par with same month last year. The inventory-intelligence view uses the same estimate to ask whether stock on hand, plus what is on order, covers demand until the next delivery could arrive, checked against the held-out months.
{
"from": "monthly_demand",
"estimate": "units_sold",
"where": {
"sku": "SKU-2983",
"season": "autumn",
"last_year_band": "270-359"
},
"select": [
"estimate",
"why"
]
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in 2 live demos today, the 📋 ERP and 🛒 E-commerce demos. Each link opens the view that shows it, where you can inspect the queries that produce the result.
Frequently asked
How does this compare to dedicated forecasting tools like Prophet or ARIMA?
Dedicated tools optimize for forecast accuracy on a specific time-series shape. Aito's prediction is more general — it works across SKUs, customers, segments, and projects in a single query. The e-commerce demo measures its own forecast: on next month's sales range, held-out accuracy ties a naive last-month rule. A simple baseline like that is the bar to check against before claiming an edge.
What if our demand is project-driven (lumpy, irregular)?
Add the project pipeline to the where clause and the estimate conditions on it, so the forecast reflects the projects in flight, not just the historical baseline. For very lumpy demand (one-off engineering builds) there are few comparable months to estimate from, and the why shows how few — the system honestly says it has little to go on, which is the right behavior.
How quickly do new SKUs reach useful forecast accuracy?
A few months of stable demand on the new SKU is usually enough to move its estimate away from the category's, and the $why shows when it has. For SKUs with similar attributes to existing SKUs, even the first observation can carry useful signal through similarity (_relate). Cold-start on completely novel SKUs follows the same path as any prediction with no history — the system says it doesn't know yet.
Does this support multi-tenant demand forecasting (per-customer SaaS)?
Yes. Add customer_id to the where clause; the conditional probability is computed only over that tenant's rows. Same engine, different forecast per tenant, no per-tenant model. The accounting demo runs 255 simulated customer companies on one shared Aito instance using this exact pattern.
