Statement of work (SOW)
A project-specific document that describes exactly what will be delivered, when, how it will be accepted, and what it will cost. Attached to a master service, consulting or freelance agreement to set the scope for a single project.
No sign-up. Editable Word (.docx) or print to PDF. Your answers stay in your browser. Updated .
A statement of work (SOW) is the document that avoids "that's not in scope" arguments. It lists the deliverables, milestones, timeline, acceptance criteria, pricing and change-control process for one project or phase.
Keep the master agreement for legal boilerplate (IP, liability, termination) and use the SOW for everything specific to this project — objectives, deliverables, dates, people and price.
What to include#
- Project overview. A short paragraph naming the project, its objectives and how success will be measured.
- Deliverables and scope. A concrete list of what will be delivered — reports, designs, code, training — and what is explicitly out of scope.
- Timeline and milestones. Start date, key milestones with dates, final delivery date, and dependencies on the client (feedback, assets, access).
- Acceptance criteria. How the client accepts each deliverable: review period (e.g. 5 business days), deemed-accepted clause, and how revisions work.
- Price, payment and changes. Fixed fee or T&M, payment schedule tied to milestones, expense policy, and a written change-order process for additional work.
How to fill it in#
Step 1: Reference the master agreement
Name the underlying contract (consulting/service/freelance agreement) that governs IP, liability and legal terms.
Step 2: List every deliverable
Name each deliverable concretely — not "design support" but "three homepage mockups, two rounds of revisions, final Figma file".
Step 3: Set acceptance criteria
Define how the client signs off, how many days they have to review, and how many revision rounds are included.
Step 4: Tie payments to milestones
Link each payment to a defined milestone or date so there is no ambiguity about when invoices are due.
Step 5: Add change-control language
State that work outside the SOW requires a written change order signed by both sides, priced separately.
Related templates and guides
Questions
SOW vs proposal vs contract?
A proposal sells the work; an SOW defines what will be delivered for this project; the master contract sets legal terms. An SOW signed by both sides becomes part of the contract.
Do I need an SOW for every project?
For fixed-fee work almost always yes — it prevents scope disputes. For hourly T&M work with clear tasks, a simpler email confirmation may be enough.
What if the client changes scope mid-project?
Any work outside the SOW should go through the change-order process: written request, price and timeline adjustment, signed before the work starts.
Who signs the SOW?
Both parties. Signed SOWs attached to a master agreement are enforceable amendments to the contract.
How detailed should it be?
Specific enough that a third party could tell whether a deliverable matches. Avoid vague wording like "high quality" or "as needed".
These are general templates, not legal or tax advice. Have anything unusual reviewed for your jurisdiction.