Robot acceptance readiness

A project may be on schedule according to the deployment timeline while being far from acceptance-ready in terms of the evidence record. Schedule readiness means the planned tasks have been completed within the allocated time. Acceptance readiness means the deployment has produced the specific evidence that demonstrates the system meets the agreed acceptance criteria, and that every failure that occurred during the deployment has been resolved with a documented root cause, a verified corrective action, and preserved retest evidence.

These two measures are related but not equivalent. A team can complete all planned commissioning tasks on schedule and still have unresolved incidents that block acceptance. Conversely, a team that encountered significant failures during commissioning may have resolved them thoroughly and be acceptance-ready, even if the resolution process extended the project timeline.

The practice of conflating schedule status with acceptance readiness leads to acceptance review meetings that surface resolution gaps the deployment team should have identified and closed before the customer arrived. Treating acceptance readiness as a distinct measure from schedule status, assessed against an explicit checklist of evidence and resolution requirements, prevents this pattern.

Acceptance readiness can only be assessed against acceptance criteria that are specific enough to measure. Criteria stated at the level of the robot will navigate reliably in the facility cannot be assessed because they do not define what reliably means, what navigation encompasses, or under what facility conditions the assessment should be made. Criteria stated at the level of the robot will complete 99 percent of assigned pick-to-drop tasks in zones A through D without operator intervention over a 72-hour continuous test window, with all unassisted failures documented and classified by root cause, is assessable because it defines the measurement method, the scope, the threshold, and the documentation requirement.

The investment in writing criteria at this level of specificity is typically done during the contract or project planning phase, and the deployment team is often responsible for translating general commitments from the contract into specific measurable criteria for the acceptance test. When that translation is not done until the acceptance review is imminent, the team and the customer often discover that they have been operating against different implicit criteria, and the acceptance review becomes a negotiation about what was promised rather than a review of evidence against an agreed standard.

The pre-acceptance review is an internal deployment team assessment conducted before the formal customer acceptance review, with the explicit purpose of identifying and closing any remaining gaps in the evidence record or the resolution record. The pre-acceptance review should work through each acceptance criterion and confirm that the evidence attached to it supports the claimed result. It should work through each incident in the deployment record and confirm that every acceptance-blocking incident has a complete resolution record: incident description, root cause statement, corrective action record, verification test design, and verification test outcome.

It should identify any issues that were closed as low-severity during the deployment and confirm that they were correctly classified, not that they were classified low-severity to avoid the work of a formal resolution record. It should also confirm that the acceptance report being prepared accurately represents the deployment record and does not claim resolutions that the underlying record does not support. A pre-acceptance review that surfaces gaps gives the deployment team time to close them before the customer's calendar commitment; gaps that surface during the customer review cost credibility in addition to time.

The most reliable measure of acceptance readiness is evidence completeness: the proportion of acceptance criteria and resolved incidents that have complete, linked evidence records. An acceptance criterion with a performance result but no supporting data is not evidence-complete. A resolved incident with a corrective action record but no verification test outcome is not evidence-complete.

A verification test outcome with no configuration state documentation is not evidence-complete. Working through the deployment record systematically and marking each element as evidence-complete or evidence-incomplete produces an accurate readiness picture that identifies exactly which gaps remain to be filled. This is a more reliable measure than a completion percentage based on ticket closure status, because closed tickets frequently lack the supporting evidence that would make them defensible in an acceptance review.

Teams that assess readiness against evidence completeness rather than task completion find that the pre-acceptance review reliably surfaces the same gaps that would otherwise appear during the customer review, giving the team the opportunity to close them in advance.

A deployment team that presents a customer acceptance review without first aligning internally on the state of the deployment record frequently creates a situation where different engineers give different answers to the same customer question, each drawing from their individual knowledge of the part of the deployment they managed. The customer experiences this as confusion and inconsistency in the deployment record rather than as normal specialization of roles, because the customer expects a coherent account of the deployment, not a mosaic assembled on the spot from different engineers' partial views.

Achieving internal alignment before the customer review requires the deployment manager to review the complete deployment record with the full team before the customer meeting, to ensure that everyone can speak to the same facts from the same source rather than from separate mental models. This review also surfaces the situation where one engineer believes an issue was resolved because it was closed in a ticket, while another engineer knows the resolution is incomplete because the retest was deferred.

A common question is who has the authority to declare that a deployment is acceptance-ready. In most deployments, the declaration is made by the deployment manager or the project lead, but the declaration should be based on a formal readiness checklist reviewed and signed off by the full team, not on the deployment manager's individual assessment. Another common question is what to do when the deployment is not acceptance-ready but the customer's acceptance review meeting is scheduled and cannot be postponed.

The recommended approach is to present the current state of the deployment record honestly, including which criteria are fully satisfied with evidence, which issues are resolved, and which items remain open, with a specific plan and timeline for closing the remaining gaps. Customers who receive an honest readiness assessment with a credible closure plan generally respond better than customers who are led into a review that reveals gaps they were not warned about.

A third question concerns partial acceptance: whether a customer can formally accept a subset of the deployment scope while other areas remain in progress. This is often possible if the acceptance criteria can be scoped to the ready areas, but it requires explicit documentation of what is and is not included in the partial acceptance to avoid disputes later.

One of the most consistent sources of inaccuracy in robot deployment project timelines is the gap between the schedule-based completion estimate and the evidence-based acceptance readiness estimate. Schedule-based estimates project acceptance based on the completion of planned tasks. Evidence-based estimates project acceptance based on the current state of the resolution record: which acceptance-blocking incidents are resolved with evidence, which are in progress with known resolution paths, and which are not yet investigated.

When these two estimates diverge, the schedule-based estimate is almost always optimistic, because it does not account for the investigation and verification work still required to close open incidents to an evidence standard. Running a systematic acceptance readiness assessment at regular intervals during the deployment, rather than only at the end, produces a running evidence-based estimate that the deployment team can use to communicate realistic expectations to the customer and to the project management team.

The assessment does not require a formal audit; it requires the deployment manager to work through the incident register and assess each open item against the criteria for evidence-complete closure. This review typically surfaces items that the field team has marked as in progress but that are actually blocked: waiting for a software update with no committed date, or waiting for a facility modification that has not been scheduled.

By identifying these blocked items early, the deployment manager can escalate to the responsible party with enough lead time to unblock the item before it becomes a constraint on the acceptance date. The discipline of regular readiness assessments also changes the deployment team's relationship to the evidence record: when readiness is assessed regularly against evidence standards, the team is motivated to maintain thorough records throughout the project rather than scrambling to complete the record at the end.

• Translate contract commitments into specific, measurable acceptance criteria before commissioning begins
• Confirm that every incident classified as acceptance-blocking has a complete resolution record before declaring readiness
• Verify that every acceptance criterion has supporting evidence attached to it, not just a completion note
• Review low-severity closures to confirm they were correctly classified and not used to avoid formal resolution records
• Conduct a pre-acceptance internal team review to surface evidence and resolution gaps before the customer meeting
• Align all deployment team members on the current state of every open and closed issue before the acceptance review
• Confirm that the acceptance report being prepared accurately represents the underlying deployment record
• Prepare specific closure plans for any items that will be presented as in progress during the customer review