Machine learning · vectorel

What it looks like

A forecast that states its uncertainty
and proves it beats a simple rule.

1
A range, not a single number
Forecasts come with an 80% range, so plans can account for how sure the model actually is.
2
Better than a simple rule
Every model is compared with a baseline. If it can't beat it measurably, you don't proceed.
3
Checked against reality
Actual results are compared with the forecast as they arrive. When accuracy drops below an agreed threshold, the model is retrained.

Demand forecast · SKU 4471 · North regionWeekly

1 3

2

7.8%Forecast error

12.4%Simple rule error

3 wksSince last retrain

Illustrative example

Why models get ignored

Why most models never change a decision,
and what we do instead.

Problem
It was never tied to an action.
A churn score nobody acts on is a report. If it doesn't change who gets called, what gets ordered or how something is priced, it isn't worth building.

What we do
Start from the decision.
We define the decision first, and what a useful prediction would change about it. If a prediction can't change anything, we say so before building it.
Problem
It lives in a notebook.
Accurate on a laptop, invisible in the business. It stops running the week the analyst goes on holiday.

What we do
Deliver it where decisions happen.
The prediction lands in a CRM field, a dashboard, an alert or an API, and runs on a schedule, not on someone's laptop.
Problem
It was measured on the wrong thing.
High accuracy on a rare event usually means the model learned to say "no" every time.

What we do
Baseline first, then the right metric.
We test against a simple rule, on data the model has never seen, with the metric that matches your decision. You see where it fails, too.
Problem
Nobody can explain it.
A score without reasons asks people to trust a black box, and they rightly won't.

What we do
Reasons with every prediction.
Each score carries the main factors behind it. Where the consequence is significant (pricing, credit, employment), the final call stays with a person.
Problem
It aged out silently.
Customers, prices and markets change. Predictions decay for months before anyone notices.

What we do
Monitor and retrain.
Predictions are compared with outcomes as they arrive, with an alert and a defined retraining path when accuracy drops.

What we build

Six kinds of prediction
we put into production.

Forecasting

Demand, revenue, headcount, inventory, cash. Predictions at the level you actually plan at (by product, region or week), with a confidence range rather than a single misleading number.

Churn and retention scoring

Which accounts are at risk, ranked, with the factors driving each score, delivered early enough that someone can do something about it.

Lead and opportunity scoring

Which deals deserve your team's time, based on what actually closed before, not on a rule someone wrote years ago.

Pricing and elasticity

What a change in price is likely to do to volume and margin, tested against your own transaction history before you roll it out.

Classification and routing

Categorise tickets, transactions, documents or products automatically, so work reaches the right place without a person sorting it first.

Anomaly and risk detection

Flag what doesn't fit (unusual transactions, failing processes, data that shouldn't look like that) before it becomes a loss.

Use cases

Decisions it improves

Team	The decision	What the model gives them
Retail and distribution	How much to order, per SKU and location	A demand forecast with a range that reflects seasonality, not last month
Subscription and B2B	Which accounts customer success calls this week	A ranked renewal-risk list, with the reasons behind each score
Sales	Which deals get attention, and what to forecast	Likelihood to close, built from deal behaviour rather than optimistic self-reporting
Finance	How much cash to hold, and which transactions to check	A cash-position forecast, and flags on transactions that don't fit the pattern
Manufacturing and logistics	When to schedule maintenance, or reroute	Early warning of failures, delays and capacity limits from sensor and operational data

How ML projects run

The same three phases as every engagement,
with a baseline to beat.

01 / Assessment

Define the decision

What the model informs, what the current process already achieves, and whether your data can support it. You get a written scope, a fixed price, and an honest answer. Sometimes the data isn't there yet.

About one week

02 / Delivery

Baseline first, then the model

We prepare the history, set the baseline, and test approaches on held-out data. You see the numbers each week, including where the model fails. Data preparation drives the timeline more than modelling does.

Usually 6–12 weeks

03 / Handover

Monitored and retrainable

Monitoring against real outcomes, an alert threshold, and a documented retraining process any competent data team can follow.

Support optional

Built on

Python
Pandas
scikit-learn
PyTorch
MLflow
Snowflake
BigQuery

How every engagement works Full stack

FAQ

Before you model anything

How much data do we need?

How accurate will it be?

Can you explain why it predicts what it predicts?

Why not use deep learning?

Know what's coming,before it costs you.

A forecast that states its uncertainty
and proves it beats a simple rule.

A range, not a single number

Better than a simple rule

Checked against reality

Why most models never change a decision,
and what we do instead.

It was never tied to an action.

Start from the decision.

It lives in a notebook.

Deliver it where decisions happen.

It was measured on the wrong thing.

Baseline first, then the right metric.

Nobody can explain it.

Reasons with every prediction.

It aged out silently.

Monitor and retrain.