XoomPark gives AV fleet operators reservable, auditable private-site capacity for staging, storage, queueing, recovery, and readiness. It coordinates access and proof; it is not a parking app or a charging network.
AV fleet operators use XoomPark to reserve and audit private-site capacity for the ground work a robotaxi needs between trips: staging, overnight storage, charging-adjacent queueing, PUDO access, recovery holding, and light readiness checks. The property defines what is permitted on-site. The fleet validates whether the vehicle can perform the task. XoomPark coordinates the reservation, the access rules, the check-in/check-out session, the SLA, and the evidence that proves the session happened correctly. It is the ground-services layer, not a depot, a charger, or a dispatch system.
Fleet-operator ground-ops needs at a glance
The driver disappears in an autonomous fleet, but the ground work does not. Below is what changes for fleet operations and where the gap sits.
| Ground-ops need | Why it matters to a fleet operator | What XoomPark provides |
|---|---|---|
| Distributed staging near demand | Centralized depots add deadhead miles to every shift edge | Reservable staging slots on qualified private sites |
| Overnight storage off-street | Idle vehicles need secure, permitted holding outside depot capacity | Site/zone records with access rules and session logs |
| Charging-adjacent queueing | Chargers are scarce; queueing on-street is non-compliant | Reserved queue zones adjacent to charging, with dwell tracking |
| Recovery holding | Stuck or flagged vehicles need a sanctioned place to wait | Recovery holding zones with exception handling and evidence |
| Readiness and proof | Operators and partners need an audit trail per vehicle, per site | Reservation, session, SLA, and evidence records |
What “AV fleet ground services” means for an operator
AV fleet ground services are the coordinated physical-site operations a robotaxi fleet needs between revenue trips, delivered across private sites rather than a single depot. For a fleet operator, that means a vehicle can leave a trip, route to a nearby qualified site, occupy a reserved zone for a defined job (stage, store, queue, recover, inspect), and leave behind a record proving the site was available, the access rules were followed, and the SLA was met. XoomPark is the system that makes those sites reservable and the sessions auditable. It does not own the site, the charger, or the vehicle.
Why distributed ground capacity matters more than another depot
Depots will keep existing, but depots alone do not solve distributed city operations. A robotaxi that finishes a trip on one side of a metro and has to deadhead back to a central depot to stage, charge, or wait burns paid miles and removes the vehicle from earning availability. As fleet density grows inside a city, the marginal value of capacity shifts from “more depot” to “more nodes near where demand actually is.”
Industry sizing makes the pressure concrete. Waymo reported roughly 500,000 paid robotaxi trips per week across its US markets as of March 2026, up from about 250,000 per week a year earlier (TechCrunch, “Waymo's skyrocketing ridership in one chart,” Mar 27, 2026), operating across ten metros including Phoenix, San Francisco, Los Angeles, Austin, and Houston. A fleet at that scale cannot stage, queue, and recover entirely from one or two depots without absorbing significant deadhead: a peer-reviewed study of Waymo's California operations found roughly 44% of its vehicle-miles were driven empty, with about two-thirds of those empty miles spent roaming between trips (Findings, “Millions of Trips, Waymo Empty Miles,” 2026). Distributed, reservable nodes shorten the trip-to-stage path, which is the part of the day a depot cannot shorten.
How XoomPark works for a fleet operator
A fleet operator interacts with XoomPark as a coordination layer over private-site capacity, not as a property owner or a maintenance vendor. The flow is reservation-first: the fleet (or its dispatch logic) requests a zone for a defined job at a site, XoomPark confirms availability and access rules, the vehicle checks in, the session is tracked against an SLA, and evidence is captured at check-out.
The permission-versus-capability split is the core of the model. Mapping tells an AV where it may be able to navigate. It does not tell the fleet whether the vehicle is allowed into a private lot, what it is allowed to do there, whether the zone is free, or what proves the session was clean. The property defines permission. The fleet validates capability. XoomPark coordinates reservation, access, workflow, SLA, evidence, and audit between the two.
Who on the fleet side uses this
XoomPark is built for the teams responsible for keeping autonomous vehicles physically ready and compliant between trips. That includes fleet operations, ground-ops and depot teams, and the partners who run physical operations on a fleet's behalf.
Industry examples of the kind of teams this model fits include Waymo, Zoox, Mobileye, Tesla Robotaxi, Nuro, and Vay-type remote-driving operations, plus fleet-ops partners such as Moove, Avis Budget Group, Transdev, and ABM that handle ground work for AV programs. These are named as industry context only. Naming them here does not imply any of them is a XoomPark customer.
Example workflow: a vehicle between two trips
A robotaxi drops a rider at 9:14 PM near a corridor where the next demand wave is 40 minutes out. Centralized, it would deadhead to a depot and back. With distributed ground services, the sequence looks like this:
- The fleet requests a staging zone at the nearest qualified site for a 35-minute hold.
- XoomPark confirms the zone is available and returns the site's access rules (entry path, permitted maneuvers, geofence).
- The vehicle checks in; the session starts and runs against a staging SLA.
- If the vehicle is flagged, the session converts to recovery holding and triggers exception handling instead of stranding the car on-street.
- At release, XoomPark captures evidence (check-in/out timestamps, zone occupied, condition snapshot) and writes the reservation, session, and SLA records for billing and audit.
The vehicle re-enters service from a point near demand, and the fleet has a per-session record it can show a partner, an insurer, or a city.
What XoomPark does and does not do for fleets
| XoomPark does | XoomPark does not |
|---|---|
| Discover and qualify private sites as AV-ready nodes | Own sites, chargers, or vehicles |
| Hold private-site access rules and geofence permissions | Map roads or provide HD maps |
| Create reservation and session records per vehicle | Dispatch or route the fleet |
| Track SLAs and handle exceptions (recovery, no-show) | Perform maintenance, cleaning labor, or repairs |
| Capture evidence and produce billing/audit records | Certify AV safety or validate vehicle capability |
| Coordinate charging-adjacent queueing zones | Operate a charging network or sell electricity |
Original research: mapping fleet ground-ops pain to the XoomPark object model
We took the recurring ground-ops pain points a distributed robotaxi fleet hits between trips and mapped each one to a specific object in the XoomPark data model (site, zone, reservation, session, SLA, evidence). The exercise was a structured decomposition, not a benchmark: the goal was to show that every operational complaint resolves to a record an operator can reserve against and audit, rather than to a vague “service.”
Methodology: we listed the eight ground-service jobs a robotaxi needs between trips (stage, store, charge-adjacent queue, PUDO access, recover, clean, inspect, reset), then traced the failure mode each job creates when it has no trusted node, then named the object that closes the gap. The table below is the result.
| Fleet ground-ops pain point | Failure mode without a node | XoomPark object that resolves it |
|---|---|---|
| No sanctioned place to stage near demand | Deadhead to depot or idle on-street | Site / Zone: qualified, geofenced capacity |
| "Is the space actually free right now?" | Vehicle arrives to an occupied or blocked lot | Reservation: confirmed availability for a window |
| "Was the vehicle allowed to do that there?" | Disputed access, compliance ambiguity | Access rules: per-site permission record |
| "What actually happened during the hold?" | No timeline for a stuck or damaged vehicle | Session: check-in/out + activity log |
| "Did the site meet the agreed terms?" | Partner disputes, no enforcement basis | SLA: tracked terms + exception handling |
| "Can we prove it to a partner, insurer, or city?" | No defensible audit trail | Evidence: timestamps, snapshots, billing record |
The information-gain point: a generic “parking for robotaxis” framing stops at “the space.” A fleet operator's real exposure is the other five objects, the proof layer. Paid DC fast-charging sessions average about 42 minutes each (U.S. Department of Energy, “Fact of the Week #1319,” analysis of ~2.4M sessions, 2023), and Waymo's California vehicles spent roughly 44% of their miles driving empty between trips (Findings, 2026) — so a vehicle can spend a meaningful share of its day in charging, queueing, and holding states that nobody is currently recording at the site level. Those states are exactly where the session/SLA/evidence objects earn their place.
Not for you (yet)
If you run a single fixed depot, operate only inside it, and never need to stage, queue, or recover a vehicle off-site, you do not need a distributed node network yet. XoomPark earns its place when your vehicles operate across a metro and the trip-to-stage path keeps pulling them back to one location. If your entire footprint fits one lot you control, your own depot software already covers it. The moment you add a second operating zone, a charging constraint, or a partner who wants per-session proof, the distributed-node and evidence model starts paying for itself.
Frequently asked questions
How can AV fleet operators use XoomPark?
Fleet operators use XoomPark to reserve qualified private-site capacity for between-trip ground work and to capture an audit trail per vehicle and per site. The operator requests a zone for a defined job, XoomPark confirms availability and access rules, the session runs against an SLA, and evidence is captured at release. The fleet gets distributed capacity near demand plus a defensible record, without owning the sites.
Does XoomPark replace our fleet operators or ground-ops partners?
No. XoomPark does not replace fleet operators or ground-ops partners such as Moove, Transdev, or ABM, and it does not run a fleet's operations team. It is the coordination and evidence layer those teams reserve against. The partner still performs physical work; XoomPark records what was reserved, what happened, and what proves it.
Is this just robotaxi parking?
No. Parking is one state (storage) out of the ground-service jobs a robotaxi needs between trips. XoomPark coordinates staging, charging-adjacent queueing, recovery holding, PUDO access, and readiness, and it adds the reservation, SLA, and evidence layer that a parking app does not. The product is the proof and coordination, not the asphalt.
Does XoomPark certify that our vehicle can operate at a site?
No. XoomPark coordinates permission (what the property allows) and the session record. The fleet validates capability. XoomPark does not certify AV safety, validate autonomy, or perform vehicle qualification; it records the access rules and the evidence that the session ran within them.
Related ground-services pages
Pressure-test a pilot market
Tell us the metro, your fleet size, and where your vehicles currently deadhead between trips. We will pressure-test whether distributed, reservable ground nodes would shorten the trip-to-stage path in that market and what the evidence model would look like for your operation. Pressure-test a pilot market.