Why your team stopped reading store alerts

The failure that looks like success

Alert systems fail in a way that is genuinely hard to spot, because the failed state and the working state look identical from the outside. Alerts are configured. Alerts are firing. A dashboard somewhere says the store is monitored. And nobody has read one in six weeks.

This is worse than having no alerts, and not marginally. A team with no alerts knows it is not covered and checks things manually. A team with ignored alerts believes it is covered, has stopped checking manually, and finds out it was wrong when a customer tells them.

The usual response to a missed event is to add another alert, which makes the volume problem worse and further trains people to ignore the feed. That is the loop worth breaking.

How to tell if you have crossed the line

Four checks, none of which require any tooling.

• Ask somebody what the last alert said. Not whether they get them. What the most recent one was about. Hesitation is your answer.
• Look for muting. If anyone has muted the alert channel, or filtered those emails out of their inbox, the system is already dead for that person and probably for others who were less honest about it.
• Count a normal day. More than about ten alerts a day to one person and they are being skimmed rather than read. More than twenty and they are wallpaper.
• Check the action rate. Of the alerts that fired last week, how many led to somebody doing something? If it is under a fifth, most of what you send is noise, and the fifth that matters is buried in it.

Why it happens

Almost always one of three causes, and they need different fixes.

The threshold is wrong

The most common. A low stock alert set at five units on a line selling thirty a week fires constantly and tells you nothing you can act on. Alerts that fire when nothing needs doing are the fastest way to teach a team that the feed is ignorable.

The fix is to set thresholds from lead time and sell-through rather than from a round number. If restocking takes ten days and you sell four a day, an alert at five units is arriving five days too late and is useless anyway. Forty is the number, and it will feel too high until the first time it saves you.

Everybody gets everything

The second most common, and it usually comes from a good instinct: nobody wanted to be the person who did not tell somebody. So all alerts go to all people, and each person receives a feed that is mostly irrelevant to them.

A person who gets thirty alerts of which two concern them learns to skim. Skimming misses the two. Sending an alert to somebody who cannot act on it does not create a safety net, it creates noise with a plausible excuse.

There is nowhere for the alert to go

The subtlest one. The alert is correctly set and correctly routed, and there is no mechanism for what happens next. It arrives, somebody reads it, and whether anything was done is unrecorded.

Over time the team learns that alerts are informational rather than actionable, because nothing follows from one. This is a design problem rather than a configuration problem, and no amount of threshold tuning fixes it.

Rebuilding the feed

If you are past the line, tuning the existing set rarely works, because the team's habit of ignoring it is now stronger than any individual alert. It is usually faster to turn everything off and rebuild deliberately.

1. Turn them all off. This feels reckless and is not. They were not being read.
2. List what actually went wrong in the last three months. Real incidents, not hypothetical ones. Stockouts, orders that sat, chargebacks, supplier failures.
3. For each, ask whether an alert would have changed the outcome. Many would not have. If the information arrived too late to act, or the person receiving it could not act, the alert was never the fix.
4. Turn on only those. Usually three to five, not fifteen.
5. Give each one a single named recipient. Not a group. One person, with one alternate for when they are away.
6. Set each threshold from your own numbers. Lead time and sell-through, not a default.

Then leave it alone for a month. The instinct after the first missed thing is to add an alert, and that is exactly how the last set grew to fifteen.

The rule that keeps it healthy

An alert earns its place by causing an action. If one has fired repeatedly over a quarter and nobody did anything differently because of it, it is not a safety net, it is a habit. Turn it off or change the threshold until it means something.

Review quarterly rather than continuously. Continuous review means reacting to the most recent incident, which is how you end up with an alert for each thing that ever happened once.

There is one more rule worth adopting, and it is the hardest because it runs against instinct. When something slips through, resist adding an alert for it. Ask first whether an existing alert should have caught it and was ignored, and if so, fix the reason it was ignored rather than adding a second voice saying the same thing louder. Most overgrown alert sets are a record of past incidents rather than a design, and every one of them was added by a reasonable person having a reasonable reaction to a real problem.

The short list most stores actually need

Rebuilding from scratch tends to land in roughly the same place. Five alerts cover most of what genuinely goes wrong in a small ecommerce operation, and each one has an obvious single owner, which is what makes them work.

• Stock approaching the reorder point. Not "low", but low enough that ordering now still arrives before you run out. The threshold comes from lead time multiplied by daily sales, plus a buffer. Owner: whoever places orders.
• An order flagged as high risk. Low volume, high consequence, and the window to act is short because it closes when the parcel ships. Owner: whoever can hold a shipment.
• An order that has not moved in longer than it should have. The quietest failure in fulfilment: nothing is wrong enough to raise an error, and the order simply sits. Owner: whoever runs the queue.
• A supplier delivery past its confirmed date. Fires the day after, not a week later when somebody notices the shelf is empty. Owner: whoever owns that supplier.
• A chargeback or dispute opened. Deadline-driven, and the deadline is unforgiving. Owner: whoever handles finance.

Notice what is absent. There is no new-order alert, because a store with enough orders to need alerting has too many to alert on. There is no daily summary, because summaries are read for a fortnight and then filtered. And there is nothing routed to a group, because a group owner is no owner.

The alert that is really a process problem

One category deserves separating out, because no threshold will fix it. If you are alerting on something that happens every day and always requires the same response, you do not have an alerting problem, you have an unautomated process.

An alert exists to tell you about an exception. When the exception is routine, the alert is just a reminder to do a job, and reminders are what task lists and recurring schedules are for. Moving those out of the alert feed is often the single biggest volume reduction available, and it costs nothing.

Related reading: who should see inventory alerts covers routing in depth, and getting the low stock threshold right covers the arithmetic behind the number.

Common questions