Spare-parts recommendation engine for a Fortune 500 maintenance unit
Designed and shipped a recommendation engine to streamline the spare-parts catalog used by a global maintenance business unit — turning a sprawling, manually-curated lookup into a model-driven workflow.
Heads up: placeholder draft based on the public bio. AJ will refine specifics — especially the metrics — and replace where anonymization is too aggressive.
Challenge
A Fortune 500 industrial business operated a global maintenance arm that lived and died by getting the right spare part to the right job in the right country. The catalog was massive, the customer-facing technicians were experienced but inconsistent, and the institutional knowledge of which part fit which scenario was distributed across spreadsheets, emails and individual minds.
The cost of getting it wrong wasn’t subtle — wrong part shipped meant a job rebooked, a customer SLA missed, and inventory tied up in the wrong place.
What they wanted was straightforward to describe and surprisingly hard to do: given a job ticket and an asset, suggest the parts a senior technician would order.
Approach
The work broke into three threads run in parallel:
- Data foundation. The first three weeks were spent reconciling part numbers across regions. The same physical part lived under multiple IDs depending on supplier, country, and historical merger. Without that reconciliation, every downstream metric was lying.
- Modeling. A pragmatic blend of collaborative filtering for the bulk of common jobs, plus rule-based fallbacks for safety-critical asset families where you do not want a model improvising. The honest answer is that the rules carried more weight than is fashionable to admit.
- Interface. The recommendation surface had to live where the technicians already worked — not a new screen. We embedded suggestions into the existing ticketing flow, with a one-tap “use these” and a one-tap “show me why.”
Throughout, the team had to fight the temptation to optimize for the demoable metric (top-1 accuracy on historical orders) instead of the operational metric (jobs completed without a re-order). They are not the same number and they don’t move together.
Outcome
- A working recommendation surface integrated into the technician workflow.
- Measurable reduction in repeat-order rate on the asset families it was deployed against.
- A reusable data foundation (cleaned part-number reconciliation) that became the basis for follow-on initiatives.
- A small, opinionated playbook the internal team has continued to apply to other recommendation problems in the business.
Lessons that travel
- The demo metric and the value metric are usually different. Decide which one you will be judged on before you start training.
- Senior technicians are the validation set. If your suggestions are upsetting them in a particular way, that pattern is the model’s biggest blind spot.
- Don’t ship a new surface for the model. Live where the work already happens.
This is an anonymized summary. Specific client details, contract figures and individual identities have been redacted.