Forecasting demand instead of chasing it

Context

The warehouse is full, yet the item your customer needs is out of stock. Your buyer has to decide whether to bring an order forward, wait or accept the risk of running out. The ERP records what has happened; deciding what comes next still depends on someone who knows the products, customers and suppliers.

Historical data in a spreadsheet and a buyer's experience both have value. To find out whether a different forecast would help, we need to measure the errors in your current method and understand their consequences. Without that comparison, a convincing chart tells you very little.

This is a representative scenario for manufacturing and distribution. The comparison describes work we propose and would need to test in practice. It does not report results from an actual client.

The challenge

1. You need the skills to judge the result. In the ISTAT report published on 15 December 2025, among surveyed businesses that had considered AI but had not adopted it, 58.6% cited insufficient expertise, 47.3% uncertainty over legal implications, 45.2% unavailable or poor-quality data, 43.2% concerns about privacy and data protection, and 43.0% high costs. These figures refer to that group, not to all Italian businesses.

2. Sales history does not tell you the whole story about demand. When an item was out of stock, recorded sales cannot show how much you might have sold. Changed product codes with no links between them, unrecorded promotions and inconsistent handling of returns add further gaps. We need to understand what each record represents before using it. Otherwise, the model may mistake a recording problem for a shift in demand.

3. A working forecast can still go unused. The pilot produces plausible figures, but the buyer carries on placing orders as before. If checking the forecast means an extra step, with no clear purpose in the decision, there is little reason to rely on it day to day. We need to define the ERP integration at the outset.

4. The costs continue after launch. Running forecasts, checking data, investigating errors and updating the model all take resources. You need an estimate that includes this work, states the assumptions and makes clear who is responsible.

The numbers to watch

We agree what to measure before choosing a model. Those measures should help you decide whether to continue, change course or stop.

• How far off is your current method when tested against your historical data? We measure both the size of the error and any tendency to overestimate or underestimate demand.
• How many stockouts have you had in the last twelve months, and on which items? We separate lost sales you can substantiate from those we can only estimate.
• How much capital is tied up in excess stock? Which items have not moved for more than six months, and which have a reason to remain available?
• How many hours each month go into preparing and checking the reports used for decisions?
• How many recommendations do you accept or change, why, and with what observable outcomes?
• What does a year of running the system cost, including infrastructure, support and staff time?
• How many months might it take to recover the investment, based on estimated additional margin and ongoing costs?

A lower average error can conceal worse forecasts for the items that matter. We also examine individual product families. Cash released from stock and additional margin are distinct benefits; treating them as interchangeable would distort the calculation.

Our approach

1. Build a comparison you can check. We test the current method and the model on the same items over the same period. Each test uses only information that would have been available when the forecast was made. Knowing the outcome in advance would invalidate the comparison. If earlier forecasts or buyers' adjustments are missing, we state what we can reconstruct and what we cannot. If the model fails to reduce error against the agreed criteria, we stop before integrating it into daily operations.

2. Keep the scope manageable. A product family, a warehouse or a production line gives us room to examine discrepancies and investigate their causes. We choose an area that matters to everyday work, where the data can be checked and someone owns the decision. A result in that setting does not establish that the method will work across your entire catalogue.

3. Put the forecast into the proposed replenishment order. We check how to incorporate it into your ERP and what changes that requires. Forecast demand informs the recommendation alongside stock on hand, outstanding orders, supplier lead times and purchasing constraints. A sales forecast alone cannot tell you how much to order. The buyer keeps the final say and can change the recommendation, recording the reason.

4. Measure for eight weeks before considering wider use. Each week, we compare forecasts, decisions and the outcomes available so far. We record adjustments to understand what the model is missing: a promotion, a lost customer or a delayed delivery. If the period does not capture seasonal effects or supplier lead times, the findings remain provisional. Finishing a pilot does not automatically justify extending it.

What changes

You can review recommendations before placing orders, with a record of the reasoning and past errors.

Which items risk running out in the next four weeks, taking expected deliveries into account? Where does stock exceed estimated demand? Which product families are becoming harder to forecast? Did an adjustment help, or did it widen the gap?

We make this information available where you make the decision, including gaps in the data and the assumptions used. The forecast remains fallible. Knowing where it is unreliable helps you decide which recommendations need closer scrutiny and when to use your judgement.

What people fear, and what we tell them

"We'll run a pilot and it'll sit there, like the last one." That can happen. Before starting, we agree who will use the forecast, which decision it will inform and how we will judge it. The model makes mistakes and may perform worse than your current method. If, after eight weeks, there is insufficient evidence that it helps, we will not recommend extending it. Stopping avoids further costs; it does not turn the money already spent into a return.

"Our data isn't good enough." That may be true. We examine a sample of your historical data to establish whether inconsistencies can be corrected and missing records recovered. Cleaning the data takes time and costs money; both need estimating before you commit to the pilot. If the history cannot support a fair comparison, we say so. Putting a number against demand does not make it reliable.

"And what does it cost to keep it running?" We prepare an annual estimate covering processing, checks, support and maintenance. We set out the volumes and activities it depends on, and what could change it. We agree who steps in when data stops arriving or errors increase: your team, with documentation and support, or ours under a defined agreement. We check during handover whether your team can run it independently.

"Where is the data processed?" The models run on AWS Bedrock with European Union inference profiles; data is processed in the European Union. That processing also takes place outside your own systems. We define which data to send, what it will be used for, and how access and retention will be managed. Processing in Europe does not settle those questions on its own.

How we approach it today

We start with a specific decision: what are you ordering today, and what information are you using? In the scoping workshop, we examine the available history, your current method and the errors that affect daily work. We then establish whether a useful comparison is possible, which data is missing and which costs need estimating.

The underlying problem may turn out to be supplier lead times or stock records. If so, that is where we propose starting. A forecast earns its place when it helps you decide and the benefit justifies the cost of maintaining it.

• AI integration in the systems you already use
• Odoo and integrated ERP
• The AIRA method

Let's talk: 30 minutes, with no obligation, to understand the decision you want to improve and whether it is worth examining the data.