Let me start with the verdict: last year I walked through a distribution center in Tennessee running 18 AMRs, and it was pushing roughly the same volume it used to push with 24. The owner didn't add a single bot. He did one thing—switched the dispatch strategy from nearest-available to zone-based assignment. I've also seen the opposite: fleets scaled past 30 bots with output flat as a pancake. The ceiling on an AMR fleet isn't the number of bots. It's the dispatch strategy.
This might sting a little: most warehouses spend 90% of their budget and attention on the bots themselves—payload, battery life, LiDAR versus magnetic tape navigation. The dispatch strategy? That's whatever the WMS or AMR vendor set as the default during installation, clicked through without a second thought, and only revisited when things went sideways. In 2024 I saw the textbook case at a 120,000-square-foot e-commerce warehouse outside Indianapolis: bots added one by one until the fleet hit 32 for peak season, and the pick zone entrance turned into a rush-hour parking lot. Empty runs, bots yielding to each other, a queue at the chargers—and management was still asking, "Do we need more bots?" They had enough bots. The dispatch never kept up.
The heart of AMR dispatch is task allocation: a task comes in, which bot gets it. Sounds like a small decision. Get it wrong, and every additional bot makes the mess bigger. Here are the three strategies I've actually seen in the wild, each with its own personality.
Three strategies, and the warehouse each one fits
Strategy one: nearest-available. Simple and brutally direct. A task comes in, the system finds the closest idle bot, and sends it. That's it.
Its one virtue is speed. Task response latency is the lowest of the three, the system is easy to implement, and it runs just fine in a small facility with a dozen or so bots. But it's blind to the big picture. The bots closest to the action are always the same few, so utilization skews hard; bots crisscross the same aisles chasing "nearby" tasks; and worst of all, it ignores battery and direction—a nearly-dead bot gets dispatched for a "close" task, finishes it, and dies right there, and now you're dispatching a second bot to go drag it back. In 2023 I watched this play out at an auto-parts warehouse in Ohio: only 20 bots, but the dispatch heatmap told the story—units near the outbound dock were being run into the ground while the far-end bots sat idle all day. One dispatch strategy had manufactured two classes of bots: the overworked and the sunbathing.
Who it's for: small fleets (under fifteen bots or so), even task distribution, compact buildings, no strong directional tides. At that scale, nearest-available is low-maintenance and works. Don't overthink it.
Strategy two: zone-based assignment. Every bot gets its own turf. The warehouse is divided into zones, bots are assigned to zones, and a zone's tasks only go to that zone's bots.
This one cures chaos. Bots stay in their lanes, paths become predictable, aisle congestion drops sharply, battery drain evens out, and maintenance planning gets easier. That's the Tennessee story—after splitting 18 bots across 4 zones, empty travel mileage dropped and total throughput went up, because the bots stopped blocking each other. The price is rigidity: when one zone spikes, the idle bots next door just sit there, and all you can do is watch, or manually re-zone on the fly. Get the zone boundaries wrong and it's worse. I saw a food warehouse that zoned by average order volume—then a promo hit, the six bots in the hot-SKU zone ran to thermal protection while four bots in the next zone waited for work. The zones were drawn on paper averages, and nobody had planned for the promo variable.
Who it's for: high-volume warehouses with clear wave patterns and relatively fixed aisles. Big e-commerce peak operations and dedicated 3PL accounts mostly land here. And when you draw zones, don't zone by the average—zone by the peak and by category surges, and leave 15%–20% of slack.
Strategy three: predictive pre-dispatch. The bot is already moving before the task exists. The system uses historical volume and wave plans to stage idle bots where tasks are most likely to appear. When the task drops, a bot is already nearby.
This is the most data-hungry and most demanding of the three. When it works, response times hit the floor and peak throughput is the highest of the bunch. But the prerequisites are non-negotiable: trustworthy historical data, a stable wave rhythm, and someone continuously tuning the parameters. I watched a cosmetics warehouse whose order spikes followed a livestreaming schedule— the forecast model got punched in the face daily, and pre-dispatched bots spent half their time waiting in the wrong spots. It would have done better on plain nearest-available. Pre-dispatch's deadliest enemy is the false pattern: something that looks like a rhythm but isn't.
Who it's for: high-volume, rhythmically stable operations with a real data foundation and a dedicated person (or vendor service) doing continuous tuning. Miss any of those three, and don't touch it—you'll just be digging your own hole.
Switching strategies isn't flipping a switch
When the strategy is wrong, sure, switch. But I've seen too many warehouses treat "switch dispatch strategy" as a config change—flip it at night, fire in the morning. Here's the sequence I've actually validated:
First, run two weeks of baseline data. Don't go by gut. Log current task response times, empty-travel share, bot utilization spread, and congestion hotspots. Without a baseline, you won't even know if the switch helped.
Second, pilot in a small area. Zone-based? Try it in one zone first. Pre-dispatch? One wave. Never cut over the whole building at once—a dispatch meltdown hits the entire outbound rhythm, and trial-and-error is billed by the hour.
Third, set a rollback line before you start. Write it down: if response time degrades by X, if congestion rises by Y, we revert. Put it on paper, on the wall, so "let's watch it a bit longer" doesn't become the plan.
Fourth, watch for two weeks before going full-scale. A dispatch strategy's real effect doesn't show on day one; the first week is usually the break-in period, and the numbers will lie to you.
One more trap to flag in advance: before switching, confirm your WMS and AMR dispatch system actually support the strategy you want. Some vendors hard-code their "dispatch strategy" into the firmware, and the so-called zone assignment has to be faked through manual task grouping in the WMS—degraded, and a maintenance nightmare. Ask before you sign, not after installation.
One question to leave you with: which strategy is your warehouse running right now? Did someone actually choose it—or was it just the default someone clicked during installation? If your fleet is past 20 bots, volume is still climbing, and nobody has ever touched the dispatch strategy, chances are the problem was never the bots.
