A 3PL operator in Ontario, California called me in 2023 with a vendor quote in hand: twelve pallet-moving AMRs, "exactly enough for your peak." He asked me how many to buy. I told him to hold the purchase order and do the math first.
His building sat in the Inland Empire, that endless grid of warehouses east of Los Angeles — a little over 200,000 square feet, doing e-commerce fulfillment. The business had two personalities. A normal day meant four to five hundred pallet moves between receiving and staging. During peak weeks, that more than doubled. Twelve sounded like an unlucky number to him, so he rounded up to fourteen.
Less than a year later he called back, sounding conflicted. In slow season, half the fleet sat napping at the charging stations all day. In peak season, the receiving dock still jammed. Not because there weren't enough robots — the post-mortem showed the robots queuing behind each other at aisle intersections and chargers. He'd bought the wrong number for the wrong reasons. That is the most common script in this business: pick a fleet size by gut feel, discover the problem after the invoice is paid.
The direction is backwards. Don't start with a robot count and check whether it's enough. Take your task volume apart first, then work backwards to the number you actually need.
What one robot really gets done in a day
Put a single AMR under the microscope. Its day is not 24 hours of hauling. Its time gets eaten by three things: driving, waiting at load and unload, and charging.
The single-trip cycle time is where every calculation starts. Distance from pickup to drop-off, the empty return leg, whether a forklift is standing by to load it, whether it has to yield in a narrow aisle, how long the WMS takes to dispatch the next task — add all of that and you get the true cost of one move. Don't use the vendor's lab numbers. Those come from an empty test floor with no traffic and a full battery. Walk your own floor with a stopwatch and take an honest average.
The capacity math is one sentence: tasks per robot per day equals productive minutes per day divided by minutes per task.
Walk through it with round numbers and it clicks. A full move — there and back plus waiting at both ends — routinely takes on the order of ten-plus minutes. After charging and dispatch overhead, a robot gets something like the mid-teens of productive hours a day. That puts one robot's daily output in the dozens of tasks. Most people hear that and say it's less than they expected. They're right to be surprised. AMRs don't get tired, but they aren't fast either — under load they move about as quickly as a person walking briskly, and waiting plus yielding eats the rest.
Charging is where buyers get burned. Everyone plans around the nameplate battery life. Nobody in real operations runs a battery to empty and then charges it — robots top up in the gaps between tasks, and how good the fleet software is at opportunity charging decides how much capacity that overhead eats. Same robot, bad dispatch versus good dispatch, and the daily output gap is real. Evaluating the robot without evaluating the dispatcher is like buying half a machine.
One more judgment call that changes the math: free-navigating AMRs pool their capacity dynamically, so the same task volume usually needs fewer of them than fixed-path AGVs running loops. But their path conflicts grow faster than linear as you add units — which is exactly what that Ontario building learned the expensive way.
Overbuying and underbuying hurt in different ways
Overbuying first. A pallet AMR, robot plus implementation, runs into the hundreds of thousands of dollars per unit. Two extra idle robots is serious money sitting on the floor doing nothing. The sneakier cost: more robots turn every intersection, charger, and load station into a queue. Robots wait on each other, and total system throughput can actually fall as the fleet grows. I've watched a building get slower after adding robots — the dispatcher couldn't resolve that many path conflicts, they had to throttle the fleet, and they'd paid good money for a slower system.
Underbuying is the other pain. Quiet most days, then peak hits and the line jams. In a 3PL the cost of a jam is measured in customers. The SLA is the SLA — a miss means penalties, and a bad miss means a lost account. When that Ontario building jammed its receiving dock during peak, they threw a dozen-plus temp workers and manual pallet jacks at it. The labor bill plus the delay penalties cost more than two extra robots would have. The owner later told me he wished he'd spent less energy on whether twelve was a lucky number.
So redundancy isn't "buy two extra for peace of mind." It has a logic. Redundancy covers two things: breakdowns and maintenance windows. Whether your service response is measured in hours or days decides how much you carry. For seasonal businesses, size the base fleet to the regular peak — the busy you actually see most of the year, not the two craziest weeks. Cover the extreme peak with temp labor and overtime. Don't buy a year's worth of robots for two weeks of chaos. If there's one sentence in this article worth money, it's that one.
Run the numbers in this order
Pull twelve months of task data and plot daily pallet moves. Find two numbers: the regular peak, the busy level you hit often, and the extreme peak, which you just need to be aware of. Size the base fleet to the regular peak.
Then measure one robot's cycle time and daily output in your building — your distances, your wait times, your stopwatch, not the brochure. Base fleet equals regular-peak daily tasks divided by per-robot daily output. If your volume swings hard day to day, add a cushion on top, on the order of twenty to thirty percent.
Add redundancy separately. Start from your real equipment uptime and your actual service response time. N+1 is the floor; long maintenance windows push it up.
The last step matters most: don't buy the whole fleet at once. Deploy the first batch at the calculated number, run it for a month or two, and watch the real data — task completion rate, average wait at load stations, how often robots queue at chargers — then decide whether to add units. If that Ontario operator had started with eight robots for one quarter and added two after seeing the data, he'd have spent nearly half less and ended up with a better-running building. There's no "if only" in this business. There's only the invoice.
The formula, in one line:
Fleet size = (regular-peak daily tasks × fluctuation factor) ÷ tasks per robot per day + redundancy units
One piece of advice to close: plug in your own measured numbers. Don't divide average volume by ideal speed. The formula won't lie to you. The gut-feel number always does.
