A forecast is only worth building if it changes a decision. We start from the decision, measure whether a model beats what you already do, and tell you honestly when it does not.
The question we ask first
Predictive analytics services use historical operational data to forecast demand, churn, failure or fraud, with a stated confidence interval. Value comes from the decision the forecast changes, so models ship with monitoring for drift and a retraining schedule.
All four are avoidable, and all four are decided before any training starts.
A churn score gets built and there is no retention offer, no owner and no process that changes when it goes red. The model is accurate and irrelevant. Naming the decision and the person who makes it is the first question we ask, and it disqualifies plenty of projects.
An impressive accuracy figure means nothing without a baseline. Your experienced planner has been forecasting this for a decade and is frequently harder to beat than a spreadsheet average. If the model does not clear that bar, it does not deploy.
Six months on, a product mix changed and accuracy fell. Nothing errored, no alert fired, and the forecasts kept arriving looking exactly as authoritative as before. Drift monitoring on inputs and outputs is not an enhancement, it is what makes the model safe to leave running.
Somebody exported history by hand for the pilot and cannot reproduce it. The model works and cannot be retrained or run on fresh data. A repeatable pipeline with documented lineage comes before modelling, and it is usually where an integration is genuinely needed.
Move the horizon and watch the uncertainty band widen. Any vendor showing you a single clean line twelve months out is hiding this, and the hidden part is exactly what a planner needs in order to decide how much buffer to hold.
How far ahead you are asking the model to predict.
Interval at this horizon
±11%
around the central forecast
Near-term forecasts are tight enough to plan against directly. This is where most of the operational value sits.
Illustrative model: uncertainty grows roughly with the square root of the horizon, which is the typical shape for a well-behaved series. Your actual intervals come from measurement against a holdout period, not from this curve.
Test this on your historyTraining the model is a small part of it, and it is not the part that decides whether it is still working next year.
We measure how well your current method performs on the same holdout period the model will be tested against. That might be a spreadsheet, a seasonal average, or a planner's judgement, and the last of those is frequently the hardest to beat.
This makes the success criterion a number rather than an impression, and it means we can tell you early when a model is not going to earn its place. That conversation is uncomfortable and it is considerably cheaper than the alternative.
Input drift catches the world changing before accuracy visibly falls. Output drift catches the model behaving differently. Both alert a named owner, with thresholds agreed during the build rather than guessed at afterwards.
Which features drove this prediction, in language the person acting on it can read. A forecast nobody can interrogate is a forecast nobody trusts, and untrusted forecasts get overridden.
Every trained model versioned against its training data and code, so you can answer which version produced a given prediction months later. The same audit expectation as any other governed AI system.
A documented, scheduled procedure rather than a call to us. Where the schedule needs infrastructure, our cloud team provisions it as code.
Five steps, following the same delivery shape as the rest of the AI and automation practice.
Which decision does this forecast change, who makes it, and what would they do differently. If the honest answer is that nothing changes, the project is a reporting exercise and should be scoped as one. This question ends more predictive projects than any data problem does.
Measure the current method on the same holdout period the model will face. Spreadsheet, seasonal average, or the planner who has done this for a decade. Setting this number publicly at the start prevents the later argument about whether the model actually helped.
Usually the longest phase and always the least anticipated. A repeatable extract with documented lineage, not a one-off export. Where the source system makes this hard, integration work becomes the real first project.
Evaluated on time the model never saw, compared against the baseline, with the uncertainty interval measured rather than assumed. If it does not beat the baseline, we report that instead of tuning until the numbers look better on data it has already seen.
Model registry, drift monitoring, accuracy tracked against the baseline over time, and a retraining procedure documented for your team. Then 100% of the code, models and IP is assigned to you on final approval.
These get lumped together as machine learning and need genuinely different data, validation and monitoring. Select the shape of your question.
Time series work. You need enough history for the seasons to repeat, which usually means two to three years, and you need to know about the events that distorted it: a stockout, a factory shutdown, a one-off contract. Feeding those in unlabelled teaches the model that a bad month is normal.
The interval matters as much as the number here, because it is what tells a planner how much buffer to hold.
Needs
Two to three years of history, with events labelled
Hard part
Beating a well-tuned seasonal baseline
Six stages. Select one to see what it does and what breaks when it is skipped, which in our experience is usually stages five and six.
The exact dataset a model was trained on, snapshotted and addressable. Not a query that would return something different if you ran it again today.
Skipped means
You cannot reproduce a model, cannot investigate a bad prediction, and cannot tell whether a retrained version is better or just different.
None of these produce an error. That is what makes them dangerous and why monitoring watches quality rather than exceptions.
Four cases with a clear decision attached and a measurable baseline. Profiles are anonymised.
A freight operator forecasting consignment volume per lane a fortnight out, so vehicle and driver capacity is committed against a range rather than last month's figure. The decision is concrete, the baseline was a planner, and the interval is what made it usable.
Logistics engagementsFlagging unusual patterns for a review team with fixed capacity, which made the alert budget the design constraint rather than raw detection rate. Tuned to the number of cases a team can genuinely investigate in a day, and monitored for alert fatigue.
Banking and insuranceForecasting component requirements against a production plan, with known shutdowns and one-off contracts labelled so the model does not learn from distorted periods. Feeds directly into the purchase requisition process rather than into a report.
Manufacturing engagementsScoring accounts on renewal risk, paired with a defined intervention and a holdout group receiving nothing, so the effect can actually be measured. Without the holdout, nobody can tell whether the model or the offer produced the result.
Consulting providersLanguage models have absorbed the general meaning of AI, which leads teams to reach for one when a smaller, cheaper, more explainable model is the correct answer.
| Criterion | Classical model | Large language model |
|---|---|---|
| Best input | Structured rows and numbers | Unstructured text and documents |
| Predicting a quantity | Purpose-built for it | Unreliable and expensive |
| Explaining a prediction | Feature attribution, routinely | A plausible narrative, not a cause |
| Running cost at volume | Negligible once trained | Per token, every prediction |
| Confidence intervals | Standard practice | Not meaningfully available |
| Use it when | The question is how much, how many, how likely | The question is about language or documents |
Plenty of systems need both: a language model to extract structured fields from a document, then a classical model to predict from them. That pairing is common in our work, and the two halves sit under generative AI development and this page respectively.
Neighbouring parts of the AI and automation practice, in the order they usually appear.
Getting history out reliably, which is usually the real first project on this page.
Where a prediction has to change a process rather than appear on a dashboard.
Turning paperwork into the structured rows a predictive model can actually learn from.
The most common home for a churn or propensity score, and the process that acts on it.
Assessing whether your data can support a model before anyone commits to building one.
Where a model affects decisions about individuals and the risk classification changes.
Training infrastructure and scheduled retraining are provisioned by our cloud architecture team, and data platform decisions sit with IT consulting and advisory. To start, tell us the decision you want to improve or read the help centre.
The ten that come up in almost every first conversation.
What someone decides every week, how they decide it now, and how well that works. That is enough for us to say whether a model would beat it. We reply in under 3 minutes.
