We keep the hardware, the software and the maintenance risk. Customers buy patrol-hours and inspection-hours — a monthly outcome, not a capital asset.
Charging schedules, firmware updates, breakdowns, spare parts, an operator trained to babysit a machine nobody on staff understands. Every buyer of a capital robot becomes, by accident, a fleet operator. Most don't want that job.
Patrol-hours — a perimeter walked, on schedule, logged and reviewable.
Inspection-hours — a route checked, anomalies flagged, no person on the catwalk.
Alert response — priced per incident triaged, not per robot deployed.
Customers never see a maintenance ticket or a firmware version number. They see a dashboard and a bill.
A rental business lives or dies on uptime and iteration speed. Owning the full stack — not integrating someone else's chassis and someone else's controller — is what makes that maintainable at fleet scale.
Route mapped, schedule set, unit shipped and commissioned remotely in days, not months.
Every deployed unit's battery, route completion and anomaly flags, watched from one ops screen.
Firmware and policy updates pushed fleet-wide; truck-roll only for hardware faults.
Every additional unit adds marginal monitoring cost, not marginal headcount. This is the structural reason the model scales like software, not like a hardware reseller.
| Driver | Direction | Why |
|---|---|---|
| Cost per patrol-hour | Falls with scale | Hardware and ops-monitoring cost amortise across more billed hours |
| Price per patrol-hour | Anchored to labor cost replaced | Priced against the manual round or guard-hour it substitutes, not invented |
| Utilisation | Rises as routes stack per unit | One robot can serve multiple scheduled routes across a shift |
| Churn risk | Falls with contract length | Annual site contracts replace one-off unit sales |
Fast sales cycle, clear ROI vs. a guard-hour
Higher price per hour, longer contracts
Highest ACV, slowest to close — entered once the fleet-ops model is proven