Store-level retail decisions: bu ne anlama geliyor
Centralised retail systems treat stores as demand nodes. The store manager knows things the centre does not: the road works blocking the entrance, the new competitor, the local employer that changed shift patterns.
When central recommendations conflict with that knowledge, the manager overrides them. Overrides are usually not recorded, so the system never learns why.
The override is data
A manager who consistently orders more of a line than the system suggests, and is consistently right, is telling you something the model cannot see. That signal is being discarded.
Capturing overrides with a reason — even from a short list — converts local knowledge into something the central system can use.
Where agents fit
Not by replacing local judgement. By making the central recommendation explicit enough to disagree with, capturing the disagreement, and adjusting where the pattern holds.
After a year, the system knows which stores’ overrides are reliable and on what. That is a genuinely new capability, and it starts with recording something that currently evaporates.
Why overrides evaporate
Because the system was not built to receive them. A manager who disagrees with a suggested order edits the number and moves on; the edit is stored as the final quantity, and the suggestion it replaced is gone.
From the centre this looks like compliance. The order matches what the store wanted, so no signal is raised. The disagreement happened and left no trace.
Recording it costs one field: what was suggested, alongside what was ordered. That single pair, kept for a year, is the entire dataset this article is about.
Reason codes have to be short and real
A free-text box produces nothing usable. A list of thirty options produces the first one on the list.
What works is five to seven codes drawn from what managers actually say: local event, competitor activity, access or footfall change, local employer or institution, know from experience. The last one is not a failure of the taxonomy — it is the residual, and its size tells you how much of local knowledge remains uncodified.
Distinguishing signal from habit
Not every override is knowledge. Some are a manager who orders 20% more of everything because they were short once in 2023.
The test is whether the override was right, and that is measurable after the fact: did the extra stock sell within its normal window, or did it sit. A manager whose overrides consistently sell is holding information. One whose overrides consistently sit is holding a habit, and the useful response is a conversation rather than a model change.
Most retailers have both and cannot currently tell them apart.
What the centre does with it
Two things, on different timescales.
Immediately: weight the store’s overrides in the recommendation. If this manager is reliably right on chilled lines, the recommendation for chilled lines starts closer to where they will move it.
Over time: look for overrides that cluster. Twelve stores overriding the same line in the same direction is not local knowledge — it is a central assumption that is wrong, and it has been wrong long enough for twelve people to work around it independently.
Why this is worth doing before anything more ambitious
It requires no model. One extra field, a short code list, and the discipline to keep them.
A year later the organisation has something it has never had: a map of where central recommendations are trusted, where they are corrected, and by whom reliably. Every subsequent piece of automation is easier to justify because that map exists.
What it costs to start
One field and a short list. No model, no integration, no project.
The organisations that have this data did not build anything to get it — they decided that a disagreement was worth recording, and then recorded it.