Common challenges
Your pickers are walkingthe warehouse, not working it.
The team is putting in full shifts and the order count still isn't moving. Look closer and most of the paid hour is spent between locations, not at them — a pick list that sends someone the length of the building for lines that should sit metres apart. The fix isn't more headcount. It's measuring how far a picker walks per line, and why, before you decide what to change.
See picking optimisation
Is this your problem?
How to tell a walking problem from a picking problem.
The measure that tells you is travel distance per line, set against the walking share of the paid hour. Wearable and scan data can split a shift into standing, walking and handling rather than leaving it as one productivity number, and when walking dominates the split while lines picked stays flat, the team isn't slow at picking — it's spending the shift getting to the next pick.
It happens because the pick list and the floor stopped agreeing with each other. Fast movers end up scattered across the building instead of clustered together, the sequence a picker follows ignores which locations actually sit near each other, and orders route through as singles instead of grouped by what's already close. None of that shows up as an error on any report — it just adds distance to every route, one pick list at a time.
WareBee scores travel per line against a peer set matched on order profile, SKU count and footprint — never an industry median — so 'our pickers walk too much' becomes a number you can compare, argue with and act on.
What's actually causing it
Five ways the pick list adds distance.
Each one is measured on your digital twin from data you already generate, so you can see which applies to you before you touch a route.
Fast movers scattered across the floor
High-velocity SKUs sit wherever they landed, not where a picker can reach them without a detour.
The twin separates the vital few driving most picks from everything else, then checks where each one is actually slotted against demand velocity, item affinity and congestion. When the fastest movers turn up spread across zones instead of clustered on the routes pickers walk most, every pick list inherits the detour.
The sequence ignores the map
A pick list ordered by SKU or order sends a picker back and forth between locations that sit right next to each other.
Routes solved as a true shortest path on the twin's real navigation graph reorder the stops themselves, rather than walking a fixed list in the order it happened to print. Replay the same pick lists through the solver and the doubling-back a static sequence keeps repeating is visible, list by list.
Orders travel the warehouse one at a time
Each order gets its own lap of the building instead of sharing a trip with orders picking from the same aisles.
Whether batching pays off depends on lines per order, SKU overlap and where those SKUs are slotted — read from your own order profile rather than assumed. Where orders share locations but never share a trip, each one pays for a lap a batch could have combined.
One-way rules nobody's re-tested
A direction rule set for a layout that's since changed can add a lap to a route that would otherwise be direct.
Aisle directions, tunnels, access points and blocked locations are re-applied at solve time rather than baked into a static map that goes stale, so a rule that made sense for last year's layout doesn't quietly survive unexamined into this one. Where it no longer earns its keep, it shows up as distance a direct route wouldn't need.
Replenishment crossing the pick routes
Restock runs and picking share the same aisles at the same time, so pickers detour around pallets instead of walking straight through.
A slow replenishment is one of the flow stalls the twin already pinpoints and prices in travel and time, alongside a congested aisle or a queue at the dock. When replenishment and picking are scheduled without seeing each other, the aisle a picker needs next is exactly the one a restock run just blocked.
Cut the distance, not the headcount.
WareBee replays your real order history through candidate routes, batching policies and slotting moves in a digital twin, and reports the travel distance per line each option returns before anyone walks it. Routes solve as a true shortest path on the twin's real navigation graph — aisle directions, one-way rules and congestion included — so the sequence handed back is one a picker can actually walk, not a straight-line best case.
Because routing, batching and slotting interact, WareBee tunes them together rather than one at a time. It's WareBee's own finding that optimal picking location assignment alone can lift picking productivity by up to 20% — pairing it with route and batching changes compounds the gain, and every approved change reaches your WMS as tasks it already understands.
- Travel per line measured and compared before rollout
- Routes, batching and slotting tuned together, not one at a time
- Approved changes reach the WMS as tasks it already understands
Questions
Excessive picker travel, answered.
How do you measure picker travel without timing people?
WareBee reconstructs a shift into standing, walking and handling time from data you already generate — WMS and ERP event streams, scans, and wearable data where you have it. Travel distance per line comes from the twin's navigation graph, not a stopwatch or a supervisor's estimate, so the split is measured per associate, per zone and per shift without asking anyone to carry a timer or fill in a log.
Is the fix slotting, routing or batching?
It's usually more than one, and which pays off first depends on your operation. Slotting decides where every SKU lives, weighing demand velocity, item affinity, congestion and replenishment effort; routing decides the order a picker visits locations in, solved as a true shortest path rather than a fixed serpentine rule; batching decides how many orders share a trip. WareBee simulates all three together on your own orders and layout, so the answer comes from evidence rather than a guess about which lever matters most.
What do one-way aisle rules actually cost?
It varies by warehouse, and the honest answer is that nobody knows until it's measured — a rule can be nearly free in one layout and add a lap to every route in another. WareBee re-applies aisle directions, tunnels, access points and blocked locations at solve time rather than baking them into a static map, so a rule that's stopped earning its keep shows up as distance a direct route wouldn't need, list by list, instead of hiding inside a site-wide average.
Can shorter routes create new problems, like congestion or mis-picks?
They can, if routing is optimised in isolation. WareBee's routes are congestion aware — busy aisles cost more in the solve, so traffic spreads across the warehouse instead of stacking into the same lane — and where similar items need to stay apart to avoid mis-picks, separation rules are built into the slotting model itself rather than discovered on the floor afterwards. Shorter on paper and safer to walk are solved for together, not traded off against each other.
What data do you need to start measuring this?
WareBee builds the analysis from data you already generate — WMS or ERP feeds, order and pick history, or a simple CSV export — with no new hardware required for a first answer. Wearable and forklift telemetry sharpen the standing, walking and handling split further if you already have it, but they're an enhancement rather than a prerequisite, so the first measurement of travel per line doesn't wait on a hardware rollout.
How does a shorter route actually reach the floor?
Approved routes, batching policies and slotting moves export as pick sequences and location assignments in the format your WMS already imports, so nothing gets re-keyed into a parallel system. Every change is simulated on the digital twin first, so the plan your team approves is the one proven to cut travel — and actuals flow back afterwards, so the next round starts from what really happened on the floor rather than from what was assumed.