Robot Acceptance with Conditions: A Deployment Guide

Conditional acceptance means that the customer agrees to accept operational responsibility for the robot system and to proceed with handover, while reserving the right to enforce specific conditions that address identified open items. The conditions may require the deploying team to deliver a software update that addresses a known defect within a specified period. They may require the deploying team to provide additional evidence for acceptance criteria that were not fully verified before acceptance.

They may require the deploying team to return to the facility for additional commissioning activities at a specified point after handover. They may require the operator to implement operational constraints that compensate for a system limitation until a technical remedy is available. Conditional acceptance is appropriate when the open items do not prevent the customer from deriving value from the deployment, when the deploying team is committed to and capable of delivering on the conditions, and when the customer has sufficient confidence in the deploying team's commitment to proceed with handover rather than waiting for complete resolution.

It is not appropriate when the open items represent safety issues that make it unsafe to operate the system, or when the deploying team cannot credibly commit to the conditions.

A conditional acceptance record must document each open item that is the subject of a condition, the specific condition that applies to that item, the responsible party for delivering on the condition, the deadline or milestone by which the condition must be met, and the evidence required to confirm that the condition has been met. Each open item should be described with enough specificity to distinguish it from other open items and to define what a satisfactory resolution looks like.

The condition should be written in terms of a specific deliverable or observable outcome, not a vague commitment to address the item. The responsible party should be identified by organizational role, not only by individual name, so that the responsibility is maintained if the named individual leaves the project. The deadline or milestone should be specific: a calendar date, a software release event, or a defined operational milestone, not an open-ended commitment to address the item when possible.

The evidence required to confirm the condition should be defined before the conditional acceptance is signed, not left to be negotiated after the fact.

Conditions agreed at acceptance must be tracked actively through the warranty period to ensure they are met. The tracking process should include periodic reviews of the condition record at defined intervals after acceptance; notifications to the responsible party as deadline milestones approach; a formal confirmation process when the responsible party believes a condition has been met, including the submission of the required confirmation evidence; and a review by the customer to confirm that the submitted evidence satisfies the condition.

Conditions that are not met by their deadline should be escalated through the commercial process rather than silently deferred: a missed condition deadline is a commercial event that may entitle the customer to remedies under the acceptance terms. The condition tracking record should capture each review event, each evidence submission, and each confirmation or rejection decision, creating an auditable history of the condition's progress from the acceptance date to its final resolution or escalation.

A condition is closed when the responsible party delivers the required evidence and the customer confirms that the evidence satisfies the condition. The closure process should be formal: the responsible party submits the evidence through a defined channel, the customer reviews it against the condition definition within a defined review period, and the customer provides a written confirmation of closure or a written explanation of why the evidence is insufficient.

A condition that is closed by the responsible party's internal determination, without customer confirmation, is not formally closed; it remains open until the customer confirms. The condition closure record should include the submitted evidence, the date of the customer's review, and the customer's closure confirmation. Conditions that are closed as remediation events may also require an update to the acceptance record if the condition addressed a previously unverified acceptance criterion: the remediation evidence should be linked to the acceptance criterion it satisfies, completing the acceptance record in a way that reflects the as-remediated state of the deployment.

Conditional acceptance records are commonly referenced in post-acceptance disputes about warranty obligations, service level agreements, and remediation responsibilities. A well-documented conditional acceptance record that accurately describes the open items, the conditions agreed, and the timeline commitments provides a clear factual basis for resolving disputes about whether conditions were met and whether the deploying team fulfilled its acceptance obligations.

A poorly documented conditional acceptance record - one that describes conditions vaguely, does not specify who is responsible, or does not define what evidence is required for closure - creates disputes where both parties have different recollections of what was agreed and neither has documentation that resolves the dispute definitively. The investment in a detailed and explicit conditional acceptance record is therefore an investment in the efficiency of any post-acceptance commercial process, whether that process is a straightforward condition closure or a disputed warranty claim.

• Define the conditions precisely: specific deliverable or outcome, responsible party by role, deadline or milestone, and required confirmation evidence
• Confirm that the open items subject to conditions do not prevent safe operation before proceeding to conditional acceptance
• Obtain customer signature on the conditional acceptance record that includes the complete condition list
• Establish a tracking mechanism for each condition with defined review intervals and escalation triggers
• Send deadline reminder notifications to the responsible party in advance of each condition deadline
• Document each evidence submission and customer confirmation or rejection decision in the condition tracking record
• Close conditions formally with customer confirmation rather than unilateral responsible party determination