The quadruped vendor RFP: questions and red flags

What the demo does not show you

A well-run product demonstration for a quadruped inspection robot is genuinely impressive. The robot walks over uneven terrain, climbs a staircase, stops precisely beneath a mounted sensor target, and returns to its dock autonomously. The demo environment has been mapped, the payloads have been calibrated, and the support engineer standing nearby has run this exact sequence dozens of times.

What the demo does not show: how long the mapping took, what happens when a door is accidentally left closed on the planned route, whether the thermal camera's data exports in a format your CMMS can ingest, and whether the vendor will still sell you spare actuators in year four.

A structured RFP process closes the gap between the demo and operational reality. The questions below are organized by the dimensions that most consistently separate programs that run from programs that stall. They are written to be sent to vendors or asked in structured vendor conversations, and to produce answers that can be directly compared across competing platforms.

Section 1: Payload ecosystem

The inspection value of a quadruped comes from its sensors. The RFP questions in this section expose whether the vendor's payload ecosystem is production-ready or a roadmap.

Q1.1 — Provide a complete list of currently shipping, commercially available payloads for this platform, with part numbers and lead times. Distinguish between payloads the vendor manufactures and payloads manufactured by third parties with a certified integration.

What a good answer looks like: A specific, itemized list with part numbers and realistic lead times. Third-party payloads with named integration partners (e.g., a specific thermal camera manufacturer's integration). A clear statement of which payloads are shipping today versus in beta or on the roadmap.

Red flag: "Compatible with any USB or Ethernet sensor." This means the vendor provides a mechanical mount and a data port but no software integration, calibration, or support for specific sensor models. You will be building the integration yourself.

Q1.2 — For each payload, describe the published software interface: is there an SDK with documented APIs, a worked example for a common inspection use case, and a version history? What operating system and ROS version does the SDK target?

Red flag: "ROS-compatible" without a specific package name, version number, or GitHub repository. Compatibility claims without documented interfaces are unfalsifiable at the RFP stage and typically require engineering work to evaluate post-purchase.

Q1.3 — Can payloads be swapped in the field by an operator without tools? What is the time required for a payload swap, and is the new payload automatically recognized by the autonomy software without reconfiguration?

Why it matters: Multi-payload inspection programs — running thermal in the morning and acoustic in the afternoon — require fast field swaps. A 45-minute swap requiring a laptop and a software restart is operationally prohibitive.

Q1.4 — What is your payload roadmap for the next 12 months? Which items on the roadmap are funded and in development versus conceptual?

Why it matters: Buying a platform based on roadmap payloads is a risk. If the program's primary inspection use case depends on a payload that is 18 months away, the program's timeline depends on the vendor's delivery.

Section 2: Autonomy capabilities

Autonomy claims are the area where vendor marketing diverges most widely from operational reality. These questions produce testable, specific answers.

Q2.1 — Describe the teach-and-repeat workflow in detail. How does an operator create a new route? What sensors are used for localization? How long does it take to map a 500-meter route with 20 waypoints, from start to a verified autonomous playback?

What a good answer looks like: A specific workflow description (software UI, mapping mode activation, waypoint logging, playback verification), specific sensors named (LiDAR, visual-inertial odometry, IMU), and a realistic time estimate from a comparable deployment.

Red flag: "Our autonomy is fully automatic" without a description of the mapping process. There is no quadruped inspection platform in commercial operation that requires no mapping before autonomous navigation in a new environment. A vendor who claims otherwise is either describing a feature that does not exist in production or misunderstanding the question.

Q2.2 — How does the platform handle dynamic obstacles on a mapped route — for example, a forklift or a portable air compressor staged near a waypoint? Does the robot stop and alert, attempt to navigate around, or abort the round?

Why it matters: Industrial environments have dynamic obstacles. A platform that aborts the entire round when a single waypoint is blocked produces unreliable inspection coverage without notifying the operator of what was missed.

Q2.3 — How often do existing customers re-map routes due to environmental changes? What triggers a required re-map? What is the typical re-mapping time for a segment of 100 meters?

Why it matters: This question produces real operational data rather than demo conditions. A vendor who cannot answer it has not deployed at scale in real industrial environments.

Q2.4 — What is the maximum consecutive runtime on a single battery charge under full payload operation at inspection speed? What is the battery's rated cycle count, and what is the replacement cost for a full battery pack?

Why it matters: Runtime determines how much of a facility can be covered per round. Battery cycle life determines a real maintenance cost line item that belongs in the TCO model.

Q2.5 — Does the autonomy software support scheduled round execution from the dock without any operator initiation — meaning a round starts at 2 a.m. Tuesday without any human action? If so, what is the software architecture: cloud-hosted scheduler, on-premise server, or onboard? What happens to the schedule if the internet connection is lost?

Red flag: A scheduler that requires cloud connectivity with no local fallback in a facility where internet connectivity is not guaranteed.

Section 3: Environmental protection and certification

Q3.1 — What is the IP rating for the complete robot system, including the payload interface connectors when a payload is attached? Provide the test standard and the specific test conditions (submersion depth, duration, particle size).

Why it matters: IP ratings are system ratings, not component ratings. A robot body rated IP67 with a payload interface connector rated IP54 has an effective system rating of IP54.

Q3.2 — Does this platform carry ATEX Zone 1 or Zone 2 certification, or IECEx certification, for operation in explosive-atmosphere environments? If yes, provide the specific certificate numbers, the certifying body, and the gas groups and temperature class covered.

Why it matters: ATEX/IECEx certification is a hard regulatory requirement for explosive-atmosphere areas. A vendor claim of "suitable for hazardous areas" without a specific certificate number from a named certifying body is not a compliant claim.

Q3.3 — What is the operating temperature range (ambient) for the full platform under payload operation? What is the storage temperature range?

Q3.4 — Has the platform been tested in the presence of electromagnetic interference (EMI) from high-voltage electrical equipment or radio-frequency sources? What testing standard was used?

Why it matters: Substations and high-voltage switchyards can affect robot sensor and control systems. Deployments at electrical utilities specifically should request EMI testing documentation.

Section 4: Support, maintenance, and parts

Q4.1 — What are the terms of your commercial support contract? Specifically: what is the response SLA for hardware failures, what is your commitment to spare parts availability, and what is the duration of that commitment?

Red flag: "We provide best-effort support" without a documented SLA. Enterprise inspection programs cannot tolerate undefined response timelines for hardware failures.

Q4.2 — What is the full list of field-replaceable units (FRUs — components that an operator or field technician can replace without returning the robot to the factory) that an on-site maintenance technician can replace? For which repairs must the robot be shipped to a service depot?

Why it matters: A program that must ship the robot to the vendor for every actuator replacement has a repair timeline measured in weeks. A program where an on-site technician can replace common wear parts has a timeline measured in hours.

Q4.3 — What is the anticipated service life of the platform's primary actuators under commercial inspection duty — defined as 8 hours of operation per day, 5 days per week? What is the replacement cost per actuator, and what is the replacement procedure?

Q4.4 — Provide references for three commercial deployments in industrial inspection environments comparable to our facility (process manufacturing, utilities, or oil and gas). Provide the contact name, site type, and duration of deployment. We will call these references before contract signature.

Red flag: A vendor who cannot provide three commercial inspection references is a research/demo-stage vendor, not an inspection-program vendor. Demos and pilots at vendor partner sites do not count; production deployments with a named operations contact count.

Section 5: Data sovereignty, cybersecurity, and NDAA compliance

Q5.1 — Where is inspection data stored, and what are the data residency options? Can the system operate in a fully air-gapped mode with no internet connectivity? If cloud connectivity is required for any function, describe which functions, what data is transmitted, and what encryption is used in transit and at rest.

Why it matters: Many industrial facilities, particularly in energy, water, and defense-adjacent sectors, have data residency requirements or air-gap mandates. A platform that requires cloud connectivity for core functions may be disqualifying.

Q5.2 — Describe the cybersecurity architecture of the platform, including the operating system, network exposure surface, authentication model for the operator interface, and patch update process.

Q5.3 — Does this platform and its components comply with the National Defense Authorization Act (NDAA) telecommunications and video surveillance equipment restrictions? Specifically, do any components — cameras, processors, wireless modules, or software libraries — originate from manufacturers named in the relevant NDAA sections? Provide a written attestation.

Why it matters: Procurement at government facilities, utilities under FERC or NERC jurisdiction, and defense-related sites may be subject to NDAA compliance requirements. A vendor who is uncertain about their component supply chain cannot make a compliant attestation. This is a straightforward question; a confident answer either way is acceptable. A deflection is not.

The red flags checklist

Use this summary checklist when evaluating vendor responses. Any item marked as a red flag warrants a clarification request before proceeding to the next procurement stage.

With this RFP framework, the procurement process produces a side-by-side vendor comparison grounded in operational specifics rather than demo impressions. The full series — from the decision to buy through deployment and vendor selection — is available in the Quadruped section of the Robolist.ai Industry Knowledge guide. The first article in this series, Why the quadruped you bought is sitting on a shelf, frames the program design decisions that determine whether the platform you select actually earns its keep.