“Make it good” is not an acceptance condition. Neither is “client is happy.” Both matter, but they are too vague to guide work or settle completion.
Define done by describing the observable state that proves a deliverable is fit for its intended use. Do this before the final review, while there is still time to resolve different expectations.
Start from use, not format
A deliverable is not complete merely because the file exists. Ask:
- Who will use it?
- What must they be able to do?
- In which environment or format?
- What errors or exclusions are unacceptable?
- Who has authority to accept it?
- What evidence will demonstrate readiness?
For a website, “responsive” is vague. “The agreed pages remain usable without horizontal scrolling at the supported mobile widths” is testable.
PMI defines acceptance criteria as conditions required before deliverables are accepted and highlights exclusions as a way to manage expectations (PMI).
Write criteria in observable language
Strong criteria describe behavior and boundary:
- The export opens in the agreed spreadsheet application and preserves required columns.
- A new customer can complete the primary flow using the supplied instructions.
- The report reconciles to the approved source data as of the stated date.
- All agreed decision-makers have reviewed the final version by the cutoff.
- Known limitations are documented and accepted.
Avoid criteria such as “modern,” “intuitive,” or “best practice” unless examples make them observable.
Separate completion from improvement
Create three lists:
Required for acceptance: conditions tied to the promised outcome.
Known limitations: understood boundaries that do not block intended use.
Future improvements: useful ideas that are not part of current completion.
This stops late-stage polish from becoming infinite scope while keeping good ideas visible.
Review criteria early
Show a sample, prototype, or first slice against the conditions before most work is complete. If the client rejects the interpretation, changing direction is still affordable.
For subjective work, include reference examples and explain which qualities they represent. Do not ask a mood board to carry a business decision by itself.
Build a delivery packet
At handoff, provide:
- the final deliverable and version;
- acceptance evidence;
- instructions needed for use;
- known limitations;
- ownership or access transfer;
- open decisions, if any;
- acceptance date and approver.
The packet should let both sides distinguish “delivered,” “accepted,” and “later improved.”
Handle rejection constructively
If a deliverable is rejected, map each concern to an agreed condition. Fix genuine misses. Treat new preferences or changed needs as change requests. If the criterion was ambiguous, acknowledge that shared gap and agree on a fair clarification.
Combine clear acceptance with client onboarding so “done” is discussed before delivery pressure begins.
FAQ
How many acceptance criteria should a deliverable have?
Only enough to protect intended use and key boundaries. A short deliverable may need three to five; a regulated or integrated system may need far more.
Who should write the criteria?
You can draft them, but the accountable client approver must confirm them. Otherwise they remain your private interpretation.
Does acceptance end all responsibility?
No. Warranty, support, legal obligations, and agreed correction periods may continue. Define those separately from delivery acceptance.
Finish with evidence, not exhaustion
Projects should not end when the solo operator runs out of energy. They should end when the agreed result has been demonstrated and accepted. PlanovAI can preserve outcomes, acceptance conditions, versions, decisions, and open risks so completion becomes a shared fact instead of a negotiation from memory.