Practical working guide
Turn project acceptance criteria into a checkable matrix
Make acceptance criteria testable by linking each agreed requirement to a check, expected outcome, reviewer and evidence. Separate pass, fail and blocked results. Completion of a task list does not prove that the customer’s agreed requirements were met.
A worked acceptance matrix
| Requirement | Details |
|---|---|
| Enquiry reaches correct team | Check: Submit a labelled test enquiry Expected outcome: One record with the correct owner Recorded result: Pass: reference TEST-18 |
| Customer can correct an error | Check: Submit missing contact details Expected outcome: Clear message; valid answers preserved Recorded result: Fail: description erased |
| Authorised customer reviews handover | Check: Open restricted delivery link Expected outcome: Only intended reviewer can access Recorded result: Blocked: reviewer unavailable |
Make the evidence meaningful
The rows above are fictional examples, not a test report for Client Craft. In your own matrix, record the version, environment, date and person running the check. Evidence can be a record reference, measurement or authorised screenshot. Avoid “works well” as an expected result: it does not tell a reviewer what to observe. Use a separate row when a requirement has materially different success and failure conditions.
Handle exceptions without relabelling them
Assign failed checks an owner and correction plan. A blocked check stays blocked until its prerequisite is available; it is not a pass. If the customer accepts a known limitation, record the precise exception, affected requirement and decision separately. Recheck only the corrected behaviour and affected dependencies. This worksheet organises operational evidence; it does not replace contractual acceptance terms.
Keep a failed result alongside its later passing recheck, linked by the same requirement, so the correction remains traceable.