Robot deployment checklist: from pilot to production
Why robot pilots stall and how to avoid it: process selection, site readiness, integration, acceptance criteria, and the metrics that matter in production.
- Most robot pilots stall for reasons that have little to do with the robot: an unsuitable process, an unprepared site, missing integration, or no agreed definition of success.
- Pick the process before the robot. Good first candidates are repetitive, tolerant of occasional failure, and already measured.
- Write acceptance criteria before the pilot starts: throughput, intervention rate, uptime and safety validation, each with a number and a measurement method.
- The metric that best predicts whether a deployment scales is how often a human has to step in, and how long each intervention takes.
A robot that works in a demo has answered one question: can it do the task? Production asks three harder ones. Can it do the task reliably, all shift, without someone standing next to it? Can it do it inside this site — these aisles, this software, these people? And can it do it for less than the alternative?
Pilots stall when they were never designed to answer those questions. This checklist is organized around the stages where that happens.
1. Choose the process before the robot
Start from a process with a problem, not from a robot looking for a job. A good first candidate:
- Is repetitive and high-volume, so reliability improvements pay back quickly.
- Tolerates failure. If the robot stops, work can route around it or a person can step in without halting everything downstream.
- Has stable inputs. The more variation in items, packaging and presentation, the more of the long tail you take on.
- Is already measured. Without a baseline for throughput, error rate and cost, you cannot show improvement.
Be wary of choosing the most painful process on site first. It is usually painful because it is hard.
2. Check the site
Robots are less forgiving of their surroundings than people are. Before committing, walk the site and check:
- Floors and space. Surface quality, slopes, thresholds, aisle widths, and room for the robot’s safeguarded space.
- Connectivity. Wi-Fi or private cellular coverage across the whole working area, including the corners. Remote assistance depends on it.
- Power. Charging locations and whether the electrical supply can support them.
- Lighting and environment. Lighting changes across the day, reflective surfaces, dust, temperature — all affect perception.
- Traffic. Where people, forklifts and other vehicles move, and whether those routes can change.
3. Do the safety work early
Safety is the stage most often left until it blocks go-live. Do it at the start, because it shapes layout and cost.
- Run a risk assessment for the application — robot, tool, payload, task and people.
- Identify which standards apply to this type of robot.
- Decide how people and robots share space: separated, or working collaboratively with speed and separation monitoring or force limiting.
- Involve the site’s safety lead and worker representatives before installation, not after.
4. Plan the integration
A robot that is not connected to the site’s systems is a science project. Find out early:
- Where tasks come from. The warehouse management or manufacturing execution system has to tell the robot what to do, and the robot has to report back what it did.
- What happens on failure. If the robot cannot complete a task, where does that task go? Exception handling is most of the integration work.
- Who owns the interface. Integration projects stall when the robot vendor and the software vendor each assume the other is responsible.
5. Write acceptance criteria before you start
Agree, in writing, what success looks like and how it will be measured. At minimum:
| Criterion | What to specify |
|---|---|
| Throughput | Units per hour, measured over full shifts, not best runs |
| Task success rate | Share of tasks completed without help, and how “completed” is defined |
| Intervention rate | Interventions per hour, and average time to resolve one |
| Uptime | Share of scheduled time the robot is available to work |
| Safety | Validation of each safety function completed and documented |
| Cost | Fully loaded cost per unit of work, including support staff |
If a criterion has no number or no measurement method, it is not a criterion.
6. Run the pilot to find failures
The purpose of a pilot is to discover how the system fails, so run it under real conditions: every shift, the full product mix, real operators rather than the vendor’s engineers. Log every intervention with its cause. The pattern in that log tells you whether the remaining problems are a short list of fixable issues or an open-ended tail.
7. Prepare the people
Deployments fail quietly when the people working next to the robot do not trust it or do not know what to do when it stops. Plan for:
- Training for operators and for whoever handles first-line faults.
- A clear escalation path from on-site staff to remote support to the vendor.
- Honest communication about what the robot is for and what changes for the people it works alongside.
8. Plan operations before you scale
Going from one robot to fifty is an operations problem, not a robotics one. Before scaling, have answers for:
- Remote assistance. Who helps a stuck robot, from where, and how many robots each person can support.
- Maintenance. Preventive schedules, spare parts on site, and who does repairs.
- Software updates. How new software or model versions are tested and rolled out, and how the risk assessment is updated when behavior changes.
- Monitoring. A view of the fleet that shows intervention rate and uptime per robot, so problems are caught as trends.
The one metric to watch
If you track a single number, track how often a person has to step in and how long it takes. Intervention rate decides how many support staff the fleet needs, which decides whether the economics work. A robot that does the task slightly slower than a person but runs for hours unattended is a product. One that is faster but needs help every ten minutes is a demo.
Frequently asked questions
Why do robot pilots fail to reach production?
Usually because the pilot proved the robot can do the task, but not that it can do it reliably enough, inside the site’s existing systems, at a cost that beats the alternative. Those three questions need to be designed into the pilot from the start.
What is a good first process to automate with a robot?
One that is repetitive, has stable inputs, can tolerate an occasional failure without stopping the line, and already has a measured baseline for throughput and cost. Avoid starting with the hardest or most safety-critical process on site.
What is intervention rate?
How often a person has to help the robot, either on site or remotely, to keep it working. It is often expressed as interventions per hour or as mean time between interventions, and it determines how many people a fleet needs to support it.
How long should a robot pilot run?
Long enough to see the rare failures, not just the common ones. That means covering every shift pattern, the full range of products or items, and at least one maintenance cycle. A pilot that only runs on good days produces a misleading result.