Preparing the published article.
How to Run an AMR Throughput Trial Without Trusting a Vendor Rate
A practical checklist for designing an AMR throughput trial, instrumenting it with your own data, and writing the acceptance clause.
Define the Task Mix Before You Measure Anything
A trial that runs one robot up and down an empty aisle measures the robot, not your operation. Before you book a slot, write down the task mix you intend to test: pick-to-station transfers, full-pallet moves, replenishment, and empty-equipment returns. Give each task type a share of the total, taken from four weeks of your own task records rather than from a demonstration. Ask which of those task types the navigation and fleet software was configured for, and put the answer in your trial file as a dated note.
Turn that mix into a run sheet with named origins and destinations. For each route, record the narrowest aisle width, door and lift interfaces, floor surface, ramp gradients, and the exact load unit. Photograph the pinch points and attach the images to the run sheet: a photograph dated before the trial settles most later disagreements about whether the environment changed.
- Data extract: task ID, timestamp, origin, destination, load unit, requesting system.
- Environment notes: tightest aisle width, floor joints, lighting level, charging room location.
- Interface list: fire doors, goods lifts, automatic doors, weighbridges, and who controls each one.
- Changes that invalidate the trial: rack moves, new pick faces, floor repairs, altered shift patterns.
Agree in writing what a completed task means before the first run. A drop that needs an operator to nudge the pallet is not the same event as a clean drop, and if both count as success your later figures will be unusable.
Instrument the Trial Instead of Watching It
A stopwatch and a clipboard produce arguments rather than evidence. Instrument the trial: export task events from your warehouse management system and from the fleet manager, then join the two exports on the task ID. For every task, record arrival at the origin, pick or lift start, departure, arrival at the destination, and drop completion. The gaps between those timestamps show where time is actually lost; a single end-to-end average hides it.
Run the trial across at least three shift patterns, including a peak hour and a shift change. Log every intervention: manual joystick recovery, emergency stop, blocked aisle, operator override, and any task the vehicle abandoned. Report interventions per hundred tasks rather than per hour, because a quiet hour flatters any system, including your current one.
- Per-intervention fields: timestamp, task ID, vehicle ID, location, cause category, recovery time, who recovered it.
- Cause categories agreed in advance: obstacle, localisation loss, battery, traffic conflict, door or lift, operator error.
- Environment fields: ambient temperature for cold stores, pallet condition, label legibility, floor contamination.
- Downtime fields: start, end, reason, and whether the affected task was re-queued or lost.
- Control route: the same task, in the same hour, performed by your existing forklift or manual process.
Record the payload actually moved and the payload the vehicle is rated for; the difference between them explains many slow cycles. Note the software build loaded on each day of the trial, because a mid-trial update makes the earlier days a different test.
Write the Acceptance Clause From Your Own Data
Build the acceptance clause around distributions, not one headline rate. State the measurement window, the task mix, the shift coverage, the percentile you will accept for cycle time, and the intervention ceiling per hundred tasks. When those thresholds come from your own baseline, they survive the contract conversation; when they come from a demonstration, they do not.
Measure the baseline first. Run your current process on the same routes for a full week and capture the same timestamps in the same format. Without a baseline you cannot call any trial result a gain, because the only comparison available is a marketing figure.
- Data ownership: who holds the raw logs, in what format, and for how long after the trial closes.
- Definitions: what counts as a failed task, an aborted task, and a completed task with manual help.
- Re-test terms: what happens to the result if a new software build is loaded during the trial.
- Exit criteria: the measured threshold below which you may end the trial, agreed before day one.
- Handover: the maintenance tasks your own technicians will own, and the spare parts held on site.
Close the trial with a short written record: task mix tested, dates, builds, intervention counts, and the routes excluded. That record is what makes the second site rollout a planning exercise instead of a repeat experiment.
Photo credits: the images in this article are licensed reference photographs of the relevant robot class, credited with author and licence in each caption; they are not photographs of the specific equipment discussed. Licence and author details are recorded with each image.