How to write a web design scope of work your client can’t misread
A practical template for fixed-price web projects: deliverables, exclusions, revision rounds and a timeline, written so both sides read it the same way.
Most scope arguments are not about bad clients. They start with a scope that could be read two ways. “Five-page website” sounds precise until the client asks whether the blog counts as a page, or whether “responsive” includes a separate mobile menu design.
A good scope of work removes the second reading. It is short, specific, and says what is not included just as clearly as what is.
1. Deliverables: count things, name things
Write one deliverable per line, and prefer nouns you can count. “5 pages: Home, About, Services, Portfolio, Contact” beats “a 5-page website”. If a page has a special feature, name it: “Contact page with one form (name, email, message) sending to one inbox.”
- Pages by name, not just a number
- Forms and what they do
- Integrations by product name (e.g. “Mailchimp signup”, not “email integration”)
- Who provides content: you, the client, or nobody
2. Exclusions: the list that saves the project
Exclusions feel negative to write, which is why they are usually missing. They are the single most useful part of a scope because they answer the question before it becomes a request.
- Copywriting and photography
- Hosting, domain and paid plugin fees
- Pages or features beyond the list above
- Content entry beyond the pages above
- Ongoing maintenance after launch
3. Revision rounds, defined
Say how many rounds are included and what a round is. Without the definition, “two revisions” can become twenty emails. We wrote a separate guide with a clause you can copy: see “What counts as a revision round”.
4. Timeline with dependencies
Give a timeline relative to the things you need: “3 weeks from receiving final content and logins.” A date that ignores dependencies becomes your problem when the client sends content late.
5. Price, currency and what happens next
State the fixed price and currency, any advance, and how extra work is handled: “Work outside this scope is quoted separately as a change order before it starts.” That one sentence makes the later conversation routine instead of awkward.
Get it approved, exactly as written
Send the scope in a form the client explicitly accepts, and keep a dated copy of the version they accepted. If the scope changes before approval, the client should approve the new version, not a memory of an old one. FirmQuote does this with one link: the client accepts a specific version, and the history keeps every earlier version.