Who should see inventory alerts, and who should not

The wrong fix for a real problem

A team drowning in alerts almost always tries the same two remedies: raise the thresholds so fewer fire, or add more channels so they are better sorted.

Both help a little. Neither addresses the actual cause, which is usually that alerts are going to people who cannot do anything about them.

An alert that reaches someone with no authority to act, no context to interpret it, and no responsibility for the outcome is not information. It is noise wearing a badge. And it does specific damage: it teaches that person that alerts are background, which means the one alert they genuinely needed to see gets skimmed with everything else.

The routing question

For any alert, in order:

1. Who can act on this? Not who is interested. Who has the authority and the ability to change the outcome.
2. What would they do? If you cannot describe the action in a sentence, it is not an alert. It belongs in a report someone reads weekly.
3. Who else is affected by that action? These people need to know, but usually after the fact rather than at the same moment. That is a different delivery.

Most alert systems are built by answering only the third question, which is how everybody ends up subscribed to everything.

A routing map for a small store

Adjust to your shape, but the logic holds.

Two patterns to notice. Most rows have exactly one actor, and several have nobody in the second column at all. Both are features. The urge to add names to the right-hand column is what created the problem you are fixing.

The promoted-product exception

The one row where wide distribution genuinely earns its place.

When something in an active campaign runs low, at least three people need to know within the hour: whoever can reorder, whoever can pull it from the email or the ads, and whoever will answer the customers asking where it went.

This is the alert most worth engineering properly, because the cost of a delay is paying to advertise something you cannot sell, and that cost accrues by the hour. It is also the alert most likely to fire at an inconvenient moment, which is exactly why the routing should be decided in advance rather than improvised.

Owners and the everything problem

Owners of small stores subscribe to every alert, for an understandable reason: it is their money and their name.

The trouble is that it produces the worst version of the failure. The owner receives everything, cannot act on most of it, gradually stops reading carefully, and then misses something significant. Meanwhile the person who should have acted assumes the owner is handling it, because they can see the owner received it.

That second effect is worse than the first and it is invisible. Visible oversight quietly transfers responsibility upward, and the more alerts an owner receives, the less anyone else feels ownership.

The better arrangement: owners see a periodic summary and the small set of alerts they genuinely act on. Everything else goes to the person responsible, with the owner able to look whenever they want. Availability is not the same as delivery, and conflating the two is what fills an owner's day with notifications.

Sending an alert to someone who cannot act on it does not add a safety net. It removes one, by making everyone assume somebody else has it.

Seasonal and part-time staff

Two failure modes, in opposite directions.

Too much. A seasonal packer added to every alert channel on day one, on the theory that context helps. It does not. They have no basis for judging what is normal, cannot act on most of it, and learn within a day to ignore the channel entirely.

Too little. The same person excluded from everything, including the one alert relevant to what they are physically doing. They pack an order for something the system thinks exists and nobody told them about.

The right answer is narrow and specific: the alerts that relate to the task in front of them, and nothing else. That means scoping by role rather than by seniority, and it is much easier to set up before the season than during it.

The quarterly prune

Alert subscriptions only accumulate. Somebody adds a channel for a specific week and it never gets removed.

Once a quarter, ask each person two questions: which alerts do you act on, and which do you skim past? Anything in the second list should be unsubscribed, and the answers are more honest than any audit of the configuration, because people know exactly what they ignore.

If someone answers "I skim past all of them", that is not a person problem. It is a routing problem, and it has been running for a while.

Delivery is a second decision

Audience is who should know. Delivery is how it reaches them, and the two get conflated constantly.

The same alert deserves different delivery depending on how quickly it needs acting on:

• Interrupt for things where minutes matter. A high-risk order about to ship, stock gone on something you are actively advertising. This is a small list and it should stay small, because the value of an interrupt collapses as soon as it is common.
• Post to a room for things needing action today but not this minute. Most stock alerts belong here. The person sees it when they next look, which is soon enough.
• Daily digest for anything where a day of latency is irrelevant. Slow-moving reorder points, packaging levels.

Most alert fatigue comes from putting category-three items on a category-one delivery. The information was worth having; the interruption was not, and after a fortnight people mute the channel that carries both.

Solo operators

Running the store alone does not remove the routing question, it changes it. You are the audience for everything, so the only lever you have is delivery.

The failure mode is different too. With nobody to hand off to, an alert you cannot act on right now competes for attention with the thing you are doing, and you lose both. The fix is to route almost everything to a digest you read at a fixed point in the day, and reserve interruption for the two or three things where an hour genuinely matters.

Alerts that should not exist

Some alerts fail the routing test entirely, and the right fix is deletion rather than better addressing.

The clearest category is the alert that fires on something nobody can change. A notification that a product is selling faster than forecast is interesting and not actionable, unless there is stock to order and someone able to order it. Without that, it is a fact delivered as an interruption.

The second category is the alert that duplicates something people already see. If your team opens the orders screen every hour, an alert for each new order adds nothing and costs attention.

The third is the alert nobody has acted on in three months. Whatever it was watching for either stopped happening or was never worth watching. Both conclusions point the same way.

Deleting alerts feels like reducing safety, which is why nobody does it. It usually increases safety, because every removed alert raises the average relevance of what remains and makes the rest more likely to be read.

Getting a person off a channel gracefully

The awkward part of fixing routing is that it means removing people, and removal reads as exclusion unless you frame it.

Say what it is: you are cutting the noise so the alerts that reach them are ones they can act on. Most people are relieved. The ones who object usually have a reason worth hearing, and it is often that the alert is their only visibility into something they care about, which is a reporting gap rather than an alerting need.

Where that happens, give them the summary instead. Access without delivery is the right compromise: they can look whenever they want, and nothing interrupts them to do it.

Common questions