Most developers meet warehouse software from the outside, as an API that returns stock levels and sometimes lies about them. Having spent a while on the inside of that problem, the interesting part is that almost every hard bug in fulfillment traces back to one of four design decisions, and none of them are about the UI.
The Data Model Under Every WMS
The naive model is a table of SKUs with a quantity column. That model breaks the first day a real warehouse uses it, because quantity is not a property of a SKU, it is a property of a SKU in a location at a moment.
The model that survives is a ledger. Every physical event, receiving, putaway, a pick, a cycle count adjustment, a return coming back to stock, is an immutable row, and on-hand quantity is the sum. That gives you two things a quantity column never will: you can answer why a number is what it is, and two operations touching the same bin cannot silently overwrite each other.
The follow-on decision is separating on-hand from available. Stock that is physically present but already promised to a picked order is not sellable, and conflating those two numbers is the single most common cause of overselling.
Why Scanning Beats Discipline
The industry average picking error rate for manual, unstructured operations is 1% to 3%. At 500 orders a day and a 2% rate, that is 10 wrong boxes a day, and each mispick costs $10 to $25 once you count return shipping, the labor to process the return, the re-pick, and the packing materials consumed twice.
You cannot train that number to zero, because it is not a knowledge problem. The person picking knows what the correct item is. They are moving fast, and two SKUs look alike.
The engineering answer is to make the wrong action impossible rather than discouraged. Scan the location, scan the item, and refuse to advance the pick if either does not match. It turns a human error rate into a system constraint, which is the only version of this that holds up under volume. The full warehouse management guide walks through the operational side of this alongside the software choices.
Pick Paths Are A Routing Problem
Once you have locations in a coordinate system, picking becomes a routing problem, and routing is where the software actually earns its cost.
Batch picking, where one pass collects items for several orders at once, and zone picking, where each picker owns a section and orders are assembled downstream, are two different answers to the same question about how far a person walks per unit picked. Which one wins depends on your order profile, specifically how many lines a typical order has and how concentrated demand is across SKUs.
That is also why slotting matters more than it sounds. Putting fast-moving SKUs near the pack stations shortens every route that touches them, and demand shifts over time, so slotting is a job that has to run again rather than a decision made once at move-in.
Where Integrations Break
The seams are where fulfillment systems fail in production, and they fail in predictable ways.
Order intake from multiple channels arrives at different rates with different idempotency guarantees, so the same order can appear twice under different external ids. Inventory sync back out to those channels is eventually consistent by nature, and the window between a pick and the channel update is exactly when you oversell. Carrier rating and label generation are third-party calls that will time out in the middle of a pack station workflow, which means the pack step needs to be resumable rather than atomic.
None of these are exotic. They are the ordinary distributed systems problems, showing up in a building with forklifts in it.
The Takeaway
If you are building or evaluating this kind of system, the questions worth asking are narrow: is inventory a ledger or a number, can the software refuse an incorrect pick rather than merely log it, does it treat picking as a routing problem, and is every external call resumable. A system that answers yes four times will beat a prettier one that does not.
Top comments (0)