A branch has taken 18 orders by eleven on Tuesday. Should someone call the manager? Before making that call, you need to know how many orders usually arrive by eleven and whether today's records have reached the report. Yesterday's closing total answers neither question.
Anomaly detection can catch a drop in orders, appointments or output while there is still time to investigate. Define that window first. Who would take the call, what could they check, and at what point would the alert arrive too late?
Choose a fixed threshold or an expected range
If your team has agreed to process an order within two hours, the threshold is already known. Use a rule. A fall in branch orders is a different problem. The usual Tuesday pattern may be quite different from Saturday's. Compare similar days first, then test whether a more complex model catches useful events that the simple comparison misses.
| Observation | Check | Recipient |
|---|---|---|
| An order is over two hours old | Check the time spent waiting against the agreed limit. | The person responsible for the queue. |
| Fewer orders than expected before lunch | Compare the same branch, local time and type of trading day. | The branch manager can check footfall and order channels. |
| No source records since yesterday | Check the feed before interpreting sales. | The person responsible for the integration. |
Build a baseline that reflects how the branch trades
Suppose the branch usually takes 45–60 orders by eleven on regular Tuesdays and 15–25 on its first working day after a public holiday. Eighteen orders might warrant a call on an ordinary Tuesday and be entirely expected after a holiday. These numbers are illustrative. Set the width of the range using your own trading history.
Use only information that was available at the time an alert would have fired. Account for opening hours and known promotions. A new branch or a permanent change in trading hours may leave too little comparable history. In that case, show the limitation and use a simpler operational check until there is enough evidence.
Count the events that went unnoticed
Replay a later period that was kept aside when tuning the model. Ask an operations manager to identify events that needed intervention, including on days when the model was silent. Incident logs can help. Record when each alert would have arrived. A statistically accurate signal that appears after closing may be of little practical use.
Take a sample run with 12 alerts. Eight highlighted real incidents and four interrupted the team unnecessarily. The independent review found 10 incidents worth acting on, so two were missed. Those four unnecessary calls and two missed events give the manager a concrete basis for deciding how sensitive the alert should be.
Common questions
How do we stop the same issue triggering an email every hour?
Identify an open incident by metric and branch. Update the existing incident as new numbers arrive. Agree when it counts as resolved and what further deterioration would justify a fresh notification.
Does anomaly detection require generative AI?
A rule or statistical model can generate the signal. A language model can turn verified figures into a readable comment. The recipient should still be able to open the underlying records and inspect the comparison.