Why warehouse software gets abandoned on the floor

The parallel register

Warehouse software does not usually get switched off. It gets quietly demoted. The system stays live because management looks at it, while the team keeps a notebook, a spreadsheet or a whiteboard holding the numbers they actually rely on.

Once that split exists, the system's figures drift from the floor's, and each divergence makes people trust it a little less. The eventual verdict — 'the software does not work' — is really a verdict on a mismatch that was designed in from the start.

Most mismatches are about layout

Off-the-shelf warehouse software assumes a warehouse shape: aisles, racks, bins, a receiving dock, a dispatch bay. Real warehouses, especially leased ones, are shaped by the building. There is a mezzanine that only fits small items, a corner that floods in monsoon, a bay that is unusable when a container is being unloaded.

When the system cannot express those facts, people work around it. Stock is recorded in a location that is approximately right, and the system's location data becomes advisory. At that point cycle counts start producing discrepancies that are really just the workaround showing up.

Stock is a ledger, not a number

The second common failure is modelling stock as a quantity that gets incremented and decremented. It is easy to build and it hides the one thing you need when figures disagree: how the number got there.

Recording every movement — receipt, putaway, pick, transfer, adjustment, return — as an entry in an append-only ledger means the current quantity is derived rather than stored. When a count disagrees, you can replay the movements and find the step that was wrong.

This also changes what a discrepancy means. With a ledger, a drift between counted and expected stock is evidence of a process or code problem, not something to be silently corrected. Systems that let a cycle count overwrite the balance destroy the only trail that could have explained it.

Expiry dates change the allocation problem

For food, pharmaceuticals, cosmetics and anything else with a shelf life, picking the wrong unit is not merely untidy — it produces stock that expires on a shelf while newer stock ships.

First-expiry-first-out allocation has to be enforced by the system at the point of picking, because it cannot be enforced by a person who is looking at two visually identical cartons. That means the system must track expiry at the level it actually varies, which is usually the received batch, not the item.

New staff are the real usability test

Warehouse teams turn over. A system that a trained team can use is not the same as a system a new joiner can use on their second day with limited English and a handheld scanner.

This is a good design constraint precisely because it is demanding. Screens that survive it tend to show one task at a time, in the order the physical work happens, with scanning as the primary input and typing as the fallback rather than the reverse.

What to check before you buy or build

• Can the system describe your actual layout, including its awkward parts?
• Is stock stored as a movement history you can replay, or as a number?
• What happens when a cycle count disagrees — is the trail preserved?
• Is expiry tracked at the level it actually varies?
• Can a new joiner complete a pick correctly on day two?
• Does it work on the handheld hardware you already own?