Separate the output from the test of completion
A deliverable is something you hand over or make available to a client: a report, a set of designs, a configured workflow, or a training session. An acceptance criterion is a condition that helps the client and the project team decide whether that deliverable is complete. The distinction matters because naming an output does not settle what it must contain. “Website copy” could mean a single draft or approved text for every page.
Start by writing each deliverable as a specific item rather than a broad activity. “Conduct research” describes work; “provide a five-page summary of interview themes” describes an output. Include the intended format, scope, and recipient where useful. Then list the conditions the output needs to meet. Criteria should be observable enough that both sides can check them without having to guess what words such as “polished” or “user-friendly” mean.
Define scope with concrete examples and boundaries
For each deliverable, ask what is included, what is excluded, and what the client needs to supply. Suppose a small team is creating a customer onboarding guide. The description might specify a PDF guide of up to eight pages, covering account setup, the first three common tasks, and where to get help. It might also state that translation and screenshots of features still in development are not included. These boundaries give everyone a more useful reference point than “create onboarding materials.”
Turn the description into a short set of checks. For the guide, criteria might include: all three agreed tasks have numbered instructions; links and contact details supplied by the client appear in the relevant sections; and the final PDF opens and displays as intended in an agreed viewer. Avoid making criteria so detailed that they prescribe every creative choice. The aim is to establish a shared standard for completion while leaving room for the person doing the work to solve the problem.
Also distinguish a project goal from a deliverable criterion. Improving customer confidence may be the reason for the guide, but it may not be possible to verify that outcome at handover. The team can commit to producing a guide that meets agreed content and usability checks without promising a particular customer response.
Agree on the review process before work begins
Acceptance depends on more than the finished file. Decide who can provide consolidated feedback, when reviews will happen, and how comments will be recorded. If several people at the client organization are involved, ask them to resolve conflicting requests before sending a single response. Otherwise, a freelancer or small team may spend a review round acting on comments that another stakeholder later reverses.
Specify which version the client will review and what kind of feedback is appropriate at each stage. An outline review, for example, may be the time to correct missing topics; a final review may focus on whether the approved topics were covered and whether identified errors were fixed. Record the agreed number of review rounds and the response time each side is aiming for. If client approvals or source materials arrive late, revisit the schedule together rather than silently treating the original deadline as unchanged.
Set out how acceptance will be confirmed, such as a written approval from the named reviewer. Also decide how to handle a response that says the deliverable is not yet acceptable: the client should point to the unmet criterion and describe the issue. That gives the team a clear path to make a correction.
Make room for changes without losing the baseline
New information often appears after work starts. A client may request an extra page, a different audience, or an additional format. These may be sensible changes, but they should not be confused with corrections to an agreed deliverable. Keep the original description and criteria accessible, then record the proposed change, its effect on the output, and any effect on timing or effort. Agree on the revised scope before proceeding.
This approach need not be bureaucratic. For a short project, a shared document or follow-up email can capture the decision. The useful habit is to make changes visible to everyone who will review the work. Without a clear baseline, one person may judge the final output against the original request while another uses a later conversation that the project team never saw.
Use a brief handover checklist
Before sending a deliverable, check it against the agreed criteria yourself. Confirm that the promised files or access details are present, the format is correct, and known limitations are stated plainly. In the handover note, identify what is being submitted, which version it is, and what action you need from the client. If a criterion could not be met because an input was unavailable, explain that rather than presenting the work as complete.
Good acceptance criteria do not eliminate every disagreement. They make disagreements easier to locate and discuss. When both sides can point to the same deliverable, checks, reviewer, and review process, the conversation shifts from “This is not what I imagined” to “Here is the specific point we need to resolve.”
