Predictive analytics: what your company can anticipate, and with what data

Predictive analytics is one of the few things in the data world that can be explained in a single sentence and still gets bought badly: using your company's history to estimate what will happen and to decide before it does. How many units you'll sell in October, which customers are about to leave, which machine will stop next week. There's no magic; there's tidy data, a statistical model and — the part almost nobody budgets for — a process that knows what to do with the prediction once it arrives.

That's what this guide is about. What predictive analytics really is and how it differs from the dashboard you already have, what data you need before anyone mentions models, which three cases hold 80 % of the value in mid-sized companies, how to tell whether a model is useful or merely pretty, how long it takes, and when the honest answer is "not yet".

What is predictive analytics, and how is it different from BI?

A dashboard answers what happened. Predictive analytics answers what is going to happen and, when it's built properly, what to do about it. The difference is one of intent, not technology: both drink from the same tables.

The most useful way to order it is by levels:

• Descriptive. Quarterly sales, monthly stockouts, customer cancellations. That's what business intelligence delivers, and it's the floor everything else stands on.
• Diagnostic. Why sales dropped: product mix, channel, region. Still looking backwards, but with causes attached.
• Predictive. Given this history and these variables, next month's demand will be around X, with this margin of error.
• Prescriptive. Given that forecast and your constraints — capacity, warehousing cost, supplier lead times — this is the quantity you should order.

Almost every company that asks us for predictive analytics is at the first level and believes it's at the second. That's not a problem; it's information. If the history isn't consolidated, the model has nothing to learn from, and whatever you save by skipping that step you pay back with interest during the "the numbers don't add up" phase.

One more nuance that saves a lot of grief: predictive analytics does not foresee ruptures. It learns from past patterns, so it works while the future reasonably resembles the past. A regulatory change, a new competitor or a supply crisis will break the model — and that isn't a flaw, it's its nature. Which is why models are monitored and retrained, not installed and forgotten.

A predictive model doesn't tell you the future. It tells you what is most likely given what has already happened to you, and with how much uncertainty. Anyone selling you certainty isn't selling statistics.

What data do you actually need?

This is where the project is decided, long before anyone picks an algorithm. The minimum checklist we apply before accepting a case:

• Enough history. As a practical rule: two or three complete cycles of the phenomenon. For demand with annual seasonality, two or three years. For churn in a monthly subscription, 18-24 months. With six months of data and strong seasonality, the model learns noise.
• The right granularity. If you want to forecast by SKU and warehouse, you need history by SKU and warehouse, not the company's monthly total. Drilling down afterwards is impossible; aggregating is always possible.
• A clearly defined target variable. What exactly is a "churned customer"? Ninety days without ordering? A formal cancellation? Two definitions give you two different models, and this discussion belongs to the business, not to the technical team.
• The events that explain the jumps. Promotions, price changes, stockouts, campaigns, public holidays. Without them, the model reads a one-off offer as a pattern and repeats the mistake the following year.
• Temporal traceability. Knowing when each data point became known. This is the most expensive and most silent error: training with information that didn't yet exist at the moment of the real prediction. The model looks excellent in testing and collapses in production.
• An identifier that survives joins. If the same customer shows up three times under three codes, the churn you measure is fiction. This is plain data governance, and it's usually half the actual work.

None of this requires a data lake or a new platform. It requires that someone can say where every figure comes from and that the source doesn't change every quarter. The underlying conclusion is the usual one: data before AI.

Which predictive analytics cases work in mid-sized companies?

Three families account for most of the value actually captured. Not because they're the most sophisticated, but because the data exists and the linked decision is clear.

| Case | What it predicts | What it needs | Decision it triggers | |---|---|---|---| | Demand forecasting | Units per SKU and period | 2-3 years of sales, calendar, promotions, prices | Purchasing, production, stock levels | | Customer churn risk | Probability of leaving within N days | Order or usage history, incidents, contacts | Prioritised commercial action | | Predictive maintenance | Failure probability or intervention window | Breakdown history, running hours, sensor signals if available | Work order before the stoppage | | Cash flow forecasting | Expected receipts and payments | Invoicing, actual payment behaviour per customer | Financing needs, calendar | | Opportunity scoring | Probability of closing | CRM with won/lost history | Where the sales team puts its focus |

A couple of clarifications on the first three, which are the ones most often requested.

Demand forecasting. The classic mistake is to evaluate the model against history and celebrate. What matters is comparing it with what you were already doing: the sales rep's forecast, the average of the last three months, the same month last year. If the model doesn't beat that baseline, it adds nothing, however well the chart fits.

Customer churn. Predicting cancellations is the easy part; the hard part is getting the list to someone with the time and the argument to act. A weekly list of twenty at-risk accounts, with the main driver and the assigned rep, is worth more than a model 5 % more accurate that nobody looks at. The value here lies in the integration with the tools the team already works in.

Predictive maintenance. It's the case with the best return and the worst starting data. Many companies record breakdowns on paper, in an email, or in the workshop manager's head. If that's your starting point, the first project isn't a model: it's recording interventions properly for a few months. Less impressive in a meeting, and the thing that makes everything else possible.

How do you know whether a predictive model is any good?

By an uncomfortable rule: a model is judged against the decision, not against the statistical metric. A 92 % hit rate means nothing if you don't know what you were doing before or what each type of error costs.

Four things to demand from any provider, internal or external:

• An explicit baseline. What accuracy the current method achieved over the same period. Without that number, any result sounds good.
• Temporal validation. Train with data up to a cut-off date and evaluate on the following months, simulating what was known at each point. Evaluating with mixed periods inflates the results.
• Asymmetric cost of error. In stock, running short and overstocking don't cost the same. In maintenance, a false alarm costs an inspection; a missed failure costs a stopped line. The model should optimise real cost, not average error.
• An explanation of why. Which variables drive each prediction. Not for theoretical transparency: because it's what makes the purchasing manager or the sales rep trust it and act.

And one metric that always gets forgotten: how many predictions ended in an action. If the model is right and nobody does anything differently, the return is zero. It's the same root cause behind why AI pilots fail: the problem is almost never the algorithm, it's the process meant to consume it.

How long does it take, and what route should you follow?

A first predictive analytics case, in a mid-sized company with reasonably tidy data, fits in a quarter. This is the sequence we use:

| Weeks | What happens | Output | |---|---|---| | 1-2 | Define the decision to improve, the metric and the current baseline | One-page case, with an owner | | 3-5 | Extract and consolidate the history; audit gaps and quality | Reproducible, documented dataset | | 6-8 | First model and temporal validation against the baseline | Does it beat it or not? Answered with a number | | 9-11 | Push the prediction into the tool where the decision is made | List or field inside the ERP/CRM | | 12-13 | Measure real usage and actions taken | Decision: scale, adjust or stop |

Two budgeting notes. First: between 50 % and 70 % of the effort goes into weeks 3 to 5, not into the model. If a proposal allocates two days to the data and three weeks to the algorithm, it's badly framed. Second: budget for maintenance. A model in production needs drift monitoring and periodic retraining; without that, it degrades quietly and within a year it's making worse decisions than the moving average it replaced.

When is predictive analytics NOT worth it?

Saying no in time is part of the job. Clear signs that you should wait:

• There's no concrete decision behind it. "We want to predict things" isn't a case. If nobody will change their behaviour based on the output, don't do it.
• The history doesn't cover one full cycle. With no observed seasonality, there's nothing to learn.
• The rules of the game have just changed. New product line, new market, new pricing model: the past no longer represents the future.
• Volume doesn't justify the effort. If you decide five times a year and one person can reason each decision through, a model is a luxury. You automate where there's repetition.
• Nobody will maintain the data. If the breakdown log or the CRM is only half filled in, the model will inherit those gaps.

In several of these cases the right next step isn't predictive at all — it's tidying up the descriptive layer, or automating the process that generates the data. Less brilliant in a meeting, far more profitable over twelve months.

Frequently asked questions

How much historical data do I need to start?

It depends on the cycle of the phenomenon, not on an absolute number of rows. As a practical reference: two or three complete cycles. With annual seasonality that means two or three years; in processes with a weekly cycle, six well-recorded months can be enough.

Do I need to hire a data scientist in-house?

Not for a first case. It makes more sense to validate with external support whether the case delivers value, and to leave the process documented. Hiring in-house is justified once you have three or four models in production and maintenance becomes continuous work.

Is predictive analytics the same as artificial intelligence?

Predictive analytics is a branch of AI — the oldest and the most checkable: structured history goes in, a number with its margin of error comes out. It's often confused with generative AI, which produces text and solves very different problems.

How do I stop the model from degrading over time?

By monitoring two things: whether the input data is drifting away from the training data, and whether the real error grows month on month. With those two indicators on a panel and a scheduled retraining, degradation is caught before it affects decisions.

If you're torn between demand forecasting, churn or maintenance — or you suspect the real problem is that your history isn't in shape — that's exactly what the audit resolves: looking at real data and processes to come out with one prioritised case, a measurable baseline and the discarded options in writing. If you'd rather test the idea in half an hour of conversation first, let's talk.