Acceptance criteria

The written checklist that decides when a deliverable is done and payable, so 'done' stops being a matter of opinion.

how we agree it's finishedthe definition of doneaceptance criteriawhat counts as donesign-off conditionsthe done checklist in the contractconditions for approvalwhen is the deliverable actually finished

See it

Live demo coming soon

What it is

Acceptance criteria are the written conditions that make a deliverable done: specific, checkable statements agreed before the work starts. 'The homepage looks good' is not one. 'The homepage renders correctly at 375px, 768px and 1440px, scores 90 or above on Lighthouse accessibility, and matches the approved Figma frames' is. Agile teams hang them off user stories, often in given/when/then form. Client contracts hang them off milestones, where they decide when an invoice becomes payable.

Reach for them on every milestone and every fixed-price deliverable. They are the antidote to infinite revision: once the criteria are met the deliverable is accepted, and everything after that is a change order. Write them so a stranger could check the list without asking you what you meant, and include the boring items (browsers supported, page count, source files handed over, who owns hosting).

Gotcha: criteria are useless without a deadline for checking them. Add a deemed-acceptance window, typically 5 business days, after which silence counts as acceptance. And keep taste out of the list entirely. Subjective judgement belongs in your capped revision rounds, not in the definition of done, or 'done' quietly becomes 'until they are happy'.

Ask AI for it

Write acceptance criteria for this deliverable: [describe it]. Give 6 to 10 numbered criteria that someone who was not in the meetings could check objectively. First work out what kind of artifact this is (a built interface, a brand identity, a written piece, a research output, a video, a data deliverable) and pull only from the dimensions that actually apply to it: functional behaviour, file formats and specs, completeness against an agreed list, compatibility or platform requirements, measurable quality thresholds, what gets handed over and in what form, and which approvals are required. Do not add web performance, browser, or device requirements unless the deliverable is a website or app. Every criterion must be pass or fail with no adjectives like 'polished' or 'clean'. Where a decision has not been made yet (a target number, a supported platform, a named approver), list it as an open question instead of guessing. Then add a deemed-acceptance paragraph: the client has 5 business days to respond in writing with specific failures against these criteria, otherwise the deliverable is accepted and invoiceable.

You might have meant

client sign offmilestone billingrevision roundsscope of work exclusionsstatement of work