Think Build Implement Repeat
Data & Scraping

Catching the Thing That Went Wrong Before It Costs You

Last updated:

Start simple, and often stay there

Anomaly detection sounds like a machine learning project. In practice a rolling mean with a standard deviation band catches most of what matters and is explainable to everyone.

Reach for models when the normal pattern is genuinely complex — strong seasonality, multiple interacting variables — not as a starting point.

Where it pays in operations

  • Duplicate payments and invoices, which are recoverable if found quickly
  • Unusual purchasing patterns against a supplier or by a person
  • Stock movements that do not match expected consumption
  • Usage spikes on metered services, before the bill arrives
  • Sudden drops in order volume from a regular customer, which is a churn signal
The last one is underrated. A regular customer whose order volume halves has usually started buying somewhere else, and finding out this month rather than at renewal is worth a phone call.

Tune ruthlessly against false alarms

An anomaly alert that fires weekly and is usually nothing gets ignored within a month, at which point the real one is missed too.

Start with a wide band, tighten only when the alerts prove useful, and review monthly: how many fired, how many mattered, and what was done.

Give every alert an owner and an action

  1. Who receives it
  2. What they check first
  3. What they do if it is real
  4. Where the outcome is recorded, so the tuning can improve

Alerts without an action attached are noise with a notification, and they train people to dismiss everything.

Account for the known patterns

Month end, quarter end, seasonal peaks, promotional periods, bank holidays. A detector that has not been told about these will flag every one of them.

Encode the calendar explicitly rather than widening the band, which would hide genuine anomalies at quiet times.

What it costs

Statistical detection on a handful of metrics is typically a few days of work on top of existing reporting. Model-based detection is a project and should follow evidence that the simple version is insufficient.

Frequently asked questions

How many alerts is too many?

If the recipient cannot investigate each one properly, too many. For most small businesses that means a handful a week at most.

Can it detect fraud?

It can flag unusual patterns, which is where investigation starts. Determining that something is fraud is a human judgement with consequences and should stay one.

What data do we need?

Enough history to establish what normal looks like, which usually means several months of the metric at the frequency you will monitor it.

Does it need to be real time?

Rarely. Daily detection catches most operational anomalies in time to act. Real time costs considerably more and suits payment fraud rather than general operations.

Keep reading

Finding out about problems from the invoice?

Simple detection on a few key metrics is quick to add. Tell us which surprises have cost you money and we will suggest what to watch.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Web ScrapingData Science