Before you use this: this is a practical business document, not legal advice, and it hasn't been reviewed by a lawyer. It handles the everyday situations freelancers run into. For high-value projects or anything you couldn't afford to lose, have a qualified solicitor or attorney check it first.
Why the exclusions section matters more than everything else
Most freelancers write down what they're delivering. Very few write down what they're not. That single omission is where almost every scope dispute comes from — and the client is usually being completely sincere when they say they assumed it was included.
Put yourself in their position. You've been quoted for "a website." You've never commissioned one before. Does that include the writing? Hosting? Setting up the email addresses? Training someone to update it? A reasonable person could assume any of those. If nothing says otherwise, why wouldn't they?
An exclusions list isn't defensive. It's the most useful two minutes in the whole document. It converts a future argument about fairness into a present-tense conversation about price, held before anyone is invested.
The template — full text
Copy everything inside the box. The highlighted parts are the blanks you fill in. Works in Word, Google Docs, or pasted into an email.
1. Project Overview
Prepared for: [Client name / company]
Prepared by: [Your name / business]
Date: [date] · Valid until: [date, e.g. 30 days from now]
[One or two sentences describing the project in plain language — what it is and what it's for. Example: "A five-page marketing website for a physiotherapy clinic, intended to generate enquiries from local search."]
2. Deliverables — What Is Included
The following will be delivered as part of this project:
- [Deliverable 1 — be specific. Not "homepage design" but "homepage design, delivered as a Figma file plus a built responsive page"]
- [Deliverable 2]
- [Deliverable 3]
File formats provided: [e.g. Figma source, exported PNG/SVG, live staging URL]
3. Exclusions — What Is Not Included
The following are not part of this project and are not covered by the fee:
- [e.g. Copywriting — client supplies all text]
- [e.g. Stock photography or icon licences]
- [e.g. Hosting, domain registration and ongoing maintenance]
- [e.g. Third-party plugin or software subscription costs]
- [e.g. Training, documentation, or post-launch support beyond 14 days]
- [e.g. Additional page templates beyond those listed in section 2]
Any of the above can be added by written agreement and will be quoted separately.
4. Timeline & Milestones
Start date: [date, or "on receipt of deposit and materials"]
Delivery date: [date or number of working days]
- [Milestone 1 — e.g. Concepts delivered — day 5]
- [Milestone 2 — e.g. Client feedback due — day 8]
- [Milestone 3 — e.g. Final files delivered — day 15]
Where the client delays in supplying materials, feedback or approval, the delivery date moves back by the same number of days as the delay.
5. Client Responsibilities
To keep the project on schedule, the client will provide:
- [e.g. All written copy, by day 3]
- [e.g. Logo files, brand guidelines, and product photography]
- [e.g. Login credentials for hosting and any third-party accounts]
- [e.g. A single named point of contact with authority to approve work]
Feedback and approvals will be returned within [number] working days of request.
6. Revisions
This project includes [number, e.g. two] rounds of revisions.
One round means a single consolidated set of feedback covering the whole deliverable, sent in one message. Feedback sent piecemeal across multiple messages will be treated as separate rounds.
A revision refines work already agreed — adjusting spacing, changing a colour, rewording a heading. A change of direction — replacing an agreed concept, restructuring the layout, or changing the brief — is new work and will be quoted separately.
Additional rounds beyond those included are charged at [rate].
7. Fees & Payment
Total project fee: [amount and currency]
- [e.g. 50% deposit — due before work begins]
- [e.g. 50% balance — due on delivery of final files]
Invoices are payable within [number] days. Ownership of the completed work transfers to the client on receipt of full payment.
Approval
By signing below, both parties agree to the scope, timeline, revision terms and fees set out above.
Client: [name] — Signature: ____________________ — Date: __________
Contractor: [name] — Signature: ____________________ — Date: __________
Short on time? Sections 2, 3 and 6 alone prevent most disputes. If you send nothing else, send those three. A partial scope of work beats a perfect one you never got round to writing.
How to fill in the sections people get wrong
Section 2 — write deliverables the way an outsider would read them
The test is whether someone who wasn't in your conversation could read the list and know exactly what arrives. "Homepage design" fails that test. "Homepage design, delivered as a Figma file plus one built responsive page, desktop and mobile" passes it.
Include the file formats. A surprising number of end-of-project arguments are really about a client expecting editable source files when you planned to hand over exports.
Section 3 — write it as if arguing with a reasonable person
Not a difficult client. A reasonable one, who simply doesn't know your industry's conventions. What might they fairly assume was covered? Those assumptions are your exclusions list.
Six lines is usually enough. The most commonly missed: copywriting, image licences, hosting, training, ongoing maintenance, and anything involving a third party's fees.
Section 4 — the delay clause is doing quiet work
The most common reason a project overruns isn't your speed. It's a client taking nine days to approve something while the deadline stays where it was. One sentence saying delivery moves back by the length of the delay turns that from your problem into a shared one — and you never have to argue the point, because it's already agreed.
Section 6 — you're defining a word that has no natural meaning
"Two rounds of revisions" sounds precise and isn't. If a client sends eleven separate emails over a fortnight, is that one round or eleven? Both readings are defensible, which is exactly why it needs stating.
The revision-versus-direction distinction matters just as much. "Make the heading bigger" is a revision. "Actually, let's try something completely different" is a new project wearing a revision's clothes. Naming that difference in advance means you never have to make the argument in the moment.
Sending it without it feeling heavy
Framing does most of the work. A scope of work presented as protection sounds defensive. The same document presented as clarity sounds like someone who has done this before.
"Here's the scope of work so we're both clear on what's included and the timeline. It covers the deliverables, the two revision rounds, and the payment schedule we discussed. Have a look and let me know if anything's missing — once you're happy, I'll get started."
Three things are working there. It's the next step rather than an obstacle. It invites correction, which makes agreement feel like a choice. And it ties the start of work to approval, which is the whole point.
If a client resists putting anything at all in writing, take note. That resistance is information.
Four mistakes that make a scope of work useless
1. Sending it after starting work. Its power comes from being agreed before anyone is invested. Three days in, raising terms reads as renegotiation and both sides feel it.
2. Never referring to it again. A document you don't cite is a document that doesn't exist. When a request falls outside scope, say so at the time, politely and in writing. Waiting until the fourth instance makes it look like a new rule.
3. Not defining "done." If completion isn't tied to something observable — delivery of the listed files, written approval, or a set number of days after delivery with no response — a client can keep the project open indefinitely by saying it isn't quite right.
4. Making it so long nobody reads it. A client who doesn't understand what they agreed to will behave as though they didn't agree to it. Plain English isn't a weaker document; it's one that actually changes behaviour.
Common questions
What is a scope of work document?
A scope of work is a document agreed before a project starts that records what is being delivered, in what format, by when, for how much, and what is not included. It is the reference point both sides return to when a request arrives that was never part of the original agreement.
What should a scope of work include?
Seven sections cover almost every freelance project: project overview, deliverables, exclusions, timeline and milestones, client responsibilities, revisions, and fees and payment. The exclusions section is the one most freelancers leave out and the one that prevents the most disputes.
Is a scope of work the same as a contract?
No. A contract governs the relationship — payment, ownership, liability, cancellation. A scope of work governs the project — what is being delivered and what is excluded. They work best together, with the contract referring to the scope of work as an attachment.
How long should a scope of work be?
One to two pages is right for most freelance projects. Long enough to list deliverables and exclusions specifically, short enough that the client actually reads it. A client who does not understand what they agreed to will behave as though they did not agree to it.
Do I need a signature?
A signature is stronger, but an email in which the client clearly states agreement to a specific document is meaningful evidence in most places. The practical minimum is that the terms exist in writing and the client has visibly agreed to them before work begins.