AMR Deployment: From Commissioning to Customer Acceptance
Autonomous mobile robot (AMR) deployments rarely fail because the robot cannot move in an empty aisle. They stall when commissioning evidence does not survive contact with warehouse variability: peak traffic, WMS reservations, charger contention, map updates, and multi-shift operators. This guide walks the path from commissioning to customer acceptance as an evidence chain, not a slide checklist. Dagmont Deployment Intelligence is designed to hold that chain; fleet management remains the layer for live tasking and robot status.
Published September 6, 2026
Commissioning is not acceptance
Commissioning proves the AMR can operate in the prepared site envelope: localization lock, map coverage, safety fields, charger docking, and basic mission completion. Acceptance proves the AMR meets the customer’s contracted conditions under representative work. Conflating the two is a common source of late conflict.
Write acceptance criteria before the first production trial: throughput or cycle-time thresholds, recovery-time limits after blockage, allowable intervention rate, integration success criteria with WMS/MES/ERP, and the evidence each criterion requires.
Evidence types that matter on AMR sites
Useful AMR evidence is specific: mission IDs and timestamps; map and localization versions; robot serial and software/firmware builds; WMS task and reservation records; network quality snapshots for problem zones; charger session logs; operator intervention notes; and video or event exports for contested failures. Generic “system healthy” dashboards from fleet tools are operationally useful but usually insufficient for acceptance disputes.
Capture primary artifacts when the failure occurs—not after the war room ends.
Failure modes that repeatedly block AMR go-live
Recurring blockers include: localization drift after layout changes; aisle deadlock when costmaps and human traffic interact; charger queue collapse during peak; WMS handshake timeouts under load; multi-robot traffic rules that work in simulation but fail at merge points; and firmware/config drift between the accepted pilot unit and the production fleet. Each blocker should map to a named requirement, an owner, and a retest plan that reproduces site conditions—not only lab or empty-aisle conditions.
Corrective action, configuration, and retest
A corrective action is incomplete until the change is identified (hardware, software, map, parameter, procedure), authorized, and verified against the original failed condition. For AMRs, configuration and map versions are first-class artifacts. If a parameter or map change lands after provisional acceptance, treat it as a baseline change that may require targeted revalidation.
Retest under the traffic, shift, and integration load that exposed the failure.
Customer acceptance package
The acceptance package should let a customer reviewer answer: what failed, what evidence showed it, what cause was confirmed, what changed, who approved it, what retest proved, and what remains conditional. Present residual risks explicitly. Do not ask for signature against a fleet uptime chart alone.
After acceptance, keep the chain available for warranty and change control when later fleet updates arrive.
Checklist
- Separate commissioning exit criteria from customer acceptance criteria in writing
- Define measurable AMR thresholds (recovery time, intervention rate, integration success)
- Capture map/firmware/config versions with every failure and every change
- Include WMS/MES/ERP evidence when integration is in scope
- Retest under peak or multi-shift conditions that match the failure
- Record acceptance, rejection, or conditions against the evidence trail