Machine
Learning
Machine Learning
Models trained on your company's historical data that predict what is going to happen, and that work inside your operations, not in a report.
A machine learning model learns from what has already happened: sales by item and week, invoices that were paid late, sensor readings before a breakdown. It then returns a figure about what comes next. How many units will sell next week, how likely this customer is to stop paying, how many days that bearing has left.
What sets this kind of predictive analytics apart from a spreadsheet full of statistics is that the model finds patterns nobody programmed. The seasonality of each shop, the effect of a promotion on the product next to it, the combination of signals that comes before a missed payment. And what sets it apart from the AI you already use is that it is trained only on the data it needs to predict, with no noise around it.
Three questions from the first meeting, with short answers.
No. ChatGPT writes and summarises; this calculates how much, when and with what probability. The two complement each other, but they do not solve the same problem.
Yes, if you have two or three years of history in your ERP and a decision that is currently made by eye. How much to buy, who to give credit to, when to stop the machine.
The first model, evaluated on your data, takes 6 to 10 weeks. In production and writing to your systems, around three months. We start with the prediction that moves the most money.
Six pieces. The first two are the model and the data it learns from. The other four turn that model into a system the company uses every day.
Trained on your history, it returns a figure or a probability for each case: units to sell, risk of late payment, a customer about to leave, a machine about to fail. Its margin of error is measured against the method you use today, not estimated.
Every night the data from the ERP, the CRM or the sensors is collected, cleaned and joined up. It ends up in the table the model learns from. This is the piece that takes the most work, and the one that decides whether the model gets it right.
The prediction arrives where the decision is made: a column in the ERP, a proposed order, an alert to maintenance. Nobody has to open a notebook or export anything.
How often it is right, which items it gets wrong and how much it improves on the previous method, measured on the same data. In euros of overstock avoided, not in technical metrics.
When the business changes, the model ages. We measure drift every day, and retraining starts automatically once the agreed threshold is crossed.
Each figure comes with its reasons: which factors weighed in and by how much. Purchasing and finance can challenge the prediction instead of accepting it blindly or ignoring it.
Five steps, and the first one does not mention algorithms.
'We overbuy on a third of our items' works. 'We want to do machine learning' has no clear goal, and it will fail.
How many years of history there are, what is missing and what is dirty. Within two weeks we tell you whether there is a model or whether you need to start with the data. If the answer is 'not yet', we say so.
We train on the previous years and check how accurate it would have been in the last one. If it does not clearly beat the method you use today, it goes no further.
One warehouse, one product family, one customer portfolio. The prediction goes into the real system and the team uses it alongside their own judgement for a few weeks.
It is extended to the rest of the business, with automatic monitoring and retraining. The model, the code and the documentation are yours.
The generative AI you use is built on machine learning techniques, so under the bonnet they are related. In practice, though, they do quite different jobs. Machine learning predicts from numbers; generative AI reasons over language. A predictive model tells you how many units of each item will sell next week, and with what margin of error. An AI agent reads that figure, checks the stock and the supplier's lead time, and drafts the order.
They need each other. An agent without a predictive model decides on borrowed instinct; a model without an agent leaves the figure in a table, waiting for someone to look at it. The model supplies the reliable figure; the agent supplies the action.
In practice they are chained together. The late-payment model flags a customer as a likely delay; the agent prepares a note for the sales rep with the history and suggests adjusting the credit limit. A person decides in one click.
Data
A pattern
How many units of each item will sell next week or next month, by shop or warehouse. It is the basis for stock that is neither too much nor too little, and for purchasing that is no longer done by eye.
Which customers are most likely to pay late or stop buying, and which signal gives it away. Finance adjusts their credit, and sales picks up the phone before they are lost.
How long a machine has left before it fails, based on its sensors and its breakdown history. The part is replaced when it is due, not by the calendar or after the line has stopped.
Which price or promotion delivers the best margin on each product, not just the most sales. You stop promoting what was already selling, and stop cannibalising what actually made a profit.
Transactions, consumption or readings that fall outside what is expected, detected as they happen. Billing errors, leaks, orders that do not fit the customer's usual pattern.
The ones asked before anything is trained. If yours is missing, write to us.
Let's talk about your projectLess than people tend to think and, sometimes, more than there is. For demand forecasting, two or three years of sales by item and week are usually enough; for late payments, a few hundred real delays. What cannot be missing is consistency: if an item has changed code three times, that has to be fixed first. The initial assessment tells you within two weeks.
It depends on the problem and on how noisy your business is, and anyone who promises a percentage before seeing your data is misleading you. What we do guarantee is the comparison: we measure the model against the method you use today, on last year's data. If it does not clearly improve on it, it is not deployed. The exact figure comes from your history, not from a promise.
The model ages: new products, another channel, a price change, an unusual year. That is why we do not deliver a model but a system that is monitored. Every day we measure the gap between what was predicted and what happened, and once the agreed threshold is crossed it is retrained on the new data. A fundamental change, such as a new line of business, means adjusting the model, not starting a project from scratch.
The cost is driven by the state of the data, not by the complexity of the algorithm. Within that, it depends on how many sources and decisions the model covers. The price is set once the two-week assessment is done, and that assessment is useful even if you decide not to go further.
Not always. If the history sits in an accessible and reasonably clean ERP, the model can read from there. When several sources need joining up or volumes grow, we build the data platform as part of the project. That is what lets the model retrain itself, and lets an AI agent use its prediction later on.
An AI agent that handles purchasing needs to know how much will sell; one that handles collections needs to know who is going to pay late. That figure comes from the machine learning model. Agents act; models give them the number to decide on. That is why many agent projects start here.
It leads in none, and that says something about the product: it almost always arrives second, once there is clean data to learn from. It comes second in three industries. In travel and hospitality, with occupancy forecasting. In manufacturing and food, with maintenance scheduled by real risk. And in logistics and supply chain, with stock calculated on the lead time each supplier actually meets.
