Taking SKU Substitution Back From The Warehouse
Confidentiality Note: Client anonymized. The fulfilment provider, the carriers, the warehouse product and the operations lead are not named, and no commercial terms appear. This work was done in an operating role inside the client's group of companies rather than under a separate vendor agreement.
The Full Story
The warehouse was making product decisions nobody could see. When an item was out of stock its system would substitute another one at pick time, and it chose using quantity on hand rather than quantity available to pick, which are not the same number: on hand includes stock that is reserved, expired or on hold. So orders were being fulfilled against inventory that was not really there, and the first anyone knew was a customer complaint.
Underneath that, a person. The operations lead ran the exception queue by hand: a spreadsheet of substitution mappings and somewhere around a hundred manual order line releases a day, every day. And behind her, a backlog nobody was counting, because orders that could not be fulfilled never reached the warehouse at all. When we looked, 1,763 of them were sitting in an accepted state, most more than four days old and the oldest at eighty three. They appeared in no throughput statistic because they never shipped. Separately, carrier status enrichment had been dead for the better part of a year: three scheduled jobs had been logging success and writing nothing.
What she had first was a spreadsheet and a vendor black box. What she has now is three services in the client's own estate. A routing service ingests the warehouse inventory feed, computes what is genuinely available to pick, resolves each substitution under explicit rules, and writes every decision to an append only log. A tracking service polls the carriers and normalises their separate vocabularies into one set of stages with a per order timeline. An operations console sits over both, with the queues, the rules, the aging and exception views and an address fix queue.
The part we would defend hardest is how it went live. No rule was trusted because we wrote it. Every rule ran first in shadow mode, logging what the system would have picked against what the warehouse actually shipped, and a rule only graduated after at least twenty scored decisions at ninety eight percent agreement or better. Six products passed that gate before anything was flipped. When the routing service took over as the sender of order payloads, the cutover harness first ran 374 of 374 payloads byte identical against the old path.
The first live rule has since produced 301 decisions across 288 orders, every one correct on inspection.
The handover reads better in the data than it would in a document. The operations lead now writes routing rules herself, in the interface, and the records carry her name on them. Go live authority for a new rule is hers, with no second approver. The spreadsheet is not a spreadsheet any more. It is a table in a system, and she is the one editing it.
We are not putting a time saving on this. The build plan's own definition of done was that the daily manual queue would be gone, and there is no measured after state on file. We would rather say what is true: the decisions are now made by a rule, logged, and reversible.
The Challenge
Physical fulfilment was outsourced, and when a product was out of stock the warehouse's own system silently substituted a different one at pick time, choosing on quantity on hand rather than quantity available to pick. So orders were routed against stock that was reserved, expired or on hold. One operations manager held the whole thing together by hand, with a spreadsheet of substitutions and around a hundred manual order line releases a day. Orders that could not be fulfilled never reached the warehouse at all and so never appeared in any throughput number. Carrier status enrichment had been dead for months: three scheduled jobs logged success and wrote nothing.
Our Solution
Three components in the client's own estate. A routing service that ingests the warehouse inventory feed, computes what is genuinely available to pick, resolves each substitution under explicit rules, writes an append only decision log, and later becomes the sender of order payloads itself. A tracking service that polls the carriers, normalises every carrier's vocabulary into one set of stages, and keeps a per order event timeline. And an operations console over both, with the queues, the routing rules, the aging and exception views, and an address fix queue.
The Result
Every Substitution Decided By A Rule And Logged