AI Demand Forecasting and Production Planning

The problem: production planning in spreadsheets

In most plants the plan is made in a spreadsheet. The planner takes the average of recent weeks, or sales from the same period last year, adds manual corrections — “May is always busier”, “this customer will order later” — and that becomes the shifts, the material orders and the machine schedule. It works as long as demand behaves like last year.

The weak spot: a plan like that doesn't tell you how wrong it might be. Each week is a single number with no margin. When demand drifts away from the average, the plant finds out on the floor — overtime and extra labor when people are missing, or paid hours with nothing to do when there are too many. Both mistakes cost money; the cost is just spread across budgets, so nobody sees it in one table.

A “same as last period” plan vs. a demand forecast

Illustration — sample data, not a test result.

The approach: demand and sales forecasting on your own data

Sales forecasting tells you how much you'll sell. Demand forecasting tells you how much customers will want to buy — even when the product runs out or an order slips to next month. Production planning needs the second one: sales capped by missing stock understate the next plans, and the error repeats itself.

One lesson from our tests: what the company already knows about the future matters most. The order book — what customers have already ordered for the coming weeks — says more about upcoming demand than sales history alone. That's why process optimization starts with a better forecast, not a new system. A forecast with an uncertainty range feeds the decisions the plant makes every week anyway — from shift staffing to material and energy needs.

Data never leaves the company

Plant data

sales and orders (ERP)
order book
energy meters
sensors and equipment

Server on site

forecast with an uncertainty range
anomaly detection

Decisions

shift staffing
material requirements
energy and peak demand
alerts for maintenance

the planner approves

Plant data, the forecast and the decisions — one loop inside the company network. The planner has the last word.

Production scheduling, MRP and inventory forecasting

A forecast isn't the goal in itself. It feeds production scheduling — how much to run on which line, and when — and material requirements planning (MRP) and inventory forecasting: how much raw material and how many components to order so nothing runs out and no cash sits frozen in the warehouse.

To be clear: we don't replace your APS or MRP system. We provide a better input for it — a forecast with an uncertainty range — and your system and your planner still build the schedule.

What it changes in numbers — results of our tests

Before we suggest anything to a plant, we check it on data. Below are the results of our tests on real public data. Each time we compare the forecast with how planning is done today — on a period held out until the very end, which the models had never seen.

Agent schedule (NYC 311 call center, 51 weeks)

−20%

Excess schedule cost — lower is better.

Shift staffing (7 warehouses)

−29%

Excess schedule cost — lower is better.

Fault detection (12 buildings)

6× more

Faults detected at about 1 false alarm per month — higher is better.

Energy — battery (12 buildings)

+26–36%

Share of possible savings achieved (with weather forecast) — higher is better.

ailone tests on real public data, 2026 (including NYC 311 Call Center Inquiry, NYC Open Data). For a specific plant, we check the result in a pilot on its own data.

Call center staffing with Erlang C: New York City's 311 line

We tested this on public NYC 311 data — every call handled by an agent of New York City's 311 line from January 2022 to September 2026, counted hour by hour. 311 is the city's information and service-request line, not an emergency number (that's 911). That's 10,800 calls a day on average, with peaks of about 1,500 an hour. We tested on the last 51 weeks, from September 2025 to September 2026 — data newer than anything the models were trained on.

Every week we forecast two weeks ahead, hour by hour, and turned the forecast into the number of agents needed to answer 80% of calls within 20 seconds, using the industry-standard Erlang C formula. We compared that with how staffing is planned today: the average of the last four weeks for the same hour of the week, with holidays planned like Sundays. A scheduled hour is always paid; a missing hour has to be bought at twice the rate.

Result: the excess cost of the schedule fell from 12.3% to 9.9% of the cost of ideal staffing — 20% less. For a 40-agent center with about €1.8 million a year in labor costs, that's roughly €43,000 a year (€16,000–79,000, depending on how much a missing agent costs). In a smaller team, about 17 agents at peak, the gain was smaller: 14%. The more expensive a missing agent, the more the forecast pays off — with a threefold premium the savings grew to 24%.

To be fair: about 10% of excess cost remains even with the best forecast, because outages, weather and city events can't be predicted two weeks ahead — that's what same-day adjustments are for. The calculation also assumes staffing can change hour by hour; contracts and minimum shift lengths take away part of the gain. That's why we check every figure on the company's own data.

Workforce planning and shift staffing: 7 e-commerce warehouses

The most measurable effect of a forecast is the schedule. Plan too few people and the missing hours have to be bought — overtime, on-call duty, temp staff. Plan too many and you pay for idle hours. Workforce planning based on a forecast reduces both mistakes at once.

We checked the same mechanism in warehouse logistics: 7 e-commerce warehouses, almost a year of testing, with schedules set for the second week ahead. The excess cost of the schedule fell from 8.5% to 6.1% of scheduled labor cost — 29% less — in every one of the 7 warehouses, not just on average. For a warehouse with about €2 million a year in labor costs, that's in the tens of thousands of euros a year — an estimate that depends on what a missing worker costs and how flexible contracts are.

To be fair: a warehouse isn't a production floor, but the mechanism is the same — variable workload and schedules set in advance. On production data the result still has to be confirmed; that's what a pilot is for.

Cutting production costs: energy monitoring and peak demand

In a test on 12 buildings over a full year, a battery shaved peaks in power draw, steered by a consumption forecast. A simple rule without a forecast achieved 52% of the possible savings; control based on a consumption forecast that includes a weather forecast achieved 65–70%, or 26–36% more. Without a weather forecast the gain was negligible.

To be fair: in money it's small — on the order of €1,000 a year per building with about 500 kW of peak demand. Energy monitoring with forecasting is one building block of energy management, not a standalone product. Contracted capacity and its overruns are a separate matter — we didn't measure them separately, and whether a forecast helps avoid overruns we'll only know from your meter readings.

Anomaly detection — predictive maintenance

The same forecast can detect deviations: if consumption differs from what the model expected, something is running differently than usual. On the same 12 buildings we injected typical faults into the data — equipment running at night, weekday mode on weekends, a lasting jump in consumption.

At about one false alarm per month, forecast-based detection found 69% of the faults, versus 11% for the rule used today — 6 times more. It caught equipment running at night in about 9 out of 10 cases, and more than two thirds of the alarms were real faults — without setting manual thresholds for each site.

To be fair: we injected the faults ourselves; they don't come from a maintenance log. We haven't tested predicting machine failures from sensors (vibration, temperature) — that belongs in a pilot on plant data.

What time series foundation models are (e.g. TimesFM, Chronos)

For years, a forecast was built separately for each time series: choosing a method, tuning parameters, manual fixes. Time series foundation models work differently. They were trained on a huge number of series from many domains and forecast a new series without building a model from scratch. Examples are the TimesFM family (Google Research) and the Chronos forecasting models (Amazon). Many of them return not just one number but an uncertainty range.

Two things are worth knowing. First, they are not language models — they don't chat, they compute future values. Second, licenses differ, sometimes even between versions of the same family: some models may only be used non-commercially. That has to be checked before a model goes into a company.

AI in production — what we don't promise

AI in manufacturing has real limits. Better to know them before a pilot than after. Here's what our tests taught us:

What the company knows about the future matters most — the order book, the weather forecast. Holiday calendars and historical weather add almost nothing.
Smaller scale, smaller gain. Not every company will find it worthwhile — and it's better to learn that in a pilot than after deployment.
No method predicts unprecedented events. Neither a forecast nor a spreadsheet would have predicted the 2020 pandemic.
A forecast doesn't replace the planner. It provides numbers and an uncertainty range; a person decides. A language model can describe the result in words, but the numbers are computed by tested code.
Results on public data may be slightly optimistic. That's why we check every number on this page again — in a pilot on the company's own data.
We don't predict prices, the effects of your own pricing decisions, or sales of products that have no history yet.

Who it's for — when forecasting pays off

Repetitive planning

Every week you set shift schedules, order materials and plan lines — in food processing, packaging, parts, chemicals or warehouse logistics.

At least a year of history

Sales or orders from at least a year, ideally 1–2 years. Without history there's nothing to forecast from — and we won't pretend otherwise.

Scale where mistakes cost money

Dozens of people on shifts, large material purchases, big energy bills. To be fair: at a small scale the gain is small, and a pilot may show that deployment isn't worth it.

Security — the data stays on site

A server in your company

The model runs on a server in your network. Sales history, the order book and meter readings don't go to an outside cloud.

Light computation

Forecasting isn't a conversation with a large language model — the computation is light and fits on hardware in the plant.

Trade secrets

Volumes, customers and labor costs are data you don't show competitors. They stay where they were created.

How it starts — a remote pilot on your historical data

We don't sell demand forecasting software. Before you deploy anything, we calculate what a forecast would have given you in the past — in money. We check on your history how the forecast would have done and compare the result with your current planning method. Only then do you know whether deployment makes sense. We run this remotely.

What we need: sales or order history (ideally 1–2 years), the order book — what customers have already ordered for the coming weeks — and, for energy and anomaly detection, meter readings.

Your historical data — sales, orders, meters
We check on your history how a forecast would have done
The result in money — compared with your current method
Decision to deploy

A pilot in four steps: the decision is based on numbers from your own history.

Frequently asked questions

What's the difference between demand forecasting and sales forecasting?

Sales forecasting estimates how much you'll sell. Demand forecasting estimates how much customers will want to buy, even when the product runs out or an order slips. Production planning needs demand: sales capped by missing stock understate the next plans.

Is a spreadsheet enough for production planning?

For building the plan, often yes — many plants do it in a spreadsheet. The weak spot is the input number: the average of recent weeks or “same as last year” doesn't say how wrong the plan might be. A forecast with an uncertainty range improves exactly that number, and the planner's tool can stay the same.

What data do you need?

Sales or order history, ideally 1–2 years, and the order book — what customers have already ordered for the coming weeks. For energy and anomaly detection, meter readings. What the company already knows about the future helps most.

Will AI replace the production planner?

No. A forecast gives numbers and an uncertainty range; the planner decides — they know the customers, the machines and the constraints that aren't in the data. No method predicts unprecedented events.

How is Erlang C used for call center staffing?

Erlang C turns the expected number of calls and the average call length into the number of agents needed to reach a service level — in our NYC 311 test, 80% of calls answered within 20 seconds. A better hourly forecast means fewer idle and fewer missing agent-hours.

What is predictive maintenance?

Detecting signs that equipment is starting to behave differently than usual — before it fails or before costs grow. In our tests, detecting deviations from an energy-consumption forecast found 6 times more faults than the rule used today. We haven't tested predicting machine failures from vibration and temperature sensors; that belongs in a pilot.

Does production data have to go to the cloud?

No. The model runs on a server in your company, and forecasting needs little computing power. Sales history, the order book and meter readings stay in your network.

Sources

NYC Open Data, 311 Call Center Inquiry — calls handled by agents of New York City's 311 line (date, time, topic).
The Erlang C formula — overview on Wikipedia.
Examples of time series foundation models: TimesFM (Google Research; licenses of individual versions are described in the repository) and Chronos (Amazon).