Case study · Illustrative example

Catching a demand forecast that had quietly stopped working

Illustrative example. This shows how an engagement of this kind typically runs. It is not a report of a specific client's project, and the figures are typical outcomes, not measured client results. Your numbers depend on your data; the readiness assessment tells you what to expect.

The typical situation

A sample-volume forecast, built by a former vendor, set staffing and reagent orders for every centre. It ran every night. Nobody had checked it since it went live, and centres had started ignoring it.

This is common: the model still produces numbers, so nobody notices when the numbers stop being right.

What the data looked like

The model's code and its nightly outputs, three years of actual sample volumes by centre and test, and the staffing and reagent order records.

What we built

  • An audit comparing two years of forecasts with what actually happened, centre by centre.
  • Monitoring that tracks forecast error every week and alerts when a centre drifts past an agreed limit.
  • A retrained model that accounts for the new centres and test types added since the original build.
  • A runbook and a monthly review, so the lab's own team can see the model's health without calling anyone.
Your systemsClean data layerModel or rulesAlerts and reports

Typical outcome

MeasureBeforeAfterPeriod
Average weekly forecast errorabout 25%under 10%typical outcome
Time to notice a drifting centrenever noticedwithin a weektypical outcome

What usually trips these projects up

The audit usually finds the problem started with one change in the business, such as a new centre or a price change, months before anyone noticed. Monitoring needs to watch for those changes, not only for the error.

Have a similar problem?

Tell us what is going wrong and what data you keep. The first conversation is free and usually ends with a straight answer about whether this is worth doing.

Start the readiness checkTalk to us