The security-robot vendor RFP: questions and red flags

Why the standard vendor demo does not surface the right information

A security robot vendor demonstration follows a predictable format: the robot navigates a prepared route, stops cleanly at designated points, and triggers a well-calibrated alert on cue. The VMS integration demo runs against a purpose-built test environment. The ROI calculation uses the most favorable assumptions.

None of this is dishonest. It is a sales demonstration, not an operational assessment. The questions that reveal how a platform performs when the environment is difficult, the integration is imperfect, and the contract terms matter are the ones that do not appear in the demo script.

An RFP process for a security robot should be structured around six domains: RaaS contract terms, SOC and VMS integration, false-alarm performance, data handling and privacy, weatherization and hardware specifications, and support and maintenance. What follows is a question set for each domain, annotated with the answers that should give a buyer pause.

Domain 1: RaaS contract terms

Questions to ask

1. What is the minimum contract term, and what is the financial penalty for early termination?

The answer defines your exit risk. Most commercial security robot vendors require 24–48 month minimum terms. Early termination clauses can require payment of the remaining contract value in full, or a percentage thereof. Know this number before signing.

2. Does the base RaaS fee include 24/7 remote monitoring, or is monitoring a separate service tier?

Many vendors bundle hardware, software, and connectivity in the base fee while separating NOC monitoring into an optional tier. If you need remote monitoring and it is not included in the quoted fee, the all-in cost is higher than the headline number.

3. What happens at contract end — do we own the hardware, return it, or renew?

Ownership terms at end-of-contract vary. Some vendors retain the hardware throughout the contract and require its return. Others offer a buyout option at the end of the RaaS term. This affects how you model residual value and switching costs.

4. What upgrade rights are included in the contract?

Security robot hardware and software generations evolve. Is your contract locked to the version shipped at deployment, or does it include firmware updates, sensor upgrades, and major software releases over the term?

5. What is the guaranteed uptime, and what is the credit mechanism if the SLA is missed?

A vendor who cannot articulate an uptime SLA for their hardware (not just their cloud service) or who offers credits that are far below the cost of downtime coverage should be pressed for specifics.

Red flags

• "We'll work it out if there's an issue" in place of written SLA terms
• Early termination clauses that require 100% of remaining contract value with no good-faith performance clause
• No upgrade path in the contract — you are locked to current hardware for 36 months
• Monitoring described as "included" but buried in addenda as an optional fee

Domain 2: SOC and VMS integration

Questions to ask

1. Provide your current VMS compatibility matrix, with version numbers.

If a vendor cannot produce a specific list of VMS platforms and confirmed version compatibility, they are either behind on integration work or describing aspirational compatibility. Ask for the matrix as a deliverable document, not a verbal assurance.

2. Does your platform comply with ONVIF Profile S and Profile T?

ONVIF (Open Network Video Interface Forum) compliance is the baseline standard for video device interoperability with modern VMSs. Profile S covers basic video streaming; Profile T covers advanced video streaming including H.264/H.265 and metadata. Compliance should be a floor requirement, not a differentiator.

3. What is the API documentation format, and what does your integration support process look like?

A vendor with mature integration support will have current REST or RTSP API documentation, a sandbox environment for integration testing, and a dedicated technical resource during the integration phase. A vendor who directs you to an integration partner channel without a direct technical resource is adding a cost layer and a communication chain that slows problem resolution.

4. Describe a real deployment where your platform was integrated into a multi-vendor security stack — what broke, and how was it resolved?

This question surfaces integration reality rather than integration aspiration. A credible vendor will have a candid answer. A vendor who only describes successful demos should be asked for customer references at integration-phase contacts (not sales contacts) who can confirm the integration experience.

5. What is your alert data format, and can alert events be ingested into a SIEM?

If you operate a SIEM (Security Information and Event Management) platform, confirm that the robot's alert data can be ingested in a format the SIEM accepts. Siloed alert data that lives only in the robot's management portal cannot be correlated with other security data sources.

Red flags

• VMS compatibility described as "works with most major platforms" without a specific version matrix
• Integration process described as "plug-and-play" without a staging environment or a technical contact
• No ONVIF compliance, with a proprietary streaming protocol as the only option
• Alert data accessible only through a closed vendor portal with no API export

Domain 3: False-alarm performance

Questions to ask

1. What is your platform's false positive rate in environments similar to mine? Provide deployment data, not lab data.

Vendors may offer data from controlled demonstrations or ideal-environment deployments. Press for data from environments with comparable characteristics to yours: similar floor materials, lighting conditions, ambient traffic patterns, and temperature variation.

2. How are alert thresholds configured, and who has access to change them?

Buyers should have direct access to alert threshold configuration in the management interface, not be dependent on a vendor support ticket to adjust sensitivity. Confirm this before signing.

3. What is the typical calibration period to reach stable false positive rates, and what support is provided during calibration?

A credible vendor will describe calibration as a 4–8 week process requiring active tuning. A vendor who claims the system is "ready to go out of the box" with no calibration period is describing a demo environment, not a production deployment.

4. What false-alarm rate metrics do you report in your quarterly reviews, and can we see an example report?

The existence of a structured performance reporting process — and the willingness to share a redacted example — is a signal of operational maturity. Vendors who cannot produce example reporting are likely not measuring this rigorously.

5. What happens when false-alarm rates remain high after the calibration period? Is there a remediation process, and is it covered under the contract?

This question tests whether the vendor has accountability for persistent false-alarm problems or whether remediation becomes a separate professional services engagement.

Red flags

• False positive rate claims below 5% for complex indoor or mixed-environment deployments without supporting deployment data
• Threshold configuration locked behind a support ticket process
• No structured calibration support period
• Alert count cited as a performance metric without false positive rate breakdown (high alert counts are not a positive indicator)

Domain 4: Data handling and privacy

Questions to ask

1. Where is robot-captured video and sensor data stored — on the robot, in your cloud infrastructure, or on-premises? Where are the servers located?

Data residency matters for compliance in regulated industries (healthcare, government, financial services). EU-based operations will require GDPR-compliant data processing. Some government facility deployments require on-premises or domestic-cloud data storage.

2. Do you process biometric data — facial recognition, gait analysis, or biometric identification — and if so, under what consent framework?

This question has significant legal exposure in US jurisdictions with biometric privacy laws (Illinois BIPA, Texas CUBI, and others). A vendor who processes facial recognition data and has not mapped this against applicable state biometric privacy law is a compliance liability.

3. What is the default data retention period for video and sensor data? Is this configurable?

Retention policies affect both privacy compliance and storage costs. Indefinite retention of video data from a security robot constitutes a significant data liability. Confirm that retention is configurable and that deletion is verifiable.

4. Who within your organization has access to the video and sensor data captured at our facility?

The answer should be specific: which roles, under what access controls, for what purposes, logged how. Vague answers ("our operations team as needed for support") are not acceptable for facilities with confidentiality obligations.

5. Describe your data breach notification process and your cybersecurity certifications relevant to video data handling.

SOC 2 Type II certification is a reasonable baseline expectation for a cloud-connected security platform handling sensitive video data. Ask for the certification documentation.

Red flags

• Facial recognition enabled by default without explicit consent framework
• Video data stored in foreign jurisdictions without disclosure
• No configurable retention policy — data is retained indefinitely
• No SOC 2 or equivalent certification for cloud infrastructure
• Access logs for facility video data not available to the buyer

Domain 5: Weatherization and hardware specifications

Questions to ask

1. What is the IP rating for the robot body and charging station? Can you provide the certification documentation?

IP ratings should be verifiable against IEC 60529 certification documentation, not just marketing copy. IP65 is a reasonable minimum for continuous outdoor operation; IP66 adds protection against high-pressure water. Confirm both the robot and the docking station carry equivalent ratings.

2. What are the operating temperature and humidity limits, and how do these affect patrol availability in our climate?

Deployments in northern climates need confirmed cold-weather operation. Deployments in high-humidity coastal environments need confirmed humidity tolerance. Ask for the specific parameter ranges from the hardware datasheet, not the marketing brochure.

3. What is the battery cycle life, and what is the replacement cost and timeline when the battery degrades?

Robot batteries degrade with charge cycles. After 500–1,500 cycles (12–36 months of daily operation, depending on cycle frequency), capacity reduction may begin to affect patrol duration. Confirm the replacement cost and lead time, and whether this is covered under the RaaS fee or a separate cost.

4. What is the procedure and timeline for hardware replacement if the robot is damaged or destroyed?

A robot damaged by a vehicle, vandalism, or flooding needs a replacement timeline. If the replacement timeline is six to eight weeks, what coverage is provided during that period?

Red flags

• IP rating cited in marketing materials without certification documentation available
• Operating temperature range not specified in hardware datasheet
• Battery replacement costs not disclosed in the RaaS agreement
• No loaner or replacement unit provision in the contract

Domain 6: Support and maintenance

Questions to ask

1. What is your technical support response time commitment, and is it 24/7?

Security robots operate overnight and on weekends. A vendor with business-hours-only technical support is not structured for operational security deployments.

2. Who performs preventive maintenance, and at what frequency? Is this included in the RaaS fee?

Preventive maintenance — sensor cleaning, mechanical inspection, seal integrity check — should occur quarterly at minimum for outdoor deployments. Confirm it is included in the fee structure and that a vendor technician (not a remote software update) conducts it.

3. Describe your firmware and software update process. Do updates require operational downtime?

Firmware updates that require taking the robot offline for four or more hours are operationally significant. Confirm the update process, typical duration, and how far in advance buyers are notified.

4. What customer references can you provide from deployments with comparable environments and similar operational requirements?

Request references at the security operations level — the person who managed the SOC integration — not just the procurement or facilities contact. Ask the references specifically about alert calibration experience, integration problems, and vendor responsiveness during issues.

Red flags

• Support hours limited to business hours for a system deployed in overnight security operations
• No preventive maintenance schedule in the contract
• Firmware updates applied remotely without buyer notification or consent
• Customer references available only at executive or sales level, not at operations level

The non-negotiables checklist

Before contract signature, a buyer should be able to check every item on this list. Items that cannot be checked are contract risks.

• Written uptime SLA with credit mechanism for missed performance
• VMS compatibility matrix with version specifics, confirmed in staging
• Alert threshold configuration accessible to buyer without vendor support ticket
• Data residency and retention policy documented and compliant with applicable law
• IP rating certification documentation for robot and charging station
• Biometric data processing disclosed and consent framework documented
• Early termination terms understood and financially modeled
• Technical support available during hours the robot operates
• Preventive maintenance schedule and responsibility explicit in contract
• Operational reference contacts provided and contacted before signing

Security robot procurement is not complex, but it rewards preparation. The questions that seem tedious in an RFP process are exactly the questions that prevent the 90-day failure arc described in "Why security robots get pulled after a few months."