A stores clerk types a part number into the ordering screen, and a short list of "you might also need" suggestions drops in underneath it. None of them belong on this job. He scrolls past, picks the part he actually came for, and closes the tab. Next week a different engineer does the same thing for a different machine, and the suggestions are wrong again — confidently wrong, in the same way, every time.
Nobody files a complaint about it, because nobody expected the list to be right. It has been wrong since the week it went live, and by now it has quietly trained the whole floor to stop looking at it at all.
Why we build it this way
Most recommendation systems are built the same way, whatever label is on the box: look at what has been bought together before, and suggest more of that pattern. It is the obvious approach, and on a catalogue with real repeat volume — the handful of items that move every week — it works well enough that almost nobody questions it.
An industrial spares catalogue rarely looks like that. It can run to thousands of part numbers, and most of them are ordered once or twice a year, by a different person, for a different machine, with no real pattern connecting one order to the next. The obvious approach needs volume to learn a pattern from. A catalogue shaped like that does not give it one, however carefully the system is tuned afterward.
The mistake is not picking the wrong vendor or the wrong model. It is choosing an approach before anyone has checked whether the shape of your own data can support it, and finding that out only after it has shipped and started giving confident, wrong answers on the floor.
A recommendation engine trained the usual way needs people to buy the same things again and again. A catalogue where almost nothing repeats gives it nothing to learn from — and no amount of tuning afterward fixes an approach built for a shape of data you do not have.
So before we choose how to build anything, we build a test set from the real cases: the actual order history, and the handful of cases where two people on the floor would genuinely pick a different part for the same job. We run the obvious approach against that set first. If it fails there, on your own catalogue, we have saved everyone the cost of building it properly and watching it fail on the floor instead.
How it works, roughly
Checking an approach against your own catalogue before building anything is mostly a matter of looking at what you actually have, not what the textbook assumes you have:
- The real order history for the catalogue — how often each part is genuinely reordered, and by whom
- The handful of cases where two experienced people would recommend a different part for the same job
- Whatever approach is on the table, including the obvious one, run against those cases before a line of it reaches the floor
Where the result disagrees with what the plant's own people would suggest, that goes back to whoever is accountable for the catalogue — the person who decides whether the approach needs more data, a different shape entirely, or dropping. Nothing about the catalogue's own shape changes just because a demo looked clean somewhere else.
A year on, what the plant has is not a suggestion list nobody trusts. It is a record of what was tried against the real catalogue, what the catalogue's own shape ruled out, and the approach that was actually kept because it survived contact with real orders — decided by the people who have to live with the result, and kept where they can check it again whenever the catalogue changes.
See how we build the test set first →