What a scope document is for
A scope of work says what will be built, who supplies what, and how both sides will know it is finished. It is not there to win an argument later. It is there so the argument does not happen — by writing down, before anyone is invested, the things otherwise discovered at the worst possible moment: how many pages, who writes the copy, what counts as a revision round, and what "done" looks like in a form someone can actually check.
It is an operational planning document, not a legal agreement. It does not replace a contract and nothing here is legal advice. What it does is settle the questions a contract is too blunt to settle.
The template is below, and the whole kit — template, example brief, completed scope and a worked change request — is a free download. It is useful without buying anything.
The template
Fourteen sections. Where a fact is not known, write TBD and name who owes it and by when — a TBD is a visible gap, a guess is an invisible one.
| Section | What it settles |
|---|---|
| 1. Project summary | Who approves. One named person. |
| 2. Objectives | What success means, in the client's words. |
| 3. Deliverables, with counts | "A website" is not a deliverable. "Nine pages" is. |
| 4. Page and content inventory | The list both sides count against. |
| 5. Functional requirements | What it must do, each written so it can be demonstrated. |
| 6. Exclusions | Everything discussed and not agreed. |
| 7. Client responsibilities | What they owe, by when, and what happens if it is late. |
| 8. Dependencies | What neither of you controls. |
| 9. Milestones and their assumptions | Every date carries the assumption it rests on. |
| 10. Review rounds | How many, and what a round is. |
| 11. Acceptance criteria | Observable checks a stranger could run. |
| 12. Change-request process | Classify first, price second. |
| 13. Handoff | What transfers, and what they can safely change. |
| 14. Open questions and assumptions | What you do not know, and what you decided without being told. |
Three of those do most of the work, and they are the three people skip.
Exclusions. Everything the client said "maybe" about, named. In the worked example, online booking is excluded in writing in March — which is why a request for it in May takes a paragraph to answer instead of a week.
Assumptions. What you decided without being told. When one turns out to be wrong you annotate it with the date rather than deleting it, and in six months the question "why doesn't the site do that?" has an answer written at the time.
Open questions. A visible TBD with an owner and a date beats a plausible guess every time. The guess is indistinguishable from a fact once it is on the page.
What you need before you can draft
Ten things. Anything missing stays missing — it does not get invented:
- Business objective. Why now, not what pages.
- Website type. Brochure, store, application, or a mix.
- Pages and content types. The count is the number everything else keys off.
- Functional requirements. Forms, search, filtering, logins, anything that does something.
- Integrations. Analytics, CRM, email, booking, payment.
- Existing assets. Copy, photography, logo, brand guidelines — and what format they are really in.
- Required client inputs. What you cannot start without.
- The approver. One person.
- Constraints. Date, budget, platform, hosting, accessibility obligations.
- Unanswered questions. An explicit list, not an absence.
The tenth is the one that separates a scope from a wish list. A first call never produces all nine of the others, and a scope that reads as though it did is a scope where somebody filled the gaps from imagination.
A completed example
The kit includes a full worked example for Harbourline Physiotherapy — a fictional two-clinic practice. It does not exist; the names, dates and effort figures were invented to demonstrate the workflow, and the costs are not market rates.
It runs from first-call notes ("built by someone's nephew", "maybe online booking eventually", "live before the summer") through to a scope with nine pages, seven demonstrable requirements, twelve named exclusions and four assumptions. Two details worth lifting:
An objective that was refused. The client asked for more enquiries. The scope does not promise a number:
Not an objective: "more enquiries" as a number. The site can make enquiring easier and measurable. It cannot commit to a volume, and a scope that promises one is promising something outside the builder's control.
A date that carries its assumption. "Before the summer" became a milestone table where every row names what it rests on, plus this note:
The binding one is C1: copy for nine pages by 11 April. If that slips a fortnight, launch slips a fortnight. This is stated now rather than negotiated in May.
That paragraph is the single highest-value sentence in the document. Every freelancer has had the conversation where a client who supplied copy three weeks late is surprised that launch moved. It is a much easier conversation when the scope said so in March.
Vague requirement, bounded requirement
Most scope disputes trace back to a sentence that sounded agreed and meant two things. The fix is mechanical: replace the adjective with a count, and add the check.
| As it arrives | As it should be written | Why |
|---|---|---|
| "A modern, professional design" | "Three page layouts — home, service, contact — presented as designs for approval. Two rounds of feedback each." | "Modern" is not checkable and cannot be finished. A count of layouts and rounds can be. |
| "The site should be fast" | "Each of the nine pages returns its main content within 2.5 seconds on a mid-range Android over a 4G profile, measured on the staging URL before launch." | Names what is measured, where, and on what. Without that, "fast" is settled by whoever is more insistent. |
| "Mobile friendly" | "No page scrolls horizontally at 390px, and all interactive controls are at least 44px tall. Checked on a real device." | Two observable facts instead of a category. |
| "SEO optimised" | "Each page has a unique title and meta description; the sitemap includes all nine pages; every old URL redirects in one hop. No ranking outcome is promised." | Deliverables you control, and an explicit refusal of the outcome you do not. |
| "And anything else needed to launch" | Delete. Replace with the exclusions list. | This clause has no edge. It is the single most expensive sentence in freelance web work. |
| "A few rounds of revisions" | "Two rounds per deliverable. A round is one consolidated set of feedback from the approver. Typos and anything that does not match this scope are fixes and are not counted." | "A few" is two to you and five to them. The definition of a round matters as much as the number. |
The email that arrives in week six
From the worked example. Three requests in one friendly message — and they are three different things:
Hi — a few bits after the team looked at staging:
1. Can we get the Contact page phone number bigger on mobile? It's tiny.
2. Rav wants to add a fourth service — dry needling. Same as the others.
3. We've decided we do want online booking after all. The team all use Cliniko, is it just a case of plugging it in?
Classify each against the scope before estimating anything.
| Request | Class | Because | Outcome |
|---|---|---|---|
| Phone number too small on mobile | In scope | Requirement F7 says pages are usable at 390px. A phone number too small to read fails it. | Fixed. No charge. Does not consume a review round. |
| A fourth service page | Out of scope | Section 4 lists nine pages; section 6 excludes "a fourth or subsequent service page" by name. | Estimated separately: 3 hours, no schedule impact if copy arrives by a stated date. |
| Online booking via Cliniko | Out of scope, and larger than it looks | Excluded by name — and assumption A1 says the site handles no patient or health data. Booking makes A1 false. | Deferred to a separate phase, with the reasoning given. |
And the third class: ambiguous
Not every request sorts cleanly. Suppose the same email had also said "and can the team photos be tidied up a bit?"
The scope says the client supplies six headshots (C2) and excludes photography (section 6). It says nothing about retouching supplied images. That is genuinely unclear — not the client being unreasonable, and not you being caught out. It is a gap.
Ambiguous is its own answer, and saying so is not a weakness:
"Good question — the scope covers you supplying the headshots and excludes photography, but it does not say anything either way about retouching the ones you send. That is a gap on my side. Cropping and straightening I will do as part of the build. Anything beyond that — background removal, colour matching across six photos — is closer to photo editing, so I would rather scope it than absorb it quietly and get it wrong. Which did you have in mind?"
Then the scope is updated so it is not ambiguous next time. An ambiguity you resolve in writing stops being one; an ambiguity you absorb silently becomes a precedent.
On tone
Notice what the reply does not do: it does not lead with cost. Two of the three requests are answered before money is mentioned, and one is simply done. A change process that prices every question teaches a client to stop asking questions — and a client who stops asking is a client discovering problems at launch instead of in week six.
What you check before sending
A drafted scope is not a sendable scope. Before it goes:
- Every count is real. Page count, revision rounds, deliverables — check them against your notes, not against the draft's own internal logic.
- Every date has its assumption. A bare date is a promise about things you do not control.
- Every exclusion the client mentioned is listed. Reread your notes for "maybe", "eventually", "would be nice". Each one is an exclusion or a deliverable — never nothing.
- No invented facts. Anything the draft states that you were not told is either an assumption (label it) or a question (list it).
- Acceptance criteria are observable. Hand one to someone who was not in the meeting: could they run it?
- The approver is one person.
- No legal language you cannot stand behind. Penalty clauses, indemnities, liability caps — leave them to the contract.
- Nothing confidential in the working files. Sanitise before drafting: no credentials, no patient or customer data, no access tokens. The brief in the kit is deliberately written as sanitised notes for this reason.
Two prompts
The first turns sanitised notes into an internal draft. It sends nothing to anyone.
Draft an internal website scope of work from the client notes I paste below. This is a draft for me to review. It is not for the client. FACTS - Use only what the notes state. Do not add pages, features, integrations, timelines or budgets that are not there. - Anything not stated is TBD. Write "TBD" and name who owes the answer and by when. Never fill a gap with something plausible. - Where I clearly decided something without being told, record it under Assumptions with what happens if it turns out to be wrong. Do not record it as a fact. STRUCTURE 1 Project summary (client, project, date, version, ONE named approver) 2 Objectives 3 Deliverables with counts 4 Page and content inventory 5 Functional requirements 6 Exclusions 7 Client responsibilities, each with a date and the effect of being late 8 Dependencies 9 Milestones, each with the assumptions it rests on 10 Review rounds, including a definition of what a round is 11 Acceptance criteria 12 Change-request process 13 Handoff requirements 14 Open questions and assumptions RULES - Deliverables get counts. "A website" is not a deliverable. - Every requirement in section 5 needs a column saying how it will be demonstrated. If you cannot write that column, move it to open questions. - Anything the notes describe as "maybe", "eventually" or "would be nice" goes in Exclusions by name, not in Deliverables. - Acceptance criteria must be observable by someone who was not in the meeting. No "works correctly", no "looks professional". - Every milestone date states what it assumes. A date without one is not acceptable output. - Do not write legal clauses. No penalties, no indemnities, no liability terms, no warranty language. This is a planning document. - Do not state a price, a rate or a total unless the notes contain one. BEFORE YOU FINISH List separately: every fact you took from the notes, every TBD, and every assumption. I want to check your sources before I check your prose. Output the draft as a Markdown file. Do not draft an email. Do not address the client. Do not send anything.
The second compares a new request against the approved scope. Run it when the email arrives.
Compare this client request against the approved scope document. Read the scope first. Then, for EACH separate request in the message — there is usually more than one, even when it reads as a single ask — tell me: 1. CLASSIFICATION: in scope / ambiguous / out of scope. 2. THE EVIDENCE: quote the exact section, requirement id or exclusion that decides it. If nothing in the scope decides it, the answer is ambiguous — say so rather than choosing the reading that suits me. 3. FOR AMBIGUOUS: name precisely what the scope does not say, and suggest the wording that would settle it in future. 4. FOR OUT OF SCOPE: what it would involve, what it depends on, and whether any assumption in section 14 stops being true if we do it. Flag that loudly — an assumption breaking is more important than the hours. Do not produce a price. Do not assume everything out of scope is chargeable; some things are worth absorbing and that is my call, not yours. Then draft a reply for me to edit. It must: - answer each request separately, in the order they were asked - lead with the ones I am simply doing, before anything about cost - explain any refusal in terms of the scope, not in terms of effort - ask a question where I genuinely need an answer I send it, not you. Do not email anyone.
Download the kit
Four connected Markdown files: the blank template, the example brief, the completed scope, and the change request. Read them in that order — the change request only makes sense against the scope, and the scope only makes sense against the brief.
Or build one in the browser: the Website Scope Builder takes the same fourteen sections and prints a visible TBD with an owner for anything you leave blank, rather than quietly omitting it. It also flags open-ended wording and acceptance criteria that could not be checked by someone who was not in the meetings. Sanitise the notes first — it keeps nothing, but that is a habit worth having anyway.
Questions
Is a scope of work a contract?
No. It records what will be built and how both sides know it is finished. A contract governs payment, liability, ownership and termination. Many freelancers attach a scope to a contract, which works well — but the scope is not doing the contract's job, and this template deliberately contains no legal clauses.
How long should it be?
The example runs to about four pages for a nine-page brochure site. Long enough to count the deliverables and state the exclusions; short enough that the client reads it. If it is too long to read, the parts that matter will not be read either.
What if the client will not answer the open questions?
Then they stay open, visibly, with a date and an owner. Some will be answered when the absence starts costing someone something. What you must not do is close them by guessing — a guess in a scope document is indistinguishable from a fact a week later.
Should every out-of-scope request be charged?
No, and a process that assumes so will cost you more than it collects. Classify first. Some out-of-scope requests are twenty minutes and worth absorbing for the goodwill; some are a separate project. The classification is the discipline; the pricing is a judgement you make afterwards.
Can I use Claude Code on real client notes?
Sanitise first. Remove names, credentials, access tokens, and any customer or patient data. The example brief in the kit is written as sanitised notes deliberately — you rarely need the real identifiers to draft a scope, and the ones you do need you can put back yourself.
Next action
Take your current project and write only section 6 — the exclusions. Ten minutes. If you can list five things the client has mentioned that are not in the build, you have just found this month's most likely dispute, and you can settle it today by email while nobody is annoyed.
Related reading: Claude Code Website Audit covers the pre-launch checks that turn into acceptance criteria, and How to Create a Production CLAUDE.md covers the per-project rules file that keeps a build matching the scope it was agreed against.