Statement of Work Template
A free, editable statement of work in Word format, designed to sit underneath a master services agreement and define one specific project.
The two sections that do the work are the ones most SOWs leave out: explicit acceptance criteria, and an out-of-scope list. Without them, "done" is a matter of opinion.
An eight-section SOW with a deliverables table carrying acceptance criteria and dates, a milestone payment schedule, client responsibilities, an acceptance window, change control, and assumptions.
What's in the template
- Reference to the governing master agreement, with a precedence rule
- Objective statement in the client's terms
- Deliverables table with acceptance criteria and due dates
- An explicit out-of-scope section
- Milestone-based payment schedule
- Client responsibilities and a deemed-acceptance window
- Change control and stated assumptions
Acceptance criteria turn opinion into a test
"Client is happy with the design" is not an acceptance criterion. It cannot be met, because it can always be un-met. "Three homepage concepts delivered as Figma files at 1440px, each with mobile and desktop frames" can be checked.
The deliverables table in this template has a column for acceptance criteria for exactly this reason. Write something a third party could verify without knowing either of you. It protects the freelancer from an endlessly moving target, and it protects the client from a supplier who declares the work finished when it plainly is not.
The out-of-scope section prevents more disputes than any other
Most scope disputes come from an assumption that was never stated, and the assumption is almost always the client's. They expected the copy to be written; you expected it supplied. Neither of you was unreasonable, and neither wrote it down.
An out-of-scope list is the cheapest insurance in the document. List the adjacent things a reasonable person might assume are included and say they are not: content creation, hosting setup, post-launch support, training, third-party licence costs. It reads as slightly pedantic and saves entire projects.
Deemed acceptance stops a project stalling in silence
The most common way a project fails to finish is not rejection — it is silence. The deliverable goes out, nobody responds, and the final invoice cannot be raised. Weeks pass.
The acceptance clause here gives the client a defined window, typically five business days, to accept or provide written feedback against the criteria. Anything not rejected in writing within that window is deemed accepted. It is not a trick: it obliges you to deliver against criteria you both agreed, and it obliges them to look. It is the clause that lets a project end.
Milestone payments beat a single invoice at the end
A payment schedule tied to milestones does two things. It funds the work as it progresses, which matters when you are carrying costs, and it limits your exposure: if a client stops paying at the midpoint, you have lost one milestone rather than the entire project.
A common structure is a deposit before work begins, one or more payments on delivery of specific items, and a final payment on acceptance. Tie each payment to an event that is unambiguous — "on delivery of item 1" rather than "halfway through".
How an SOW relates to your contract
The SOW describes one project. The master services agreement describes the relationship — payment terms, IP, confidentiality, liability, governing law — and does not change project to project.
Splitting them this way means a repeat client signs the long document once and a short SOW for each new piece of work. The template includes a precedence clause stating that the master agreement controls where the two conflict, which prevents an SOW from accidentally rewriting terms you negotiated carefully. If you do not yet have a master agreement, our freelance contract template is the document this sits under.
Frequently asked questions
What is the difference between a statement of work and a contract?
A contract, or master services agreement, governs the relationship: payment terms, intellectual property, confidentiality, liability, and governing law. A statement of work defines one specific project underneath it — deliverables, acceptance criteria, timeline, and price. The split lets a repeat client sign the long document once and a short SOW for each new engagement.
What should a statement of work include?
An objective, a deliverables table with acceptance criteria and due dates, an explicit out-of-scope list, a milestone payment schedule, client responsibilities, an acceptance window, a change-control process, and any assumptions the estimate relies on. The acceptance criteria and out-of-scope sections are the two most often omitted and the two that prevent the most disputes.
How specific should acceptance criteria be?
Specific enough that someone who knows neither party could judge whether the deliverable meets them. "Client approves" fails that test; "three concepts as Figma files with mobile and desktop frames, delivered by 14 March" passes it. Vague criteria are not neutral — they systematically favour whoever is more persistent when a disagreement arises.
Do I need an SOW for a small project?
For a very small job a contract with a clear scope section is usually enough. The SOW earns its place when a project has multiple deliverables, several milestones, or dependencies on the client — that is, when "what is included" is complicated enough that memory will not settle it later. If you work with a client repeatedly, an SOW per project is also simply less paperwork than a new contract each time.
Can a client change the scope after signing?
Only through the change-control process, which is why the template includes one. Any change to scope, deliverables, timeline, or fees requires a written change order signed by both parties before the affected work begins. Without that clause, scope creep arrives as a series of small requests that individually seem unreasonable to refuse.
Sources
We prioritize primary sources for rules, formulas, rates, limits, and definitions. See our calculator methodology and editorial policy.