Skip to content

What to require in an AMR RFP: a buyer's checklist

By Service Robot Co.

A good AMR RFP scores deployment, integration, service, and financing — not just the robot's specs. Here is the checklist to require so you buy a working outcome, not a box that becomes your problem.

The short answer: a good AMR RFP scores the whole deployment — integration, service coverage, financing, and downtime ownership — not just the robot's specs. Most RFPs over-weight the machine and under-weight everything that decides whether it actually runs: who maps your floor, who fixes it when it breaks, how fast, and who eats the downtime. Require those answers and you buy a working outcome instead of a box that becomes your problem.

Use the checklist below as the backbone of your RFP. It's organized the way the real cost falls — the robot is a small part; deployment, service, and downtime are the rest.

What most AMR RFPs get wrong

Teams write RFPs around payload, speed, battery life, and navigation specs — all real, but all about the robot in isolation. They under-specify the four things that decide success:

  • Integration — who maps the floor, builds the routes, and fits the robot into the operation you already run.
  • Service — who repairs it, with what parts, how fast, and in which locations.
  • Downtime ownership — what happens to your throughput when a unit goes down.
  • Financing — whether you're buying a capital asset, a lease, or a working service with everything bundled.

An AMR that meets every spec and has no service plan behind it is a liability the first time it breaks. Score the deployment, not just the datasheet.

The AMR RFP checklist

Require a clear, written answer to each of these. Score vendors on the full set, weighting deployment and service at least as heavily as the robot's specs:

| Category | What to require | Why it matters | | --- | --- | --- | | Robot fit | Payload, navigation, no-track operation, route types | Has to match your floor and loads | | Integration | Floor mapping, route setup, workflow fit, team training | A robot nobody deploys never runs | | Deployment timeline | Days to first run; what's required on-site | A long ramp is lost throughput | | Service coverage | Where they service, and how — your sites included | A national operation needs national service | | Response times | Remote triage and on-site dispatch commitments | Decides how long a breakdown costs you | | Downtime plan | What happens when a unit goes down | A backup unit keeps you running; nothing means you stop | | Financing | Buy, lease, or rental/RaaS; what's bundled | Decides who carries maintenance and idle cost | | Single point of contact | One vendor or a stack of three | Finger-pointing kills uptime | | Scaling | Add or return units as the work changes | Peaks and slow seasons shouldn't strand hardware | | References | Real, comparable deployments | Proof it works in an operation like yours |

The questions to put in writing

Beyond the table, make these explicit asks in the RFP so vendors can't answer around them:

  1. Who maps our floor and builds the routes — your team or ours? A vendor that hands you a robot and a manual is selling you a project, not a deployment.
  2. Where, specifically, can you service the robot, and how fast? If you operate in many states, require nationwide coverage with named response commitments, not "we'll find someone local."
  3. What happens the day a unit breaks down? Require a written answer: remote triage time, on-site dispatch time, and whether a backup unit keeps you running.
  4. Is this one vendor or a chain of them? Require a single point of contact accountable for the robot, the integration, the financing, and the service — so a problem doesn't bounce between suppliers.
  5. What does it cost when the robot is idle? Seasonal and variable operations should require a financing model that lets capacity flex, not a fixed fleet you own through the slow months.
  6. Can we start small and scale? Require the ability to add units for a peak and return them after, without buying a fleet up front.

Why one vendor for all five things wins the RFP

The cleanest way to score well against this checklist is to require a single vendor for the whole job — and that is exactly what we do. We are one company for all five things an AMR deployment needs: sales, integration, financing, deployment, and nationwide service.

  • One point of contact. The robot, the integration, the financing, and the service all run through us — no finger-pointing between a hardware vendor, an integrator, and a service contractor.
  • We deploy and integrate. Floor mapping, route setup, workflow fit, and team training so the AMR runs on day one — see the AMRs we rent and service.
  • We finance it. Rent throughput by the month instead of a capital purchase, so a changing operation doesn't strand a fleet — see how rental pricing works.
  • We service it nationwide. Repairs and parts across all 50 US states, backed by 3,000+ service engineers in the US: 10-minute remote triage during business hours, 24-hour nationwide on-site dispatch, and 24/7 emergency response.
  • We carry the downtime. If a unit goes down, we swap in a backup. Your throughput holds; we carry the spare.

That maps one-to-one onto the RFP categories that actually decide success — which is the point of writing the RFP this way.

Common questions

What should an AMR RFP score besides robot specs? Integration (who maps the floor and builds routes), service coverage and response times, the downtime plan, financing model, single point of contact, scaling, and real references. Weight these at least as heavily as payload and navigation specs — they decide whether the robot actually runs.

How do I compare a single-vendor proposal to a multi-vendor one? Score accountability. With a stack of vendors, a problem bounces between the hardware maker, the integrator, and the service contractor, and your uptime suffers. A single vendor accountable for all five things removes the finger-pointing — require a named single point of contact in the RFP.

Should the RFP ask for buy, lease, or RaaS pricing? Yes — require all three where available, because the financing model decides who carries maintenance and idle cost. For variable or seasonal operations, a rental/RaaS model that flexes capacity usually beats owning a fixed fleet. See RaaS vs buying an AMR for the total-cost math.

What response times should I require? Require written commitments, not vague promises. Ask for remote triage time, on-site dispatch time, and emergency coverage — and confirm they apply at every site you operate, not just near the vendor's headquarters.

Write the RFP around the deployment, not the datasheet

A strong AMR RFP scores the whole job — integration, service, downtime ownership, and financing — and weights them with the robot's specs, not behind them. Require a single accountable vendor and written commitments on deployment and service, and you'll buy a working outcome instead of a box. Not sure AMRs are even the right category? Start with our AMR vs AGV guide or the material handling robots guide. If you want help shaping the requirements or a proposal that covers all five things, tell us the job and the sites — we'll recommend the robot, quote the rental, and keep it serviced. You can also browse the robots we rent or read more in our resources.

Keep reading

Want a robot working for you?

Tell us the job and the site. We will recommend the robot, quote the rental, and keep it serviced.