Off-Depot Fleet Support: The Distributed Layer Robotaxi Depots Can't Replace

Off-depot fleet support is the distributed ground-service capacity a robotaxi fleet uses between trips, away from its central depot. A depot is where vehicles get deep service, overnight storage, and a full reset. But a fleet spread across a metro spends most of its idle minutes nowhere near that depot. Off-depot support puts staging, charging-adjacent queueing, recovery holding, light cleaning, and inspection on private sites near where rides actually start and end, so vehicles don't deadhead all the way back to one building to do simple ground work. XoomPark coordinates the reservation, access, workflow, SLA, and evidence layer across those nodes.

Why one central depot can’t operate a city-scale fleet

A depot is built for throughput and depth, not proximity. It centralizes heavy maintenance, parts, overnight storage, and fleet reset in one well-equipped building. That model works for the jobs that genuinely need a workshop. It breaks for the jobs that just need a trusted place to wait, charge, or get wiped down, because the depot is, by design, in one location while demand is spread across the whole metro.

The cost is deadhead: empty miles a vehicle drives to reach the depot and return. Industry analyses of robotaxi operations consistently flag non-revenue repositioning as a major efficiency drain: an analysis of CPUC data covering 86 million miles over roughly 14 million Waymo trips (Aug 2023–Dec 2025) found only about 54% of California robotaxi miles carried a passenger, leaving roughly 43–46% as deadhead, two-thirds of it vehicles roaming while waiting for a request (Abdelhalim, Findings, 2026). Every minute a car spends driving to a depot for a two-minute cleaning is a minute it is neither earning nor available. As fleets scale from hundreds to thousands of vehicles in a metro, the depot becomes a bottleneck and a magnet for empty miles.

What “off-depot” actually means in fleet operations

Off-depot means any ground work a vehicle does while it is not at its home depot. It is not a smaller depot and it is not parking. It is a set of short, repeatable jobs handled at private sites positioned near demand: lots, structures, yards, and underused commercial land that can be made AV-ready.

The distinction matters because depots and nodes solve different problems. A depot solves depth: the workshop, the lift, the parts inventory, the overnight footprint. A node solves distribution and latency: getting a vehicle a charged stall, a staging slot, or a recovery hold without a metro-crossing deadhead. The property defines permission (where the vehicle may go and what it may do there). The fleet validates capability. XoomPark coordinates reservation, access, workflow, SLA, evidence, and audit so the fleet can trust that an off-depot session happened correctly.

Our depot-vs-node cost and latency model

We built a simple decision model for when a fleet should send a vehicle to the depot versus the nearest off-depot node. The variable that dominates is deadhead: the empty miles and minutes to reach the service location. We frame it as a per-event comparison, not a facilities-planning exercise.

The model compares two paths for a given between-trip job (say, a charge top-up plus a quick interior wipe):

• Depot path cost = (deadhead miles to depot × cost per mile) + (deadhead minutes × opportunity cost of an idle revenue vehicle) + queue wait at a centralized facility.
• Node path cost = (deadhead miles to nearest node × cost per mile) + (deadhead minutes × opportunity cost) + node session fee.

When the nearest node is meaningfully closer than the depot, the node path wins on both miles and minutes even after paying a session fee, because the opportunity cost of an idle robotaxi during peak demand is high. As an illustrative example, if a depot is 6 miles away and the nearest node is 1.5 miles away, the node path removes roughly 9 round-trip empty miles per event (simple distance arithmetic; the dollar value depends on the fleet's own cost-per-mile and idle-vehicle opportunity cost, which it supplies as model inputs). Multiply that by the number of charge/clean/hold events a busy vehicle needs per day and the empty-mile reduction compounds across a fleet.

Methodology note: these figures are a model framework, not measured XoomPark results. XoomPark has no public operating history. The point of the model is the structure of the decision (deadhead-dominated), not the specific numbers, which a fleet plugs in from its own cost-per-mile and demand data. Per-event savings validated against a live deployment will follow once pilot data exists; until then the model stands as a framework, not a measured result.

The between-trip jobs a node handles

Between two paid trips, a robotaxi needs a short, predictable set of ground jobs done. We mapped the work a fleet still needs after the driver disappears, and most of it does not require a depot:

• Staging: a trusted place to wait near demand instead of circling or curb-idling.
• Charging-adjacent queueing: holding orderly access to charging so vehicles aren't blocking or hunting for a plug.
• Recovery holding: a safe, accountable place to hold a vehicle flagged for an issue until the fleet decides next steps.
• Light cleaning: a quick interior wipe and trash removal between riders, not a detail bay.
• Visual inspection: a documented look-over with evidence captured.
• PUDO access: controlled pick-up/drop-off on private sites.
• Overnight storage: off-depot parking when the home depot is full or far.
• Service coordination: sequencing the above and producing an audit trail.

A central depot can technically do all of these. It just can’t do them close to where the vehicle currently is. That gap is what off-depot support fills.

Who needs off-depot fleet support

You need off-depot support when your fleet operates across a metro and your idle vehicles spend real time far from your depot. Fleet operators (the teams running Waymo, Zoox, Nuro, or similar deployments) feel it first as deadhead and depot congestion. Fleet-ops partners and infrastructure teams (Moove, Avis Budget Group, Transdev, ABM, and comparable operators) feel it as the cost of standing up enough physical footprint to keep vehicles available. Investors feel it as utilization: every empty mile to a depot is margin lost. None of these groups are XoomPark customers; they are the operating context the model is built around.

If you run a small pilot from a single building and your vehicles rarely stray far from it, you do not need a distributed node network yet. The depot is enough.

Example off-depot workflow

A robotaxi finishes a trip downtown at 5:10pm during peak demand. Its battery is at 30% and the cabin needs a quick wipe. Sending it 6 miles back to the depot would burn 12+ empty round-trip miles and pull it offline for the most valuable 25 minutes of the day.

Instead, the fleet's system queries available nearby capacity. XoomPark returns the nearest AV-ready node (1.4 miles away) with an open charging-adjacent stall and a light-clean slot, plus the site's access rules. The fleet reserves the session. The vehicle arrives, checks in against the reservation record, charges while held in the queue, gets a documented wipe-down, and a visual inspection is captured as evidence. It checks out with a complete session record (time, services, photos) for billing and audit, and is back earning within the same demand window. The depot never saw it.

What XoomPark does and does not do

XoomPark is the AV ground-services layer for the off-depot work above. It does not run the depot, own the chargers, clean the cars, or operate the fleet.

When off-depot support is the wrong fit

If you run a single fixed depot, your fleet is small, and vehicles almost never operate far from that building, you do not need a distributed node network. Your deadhead is already low and a node layer adds coordination overhead without a payoff. The same is true if your operation is fixed-route and predictable rather than on-demand and metro-wide. Off-depot support earns its keep when distribution and latency are real costs, not when geography is already tight. The exact fleet-size and metro-spread point where node economics turn positive is operator-specific and falls out of a fleet's own deadhead and demand data rather than any published threshold.

Frequently asked questions

Related ground-services pages

Pressure-test a pilot market

Have a metro where deadhead-to-depot is eating utilization? Pressure-test a pilot market with XoomPark and model the off-depot node math against your own cost-per-mile and demand data.