Statement of Work Template: What to Include
A statement of work (SOW) is the document that turns a proposal into a precise agreement: what will be delivered, by when, to what standard, by whom and on what terms. Be specific enough that a stranger could tell whether a deliverable is done. This page describes a standard structure, with sample wording you can adapt. It is educational only: the terms of any real agreement should be reviewed by a qualified professional.
The nine sections of a SOW
| # | Section | Purpose |
|---|---|---|
| 1 | Parties and reference | Who is agreeing, and which proposal or contract this belongs to |
| 2 | Background and purpose | Why the work is being done |
| 3 | Scope of work | What is included, and what is explicitly not |
| 4 | Deliverables and acceptance criteria | What will be handed over and how it will be judged |
| 5 | Schedule | Key dates and milestones |
| 6 | Roles and responsibilities | Who does what on each side |
| 7 | Assumptions, risks and change control | What you are relying on, and how changes are handled |
| 8 | Commercials | Fees, expenses and payment schedule |
| 9 | Signatures | Who accepts the terms and when |
Section by section
1. Parties and reference
Name the organizations and the people who sign, the date, the version, and the proposal or master agreement the SOW sits under.
2. Background and purpose
Two to four sentences: the situation, the problem and the decision the work will inform. This should echo your agreed problem statement so that everyone starts from the same question.
3. Scope of work
Write what is in and what is out. The out-of-scope list is the most useful part, because scope grows through small, reasonable-sounding additions.
In scope: analysis of web-shop returns for adult bikes using order data from the last 24 months; up to ten internal interviews; two working sessions with the e-commerce team. Out of scope: store returns; customer interviews; implementation of recommended changes; new data collection.
Cover the four dimensions of scope: who (customers, teams, regions), what (products, processes, decisions), when (the period analyzed and the deadline) and how deep (diagnose, recommend, or also plan implementation).
4. Deliverables and acceptance criteria
For each deliverable, state the format, the content, the owner and how it will be accepted.
| Deliverable | Format and content | Acceptance criteria |
|---|---|---|
| Diagnosis summary | 10 slides: findings with evidence | Sponsor confirms it answers the key question |
| Final report | 20 pages: recommendation, options, risks, data appendix | Accepted or returned with written comments within five working days |
| Handover folder | Data, models, notes | Another person can follow it without the team's help |
Acceptance should be objective where possible. Name who accepts, how long they have, and what happens if they do not respond.
5. Schedule
A short table of milestones and dates. Link each milestone to a deliverable or a decision, not to an activity. Include the dependencies that could move the dates, such as data access.
6. Roles and responsibilities
List the people on both sides and what each is responsible for. A simple RACI matrix works well as an appendix.
7. Assumptions, risks and change control
- Assumptions: the data will be available by a given date; people will be available for interviews; decisions will be made within a set time.
- Risks: the top three, each with an owner.
- Change control: how a change to scope, dates or fees is requested, assessed and approved in writing.
A change process is not negative. It is what lets you say yes to a request while keeping everyone clear on the impact.
8. Commercials
Fees, expenses, invoicing dates and payment terms. This section is where legal and finance input matters most. Keep it consistent with the main agreement.
9. Signatures
Names, titles, dates. Only people with authority should sign.
SOW versus charter versus scope statement
A project charter is an internal agreement on why the project exists and who runs it. A scope statement is a working page that fixes boundaries. A SOW is the fuller agreement between a client and a supplier. For internal projects, a charter and scope statement are often enough.
Writing tips
- Use verbs and nouns, not adjectives. "Deliver a ranked list of causes" beats "provide comprehensive insights".
- One idea per sentence. Long sentences hide ambiguity.
- Avoid undefined terms. If you say "standard", define it.
- Numbers over words. Dates, quantities, page counts.
- Write the acceptance criteria first, and the deliverable second.
- Read it as the other party. Where could they reasonably disagree?
Common mistakes
- Deliverables described as activities ("conduct analysis") rather than outputs.
- No out-of-scope list.
- No acceptance process, so "done" is a negotiation.
- No change control, so every request becomes a dispute.
- Assumptions left unwritten.
- Signing before the sponsor has read it.
After the SOW is signed
Governance starts. A steering committee update keeps the sponsor informed and gets decisions, and a lessons-learned review closes the work.
Go deeper
Guide 12 of The Consultant's Playbook covers how to run a scoping conversation, write a sharp key question, list what is out of scope, build the proposal and workplan, and close with a decision memo. It includes a Scope Statement worksheet and a Workplan and Risk Log worksheet, plus a fictional furniture retailer case. The guide gives you the thinking behind each SOW section. Editable templates are a separate add-on and are not part of the base playbook.
Educational content. It is not legal, financial or tax advice. Have any agreement reviewed by a qualified professional before relying on it.