Most disputes on a build are not about what was delivered. They are about what someone assumed was included, and the document that was supposed to settle it listed deliverables and nothing else.
The sections below are the ones the Proposal & Scope Studio produces, in the order a client reads them. Four of them do almost all of the work of preventing a disagreement, and they are rarely the four people spend their time writing.
Start here
Four sections prevent almost every argument.
Acceptance criteria, exclusions, client responsibilities and change requests are the load-bearing parts of a scope document. Everything else describes the work; these four describe the boundary of it.
A deliverables list on its own says what will exist. It does not say when it is finished, what sits outside it, what the client has to provide for it to happen, or what occurs when someone asks for something new. Those are the four questions that actually get argued about.
| Section | The question it answers | What its absence costs |
|---|---|---|
| Acceptance criteria | How do we both know this is done? | "Done" becomes a matter of opinion at the exact moment the invoice is due |
| Not included | What did we agree is outside this? | Every reasonable-sounding extra arrives as an assumed inclusion |
| Client responsibilities | What do you owe, and by when? | Delays caused by missing content or access are attributed to the build |
| Change requests | What happens when the ask changes? | Scope grows without price or timeline moving, until someone objects |
The document
Twelve sections, and what each is for.
A scope does not need every section every time. It needs the ones that carry a real risk for this project, and it needs them specific enough to be checked.
| Section | What belongs in it |
|---|---|
| Project overview | The business problem in the client's language, not a summary of the technology |
| Objectives | What has to be true afterwards, phrased so someone could disagree with it |
| Deliverables | The artefacts that will exist: pages, screens, endpoints, documents, environments |
| Acceptance criteria | The condition under which each deliverable is finished |
| Requires assessment | Work that is genuinely in scope but cannot be priced until something is inspected |
| Not included | The reasonable assumptions this project is deliberately not covering |
| Client responsibilities | Content, approvals, access, credentials, decisions and their deadlines |
| Dependencies | Third parties, systems and approvals the timeline is exposed to |
| Timeline | Phases with the dependency that gates each one, not a single end date |
| Revisions | How many rounds are included per deliverable, and what counts as a round |
| Change requests | How a new ask is priced, approved and scheduled |
| Handover and support | What is transferred, in what form, and what happens after |
Honesty
Carry unpriceable work openly instead of guessing at it.
There is usually one item nobody can price yet: a migration off a system nobody has looked inside, an integration with an API whose documentation is a PDF from 2019, a data clean-up whose size is unknown until someone opens the export.
Two bad options are common. Pad the number to cover the worst case, which loses the work or overcharges for it. Or price it optimistically and absorb the difference, which turns into resentment on both sides halfway through.
The third option is to put it in its own section, say plainly that it is in scope and not yet priceable, state what has to be inspected before it can be, and carry it at nil in the total. The client sees a total they can act on and a named item that will change it. Nobody is surprised later.
Money
Milestones should be events, not dates.
"30% on 1 March" is a calendar entry. "30% on approval of the design phase" is a milestone: it is tied to something that either happened or did not, and it moves when the project moves.
Date-based milestones create the worst version of a delay — an invoice falling due for work that is blocked on something the client has not sent. Event-based ones make the dependency visible before it becomes a billing conversation.
The arithmetic has to close as well. Percentages that total 97% or 103% are common in hand-built documents and are noticed by exactly the person you do not want noticing them.
- Each milestone names the event that triggers it.
- The percentages total exactly 100, and the amounts total exactly the price.
- Any deposit is described as what it secures, not just as a number.
- Payment terms state the period and what happens if it passes.
- Tax treatment is stated once, explicitly, rather than implied by the total.
Boundaries
A proposal is not a contract, and a typed name is not a signature.
A scope document describes work and price. It becomes an agreement when both parties sign something that says so, under terms that cover liability, IP, confidentiality, termination and governing law. Those are not in a scope of work and should not be improvised into one.
An approval block on a PDF is a placeholder for a signature. A name typed into a form is not a verified electronic signature and does not execute an agreement, whatever the box says. Where the value or risk justifies it, use a proper signature service or a signed contract.
This matters more than it sounds. A well-written scope attached to no agreement is still useful — it is the shared description of the work — but it is not the thing that will be enforced.
Progressive disclosureTechnical Notes
Version the document
A scope that changes during negotiation should carry a version and a date. Two people quoting different paragraphs from documents both called "proposal.pdf" is a preventable problem.
Keep the pricing basis with the price
Whether a figure is tax-inclusive or exclusive belongs beside the figure, not in a footnote. It survives copy-paste into an email; a footnote does not.
Keep reading