Customer acceptance of robot deployments

Customers reviewing a robot deployment for acceptance are not simply checking a task list. They are evaluating whether the system they are about to accept is demonstrably safe to operate in their facility, reliably performs the tasks they contracted for, and has been investigated thoroughly enough that any failures that occurred during deployment have been resolved in a way that is likely to hold in production. That evaluation requires access to the deployment evidence record: a complete account of what failures occurred, what investigation was conducted, what corrective actions were taken and verified, and what evidence supports each resolution.

Customers who receive only a summary slide deck cannot evaluate the quality of the deployment work; they can only decide whether to trust the deployment team's assertions. Customers who receive access to the underlying record can evaluate the investigation methodology, the evidence quality, the rigor of the corrective actions, and the coverage of the acceptance criteria. The shift from assertion-based acceptance to evidence-based acceptance is the single most significant lever for reducing customer acceptance disputes and post-acceptance warranty claims.

A customer acceptance review that is productive requires preparation from both the deployment team and the customer. The deployment team's preparation involves ensuring the deployment record is complete, organizing the acceptance report so that it presents the evidence chain clearly, and briefing the customer in advance on the format of the review and what they will be asked to evaluate. The customer's preparation involves identifying the specific criteria they want to review in detail, any concerns from the commissioning period they want to trace through the evidence record, and the internal decision-making process they need to complete before signing acceptance.

When the deployment team provides the customer with a pre-read package that includes the acceptance report and the list of resolved incidents before the review meeting, the meeting itself can focus on evaluation and decision-making rather than on the deployment team explaining the record from scratch. Pre-reads also allow the customer to identify questions in advance, so that the team can prepare detailed answers with relevant evidence rather than searching for it during the meeting.

A productive acceptance review meeting has a defined agenda that covers the acceptance scope, the evidence review, the open items, and the acceptance decision. The acceptance scope component confirms what is included in the current acceptance and what is excluded, preventing the review from expanding into areas that were not prepared. The evidence review component walks through each acceptance criterion with the supporting evidence, allowing the customer to ask questions and request additional evidence for criteria they want to examine more closely.

The open items component covers any issues that were not fully resolved before the review, with a clear explanation of the resolution status, the evidence available, and the plan for closure during the warranty period or a subsequent review. The acceptance decision component is the formal outcome: acceptance with no conditions, acceptance with documented conditions, or deferral pending specific additional evidence. Each of these outcomes should be captured in the acceptance record with sufficient detail to define what the next step is and who is responsible for it.

A meeting that ends with a vague status of we need to discuss some things further is not an acceptance review; it is a status meeting that deferred the acceptance decision without a defined path to resolution.

Very few robot deployments reach the customer acceptance review with every issue resolved to a zero-open-items state. In practice, most acceptances involve a combination of fully resolved issues with complete evidence records, issues that are resolved to the deployment team's standard but where the customer wants additional evidence, issues that are in progress with a known resolution path, and issues that are accepted as known limitations with a documented operational workaround.

The handling of each category must be explicit in the acceptance record. Issues that are accepted with known limitations should have a clear description of the limitation, the conditions under which it manifests, the operational impact on the customer, and any steps the customer can take to manage around it. Issues that are in progress should have a documented timeline, responsible party, and criteria for closure.

Issues where additional evidence is requested should have a specific request documented and a commitment to provide the evidence by a specific date. Vague acceptance conditions such as pending review of open issues are not actionable and frequently become the source of disputes months later when the deployment team and the customer have different recollections of what was agreed.

Acceptance is not complete until the deployment knowledge has been formally transferred to the customer's operations team. Handover documentation serves two purposes: it gives the operations team the information they need to operate, maintain, and troubleshoot the system in day-to-day use, and it provides the base record against which warranty claims and post-acceptance issues will be evaluated. Handover documentation for a robot deployment typically includes the system configuration record (the full parameter set and software versions at acceptance), the deployment evidence record (the complete record of incidents, investigations, corrective actions, and retest outcomes), the acceptance test results (the formal performance measurements taken at or near acceptance), the known limitations register (a formal list of conditions under which the system has known performance constraints), the escalation and support contacts for warranty-period issues, and the change management process for any modifications to the system configuration after acceptance.

The operations team that takes on responsibility for the system without this documentation is operating without the institutional knowledge the deployment team built during commissioning, and any issue that arises after handover requires reinvestigation of history that was available in the deployment record.

A common question is whether the customer must accept the system even if they have unresolved concerns about specific behaviors. The answer depends on the contract terms, but in practice, acceptance decisions are almost always negotiated rather than unilateral. The customer's concerns should be documented specifically in the acceptance record, with the deployment team's response and the agreed resolution path.

Another common question is what happens when the customer accepts the system and then a failure appears that seems related to an issue that was resolved during deployment. This situation requires reference to the deployment record to determine whether the post-acceptance failure is a regression of the resolved issue (which may trigger warranty provisions) or a new failure mode that the deployment record does not cover.

A third common question is whether the customer's operations team needs to be involved in the acceptance review or whether the customer's project team representative can sign acceptance on their behalf. Best practice is to include the operations team in the final acceptance review so that operational concerns and limitations are understood by the people who will manage the system, not just by the project representative who may not be involved in day-to-day operations after handover.

The quality of the acceptance process has effects that extend well beyond the acceptance meeting. A customer who received a thorough, evidence-backed acceptance process with clear documentation of how every incident was resolved, what the system's known limitations are, and what the operations team needs to know to manage the system effectively, starts their operational relationship with the deployed robot with a foundation of informed confidence.

They know what the system was designed to do, what it actually does in their specific environment, and what conditions require operator attention. This informed confidence is qualitatively different from the blind confidence that results from a superficial acceptance process where the customer was told everything works and the evidence behind that claim was never examined. Blind confidence leads to operational surprises, which erode the customer relationship and generate warranty claims that could have been prevented by better disclosure at acceptance time.

Informed confidence, based on transparent evidence review, allows the customer to calibrate their operational procedures and staffing to the actual performance characteristics of the system. A customer who understands the system's performance envelope is less likely to blame the deployment team when the system operates at the edges of its specification, because they reviewed the evidence of that performance range during acceptance.

The acceptance record also becomes the foundation for expansion discussions: a customer who accepted a deployment with documented thoroughness is in a much better position to decide whether to expand to additional sites or additional robot types, because they have a reliable record of what the deployment process looked like at the first site. That record helps them evaluate the deployment team's capability accurately rather than relying on the deploying team's self-assessment.

The investment in a thorough acceptance process is an investment in the customer relationship well beyond the signature date.

• Prepare a pre-read package including the acceptance report and resolved incidents list for the customer before the review meeting
• Define the acceptance scope explicitly before the meeting to prevent scope expansion during the review
• Walk through each acceptance criterion with the supporting evidence rather than asserting that criteria are met
• Document every open item with a specific resolution plan, responsible party, and due date
• Capture the acceptance decision with any conditions or open items explicitly stated in the signed acceptance record
• Prepare handover documentation that includes the system configuration record and the full deployment evidence record
• Confirm that the operations team understands the known limitations register before they take operational responsibility
• Retain the complete deployment record through the warranty period for warranty claim and regression comparison