The expiry audit we got wrong in the first weeks
We walked into a grocery chain with an expensive expiry problem. Perishables spoiling on the shelf, high loss, and a director who knew the size of the damage but not where it happened.
The hypothesis was good. A system that reads expiry dates and shelf-exposure time and warns before the product goes bad. We shipped the first version in three weeks. And it failed in a way we should have seen coming.
What we found
The problem was not a lack of warnings. It was too many. When we started looking, the store team already received expiry alerts from the old system, and had stopped reading them.
Too many alerts equals no alerts. The first thing we found was not a data gap; it was alert fatigue. The team had learned that most warnings were not worth the walk to the shelf.
What we changed, after getting it wrong
In the first two weeks, we made it worse. We tuned the system to flag the maximum number of at-risk items, proud of the coverage. More alerts, more “hits” on the dashboard. And the team ignored it even more.
We were measuring the wrong thing. We optimized what the camera saw, not what the team acted on. An alert nobody acts on is not detection; it is noise with an AI stamp.
The turn was to invert the criterion. Fewer alerts, only the ones with the most avoidable loss, each with a clear action. Precision over coverage. The system moved to flagging twenty items a day, not two hundred, and each one was worth the walk.
The number that moved
In seven weeks, expiry loss in the pilot section fell by about a third. The team trusted the alert again, because the alert was worth trusting again.
The honest part: part of the drop came from order adjustment, not the alert. Less buying of what spoiled, fewer items to spoil. The alert caught what was already on the shelf; replenishment fixed it upstream. The two together moved the number, not the alert alone.
What we got wrong, in one sentence
We confused detecting with solving. We spent two weeks improving detection when the bottleneck was action. The same mistake of measuring the model and not the operation we see become shrinkage that never gets decomposed.
What we left behind
An alert rule with a ceiling: the system never sends more warnings than the team can handle in a shift. A definition of avoidable loss, separated from unavoidable loss. And the internal team running the tuning, raising the ceiling only when action keeps up.
Think about the alert your operation generates and nobody acts on. A report that arrives and never becomes action. Before asking for more detection, ask whether the problem is seeing or acting.
If this shape of gap sounds familiar, between what the system flags and what the team does, describe in one paragraph what is happening. We step inside the operation for two weeks and leave with a one-page document your team keeps: what we saw, what the metric missed, and the three changes that close the gap. That is how we work.