AISTORS ServicesForecasting and prediction

Service 04

Forecasting that beats what you already do.

Only where the history is long enough to test against.

For planning, inventory and revenue teams who forecast in a spreadsheet today and cannot say how wrong it is. We measure your current method first, hold back a period the model never sees, and report against that. If we cannot beat what you already do, we tell you and you keep the analysis.

Book a 30-minute call

Two colleagues at a two-monitor desk in a bright daylit office, one screen showing a history line continuing into a shaded band of projected values, the other a dense table of weekly figures by product line. — Before we model anything
Your current forecast is measured first, on periods nobody hand-picked. Whatever we build afterwards is reported against that number rather than against an industry average.

Who this is for

If the left column is not you, say so on the call and we will tell you what would help instead.

This is for you if

You already forecast somehow. In a spreadsheet, in the planning system or by judgement. A current method is what gives us something honest to beat.
You have two or three years of history. Enough to hold back a test period and measure properly rather than simply fit the past and call it accuracy.
The forecast feeds a real decision. A purchase order, a staffing rota, a reorder point, a price change. A forecast nobody acts on is a report.
You know the cost of being wrong. Stockouts, write-offs, expedited freight, idle staff. That figure is what the work is worth and what we size against.
Somebody owns the number. A planner or analyst who will use it, argue with it, and tell us plainly when it is wrong.

This is not for you yet if

You have under a year of history. Then this is a data and instrumentation job first. We will scope that instead and say so rather than model thin air.
The market just changed fundamentally. A relaunch, an acquisition or a pricing overhaul makes past demand a poor guide, and we will say so before taking the work.
The series is genuinely close to random. Some are. We would rather establish that cheaply in a backtest than sell you a model that dresses up noise.
No decision will change because of it. Then the honest recommendation is a better report, not a forecasting engine.
You want one number with no range. Forecasts are distributions. A provider handing you a single figure with no confidence interval is hiding the uncertainty, not removing it.

What we fix, and how

Four things go wrong with forecasting projects. Three of them are measurement failures rather than modelling failures.

PROBLEM 01

You cannot say how wrong your current forecast is

What we do. We measure your existing method first, on held-back periods, and that error becomes the number to beat. Every model is then reported against it rather than against an industry benchmark that does not describe your business.

PROBLEM 02

The model fitted the past and missed the future

What we do. We hold back a test period the model is never shown, and score only on that. A backtest that includes the period being predicted is the most common way a forecasting project flatters itself.

PROBLEM 03

The forecast is accurate and nobody uses it

What we do. We build to the decision rather than to a dashboard. If the output is a purchase quantity it arrives as a purchase quantity, in the system that raises the order, with its confidence range attached.

PROBLEM 04

It worked for a quarter and then drifted

What we do. Demand regimes change. Drift detection against the recorded baseline, a retraining schedule and a monthly review are part of the engagement rather than a phase two nobody buys.

What you get

Nine deliverables, each scoped only where the history supports it.

What we build

Demand and sales forecasting. At the level the decision is actually made, by item, location and period, rather than at whatever level the data happened to arrive in.
Inventory and replenishment. Reorder points and safety stock derived from the forecast distribution rather than from a flat rule somebody set years ago.
Pricing support. Elasticity where the data genuinely supports it, and a clear statement where it does not, because most pricing data is too thin for the claim.
Churn and customer risk. Scored with the contributing reason attached, so somebody can act on it rather than admire the score.
Fraud and anomaly detection. Tuned to your tolerance for false positives, which is a business decision and is agreed with you rather than assumed.
Predictive maintenance. Where sensor or service history exists at sufficient density to distinguish a failure pattern from ordinary variation.
Route and capacity planning. Against real constraints, real availability and real travel time, not an idealised network.
Computer vision for inspection. Where the defect can be photographed consistently enough to be labelled, and where a person reviews the borderline cases.
A backtest report you keep. Method, held-back periods, error against your current approach, and an explicit statement of where the model is weakest.

What this is not

Not a forecast without a baseline. We will not ship a model we cannot compare against what you do today, because there would be no way to tell whether it helped.
Not a single number. Every forecast is delivered with a range and the assumptions behind it, including the ones you may disagree with.
Not a platform of ours. Built in your tenancy, on your accounts, in code you keep. Nothing of ours sits in the middle.
Not recommended where history is thin. We will tell you and scope the data and instrumentation work instead, which is the cheaper honest answer.
Not set and forget. Accuracy decays as conditions change. The engagement names who watches it, against what threshold, and how often.

How it runs

The first two phases can end the project, and sometimes should.

Baseline the method you use today

We reconstruct your current forecast on past periods and measure its error. Without this number there is nothing to prove afterwards, and it is the single most common thing missing from a failed forecasting project.

3 to 5 days · No production change

History and data assessment

How far back the data goes, how clean it is, what changed in it, and which structural breaks make earlier periods unusable. The output names what is usable rather than summarising it.

Findings named, not summarised

Backtest on held-back periods

Candidate methods are scored on periods the model never saw, reported against your baseline error, with confidence intervals shown. A no-go with reasoning attached is a legitimate result here.

You keep the backtest report either way

Build into the decision, with the range attached

The output is written into the system where the decision is made, in the unit the decision uses, with its confidence range and the assumptions visible to the person acting on it.

Fixed scope against the plan

Monitor for drift, retrain on a schedule

Accuracy is tracked against the baseline, thresholds are agreed in writing, and retraining is scheduled rather than triggered by somebody noticing that the numbers look wrong.

Monthly review · Quarterly retrain

Platform native

Forecasting models are small. They run natively on whichever platform you already use.

Azure

Azure Machine Learning for training and registry, Databricks or Fabric where the data already sits there, Data Factory for scheduling, Managed Endpoints for scoring.

AWS

SageMaker for training, registry and scheduled retraining, Step Functions for orchestration, Athena or Redshift for the feature history, Lambda for scoring.

Google Cloud

Vertex AI training and model registry, BigQuery ML where the history is already in BigQuery, Cloud Composer for scheduling, Cloud Run for scoring.

DigitalOcean

Managed Postgres for the feature store, App Platform or DOKS for scheduled training and scoring. Ordinary infrastructure is sufficient for most forecasting workloads.

Forecasting rarely needs a GPU or an external model API, which makes it one of the cheapest categories on this site to run and one of the easiest to keep entirely inside your own estate.

Questions we are actually asked

How accurate will it be?

Unknown until we have seen your history, and any figure quoted before that is marketing. What we commit to is a measured error against your current method, on periods the model was never shown.

We only have eighteen months of history. Is that enough?

Sometimes. For a weekly series with strong seasonality it is marginal, because you get barely one full cycle to learn from and another to test against. We run the backtest and show you the confidence intervals rather than decide on your behalf.

What if your forecast is worse than our spreadsheet?

Then we say so, and you keep the backtest report and the baseline method. That is a legitimate outcome of the assessment and it is far cheaper to establish now than after a build.

Do you need our pricing and margin data?

For pricing work yes, and it stays inside your environment throughout. For demand forecasting on its own, usually not, and we would rather not hold it if it is not needed.

Can this run without our data leaving our estate?

Yes, and more easily than most AI work. Forecasting models are small and run comfortably inside your own tenancy on ordinary infrastructure.

Who owns the model afterwards?

You do. Code, features, backtests and the retraining schedule are yours, documented as delivery proceeds rather than written up at the end.

Next step

Bring three years of history and one decision.

Thirty minutes, no obligation. Tell us one decision you make on a forecast today and how you currently produce it. We will tell you whether the history supports a model, whether the decision is worth improving, and what your current error probably is.

Starts with: The AI Readiness and Baseline Diagnostic, extended to reconstruct and score your current forecasting method.
Investment: Scoped on the introductory call, and credited in full against the build that follows.
If the answer is no: You keep the backtest report, the baseline method and the reasoning. No further commitment.

Book a 30-minute call

Or write to [email protected].

Related work

Service 03

Data and retrieval for AI

Forecasting needs history that can be reached and trusted. This is the work that makes that true when it is not.

Service 09

Managed AI and cloud operations

Accuracy decays. This is the layer that watches for drift and retrains on a schedule rather than on a complaint.

Service 02

Document and process automation

Where the forecast should trigger an action rather than a report, this is how the action gets taken.