Services / Data / Forecasting & alerts

See it coming, early enough to do something about it

Demand, revenue and cash-flow forecasts tested against your own history and shown as an honest range, plus alerts that reach the person who can act, the moment a number leaves the territory you expect.

Start the conversation →See the technology

Why it matters

The cost is the wait

Most reporting tells you what happened. That is necessary, and it is also the past. The decisions that actually cost money (how much stock to buy, when to hire, whether next quarter's cash covers the VAT bill) are made about a future nobody has looked at properly, usually by taking last year and adding a bit.

The good news is that a lot of business behaviour is more predictable than it feels. Sales have a weekly rhythm and a seasonal one, holidays and promotions move demand in ways that repeat, and a churn risk usually shows up in behaviour weeks before the cancellation. None of that needs an exotic model. It needs your own history, an honest method, and someone willing to test the forecast against what actually happened rather than presenting a confident line on a chart.

Alerting is the same instinct pointed at the present. Rather than someone noticing on Thursday that Tuesday was strange, the system watches the numbers continuously, understands what normal looks like for a Tuesday in your business, and tells the one person who can act, with the relevant chart attached, in the tool they already have open.

What you actually get

Built to be trusted

Forecasts are easy to produce and easy to produce badly. What follows is what separates a number you can plan against from a decoration.

Ranges, not single numbers

Every forecast comes as a likely range with a stated confidence, because a single figure implies a precision that does not exist. "Between 180 and 240 units, most likely 205" leads to better buying decisions than a confident 205 that turns out to be wrong.

Tested against your own history first

Before you rely on it, the model is run against past periods where we already know the answer, and we tell you how far off it was. If it cannot beat a simple rule of thumb on your data, we say so rather than shipping it anyway.

Seasonality, holidays and promotions accounted for

Weekly and yearly patterns, bank holidays, school terms, your own sale periods and known one-offs are modelled explicitly, so last Black Friday does not distort next Tuesday's expectation.

Alerts that know what normal looks like

Thresholds tuned to each metric's own history and rhythm, so an ordinary Monday peak does not wake anyone. The aim is a small number of alerts that are all worth reading.

Routed to whoever can act

Each alert goes to a named person or channel with the chart, the context and what changed: into Slack, Teams, email, or a phone call for the genuinely urgent ones. Alerts to a shared inbox nobody owns are the same as no alerts.

Watched for going stale

Model accuracy is tracked over time, so when your business changes shape and the forecast starts drifting, that is visible and fixable, rather than a model quietly getting worse while people continue to trust it.

Where it earns its keep

Same pattern, different desks

Three common versions of the same problem: a decision being made a few weeks too late to be a good one.

01 · Wholesale & distribution

Money sitting in the wrong stock

The problem: Buying is done from last year's figures plus instinct. The result is cash tied up in lines that move slowly and stock-outs on the lines that sell, with the pattern only obvious in hindsight at the end of the season.
What we build: Demand forecasts per product line accounting for seasonality, promotions and lead times, expressed as ranges with reorder points, plus alerts when a line's actual sales leave the forecast range early enough to change the next order.
What changes: Fewer stock-outs on the lines that matter, less cash immobilised in slow stock, and a buying conversation that starts from a tested number rather than a memory of last year.

02 · Hospitality & events

Rostering for a Saturday nobody predicted

The problem: Staff rotas are set a fortnight ahead on gut feel. Overstaffing quietly destroys margin on a quiet week; understaffing produces bad reviews and burnt-out staff on a busy one, and neither is spotted until the wage cost lands.
What we build: Covers forecast per site, per day and per shift from trading history, seasonality, local events and weather, presented as a range next to the planned rota so the gap is visible while the rota can still be changed.
What changes: Labour cost as a share of revenue held closer to target across every site, with the reasoning visible to managers so they can override the forecast when they know something it does not.

03 · Subscription & membership businesses

Cancellations you only see at renewal

The problem: Churn is measured monthly, after the fact. By the time a member appears in the report they have already gone, and the retention team is working from a list of people whose minds are made up.
What we build: A risk score built from the behaviour that historically precedes cancellation (usage falling off, support contacts, failed payments), surfaced as a weekly list for the retention team, together with a cash-flow forecast that reflects expected churn rather than assuming it away.
What changes: Retention effort aimed at members still worth saving, and a revenue forecast that stops being an optimistic straight line.

The technology

The tools behind it, named

Established statistical methods first, machine learning only where it demonstrably beats them on your data. Most business forecasting problems are solved well by unglamorous tools, and we would rather be right than impressive.

6 layers · 31 technologies

The modelling

Proven forecasting and anomaly-detection methods, chosen for the shape of your data and the length of your history rather than for how modern they sound.

Python
pandas
NumPy
statsmodels
Prophet
scikit-learn

Testing and explaining it

The part that decides whether a forecast is worth trusting: backtesting against known outcomes, and showing the working so people can argue with the model instead of obeying it.

Jupyter
Plotly
XGBoost
Backtesting
Polars

The history it learns from

Forecasts read from the same modelled, tested tables as your dashboards, so the prediction and the actuals are always counting the same thing.

Google BigQuery
Snowflake
PostgreSQL
ClickHouse
DuckDB

Getting the alert to a human

Routing, escalation and quiet hours, so urgent things interrupt someone and merely interesting things wait for the morning.

Slack
Microsoft Teams
PagerDuty
Twilio
Resend
Grafana

Where people see the output

Forecast ranges shown next to actuals on the dashboards your team already opens, not in a separate tool that only the analyst logs into.

Metabase
Power BI
Apache ECharts
Looker

Running and watching it

Models retrained on a schedule, accuracy tracked every cycle, and failures raised, because a silently degrading forecast is worse than none at all.

Apache Airflow
Prefect
Docker
Sentry
Prometheus

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Four to eight weeks, and the first two are spent finding out whether your data can support a useful forecast at all.

We check whether this is forecastable

How much history is there, how consistently was it recorded, how noisy is it, and did the business change shape halfway through? Some series genuinely cannot be forecast usefully, and we would rather find that out in week one than sell you a model that cannot work.

We agree what a useful forecast would change

A forecast that arrives after the purchase order is signed is decoration. We work backwards from the decision (when it is made, by whom, and how far ahead they need the number) and design to that horizon.

We start with the simple method

A straightforward seasonal baseline is built first and measured. It is often good enough, and it becomes the bar that anything more complicated has to beat before it earns its place and its running cost.

We backtest it honestly

The model is run against past periods and scored against what actually happened, then shown to you with its error rate stated plainly. You get to see how wrong it typically is before you decide how much to lean on it.

We tune the alerts on live data

Alerts run in listen-only mode for a couple of weeks so we can see how often they would have fired and whether anyone would have cared. Thresholds are tightened until what survives is worth interrupting someone for.

We keep score afterwards

Forecast against actual is tracked every cycle and reviewed with you. When accuracy drifts (because your business changed, not because the maths broke), that is visible immediately and the model gets revisited.

Before you commit

The questions worth asking

How accurate will the forecast be?

We cannot tell you before we look at your data, and anyone who quotes you an accuracy figure up front is guessing. What we will do is backtest against your own history and give you the real error rate before you rely on it. Some series (steady, seasonal, well-recorded), forecast very well. Others are dominated by a handful of large unpredictable deals, and for those the honest answer is that a forecast adds little and we will tell you so rather than build one.

What happens when something genuinely unprecedented occurs?

The forecast will be wrong, and it is important to be clear about that. A model learns from history; it cannot anticipate a new competitor, a regulatory change, a supplier collapsing or a pandemic. What it can do is show you quickly that reality has left the expected range, which is why forecasting and alerting belong together. We also rebuild models after a structural break rather than letting them keep averaging in a world that no longer exists.

Do we need machine learning for this?

Usually not. Classical seasonal methods handle most business forecasting well, are cheaper to run, and, importantly, can be explained to a board. We reach for heavier machine learning when there are many interacting drivers and enough history to justify it, and only when it measurably beats the simple approach on your data.

How much history do we need?

For anything with yearly seasonality, two full years is the comfortable minimum and three is better; with one year the model cannot tell a seasonal pattern from a trend. Shorter histories can still support weekly patterns and anomaly alerts, which are often the more valuable half anyway.

How do we stop alert fatigue?

By treating every alert that nobody acted on as a fault to be fixed. Thresholds are tuned to each metric's normal rhythm, related alerts are grouped rather than fired individually, quiet hours are respected for anything non-urgent, and we review firing rates with you after the first month. A channel people mute is worse than no alerting, because everyone assumes it is being watched.

Will people actually trust a number a model produced?

Only if they can see how it got there, so we build for that: the drivers behind each forecast are visible, past accuracy is published alongside the prediction, and the range is shown rather than hidden. In practice trust is earned over a few cycles of the forecast being roughly right, and it is lost instantly by a single confident number that turns out to be badly wrong, which is exactly why we show ranges.

Tell us the number you wish you could see coming

Tell us the decision you make too late and the history you have to work with. We will tell you honestly whether it can be forecast usefully, and say so if it cannot.

Start the conversation →

Explore more

The rest of Data & Dashboards

Live dashboards Connecting systems Automated reporting ← All of Data