What Is a Statement of Work (SOW)?

What a statement of work means in plain English

A proposal says what a vendor could do. A statement of work says what they will do. It lists every deliverable, such as page designs, templates, integrations and content migration, and what counts as done for each. It also states what is out of scope, who provides what, the schedule and how payments tie to milestones.

A SOW often sits under a master services agreement, which holds the legal terms such as liability, confidentiality and ownership. The SOW holds the project details. That split lets a business run several projects with the same vendor, each with its own SOW, without renegotiating the legal terms every time.

Why a statement of work matters for a website project

Many website disputes start with two different memories of what was promised. A clear SOW replaces memory with a written list, so both sides can check progress against it. It protects the budget, makes change requests easy to price and states what you own at the end, from code and design to content, domain and accounts.

A statement of work example

A SOW for a 25-page service business website might list a discovery workshop, sitemap and wireframes, two homepage design rounds, a WordPress build the team can edit, migration of 40 blog posts with 301 redirects, GA4 lead tracking, launch, and 30 days of support. Payment is split across deposit, design approval and launch.

Common statement of work mistakes

• Writing vague deliverables like a modern website instead of named pages, features and revision rounds.
• Leaving out what is not included, such as copywriting, photography or ongoing hosting.
• Skipping acceptance criteria, so nobody can say when a milestone is complete.
• Forgetting to state who owns the code, design, content, domain and accounts after launch.
• Having no change request process, which invites scope creep.

Copy this SOW section list

STATEMENT OF WORK
Client: Lakeside Physio (example.com)    Vendor: [agency name]
Governed by: Master Services Agreement dated [date]

1. Project summary and goals
2. Deliverables, each with an acceptance criterion
3. Out of scope
4. Client responsibilities and due dates
5. Assumptions the price depends on
6. Timeline and milestones
7. Review and approval: 5 business days per milestone, 2 revision rounds
8. Fees and payment schedule:
   30% on signing, 40% on design approval, 30% on launch
9. Change request process
10. Ownership: code, design, content and accounts transfer on final payment
11. Warranty: 30 days of defect fixes after launch
12. Contacts: one named approver on each side

How to check a statement of work before you sign

1. Match every promise in the proposal to a line in the SOW. Anything said in the sales pitch but missing here is not part of the deal.
2. Check that each deliverable has an acceptance criterion, a test that says when it is done, and a stated number of days for you to review it.
3. Read the payment schedule and confirm each payment is tied to a milestone you can see, such as approved designs or launch, not only to calendar dates.
4. Find the ownership section, or the master agreement it points to, and confirm code, design, content and accounts pass to you on final payment.
5. Look for the change request process, a named approver on each side and the warranty period after launch.

What good looks like: Deliverables you can count, an acceptance test for each, payments tied to approved milestones, a written ownership transfer and a change process. A spoken promise that you will own the site is not enough: US law requires a copyright transfer to be in writing and signed.

Questions to ask your web developer

“How long do we have to review each milestone, and what happens if our feedback is late?”

A good answer: A set number of business days per review, a limit on revision rounds, and a written rule for late feedback, such as the schedule moving by the same number of days.

“What does the warranty after launch cover?”

A good answer: A defined period, such as 30 days, in which defects against the agreed acceptance criteria are fixed at no charge, with new requests handled through the change process.

“Which assumptions does this price depend on?”

A good answer: A written assumptions list in the SOW, such as the number of products to migrate or the CRM's available API, so a change in any of them leads to a priced change rather than a dispute.

Statement of work (SOW): common questions

What is the difference between a SOW and a contract?

A contract sets the legal relationship, such as payment terms, liability and how either side can end the deal. A statement of work describes the specific project: what will be delivered, when and at what price. A SOW can sit inside a contract or attach to a master agreement. A lawyer is the right person to check the legal terms themselves.

Who writes the statement of work?

The vendor usually drafts it, because they know how the work will be done, and the client reviews and edits it before signing. For larger projects the client may supply a template or require one in the RFP. Either way, both sides should read it line by line before any work begins.

Sources

• 17 U.S.C. 204: Execution of transfers of copyright ownership (Cornell LII)