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
- Who receives it
- What they check first
- What they do if it is real
- 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.