A robot pilot needs a decision rule before it needs an impressive demonstration. Agree what the system must do, where it must do it, what people still need to handle, and which results will justify a next step. This template helps a buyer and supplier discuss those questions using the same record.
It is a planning aid, not a safety certification or a statement of OpenDroids product performance. Qualified people still need to review the environment, operating instructions, and safety arrangements for the actual system. Begin with the AMR site survey checklist and a narrowly defined workflow.
State the task and its boundaries
Name one repeatable task. Record its start condition, destination, load or object, handoff point, and completion condition. Define when a cycle begins and ends so everybody counts the same event.
An illustrative delivery cycle might begin when an authorized operator releases a prepared tray and end when a receiving person confirms collection at the agreed station. Time spent waiting for a missing recipient belongs in the workflow record; it should not disappear because the robot reached the destination.
List what the pilot excludes. A successful flat-floor route does not establish performance on stairs, a different payload, or a crowded route that was never tested. Save the software configuration, route version, and relevant environment conditions beside the results.
Agree the observation plan before running it
Prepare a simple test sheet with these fields:
- Cycle identifier and observation time.
- Task version and operating condition.
- Attempted, completed, stopped, or unresolved status.
- Human handoff time and intervention time.
- Failure or interruption description.
- Evidence reference and person responsible for reviewing it.
Decide which operating conditions matter to the intended use. Quiet-period observations alone cannot answer a question about peak service. Record planned conditions and any conditions that were unavailable rather than labeling the missing evidence as a pass.
Use a shared definition of successful completion. Reaching a waypoint, avoiding an obstacle, and completing the business task are different claims. Navigation configuration also depends on the robot's footprint and its representation of the environment; a generic worksheet cannot validate that configuration.
Keep interventions in the result
A person resetting a route, moving an obstacle, rescuing a dropped object, or finishing an unsuccessful task is part of the observed workflow. Count those events and their human time. Record the reason without assigning blame to a staff member who followed the agreed fallback procedure.
For an illustrative set of 100 attempts, 90 completions and 10 failures is a 90% completion rate. It does not tell you whether the pilot met the business goal. You still need the time record, the failure conditions, and the agreed acceptance criteria. The robot pilot calculator can explore human-time assumptions, including fallback and recovery, before you replace them with measured values.
Define acceptance criteria as review questions
Write the criteria jointly with the people responsible for operations and the supplier. Avoid borrowing a universal completion-rate target from another workplace. A useful criterion names the measure, the tested condition, the evidence required, and who can accept it.
For example: “For the agreed route and load, review completion records, human intervention time, and all stopped cycles. Expansion requires operations and the supplier to resolve the recorded exceptions.” The numerical thresholds and observation period belong in the actual agreement; this example does not supply them.
Keep safety review separate from business efficiency. A positive time comparison does not override a stop condition or demonstrate safe operation.
Hold a decision review with the complete record
Choose among continuing the same pilot, changing one condition and retesting, preparing a limited expansion, or stopping. Name the unresolved question that each decision addresses. Retain the unsuccessful cycles and the configuration used; removing difficult cases makes the next pilot harder to interpret.
Before expanding, compare integration, training, support, and recurring costs using the robot total-cost worksheet. For restaurant operations, connect the acceptance record to the restaurant pilot plan.
Bring the task definition, site observations, and open questions to OpenDroids when discussing a deployment. A specific workflow gives that conversation a much stronger starting point than a request for a robot that can do everything.
Sources
Prepared with AI assistance using the current public product and linked references. Practical checklists and illustrative examples are original planning aids. They do not establish product guarantees or replace a situation-specific review.