A scope of work (SOW) sets out exactly what will be delivered, who does what, by when, and how the client confirms each piece is done. Write it after discovery and before work starts, and include objectives, deliverables, tasks, timeline, acceptance criteria, assumptions, exclusions, responsibilities, payment milestones and a change process.
This guide explains what a scope of work is, how it relates to a proposal, a contract and a change order, what each part should contain, and how to write one. It includes a filled example for a fictional website project, a statement of work template you can copy, the mistakes that cause most disputes, and how to handle scope creep when it happens.
What is a scope of work?
A scope of work is the detailed description of a project’s work: the outputs, the tasks that produce them, the schedule, and the standard each output must meet. Its job is to make sure you and the client have the same picture of “done” before any money changes hands.
You will see two terms used. “Scope of work” usually means the section that defines the work. “Statement of work” usually means a standalone document that contains the scope plus project details such as timeline, payment milestones and governance. In practice many people use them interchangeably, and both are shortened to SOW. What matters is the content, not the label.
For a small project the scope of work can sit inside your proposal. For larger or longer engagements, it often becomes its own statement of work that sits under a master service agreement, so each new project gets a new SOW without renegotiating the legal terms.
SOW vs proposal vs contract vs change order
Each of these documents answers a different question. Keeping them separate makes each one easier to write and easier to change.
| Document | Question it answers | When it is used |
|---|---|---|
| Proposal | Should we do this project, and why with you? | Before the client decides. Persuades and explains. |
| Scope of work | What exactly will be delivered, by when, and to what standard? | Inside the proposal or alongside the contract, before work starts. |
| Contract or service agreement | What are the legal terms: liability, ownership, confidentiality, termination? | When the client agrees to proceed. Often covers several SOWs. |
| Change order | What is changing from the agreed scope, and what does it cost? | During the project, whenever scope, timing or price changes. |
How these documents work together legally depends on their wording and the governing law. If you use a master agreement with separate SOWs, state which document takes priority if they conflict, and have a lawyer review the arrangement.
What to include in a scope of work
These are the parts of a complete SOW. Smaller projects can combine some of them, but each question should still be answered somewhere.
Objectives
One to three sentences on what the project is for. This is the reference point when someone later asks whether a request is in scope.
Deliverables
The concrete outputs, each named and counted: “up to eight page templates”, “one 30-minute training session”, “a written audit report”.
Tasks and activities
The main work that produces each deliverable. Enough detail that the client understands what is happening, without listing every hour.
Timeline and milestones
Phases with dates or week numbers, and the approval points between them. Note which dates depend on client inputs.
Acceptance criteria
How each deliverable will be checked and approved, by whom, and within what review period. This is the part most SOWs leave out and the part that prevents the most arguments.
Assumptions
What you are taking as given: the client provides content, the existing system has an API, one stakeholder signs off. If an assumption turns out to be wrong, the scope may change.
Exclusions
What is explicitly not included. Name the things a reasonable client might expect: copywriting, stock imagery, hosting, ongoing maintenance.
Responsibilities
Who does what on both sides, including the client’s named decision-maker, access they must provide and how quickly they will give feedback.
Payment milestones
Fixed amounts tied to milestones or dates, the currency, and whether taxes are included.
Change process
How changes are requested, estimated and approved, and that no extra work starts until a change order is signed.
How to write a scope of work, step by step
1. Start from discovery notes
Pull the client’s goals, constraints, deadlines and stated must-haves from your call notes and brief. Write the objective in their words.
2. List deliverables before tasks
Decide what the client will receive, then work back to the tasks. Clients approve outputs, not activities.
3. Put a number on everything you can
Pages, rounds of revisions, meetings, hours of support, weeks of warranty. Vague quantities are where disputes start.
4. Write acceptance criteria for each deliverable
Say what “approved” means, who approves it and how long they have. Decide what happens if no feedback arrives in that time.
5. Write down your assumptions and exclusions
Read through the scope and ask “what might the client think is included that is not?” Put those items in exclusions.
6. Tie payments to milestones
Link each payment to a deliverable or date so both sides know when money is due.
7. Review it with the client
Walk through the SOW on a call before signing. Questions now are cheaper than changes later.
Example scope of work: a website project
Below is a filled example for a fictional client, Fernhill Bakery, an invented two-shop bakery that wants a new website with online pre-orders. The names, dates and amounts are made up for illustration and are not market rates.
| SOW section | Example entry (fictional) |
|---|---|
| Objective | Replace the current website with a mobile-friendly site that lets customers pre-order cakes online for collection. |
| Deliverables | Homepage, About, two shop pages, menu page, pre-order page and contact page (seven pages in total). Pre-order form connected to the bakery’s existing email inbox. Basic on-page SEO set-up. One 45-minute handover session. |
| Tasks | Discovery workshop, site map, wireframes, visual design, build, content entry from client-supplied copy, testing on current browsers and devices, launch. |
| Timeline | Week 1 to 2: discovery and site map. Week 3 to 5: design. Week 6 to 8: build and content. Week 9: testing and launch. |
| Acceptance criteria | Each phase approved in writing by the named decision-maker. Client has five working days to review each deliverable. Site accepted when all pages load correctly on the agreed browsers and a test pre-order reaches the inbox. |
| Assumptions | Client supplies all text and photos by the end of week 4. Domain and hosting are already in place. One decision-maker approves all phases. |
| Exclusions | Copywriting, photography, online payments, a full e-commerce shop, ongoing maintenance after the support period, paid advertising. |
| Client responsibilities | Name one decision-maker. Provide hosting and domain access by week 2. Supply content by week 4. Give consolidated feedback within the review period. |
| Our responsibilities | Deliver each phase on schedule, provide a weekly status update, fix defects reported within 30 days of launch. |
| Revisions | Two rounds of revisions on design and one round on the built site. Further rounds handled through the change process. |
| Payment milestones | $3,600 on signing. $3,600 on design approval. $4,800 on launch. All amounts in US dollars, excluding taxes. |
| Change process | Changes requested in writing. We reply with the effect on cost and timeline. Work starts once the client signs a change order. |
Look at the exclusions row. Online payments and a full shop are the two things a bakery might easily assume come with “online pre-orders”. Naming them now prevents an uncomfortable conversation in week seven.
Statement of work template
Copy this outline and replace each bracketed prompt. Keep the headings even when a section is short, so the client can see that each question has been considered.
If you already send proposals from templates, the scope section of a good proposal template covers most of this. You can browse the templates freely; customising one requires a Propovo account.
Project: [project name], prepared for [client], [date], version [number].
1. Objectives: [What the project is for, in one to three sentences.]
2. Deliverables: [Each output, named and counted.]
3. Tasks: [Main activities that produce each deliverable.]
4. Timeline and milestones: [Phases with dates or weeks and approval points.]
5. Acceptance criteria: [How each deliverable is checked, who approves it, review period.]
6. Assumptions: [What you are taking as given.]
7. Exclusions: [What is not included.]
8. Responsibilities: [Client and supplier responsibilities, named decision-maker.]
9. Payment milestones: [Amounts, currency, taxes, due points.]
10. Change process: [How changes are requested, priced and approved.]
11. Governing agreement: [Reference to the service agreement or contract this SOW sits under.]
Signatures: [Client name, title, date] [Supplier name, title, date]
Common scope of work mistakes
Describing activities instead of outputs
“Ongoing design support” has no end. “Up to ten social graphics per month” does.
Unlimited or undefined revisions
If the number of rounds is not stated, the client will reasonably assume it is open-ended.
No acceptance criteria
Without a definition of “done”, a project can sit at “nearly finished” for months while the final payment waits.
Exclusions left implicit
You know photography is not included. The client may not. Write it down.
Client responsibilities missing
Most delays come from late content, access or feedback. If these are not in the SOW, the delay becomes your problem.
Copying the last SOW
Reused scopes carry over deliverables and assumptions that do not fit the new client. Start from the new discovery notes.
No change process
Without one, every request becomes a negotiation, and small favours turn into unpaid work.
Scope creep: how to spot it and handle it
Scope creep is the gradual growth of a project beyond what was agreed, without matching changes to the timeline or price. It rarely arrives as one big request. It is usually a series of small, reasonable-sounding asks: one more page, a quick extra banner, a second set of stakeholders reviewing the design.
Scope creep is not always the client’s fault. It often comes from a vague SOW, from saying yes on a call to keep things friendly, or from a genuine change in the client’s business. The fix is the same in every case: compare the request to the agreed scope, and route anything new through the change process.
Know the early signs
Requests that start with “while you are at it”, new people joining review calls, feedback that reopens approved work, and deliverables described differently from the SOW.
Check the request against the SOW
Is it listed in deliverables? Is it covered by remaining revision rounds? Is it in exclusions? Answer from the document, not from memory.
Acknowledge it, then price it
Thank the client for the request, say it sits outside the current scope, and give the cost and timeline effect in writing.
Use a change order
Get the change approved and signed before starting. Record what changes in deliverables, dates and price.
Offer a trade where it makes sense
Sometimes the client would rather swap something out than pay more. Give them that option.
Fix the SOW next time
If the same type of request keeps appearing, add it to your standard exclusions or deliverables.
The tone matters. You are not refusing; you are giving the client a clear choice with the cost attached. Most clients respect that, and it keeps the relationship on a professional footing.
Hi Alex,
Thanks for sending the idea for a gift card page. It is not part of the current scope, which covers seven pages and the pre-order form.
I can add it as a change: it would be $900 and add about one week to the build phase. Alternatively, we could swap it for the menu page and keep the price and dates the same.
Let me know which you prefer and I will send a change order to sign.
Thanks, Sam
Writing and sharing a scope of work in Propovo
In Propovo you can start from your client notes and review the AI suggestions before applying them, so the scope reflects what was actually discussed. You share the proposal and scope in a client room, where the client can comment on specific points before signing, and they accept with an e-signature.
Your contract terms still depend on the governing law, so have a lawyer review your standard agreement and SOW wording. Propovo is free to try for 14 days, with no card required.
Frequently asked questions
What is the difference between a scope of work and a statement of work?
A scope of work usually means the section that defines the work: deliverables, tasks and boundaries. A statement of work is usually a standalone document that includes the scope plus timeline, acceptance, payment and governance details. Many people use the terms interchangeably.
Is a scope of work legally binding?
It can be, especially when it is signed and referenced by a contract. Whether and how it binds the parties depends on its wording and the governing law, so have a lawyer review your SOW and agreement.
Who writes the scope of work?
Usually the supplier writes it, because they know what the work involves. The client then reviews it, asks questions and approves it. On larger projects the client may supply a draft SOW for the supplier to respond to.
How detailed should a scope of work be?
Detailed enough that someone who was not in the discovery call could tell whether a request is in scope. Name and count every deliverable, state the revision rounds and list the exclusions.
What should I do when a client asks for work outside the scope?
Acknowledge the request, explain that it sits outside the agreed scope, and give the cost and timeline effect in writing. Start the extra work only after the client signs a change order.
Should the scope of work be inside the proposal or separate?
For small projects, a scope section inside the proposal is usually enough. For larger or repeat engagements, a separate statement of work under a master service agreement makes it easier to add new projects later.