Services
A forecast is a claim about the future, and claims decay. We backtest before you rely on one, watch it for drift once it is live, and hand it over documented well enough that your own team can retrain it without calling us.
Four failures that surface months after the project was signed off.
A model measured at launch is quietly a different model a year later, and usually nobody is watching the gap widen.
Reports built to a specification rather than to a decision end up answering questions that nobody was actually asking.
When the people who built it move on, nothing can be retrained, and the forecast slowly turns into fiction that still gets quoted.
A confident number computed from a broken pipeline is worse than no number, because a number gets believed.
Four commitments, mapped one-to-one onto the four failures above.
Accuracy measured against history you already hold, so the figure is earned rather than asserted in a slide.
Every dashboard starts from the decision it should change and the person who has to make it, not from the fields available.
Documented models, readable code, and your team trained to retrain them. We would rather not be a dependency.
We say plainly when the pipeline has to be fixed before any prediction built on top of it is worth computing.
Two representative slices of a typical build.
Per-site demand projected from your own sales history and seasonality, backtested against the last three years before anyone plans stock against it.
Accounts ranked by risk, each score paired with the factors driving it, so the retention team knows what to do rather than just who to worry about.
Per-site, per-product projections backtested on your history.
Risk scores that carry the reason behind them.
Anomalies surfaced early, with false positives budgeted for.
Failure windows forecast from sensor and service history.
Built around a decision, so they get opened twice.
The foundation the predictions have to stand on.
Drift caught while it is still small.
Lineage and ownership, so numbers stop being argued over.
A decision first, a backtest second, and a model your team can keep.
We find the decision a forecast should change and who makes it. If no decision changes, we say so instead of building a dashboard.
The model is scored against periods you already know the answer to, so accuracy is measured rather than promised.
Output lands where the decision is actually made — the CRM, the planning sheet, the ops screen — not in a portal nobody visits.
Live accuracy is tracked against the backtest, with a retraining runbook your team owns and can follow without us.
Directional outcomes from comparable builds — not contractual targets.
Accuracy with a date on it
A measured figure that gets re-measured, not a launch-day claim.
Dashboards with an audience
Built around a decision, so somebody opens them a second time.
Models your team owns
Documented and retrainable in-house when the data shifts.
Often not. A focused forecast can usually be built from the few tables that matter, and doing that first tells you whether the warehouse is worth funding. We will say when the foundation genuinely has to come first rather than selling you a platform by reflex.
We answer that with a backtest, not an estimate: the model is scored against periods where you already know what happened. That number is honest, specific to your data, and comes before you commit to a build.
You do. You get the model, readable code, the documentation, and a retraining runbook, plus training for whoever will run it. A model only its authors can maintain is a liability dressed up as an asset.
Usually because they were specified from the data available rather than from a decision someone has to make. We start at the decision and the person making it, which is why the second one tends to get opened.
Live accuracy is compared against the backtest, so drift shows up as a measured gap rather than as a slow loss of confidence. The runbook says when to retrain and who does it — a forecast nobody is watching is just an old opinion.
Whatever you already run, wherever that is credible — Power BI, Tableau, dbt, Databricks, or the warehouse your cloud already includes. We are not reselling licences, so the honest answer is often that your existing stack is enough.
It depends on how many decisions are in scope and the state of the underlying data. The backtest is deliberately small and comes first, so the business case rests on a measured accuracy figure rather than on optimism.
We will backtest one forecast against it and show you the accuracy before you commit to a build.