A statement of work exists to define the word "done".
Almost every dispute on a project is a disagreement about whether the work was finished, and almost every one of those traces to a statement of work that described activities rather than outcomes. The sections below all matter, but acceptance criteria are the reason the document exists.
Every section, and which ones carry the risk.
A checklist for any SOW, whatever you write it in. Scope, deliverables and acceptance carry almost all the risk; the rest is administration.
| 01Parties and governing agreement | Who, and which master agreement this sits under. The SOW describes the work; the MSA carries liability, IP and payment terms. Saying which one governs avoids re-litigating them here. |
|---|---|
| 02Background and objectives | Why this work is happening and what it is meant to achieve. Short, and it is what a new person on either side reads first. |
| 03Scope of work | The activities to be performed, broken down far enough to estimate. This is the difference between a statement of work and a scope of work: the scope is this section, the statement is the whole document. |
| 04Deliverables | Named artefacts with formats and due dates. "A report" is not a deliverable; "a written migration plan in PDF, by 14 March" is. |
| 05Acceptance criteria | How each deliverable is judged, who judges it, and how long they have. Include what happens if they say nothing: a deemed-acceptance period after a stated number of days is what stops a project hanging open indefinitely. |
| 06Out of scope | Explicitly what is not included. The cheapest section in the document and the one that prevents the most expensive arguments. |
| 07Schedule and milestones | Dates, phases, and the dependencies each one rests on, with an owner by name. |
| 08Assumptions | What you assumed to be true when estimating. If an assumption fails, this clause reopens the price and the schedule cleanly. |
| 09Price and payment schedule | Fixed, time and materials, or milestone-based, and what triggers each payment. Tie payments to accepted deliverables rather than to dates where you can. |
| 10Change control | How a change is requested, priced and approved, and by whom. Without it, scope moves for free. |
What changes with the engagement.
Pricing model
Fixed price needs tight scope and acceptance. Time and materials needs a cap and reporting. Milestones need each one defined.
Acceptance rigour
Software and regulated work need testable criteria. Advisory work often needs a named reviewer and a deemed-acceptance window.
Depth of detail
Enough that a third party could tell whether it was delivered. That is the test.
Whether an MSA exists
If not, the SOW has to carry liability, IP and confidentiality itself and becomes a much longer document.
What a SOW template cannot decide for you
Acceptance criteria are specific to the work
The one section that prevents disputes is the one no template can supply, because what counts as done depends entirely on what is being made.
It cannot tell you what is missing
A SOW without a dependency owner, or without a deemed-acceptance window, looks complete. The gap only appears when the project is late and nobody agreed whose fault it was.
Priced sections are typed by hand
Milestone amounts in a template are placeholders. Left as typed figures they are unconnected to any rate card, and the total is only as good as the last person's addition.
The omissions that leave a project open.
Each of these turns up as a dispute about whether the work was finished, which is what almost every project argument is really about.
- A deemed-acceptance period, so silence does not leave the project open forever.
- Who specifically signs off, by role and name.
- The dependency list, with an owner against each one.
- What happens when an assumption turns out to be wrong.
- A cap on review rounds before change control applies.
A SOW from the call that scoped it
One sentence like this is enough: Statement of work for Northwind: customer portal, three phases, fixed price $96,000, Net 45, portal work split out from the core build, acceptance deemed after 10 business days.
- Give it the conversation. The transcript, the spec, the notes on what is in and out. It reads all of it rather than asking you to summarise.
- It asks the scoping question, not fourteen others. Whether a workstream is inside this SOW or a separate phase is the question that actually changes the document. It asks that one.
- Deliverables become named artefacts. With formats and due dates, because "a report" is not a deliverable and a third party has to be able to tell whether it arrived.
- Phases are priced from your catalog. Milestone amounts are calculated rather than typed, and payments can be tied to accepted deliverables rather than to dates.
- Acceptance is written in, then tracked. A named reviewer and a deemed-acceptance window, so silence has a defined consequence instead of leaving the project open.
Straight answers.
What is a statement of work?
The document that defines one piece of work: its scope, deliverables, acceptance criteria, schedule, price and change control. It normally sits under a master agreement that carries the legal terms, so the SOW can stay focused on what is being built and how anyone will know it is finished.
What is the difference between a scope of work and a statement of work?
The scope of work is one section, describing the activities. The statement of work is the whole document, adding deliverables, acceptance criteria, schedule, price, assumptions and change control. People use the terms interchangeably, which matters when one party means the section and the other means the document.
What makes acceptance criteria good?
That a third party with no context could apply them. "The client is satisfied" is not a criterion; "processes 10,000 rows in under 60 seconds with zero validation errors" is. Pair them with a named reviewer and a deemed-acceptance window so silence has a defined consequence.
Can I generate a SOW from a call?
Yes. Hand over the transcript, your notes and any spec, and the sections above come back written, with phases priced from your catalog. It asks the two things that genuinely change the document, such as whether a workstream is in scope, rather than making you fill in a form.
General guidance, not legal advice. A statement of work usually sits under a master agreement carrying the legal terms; this page does not address those.
Contract template
A contract template gives you headings. The deal is in the gaps.
NDA template
An NDA is short, which is why the wrong one is easy to sign.
Consulting agreement
A consulting agreement is a services contract with four extra arguments.
Freelance contract
Most freelance contracts fail on payment, not on law.
Photography contract
In photography, the argument is almost always about usage.
Business proposal
A proposal is not a description of your company.
Scope it properly, in seconds.
Hand over the call that scoped it and get the statement of work back written, with phases priced and acceptance defined. Three a month, free.
Create one free