Why “to the client's satisfaction” is rarely enough.
Satisfaction describes an outcome. It does not necessarily provide a usable acceptance process.
In a tailored Agreement Build, Operative.law considers the deliverable, evidence, decision-maker, review process and applicable governing documents. The appropriate acceptance mechanism depends on the particular matter.
This guide is a design lens, not a universal clause.
The acceptance chain.
- 01
Deliverable
State what must be produced, including boundaries, exclusions and any client inputs on which delivery depends.
- 02
Evidence
Identify the record or output that shows delivery: a test result, delivery record, system output, report, file, demonstration or other appropriate proof.
- 03
Reviewer
Name the person, role or authorised representative who can decide. Delivery should not wait on an undefined group of stakeholders.
- 04
Review window
Give the reviewer a defined period and a route for raising specific reasons why the work does not meet the agreed standard.
- 05
Consequence
Connect valid acceptance or the agreed treatment of silence to the next step: correction, invoicing, payment, handover or project progression.
Objective where possible. Procedurally fair where judgment is unavoidable.
Some work can be tested against clear outputs: system behaviour, quantities, delivery records, agreed formats or defined milestones. Other work involves professional or aesthetic judgment that cannot be reduced to a binary test.
For judgment-heavy work, a tailored Agreement Build can consider the decision-maker, review process, reasons for rejection, revision structure and escalation path. Whether silence should have a contractual consequence depends on the particular matter.
The contract should not pretend that judgment has disappeared.
It should define who exercises that judgment, the agreed basis and the process by which the decision becomes commercially usable.
Payment and change must follow the same map.
If payment depends on acceptance, the invoice trigger should use the same deliverable, evidence and review process. A contract can appear to have a clear payment date while leaving the preceding acceptance event indefinitely open.
Change control matters because a revised deliverable may also require revised evidence, acceptance criteria, timing and price. The additional work should not reach delivery while the contract still records the original bargain.
Where Operative.law applies this work.
Contract Review
Tests existing paper for exposure across scope, evidence, acceptance, payment and change before signature.
Read the review guide →Agreement Build
Builds one service agreement or SOW package around the intended delivery and decision process.
Read the build guide →Contract Flow Design
Maps ownership, approvals, templates, records and handover when acceptance has become a recurring business process.
Read the Flow Design FAQ →This guide is general information, not legal advice. It does not create an attorney-client relationship and should not be copied into a contract without considering the specific deal and governing documents.
Want to test these controls in your own contract? Run the 10-minute Definition-of-Done Checklist first.