What is a statement of work?
A statement of work (SOW) defines the work for one engagement: objectives, scope, deliverables, timeline, responsibilities, how work is approved and the commercial terms for that piece of work. Get it right and most of the arguments that sink client projects (scope creep, slow approvals, “that’s not what we asked for”) never start.
It usually sits alongside two other documents:
- Master services agreement (MSA): the legal relationship, including liability, confidentiality, intellectual property and payment terms. Signed once.
- Statement of work: what you’ll do on this project. Signed per project.
- Proposal: the pitch. It sells the work; the SOW defines it.
Smaller firms often combine the MSA terms and the SOW in one document. That’s fine, but keep the scope sections as specific as they would be in a standalone SOW.
The sections in this template
The download contains the full template with placeholders. Replace the bracketed text and delete anything that doesn’t apply.
| Section | What it covers |
|---|
| 1. Background and objectives | Why the project exists and what success looks like, in two or three sentences. |
| 2. Scope of work | The activities you will carry out. |
| 3. Deliverables | Each deliverable with a description, format and due date. |
| 4. Out of scope | What is not included and would need a change request. |
| 5. Assumptions and client responsibilities | Inputs, access and feedback the client must provide, and what happens to dates if they’re late. |
| 6. Timeline and milestones | Target dates and the dependency behind each one. |
| 7. Review, approval and acceptance | Who approves, the review window, revision rounds and when a deliverable counts as accepted. |
| 8. Change requests | How changes are agreed and priced before work begins. |
| 9. Fees and payment | Fee basis, payment schedule, terms and expenses. |
| 10. Project contacts | Leads and approvers on both sides. |
| 11. Signatures | Names, titles and dates for both parties. |
Example: a website redesign SOW
Here’s how the key sections read for a typical agency project. Northfield Physio is a fictional client used for illustration.
Background and objectives: Northfield Physio’s current website doesn’t support online booking and isn’t easy to update. This project will deliver a new five-page website, built in Webflow, with a booking integration, that the client’s team can edit themselves.
| # | Deliverable | Description | Due |
|---|
| 1 | Sitemap and wireframes | Five-page sitemap; desktop and mobile wireframes | 10 Nov |
| 2 | Visual design | Homepage and one inner-page design in Figma | 24 Nov |
| 3 | Built website | Five pages built in Webflow, booking widget embedded | 15 Dec |
| 4 | Handover | 45-minute editor training session and a short how-to guide | 18 Dec |
Out of scope: copywriting (the client supplies all text), photography, SEO beyond basic page titles and descriptions, and hosting and maintenance after launch.
Client responsibilities: final copy for all five pages by 17 Nov; Webflow and booking-system access by 3 Nov; one approver (the practice manager) reviews each deliverable within three working days.
Approval and acceptance: two rounds of revisions per deliverable, with feedback sent as one consolidated set. A deliverable is accepted on written approval or five working days after delivery without requested changes.
Five sections people get wrong
- Vague deliverables. “Website design” invites a debate about what was promised. “Homepage and one inner-page design in Figma, desktop and mobile” doesn’t.
- No out-of-scope list. If you don’t write down what’s excluded, the client can reasonably assume it’s included. It’s the simplest defence against scope creep.
- Missing client responsibilities. Most project delays are waiting on the client: content, access, feedback. Write those dependencies into the SOW and link them to your dates.
- No named approver. “The client will approve” isn’t enough. Name one person per deliverable, agree a review window and say what happens if nobody replies.
- Approval with no record. An SOW that says “approved in writing” only helps if you can find that approval later. A thumbs-up buried in a chat thread is hard to point to three months on.
After the SOW is signed
The SOW is where onboarding starts. Turn its client responsibilities into a request list (the client onboarding questionnaire and checklist is a good starting point) and keep every review and approval tied to the deliverable it covers.
Angelwood can use the proposal or statement of work to prepare an onboarding plan, which your team reviews and edits before asking the client to act. Clients then approve work and record decisions in the portal, so the acceptance terms in your SOW have a clear record behind them.
This template is a starting point, not legal advice. Have a qualified lawyer review your agreements for your jurisdiction and business.
Use it in Word, Google Docs or PDF
Microsoft Word
- Download the Word (.docx) file and open it. If Word opens it in Protected View, select Enable Editing.
- Use Find (Ctrl+F or Cmd+F) and search for “[” to jump between the placeholders you need to replace.
- Save a clean copy as a Word template (File → Save As → Word Template) so every new document starts from it.
Google Docs
- Upload the .docx file to Google Drive.
- Right-click it and choose Open with → Google Docs, then File → Save as Google Docs to keep an editable copy.
- Use File → Make a copy for each new client so your master stays clean.
PDF
Fill it in Word or Google Docs, then export it: File → Save As → PDF in Word, or File → Download → PDF document in Google Docs.