Customer acceptance
Acceptance is a defined event with defined evidence. Satisfaction is measured along the way, at milestones, so that a problem is corrected before closure rather than documented after it.
The standard. A defined acceptance process with clear handoff responsibilities and acceptance criteria, plus satisfaction checkpoints at each project milestone.
Acceptance criteria
Defined in the statement of work before delivery begins:
| Criterion | Evidence |
|---|---|
| Deliverables delivered | Each item accessible and matching its description |
| Functional testing complete | Test results recorded and reviewed |
| User acceptance testing complete | UAT scenarios passed within the acceptance window |
| Training delivered | Attendance and recordings |
| Documentation handed over | Customer review record |
| Operational readiness | Drill results: deploy, rollback, restore |
Acceptance process
Readiness review The delivery team confirms every deliverable against its criteria and assembles the evidence pack.
Customer review The customer reviews deliverables and evidence within the agreed window and raises any gaps.
Correction Gaps are corrected within an agreed period. A correction that changes scope becomes a change request.
Verification session The customer performs the key operations unaided: deploy, roll back, restore.
Formal sign-off The acceptance record is signed by the customer's authorised representative.
Closure Closure report, retrospective, and transition to support.
When the customer does not respond
The SOW defines the rule. A common and defensible default: if no issues are raised within the review window, the deliverables are deemed accepted, and the record states that the window elapsed. Silence is not the same as approval, so the rule is written down rather than assumed.
Satisfaction checkpoints
Measured at every milestone, not only at the end.
| Checkpoint | When | Instrument |
|---|---|---|
| Kick-off | After scope is confirmed | Short pulse survey |
| Discovery complete | After workshops and interviews | Structured feedback |
| Design approved | After architecture sign-off | Pulse survey |
| Pilot complete | After the pilot decision | Pilot feedback report |
| UAT complete | Before production | Satisfaction survey |
| Handover | At acceptance | Post-delivery questionnaire |
| Post-engagement | 30–90 days later | Relationship survey |
Questions that produce useful answers
- Is the work meeting your expectations? Where does it fall short?
- Do you understand what is being built and why?
- Are you getting the information you need, at the frequency you need it?
- Is the team responsive when you raise an issue?
- Would you recommend working with us? Why or why not?
A satisfaction score without a reason is not actionable. Always ask why.
Responding to feedback
| Signal | Response |
|---|---|
| Score drops at a checkpoint | Discuss at the next steering meeting; agree corrective action |
| Repeated concern across customers | Process change, not a project change |
| Individual escalation | Direct conversation with the sponsor within 48 hours |
| Positive but low-confidence | Ask what would need to change for a higher score |
Feedback is closed with the customer — they are told what changed as a result. Otherwise the next survey measures their cynicism, not their satisfaction.
Closure
| Artefact | Content |
|---|---|
| Acceptance record | Criteria, evidence, sign-off |
| Project completion report | Outcomes against objectives, KPIs, deviations |
| Post-implementation review | What worked, what did not, what to change |
| Final satisfaction result | Score, verbatim feedback, actions taken |
| Handover pack | Documentation, runbooks, training recordings |
| Support transition | Who supports what, from when, how to escalate |