How to Write a Service Robot RFP — Procurement Template for Facility Managers

A facility director at a 400-room convention hotel received three vendor responses to her RFP for 8 delivery robots. All three proposed units met the "autonomous navigation, 22-lb payload, 8-hour battery" specs she had listed. Six months after deployment, two of the three robot types were operating at 40% utilization — not because the robots malfunctioned, but because the hotel's fire doors lacked automatic openers (a $14,000 retrofit she hadn't budgeted), the Wi-Fi in the basement-level service corridors had dead zones that caused navigation failures on 30% of delivery runs, and one vendor's fleet management software couldn't integrate with the hotel's work-order system.

The RFP wasn't wrong. It was incomplete. It described the robots, not the operating environment.

Most facility managers purchasing their first service robots bring procurement experience from conventional equipment categories — HVAC chillers, commercial kitchen appliances, janitorial service contracts. Those RFPs are built around spec sheets and service-level agreements that assume the equipment operates in a controlled, static environment. Service robots operate in dynamic human spaces with unpredictable obstacles, wireless network dependencies, door and elevator interfaces, and social dynamics (guests who jump in front of the robot to "test" its obstacle avoidance, staff who unplug charging stations to use the outlet for a vacuum cleaner). An RFP that doesn't account for these variables produces technically compliant responses that fail operationally.

This guide provides the RFP template that procurement teams at deployed facilities have refined through multiple purchasing cycles — with the questions that expose vendor gaps before the contract is signed.

The 7 Sections a Service Robot RFP Must Include (And the 3 Most RFPs Miss)

A service robot RFP has ten possible sections. Seven are mandatory. Three are commonly omitted — and their omission is the root cause of 80% of post-deployment integration failures, per aggregate data from the facilities management teams interviewed for this guide.

The mandatory seven:

1. Operating Environment Specification — not the robot, the space
2. Integration Requirements — doors, elevators, Wi-Fi, work-order systems
3. Performance Guarantees — with defined failure modes and remedies
4. Deployment and Training Scope — site mapping, staff training, change management
5. Total Cost of Ownership Schedule — hardware, software, maintenance, consumables, Year 1-5
6. Service-Level Agreement — response times, spare parts availability, uptime guarantees
7. Vendor Financial and Operational Stability — how long has the vendor been deploying at your scale?

The three commonly omitted:

8. Staff Impact Assessment — which roles change, which roles are eliminated, and the transition plan
9. Data Ownership and Privacy Terms — who owns the operational data the robots generate
10. Exit and Decommissioning Clause — what happens to the robots, data, and software licenses if the contract is not renewed

The omission pattern is not random. Procurement teams focus on Sections 1-4 (the visible deployment) and 5-7 (the contractual protection). Sections 8-10 address what happens after deployment — the operational and organizational consequences — and these are the sections where post-deployment friction concentrates.

Section 1: Operating Environment Specification

This is the section that distinguishes a service robot RFP from any other equipment procurement. Instead of specifying what the robot must do in isolation, you specify the environment in which it must operate. The robot's capabilities are the vendor's problem — your job is to describe the space accurately enough that the vendor can determine whether their product will function.

Required Specifications:

Attribute	Detail Required	Why It Matters
Floor surface type and condition	Tile, carpet, epoxy, polished concrete, transitions between types, floor unevenness >3mm	Robots with differential-drive wheelsets handle carpet thresholds differently than omnidirectional. A robot that works on the lobby's polished marble may fail on the kitchen's textured tile.
Door types and automation status	Fire doors (width, weight, closer mechanism), swing doors, sliding doors, revolving doors. Which have automatic openers? Which require robot-to-door communication?	The budget planning framework identifies automatic door retrofits as the single most commonly overlooked facility cost — $1,200-2,500 per door.
Elevator model and integration readiness	Manufacturer, model year, existing IoT/access-control integration, elevator bank configuration	Elevator IoT modules cost $3,000-8,000 per bank. If the elevator cannot be integrated, multi-floor delivery robots are non-viable.
Wi-Fi coverage map	Signal strength (dBm) at all proposed operating zones, AP locations, channel congestion at peak hours	Dead zones cause navigation failures. A site survey costs $800-2,000 — include the requirement in the RFP so vendors factor it into their proposal.
Corridor width and obstacle density	Minimum corridor width along all planned routes, typical obstacle density (cleaning carts, linen bins, room service trays) at peak hours	A robot that needs 1.2m of clearance cannot operate in a 1.1m corridor with housekeeping carts parked along one side.
Operating hours and peak-load periods	Facility hours, peak robot-demand windows (check-out, meal service, event changeover), and the required throughput during those windows	The fleet management guide addresses how fleet sizing must account for peak demand, not average demand. A fleet that meets average throughput will fail at checkout hour.

Sample RFP Language:

"The deployment environment is a 320,000 sq ft full-service hotel spanning 18 floors. Guest corridors are 1.4m wide with housekeeping carts occupying 0.5m of that width during 9 AM-2 PM daily. The facility has 12 fire doors (2-hour rated, 1.2m width, hydraulic closers) between guest room wings — 4 have existing automatic openers connected to the fire alarm system, 8 require vendor-proposed integration. Elevators are Otis Gen2 (2018), 4-bank configuration, no existing IoT integration. Wi-Fi is Aruba AP-515 mesh (Wi-Fi 6), signal strength ≥ -67 dBm in all guest corridors, -72 dBm in basement-level service corridors. Proposals must include cost and timeline for elevator IoT integration and fire-door automation, or a technical demonstration that the proposed robots can traverse the specified doors without automation."

Section 2: Integration Requirements

Service robots do not operate in isolation. They require connectivity, fleet management software, and integration with existing facility systems. Specifying these requirements in the RFP prevents the "the robot works but we can't manage it" outcome.

Integration Checklist:

• Wi-Fi / Network: Does the robot require a dedicated SSID? Bandwidth per unit? Latency tolerance? Does it function on Wi-Fi 6, Wi-Fi 5, or specific channel configurations?
• Fleet Management Platform: API availability for integration with work-order systems (CMMS), building management systems (BMS), or property management systems (PMS). The multi-site deployment guide details how centralized fleet oversight depends on API-level integration.
• Elevator Control: Protocol (BACnet, Modbus, vendor-proprietary), certification requirements for life-safety integration
• Access Control / Security: LDAP/SAML for operator authentication, audit logging
• Data Export: Can operational data (utilization, battery cycles, navigation failures, task completion rates) be exported to the buyer's analytics platform?

Sample RFP Language:

"The successful vendor must provide a documented REST API for fleet management integration with the buyer's existing CMMS platform (IBM Maximo 7.6). The integration must support: (1) task creation and status tracking, (2) real-time robot location and battery status, (3) maintenance alerting with severity levels. Vendor must provide an integration-test environment for buyer's IT team 30 days before deployment. License for fleet management software must be perpetual, not subscription-terminable, with source-code escrow in the event of vendor insolvency."

Section 3: Performance Guarantees

Specify what "works" means in operational terms, with defined measurement methods and remedies for non-performance.

Performance Metric	Measurement Method	Minimum Acceptable	Remedy if Not Met
Navigation success rate	% of delivery/cleaning runs completed without human intervention	95%	Vendor deploys additional site-mapping and recalibration at no cost
Obstacle avoidance	Incidents per 1,000 operating hours where robot contacts person or fixed object	<2	Vendor upgrades sensor firmware; if unresolved after 30 days, 10% price reduction
Battery endurance	Operating hours per full charge under specified load and route conditions	≥90% of quoted spec	Vendor provides supplemental battery or replacement unit at no cost
Downtime	Hours of non-operation (excluding scheduled maintenance) per month	<8 hours	SLA credit: 5% of monthly fee per 8-hour increment
Mean time to repair	Hours from service-request submission to functional restoration	<24 hours (business hours)	Emergency spare unit provisioned at vendor cost after 48 hours

The vendor evaluation framework provides a 12-point assessment methodology that complements these contractual performance guarantees — the framework evaluates vendor capability before the contract; the guarantees enforce it after.

Section 4: Deployment and Training Scope

Specify exactly what the vendor must deliver beyond hardware delivery. This prevents the "we dropped off the robots, good luck" scenario.

• Site mapping: Number of floors, total square footage, timeline, who provides escorts during mapping
• Charging station installation: Electrical requirements, who performs the work (vendor or buyer's electrician), warranty on installation
• Staff training: Number of staff, role types (operators, supervisors, IT), training format (on-site, remote, train-the-trainer), training materials (language, format)
• Change management: Communication templates, staff FAQ, feedback collection mechanism. The change management playbook details the soft costs and failure modes of workforce integration.
• Pilot program: Duration, success criteria, go/no-go decision authority. The structure should follow the pilot program methodology to validate assumptions before full-scale deployment.

Section 5: Total Cost of Ownership Schedule

Require vendors to populate a standardized TCO table covering Year 1 through Year 5. The TCO guide covers lifetime cost modeling, and the RaaS financing models guide addresses lease-vs-buy economics.

Cost Category	Year 1	Year 2	Year 3	Year 4	Year 5
Hardware (purchase or lease)
Deployment (mapping, installation)
Facility modifications
Software licensing
Maintenance contract
Battery replacement
Consumables
Training (initial + ongoing)
Total

Why This Matters: The RFP That Paid for Itself

A regional hospital network issued an RFP for 12 delivery robots across three facilities. Their previous equipment procurement cycle (MRI machines, patient monitors) had conditioned them to accept vendor responses at face value. This time, they included the operating environment specification from Section 1 — specifically, the requirement that robots traverse 1.1m corridors with gurneys occupying 0.7m of width during 7-9 AM patient transport hours.

Two of five vendors withdrew their proposals after reading the environment spec. A third vendor proposed a unit that failed the corridor-width test during the on-site demonstration — their robot needed 1.3m clearance and the hospital's narrowest corridor was 1.1m. The hospital avoided a $340,000 deployment that would have failed within the first week. The RFP cost $8,000 in staff time to write. It saved $340,000.

The lesson is not that vendors are dishonest. It's that vendors answer the questions you ask. If you don't ask about 1.1m corridors with gurneys at 7 AM, they won't volunteer that their robot needs 1.3m of clear width. The RFP is not a formality — it is the primary tool for exposing the gap between vendor claims and operational reality.