Delivery Robot Cost per Drop

Every delivery robot proposal contains the same sentence in some form: "replaces a staff member's delivery runs". It is a true statement and a useless one, because the cost comparison depends entirely on how many runs the robot absorbs and how close to theory the vehicle actually operates in a building with lifts, doorways, and a busy lobby at nine in the morning.

The useful reframing is cost per drop at a given volume. That single number is comparable across robot, staff, and courier, it exposes the fixed-cost problem immediately, and it makes the negotiation with a vendor about the right thing: not the unit price, but the volume the deployment can realistically support.

The Five Cost Lines in a Robot Drop

A cost per drop model has five lines, and only the first is visible in a quotation.

Cost line	Typical annual value	Behaviour
Capex amortisation	$8,500 per unit (5-year life, $34,000 unit)	Fixed. Does not move with drops.
Energy	$380 to $620 per unit	Variable, but weakly. Two extra hours of running adds roughly 15%.
Maintenance and service	$2,400 to $3,600 per unit	Half fixed, half variable. Wear scales with distance, not with drops.
Supervision and exception handling	$1,800 to $4,200 per unit	Strongly variable. Rises with drops, then plateaus with experience.
Dock, space and network	$900 to $1,600 per unit	Fixed, and easy to forget because it lands in the facilities budget rather than the project budget.

The first, third, and fifth lines are fixed. That is the entire source of the utilisation effect. On a $34,000 unit over five years, the fixed annual burden including service and dock space is roughly $12,500. Every drop the unit performs divides into that number, and there is no way around it except performing more drops.

The supervision line is where models diverge most between theory and practice. A robot that completes 95% of its drops unattended still needs a human to resolve the 5%: a recipient who does not answer, an elevator that refuses the call, a package too large for the shelf, a floor that has been cordoned off for maintenance. At 20 drops a day that is one exception, which a part-time operator absorbs. At 80 drops a day it is four, which is a staffed exception desk whether or not anyone has budgeted for one.

Cost per Drop as a Function of Volume

Take a single unit with the cost lines above, and compute cost per drop at four realistic volumes. These volumes assume an average service cycle of 9 to 12 minutes door-to-door, which is consistent with a mid-rise hotel, a large office campus, or a hospital wing.

Drops per day	Operating days	Annual drops	Fixed + variable	Cost per drop
20	312	6,240	$12,500 + $1,900 = $14,400	$2.31
40	312	12,480	$12,500 + $3,100 = $15,600	$1.25
60	312	18,720	$12,500 + $4,600 = $17,100	$0.91
80	312	24,960	$12,500 + $6,800 = $19,300	$0.77

Read the table for what it says about the business case rather than for the absolute numbers. Tripling volume from 20 to 60 drops a day cuts cost per drop by 61%. Tripling volume again from 60 to 180 would cut it further but by much less, because the fixed line is no longer dominant and the variable lines have taken over. The curve is steep where it matters and flat where it does not, and the operator's whole job is to know where on the curve they will actually land.

Note also that the marginal cost of the twentieth drop and the sixtieth drop are almost identical, at roughly $0.25 to $0.30 including supervision. The difference in average cost is entirely the fixed line being spread over more work. This is why adding a second unit to an under-utilised deployment makes the averages worse, not better, and why the correct response to low utilisation is a route redesign rather than more hardware.

The Utilisation Trap

Pilot programmes systematically overstate utilisation, and they do it in three predictable ways.

• Pilot demand is not baseline demand. During a trial, staff route work to the robot deliberately because they are watching it. Once the novelty fades and the robot is simply part of the operation, task allocation reverts to habit, and the robot's queue thins.
• Pilot scope creeps wider than production scope. Trials often carry documents, laundry, and internal mail as well as guest deliveries. The production scope is frequently narrower because a different department owns each of those flows and none of them wants to depend on a robot they did not buy.
• Pilot hours are not trading hours. A four-week trial that runs through a quiet period produces a different volume profile than the December peak, and a deployment sized on the quiet period will be capacity-constrained in the busy one.

The practical defence is to state the volume assumption explicitly in the business case and then test the case at 60% of it. A deployment that still pays back at 60% of the assumed volume is robust. One that only works at the assumed volume is a forecast, not a business case.

Robot Drop Versus Staff Run Versus Courier

The comparison that matters commercially is against the alternatives the operation would actually use, fully loaded.

	Robot, 40 drops/day	Staff runner	External courier
Cost per drop	$1.25	$3.10 to $4.60	$6.50 to $14.00
Basis	Amortised capex + service + supervision	Loaded hourly rate × cycle time, with idle time included	Per-ticket rate, zone dependent
Availability	Shift hours, needs a clear floor	Shift hours	Contracted window
Marginal cost of one more drop	$0.25 to $0.30	Effectively zero until the shift is full	Full ticket price
Ceiling	Route and lift capacity	One person's shift	Contract volume
Peak behaviour	Queues, absorbs poorly without a second unit	Overtime or a second person	Rate premium or refusal

The staff comparison deserves care, because the loaded rate is where most proposals cheat. A runner on a $19 hourly wage at 1.35 for benefits and payroll is $25.65, and a five-minute round trip plus walk-back is not five minutes of productive work: it is an interruption to whatever else that person was doing, and the real cost includes the context switch. That is why the fully loaded staff figure used by operations teams, $3.10 to $4.60 per drop, is higher than the naive wage-time multiple, and why the robot wins on cost per drop far earlier than expected.

But the staff comparison also conceals a benefit the robot does not have. A staff runner carries judgement: they notice a spill, they handle a difficult recipient, they adapt when the lift is out. The robot's cost advantage is real and its capability is narrow, and an operation that replaces a runner entirely usually discovers within a month that the judgement went somewhere, and that it now needs to be funded separately.

What Changes the Curve Most

Four variables move the cost-per-drop curve more than any hardware specification, and three of them are properties of the building rather than the robot.

Elevator wait. On a multi-floor site, the lift is usually the dominant term in cycle time. A 45-second average wait against a 6-minute in-floor cycle lengthens the trip by 12%, and during a morning peak the wait can exceed the whole in-floor cycle. Every floor the route touches multiplies the exposure. This is why elevator integration is a cost question before it is a technology question.

Door handoff time. The interval between arrival and confirmed handoff ranges from 40 seconds at a staffed counter to over four minutes at a guest room where the recipient is not ready. On a 40-drop day, moving average handoff from 90 seconds to 180 seconds costs 40 minutes of robot time, which at the margin is 3 to 4 drops a day. The handoff protocol is set out in room delivery handoff design and it is worth more than the vehicle's top speed.

Payload batching. The next section, because it is the largest single lever available to an operator.

Floor surface and traffic. Polished tile and carpet deliver close to rated speed; a busy lobby at opening time does not. Routes that cross a public concourse should be scheduled outside the peak rather than optimised for distance.

Batching: The Lever Nobody Pulls

Almost every pilot runs one drop per trip, because that is how a staff runner works and because a single delivery feels like the natural unit. It is the most expensive way to operate the vehicle.

A D1-class unit with an open shelf stack can carry three to five small parcels within its payload limit. If the route touches two floors and four destinations, a batched trip covers four drops in roughly 14 minutes instead of four separate trips at 9 minutes each, a 61% reduction in robot time per drop. The cost per drop falls by the same proportion on the variable lines and by a larger amount on the fixed line, because more drops are absorbed by the same amortised unit.

Batching has a real limit, and it is the customer's patience rather than the vehicle's capacity. A parcel that waits 25 minutes for the batch to fill before departing is a worse experience than one that leaves immediately, and in guest-facing settings that trade-off is the whole service design. The workable compromise is a departure window: batch within a maximum hold time of 8 to 12 minutes during peak and dispatch immediately off-peak. That single policy change typically lifts effective volume by 40% to 70% without a second unit, and it is free.

The Break-Even Formula

The whole model reduces to one line. Use it before the vendor presentation, not after.

Break-even drops per day = Fixed annual cost / (Cost per staff drop − Variable cost per robot drop) / Operating days

With the numbers used throughout this article: $12,500 fixed, a $3.60 staff cost per drop, a $0.28 variable robot cost per drop, and 312 operating days gives 12,500 / 3.32 / 312 = 12.1 drops per day. That is the volume at which the robot matches a staff runner on cost and nothing else. It says nothing about service quality, peak capacity, or the value of freeing a person from delivery work, and those are legitimate reasons to deploy below break-even. What it does say is that the technology decision is settled at a dozen drops a day, and most of the argument in procurement meetings is about the wrong question.

Contract Structures That Share Volume Risk

Because the business case is so sensitive to volume, the contract matters as much as the model. Three structures are worth asking for.

• Per-drop pricing. A RaaS or managed-service rate expressed per completed drop converts fixed capex into variable cost and moves the utilisation risk to the provider. Rates covering hardware, service, and software typically land between $1.10 and $2.40 per drop at contract volumes, which is competitive with a $1.25 in-house cost at 40 drops and better at 20.
• Minimum-volume clauses with a floor. A minimum annual volume protects the provider's utilisation and usually buys a lower rate. Set the floor at 70% of your conservative estimate, not your pilot figure, and negotiate an explicit mechanism for what happens below the floor rather than leaving it to a renewal conversation.
• Capacity step-ups without new capex. If the operation grows, the second unit should be an addendum at a pre-agreed rate rather than a fresh procurement. Pre-agreeing the second-unit rate is nearly free at signature and expensive later.

The structure to avoid is a fixed lease with a volume commitment set from pilot data and no step-down mechanism. It is the one arrangement that combines the provider's utilisation risk with the operator's demand risk, and it fails in the direction that hurts the operator.

Sizing the Fleet, Not the Unit

The final step is to stop treating this as a single-unit decision. Once you have cost per drop at realistic volume, the fleet size follows from peak demand rather than average demand, and peak demand is what determines whether the service promise holds on the worst day of the week.

Model the peak hour separately. If the peak hour carries 18% of daily volume and the daily volume is 60 drops, the peak is 11 drops in 60 minutes, which at a 10-minute cycle requires two units to clear without queueing. A one-unit deployment sized on daily average will visibly fail for one hour a day, and that hour is the one the customer remembers. The payload and fleet sizing model works the peak-hour arithmetic in more detail, and the ROI framework sets out how to value the service benefit alongside the cost line.

If you want the curve computed against your own floor plan, handoff times, and lift behaviour, send us the route and the current delivery log and we will return a volume, unit-count, and cost-per-drop model. Operators comparing a purchase with a managed service should read buy, lease and RaaS economics before signing either, and anyone still defining the route should start with tray return and table-turn cycles, which have the same cost structure in a different setting.

The One Number to Take to the Meeting

Delivery robot economics is a utilisation problem wearing a hardware costume. The unit price varies by maybe 40% between credible suppliers; the volume assumption varies by 400% between a pilot and a year of production, and the cost per drop is dominated by the second number.

So take one number into the room: the drops per day you can actually sustain in the twelfth month, after the novelty has gone and the task allocation has settled. Compute cost per drop at that volume, and again at 60% of it. If both cases hold, the deployment is sound and the vendor conversation can focus on price. If only the first holds, the honest decision is to fix the route and the handoff policy first, because those are free and they move the curve more than any discount.