Service Robot Vendor Evaluation — 12-Point Framework for Enterprise Procurement
At a glance: A 12-point framework scores vendors out of 100, with navigation worth 12% of the total and API readiness 8%. It turns RFP responses into comparable evidence — documentation, not claims.
When an enterprise shortlists service robot suppliers, the RFP responses often look nearly identical: every vendor claims industry-leading navigation, enterprise-grade fleet software, and 12-hour runtime. Separating signal from noise without a standardized framework is the most common failure mode in robotics procurement — teams default to price comparison, which is the least predictive success metric in this category.
This guide provides a 12-point framework organized into four categories — technical capability, operational reliability, commercial terms, and vendor maturity. Each dimension is scored 1–5, weighted for enterprise impact, and summed to a total score out of 100. The weights below come from the operational realities of service robot deployments, not from spec sheets.
Why Standardized Evaluation Matters
Three dynamics make ad-hoc evaluation particularly dangerous in service robotics.
Spec parity masks real divergence. On paper, most delivery robots offer LiDAR plus SLAM and a fleet dashboard. In production, the spread on mean time between failures, navigation accuracy in dynamic environments, and API quality is far wider than any spreadsheet suggests. Without a structured rubric, those differences surface only after signing.
Integration costs dominate total cost. A robot that looks cheaper but needs substantial custom integration work is more expensive over three years than a mid-priced unit with mature APIs and pre-built connectors. The framework weights integration readiness ahead of base hardware price.
Vendor lock-in compounds with fleet scale. A 5-robot pilot tolerates vendor-specific protocols; a 200-robot fleet does not. The framework explicitly scores openness — documented APIs, standard protocol support, and third-party integration track record — because switching costs in robotics are far higher than in enterprise software.
The 12-Point Framework
Category 1: Technical Capability (weight 35%)
1. Navigation performance in your environment (12%). This is the highest-weighted dimension because it determines whether the robot works at all in your facility. Evaluate with an on-site demo, not a spec sheet: dynamic obstacle handling (how often path replans succeed without stopping), multi-floor operation (measured over a large number of elevator trips), narrow passage and door handling (completion rate over a standard 10-passage test course), and map adaptability after furniture changes (remapping time in minutes). Score 1–5 based on the demo. A score of 3 means "meets requirements"; 5 means "exceeds requirements with headroom."
2. Fleet management software (10%). This is what your operations team uses daily. Test: real-time visibility of every robot's status, location, and battery on one dashboard; priority-based task orchestration with reassignment when a unit goes offline; analytics such as utilization and per-robot cost-per-task; configurable multi-channel alerting; and multi-site management with role-based access control. Score 5 only with demonstrable reference deployments.
3. API and integration readiness (8%). Service robots interface with elevators, access control, building management systems (BMS), warehouse management systems (WMS), and enterprise ERPs. Evaluate: quality of API documentation and SDKs; support for open protocols (MQTT, REST, WebSocket, ROS 2) rather than proprietary-only ones; and pre-built connectors for common elevator and access-control ecosystems. Proprietary-only integration guarantees vendor lock-in from day one.
4. Robot-to-human interaction design (5%). Robots share space with employees and customers. The interaction design — intent signaling (light rings, audio cues), yield behavior when human and robot both try to yield, error recovery (does it say "assistance needed" or sit silently?), and accessibility — directly affects acceptance and safety.
Category 2: Operational Reliability (weight 30%)
5. Hardware reliability and MTBF (12%). Mean time between failures is the most honest number in robotics and the one vendors are least transparent about. Demand field data from comparable deployments at similar usage intensity — a delivery robot doing 200 trips a day in a hospital has a different reliability profile from one doing 50 trips a day in a quiet office. Also ask: reliability figures for the three most-failed components (typically drive motors, LiDAR, battery packs), field replacement time (30 minutes or less is the practical bar for trained on-site staff), and warranty scope.
6. Service and support infrastructure (10%). A robot is only as reliable as the support organization behind it.
| Support Dimension | Enterprise Requirement | Red Flag |
|---|---|---|
| Response time SLA | Contractual response times for critical and standard tickets | "Best effort" with no SLA |
| Local support presence | Technician within a reasonable travel radius of your facilities | Nearest support is a flight away |
| Remote diagnostics | Most issues diagnosable remotely | Every issue requires an on-site visit |
| Spare parts availability | Critical parts stocked within a delivery radius of days, not weeks | Parts ship from an overseas factory |
| Software update cadence | Committed schedule for security patches and feature releases | "When available" |
7. Safety certifications and compliance (8%). Check CE (EU), FCC (US), and UKCA (UK) for your target regions; ISO 13482 for service robots or ISO 10218 for industrial categories; industry specifics such as UL listing for healthcare, ATEX for potentially explosive atmospheres, and IP ratings; and whether the vendor carries product liability insurance.
Category 3: Commercial Terms (weight 20%)
8. Total cost of ownership transparency (8%). The purchase price is the smallest number in the TCO equation. Demand a 3- or 5-year breakdown with seven line items: hardware purchase or lease; annual software and fleet-management licensing; maintenance and spares (year-2 and year-3 estimates, not year-1); installation and integration services; training; energy per robot per year; residual value or end-of-lease terms. If the vendor cannot provide all seven, score this dimension 1 regardless of the headline price.
9. Contract flexibility and financing (7%). Deployment model options (CapEx, lease, RaaS, hybrid), minimum commitment (some vendors require 10+ units, which disqualifies small pilots), termination costs and notice, and performance guarantees — uptime, MTBF, or completion-rate SLAs with financial penalties.
10. Scalability economics (5%). Per-unit cost at 5, 20, 50, and 100 units — the discount curve shows how aggressively the vendor wants fleet-scale business. Check whether fleet software is priced per robot, per site, or flat, and whether training scales linearly or through a train-the-trainer model.
Category 4: Vendor Maturity (weight 15%)
11. Financial health and long-term viability (10%). A bankrupt vendor turns your robot fleet into unmaintainable hardware. Under appropriate NDAs, evaluate funding and runway, revenue trajectory and customer concentration (one customer above roughly 30% of revenue is a red flag), manufacturing maturity, and secondary sources for critical components such as LiDAR, motors, and batteries.
12. Product roadmap and innovation velocity (5%). Roadmap transparency under NDA and delivery history; release cadence in the past 12 months; and whether you can point to features built from enterprise customer requests.
Running the RFP in Four Phases
Phase 1 — Pre-qualification. Send a two-page questionnaire covering dimensions 5 (reliability), 7 (certifications), and 11 (financial health). Vendors that cannot provide verifiable field MTBF data, lack required certifications for your markets, or are too early-stage should not proceed to full evaluation. This step typically removes most of a longlist.
Phase 2 — Full RFP with weighted scoring. Require evidence, not claims: field MTBF reports, API documentation URLs, reference customer contacts, financial statements. Score each dimension 1–5 with the criteria above, apply the weights, and rank.
Phase 3 — On-site demo with a scorecard. Invite the top three vendors to run the same test course in your actual facility. The navigation performance demo is the single most predictive element of the entire evaluation — a robot that handles your environment well in a four-hour demo will likely perform well in production.
Phase 4 — Structured reference calls. Call three references per finalist with specific questions: actual MTBF in the first six months, unplanned service visits in year one, and what they wish they had known before signing.
Red Flags That Should Eliminate a Vendor Immediately
- No field reliability data. A vendor shipping robots for over a year that cannot share MTBF data from any customer deployment either does not track it or does not want you to see it.
- Proprietary-only integration. No public APIs, no open protocol support — vendor lock-in from day one.
- Single-sourced critical components. One supply chain disruption paralyzes your fleet.
- "AI solves everything" positioning without substance on mechanical engineering, sourcing, and support infrastructure.
- No reference customers in your industry. A warehouse vendor claiming hospital fit without a single healthcare reference is asking you to fund their market entry.
From Evaluation to Deployment: A 90-Day Example Timeline
Once a vendor is selected, the real work begins:
Days 1–30: contract finalization, site assessment, integration planning with IT and facilities teams, and KPI definition — tasks per robot per day, uptime target, user satisfaction threshold.
Days 31–60: pilot with 2–5 robots in a single facility, run as an experiment with a documented hypothesis — for example, an illustrative target of 40% fewer transport man-hours. If the pilot data does not support the hypothesis by day 60, pause and diagnose before scaling.
Days 61–90: finalize the fleet plan and budget from pilot data, submit for approval with results attached, and begin production procurement.
Every AOMAN FUTURE unit — from the AOMAN D1 delivery robot to the AOMAN C1 floor scrubber — ships with the documentation this framework asks for. See the full range, or tell us your environment and we will share reliability data from comparable deployments.
