· 8 min read
How to write a scope of work: sections, wording and a full example
A scope of work says what you will deliver, by when, for how much, and what you will not do. Written well, it settles most disagreements before they start. Written vaguely, it is how a four-week project runs to ten.
This guide covers the sections every scope of work needs, the wording that holds up when a client asks for "one more thing", and a complete example for a website project. The last section is about writing the next one without starting from the previous client's copy.
What is the difference between a scope of work and a statement of work?
A scope of work describes the tasks, deliverables and timeline of a project, and a statement of work is the full agreement that contains that scope plus payment terms, requirements and legal terms. Both are abbreviated SOW, and some people use either name for the whole document, so check which one a client means when they ask for "the SOW".
Two other documents sit next to it:
| Document | What it holds | When it is used |
|---|---|---|
| Proposal | The client's problem, your approach and the price | Before the work is agreed, to win it |
| Scope of work | Tasks, deliverables and timeline | Inside a statement of work, or alone when no statement of work is needed |
| Statement of work | The scope plus payment terms, requirements and legal terms | Once the project is agreed |
| Master services agreement | The terms that govern all future work with one client | Once per client; each project then gets its own statement of work |
Without a master services agreement, the statement of work, or a service agreement attached to it, has to carry the legal terms itself.
What should a scope of work include?
A scope of work should cover nine things: the goal, the deliverables, what is out of scope, the timeline, the client's responsibilities, revisions, acceptance, fees and how changes are handled. The order can change, but each missing section is a question the client gets to answer in their own favour.
1. Project summary and goal
Two to four sentences on what is being made and why. Name the business goal, such as "take online orders for pickup", so later requests can be checked against it. A request that does not serve the goal is easier to move to a later phase.
2. Deliverables
Everything you hand over, each item specific and countable. "Website design" invites an argument; "visual design for up to 8 page templates, desktop and mobile" does not. Give quantities, formats and the platform.
3. Out of scope
The list of what the price does not include. It is the section most often left out, and it prevents more disputes than any other because it answers requests before they are made. For a website the usual entries are copywriting, photography, content entry beyond an agreed number of pages, licence fees for third-party tools, hosting, and maintenance after launch.
4. Timeline and milestones
Dates tied to deliverables, with the dependencies behind them. "Design starts when we receive the content and brand assets" protects your dates when the client is late with theirs.
5. Client responsibilities
What you need from the client and by when: content, access to hosting and accounts, feedback within a set number of business days, and one person who approves each deliverable. Feedback from five people who disagree with each other is a common cause of delay.
6. Revisions
How many rounds of changes each deliverable includes, and what a round is. Defining a round as one consolidated list of changes keeps it from turning into a stream of separate emails.
7. Acceptance
How a deliverable is approved, and what happens when nobody answers. Without a deadline, a design can sit unapproved for weeks while the client keeps the right to change it.
A deliverable is accepted when the client approves it in writing, or five business days after delivery if the client has not sent written feedback.
8. Fees and payment schedule
The fee, what triggers each payment and when invoices are due. Tie payments to milestones, for example 40% on signing, 40% on design approval and 20% on launch. A payment due on "completion" can be put off for as long as the project stays open.
9. Changes
How work outside the scope is handled: described in writing, priced, and approved before it starts. With that sentence in place, "can you just" becomes a decision with a price on it. The details and a complete change order are in how to stop scope creep with a change order.
Which words in a scope of work cause disputes?
Words without a number, a date or a list cause most scope disputes, because each side can read them its own way. These are the usual ones, with what to write instead:
- "Unlimited revisions": give a number of rounds.
- "As needed", "ongoing" and "support": say how many hours, for how long, covering what.
- "Etc." and "including but not limited to" in a list of deliverables: they leave the list open. Close it.
- "Mobile friendly", "fast" and "modern": name screen sizes, browsers or a measurable target.
- "ASAP": write the date.
What does a scope of work look like?
Below is a complete scope of work for a website redesign. The highlighted parts change for every client; the rest is wording you write once. Copy it, change the fixed parts to match how you work, and keep the structure.
Statement of Work: Website redesign
This Statement of Work (SOW number, dated Issue date) is between Your studio and Client company, represented by Client contact.
1. Summary
Redesign and rebuild of Client company's website at Website address so that Project goal.
2. Deliverables
Sitemap and wireframes for up to Page templates page templates. Visual design of those templates for desktop and mobile. Build on Platform, with content entry for up to Content pages pages. Contact form and analytics set-up. One recorded 60-minute handover session.
3. Out of scope
Copywriting and translation. Photography, and stock images beyond Image budget. Hosting, domain and third-party licence fees. Maintenance and updates after launch. Integrations not listed in section 2.
4. Timeline
Kick-off Start date. Wireframes Wireframes date. Visual design Design date. Launch Launch date. Each date moves by the length of any delay in the client responsibilities in section 5.
5. Client responsibilities
Provide all text and images by Content deadline. Send consolidated feedback within Feedback days business days of each delivery. Approver approves each deliverable on the client's behalf.
6. Revisions
Two rounds of revisions on the wireframes and two on the visual design. A round is one consolidated list of changes. Further rounds are billed at Hourly rate per hour.
7. Acceptance
A deliverable is accepted when Approver approves it in writing, or Feedback days business days after delivery if no written feedback has been sent.
8. Fees
Fixed fee of Project fee, invoiced Deposit on signing, Design payment on design approval and the remainder on launch. Invoices are due within Payment terms days.
9. Changes
Work outside this scope is described and priced in a written change order and starts only after the client approves it in writing.
Signed for Your studio: Your name. Signed for Client company: Client contact.
Turn this scope of work into a template where each new client is a short form.
Try it freeCheck it before you send it
- 1Every deliverable has a number, a list or a format.
- 2The out-of-scope list names what this client is most likely to assume is included.
- 3Every date that depends on the client says so.
- 4Revisions are counted, and a round is defined.
- 5Acceptance has a deadline.
- 6Payments are tied to milestones, not to "completion".
- 7The change process is written in.
- 8The client's name, the dates and the fee are right everywhere they appear, headers and footers included.
How do you reuse a scope of work for the next client?
Keep the wording you decided once in one place and fill in only the values that change, instead of copying the last client's document. Copying is how most second scopes of work get written, and it is where the previous client's name ends up in a footer, last year's rate stays in the fee section, and a deliverable from another project survives in the list.
The fixed wording drifts too. Each copy is edited a little, so after a dozen projects there are a dozen versions of your acceptance clause and no record of which one is current. Separating the two kinds of text, as the example above does, fixes both problems.
This is practical guidance from client work, not legal advice. Have a lawyer review the terms you rely on, especially if you work without a master services agreement.