Statement of Work (SOW) Template
A project goes over budget in a quiet, deniable way. Nobody signs off on extra work; it just accumulates.
Free to download and edit · No watermark · Add your own branding
The client assumes the revised homepage was always included. The agency assumed two rounds of revisions, not five. Neither party is lying. The project was simply never written down precisely enough to disagree about.
By the time the invoice arrives, there is no document either side can point to, only two different memories of a kickoff call. A Statement of Work is the document that would have settled it: the exact deliverables, what "finished" means for each one, when payment is released, and what is explicitly not included.
This page gives you a free, editable Statement of Work template for agencies and freelancers, built to lock scope before the work starts. It defines each deliverable against a written acceptance standard, ties payment to milestones instead of the calendar, lists what the client owes you and by when, and names — in writing — everything outside the project. Download it, fit it to your engagement, and attach it to your master services agreement for every new project.
What Is a Statement of Work?
A Statement of Work (SOW) is a document that defines one specific project in enough detail that both sides agree on what will be delivered, how it will be judged complete, when it will be paid for, and what falls outside it.
It turns a proposal's intentions into commitments: deliverables with acceptance criteria, a schedule of milestones, a payment plan tied to those milestones, the responsibilities each party carries, and an explicit out-of-scope list.
It is not the same as your contract, and the distinction matters. A master services agreement (MSA) or client service agreement sets the legal terms that govern the whole relationship — liability, confidentiality, ownership, termination. The SOW sits underneath it and describes a single project's actual work. One signed MSA can carry many Statements of Work over the years, each one scoping a new project without renegotiating the legal foundation every time. When the two documents conflict, the MSA normally governs, and a good SOW says so directly.
How it differs from the documents around it
It is also distinct from a scope of work, though the terms are used loosely. The scope of work is one section — the description of the tasks and deliverables. The Statement of Work is the whole document that wraps that scope in acceptance standards, a timeline, payment terms, and responsibilities. The scope answers "what are we building"; the Statement of Work answers "what are we building, by when, for how much, judged how, and what are we not building."
Why Agencies Need a Statement of Work for Every Project
A proposal wins the work. A Statement of Work governs it. The gap between those two jobs is where unpaid hours and awkward invoicing conversations live, and a per-project SOW is what closes it.
It converts a vague "yes" into a defined scope
A client who approved "a new website" has not approved a page count, a revision limit, or a content responsibility. The SOW pins each of those down before anyone starts building, so the project everyone imagined is the project everyone signed.
It makes "finished" an agreed fact, not an opinion
Attaching an acceptance standard to each deliverable turns the most common dispute — "this isn't what we wanted" — into a check against a written definition rather than a difference of taste.
It ties money to delivery
Payment released against completed milestones, rather than on a fixed monthly date, keeps cash flow matched to progress and gives the client a clear reason each invoice exists.
It puts the client's obligations in writing too
Most project delays trace back to something the client owed — content, access, approvals — arriving late. Naming those dependencies and their due dates makes a slipped timeline attributable instead of absorbed.
It documents what you are not doing
The out-of-scope list is the single most protective line in the document. Consider a brand identity package — logo, colour palette, typography system — where the SOW limits revisions to two rounds. Without an explicit exclusion, it is easy for a client to reroute consolidated feedback through three internal stakeholders between each round, effectively doubling the revision count while each individual request feels minor. An explicit exclusion list makes every addition a visible, quotable change rather than something quietly absorbed into the budget.
The Risks of Running a Project Without a Written SOW
Skipping the Statement of Work rarely causes a problem on day one. It causes problems at delivery and at invoicing, when there is no longer a neutral document to appeal to. Here is how each gap tends to surface.
With no written acceptance standard, the argument is one opinion against another, and the agency usually concedes to keep the relationship — reworking something that was, by any reasonable reading, already complete.
None of the additions were big. A testimonial section here, an extra landing page there, "while you're in there, can you also…". Without an out-of-scope list and a change process, each one slips in free, and the project quietly doubles the work it was priced for.
The SOW never set a revision cap, so the client reasonably assumes there isn't one. The fourth and fifth rounds of changes land as if they were always included, and there is no agreed baseline to bill against.
The timeline slips because the copy arrived three weeks late, or the staging access was never granted. But the delay was never documented as a client dependency, so in the client's memory the agency simply ran late.
An unpaid invoice goes to collections or small-claims court. Without a signed SOW, there is no document proving what was agreed, what was delivered, and when — making it significantly harder to demonstrate the agency fulfilled its obligations.
Each of these is prevented by a specific part of the template below.
The Key Sections of a Statement of Work
The template holds all of these as fillable fields and tables. Here is what each section is for and how to fill it without leaving the gaps that cause disputes.
Project Overview and Objectives
A short statement of what the project is and what it is meant to achieve. Keep it to the business outcome, not the task list. Write "a marketing site that generates qualified demo requests," not "eight pages in WordPress." The objective is what you point to when a mid-project request comes in: does it serve the stated goal, or is it a new goal wearing the old project's clothes?
Scope of Work
The description of the work itself: the tasks, the approach, the phases. This is the section people mean when they say "the scope." Write it specifically enough that a reader who was not on the sales call could tell what is included. Vague scope is the raw material of every later disagreement, so name the actual pages, platforms, deliverable types, and quantities.
Out of Scope
An explicit list of what the project does not include — the single most valuable section for an agency. Everything a client might reasonably assume is covered but isn't belongs here: content writing, ongoing maintenance, third-party licence costs, additional pages, hosting, training beyond a set number of sessions. An item on this list is not a refusal; it is a quotable change. Without the list, the same request is an argument.
For example, a single line such as "Copywriting for any page — client supplies all final copy by [date]" removes an entire category of dispute. If copy arrives late or incomplete, the documented out-of-scope line is what you point to, not a memory of a conversation.
Deliverables and Acceptance Criteria
The heart of the document. Each deliverable gets a matching acceptance standard: the written definition of what makes it complete and accepted. An acceptance criterion is concrete and checkable, not a vague quality judgement. For example:
Homepage delivered as responsive design matching approved Figma file v3, tested in Chrome 120, Safari 17, Firefox 121, and Edge 120; all CTA buttons link to correct destination pages; no console errors on page load.
That is a criterion a developer, a project manager, and a client can all read and reach the same conclusion about. "A good homepage" is not.
Pair each criterion with a review window: the client has a set number of business days to accept or return a deliverable with specific feedback, after which it is treated as accepted. This one pairing (a clear standard plus a review deadline) removes most "that's not what we wanted" disputes, because "what we wanted" was written down and agreed before the work began.
Milestones, Timeline, and Dependencies
The schedule, broken into milestones rather than one distant finish line. Each milestone names what is delivered, its target date, and — critically — what it depends on. A dependency is anything that must be in place for the milestone to proceed, and most dependencies are owed by the client: approved copy, brand assets, platform access, sign-off on the previous phase. State the dependency and its due date, and state the consequence of a late dependency plainly: the timeline shifts by the delay. This keeps a client-caused slip visible and attributable instead of silently absorbed by the agency.
Fees and Payment Schedule
What the project costs and when each portion is due. Tie payments to milestones, not to the calendar: a deposit to begin, then portions released as named milestones are accepted, with a final payment on completion. Milestone-based payment keeps the money matched to delivered value and gives both sides a clear trigger for each invoice. State the currency, the payment window (net terms), and what happens to the schedule if a milestone is delayed by a client dependency.
Roles and Responsibilities
Who does what, on both sides. Name the agency's project lead and the client's single approver — the one person whose sign-off counts. Projects stall when feedback arrives from four stakeholders who disagree with each other; naming one approver makes acceptance a decision rather than a committee. List the client's standing responsibilities here too: providing content, timely feedback, and access.
Change Control
How a change to this SOW gets made. The rule is simple and worth stating explicitly: any work beyond what this document describes is handled through a written change request that defines the change, its cost, and its schedule impact, approved in writing before the work begins. This is the mechanism that turns scope creep from a quiet loss into a visible, billable decision. Without it, "can you just…" has no home; with it, every addition has a quote.
Revisions
The number of revision rounds included per deliverable, what counts as a single round, and the rate for rounds beyond the included set. "Unlimited revisions" is not generosity; it is an uncapped liability that invites the endless feedback loop. A defined cap — commonly two or three rounds, with one consolidated set of feedback counting as a round — keeps revision work bounded and billable.
Assumptions and Constraints
The conditions the plan depends on. Assumptions are what you are taking as given: the client has a working CMS, content will be supplied in final form, approvals come within the review window. Constraints are the hard limits — a fixed launch date, a set budget, a required platform. Writing these down matters because an assumption that turns out to be false is the most common reason a timeline or budget breaks, and a documented assumption makes the renegotiation a pointing-to-the-SOW conversation rather than a fight.
Sign-off
The signatures that make the SOW binding, with a line noting that it operates under the governing master services agreement and that the MSA controls in any conflict. This single line prevents the SOW-versus-contract ambiguity that turns a dispute into a legal argument.
Tips for Writing a Statement of Work That Holds Up
A template gives you the sections. What makes a Statement of Work actually prevent disputes is how precisely you fill them in.
Quantify everything quantifiable
Page counts, revision rounds, number of concepts, training sessions, hours of support. A number is enforceable; "a few" and "some" are invitations to disagree.
Write the out-of-scope list as carefully as the scope
For each major deliverable, ask what an optimistic client might assume comes with it, and either include it or exclude it by name. The exclusions you forget are the ones you end up doing for free.
Write acceptance criteria someone else could verify
If you cannot imagine a neutral third party checking whether a deliverable meets its criterion, the criterion is too vague. Replace "looks professional" with the specific, observable conditions that count as done.
Always pair a deliverable with a review window
A deliverable with no deadline to respond to it can sit unaccepted indefinitely, holding up payment. State the number of business days and what happens when they pass.
Match your net terms to the payment structure
Project milestones warrant tighter terms — net-7 from the date of acceptance is common and reasonable, since the client has just reviewed and signed off on work. Ongoing retainers follow a predictable calendar and can comfortably run net-30. Write the specific net period into the SOW next to each payment line so there is no ambiguity about when the clock starts. For partial acceptance — where a client approves most of a milestone but disputes one element — specify in advance whether the undisputed portion is invoiced immediately at a prorated amount or whether the full payment is held until the dispute is resolved. Leaving this unaddressed is the most common cause of milestone payment delays.
Route every addition through change control
Train yourself and the client that new work means a short written change request first. The discipline of quoting before doing is what keeps a project profitable.
How to Use the Free Statement of Work Template
Turning the template into a signed SOW for a real project takes five steps.
Start from a copy
Download the Word (.docx) file, or upload it to Google Docs, and work on your copy, not the original.
Fill the scope and the exclusions together
Write what is included, then immediately write what is not.
Attach an acceptance criterion and a date to every deliverable and milestone
This is the step that does the most work later, so do not shortcut it.
Tie payment to the milestones you just defined
Set the deposit, the milestone payments, and the final payment, with net terms and the late-dependency rule.
Reference your master agreement and sign
Note the governing MSA, confirm it controls in any conflict, and get both signatures before work starts.
Doing them as a pair is how you catch the assumptions that would otherwise go unpriced.
Each row needs a definition of done and a due date.
Managing a Statement of Work Inside a Client Portal
A signed SOW defines the project. What the client lives through afterward is the sequence of milestone approvals, invoices against those milestones, and the back-and-forth of deliverable sign-offs — and that experience is what a client portal carries.
- ✓A proposal the client signs online, which creates the invoice and the order
- ✓A deposit percentage on the first invoice
- ✓Deliver each deliverable for approval, and the client approves it or asks for a revision
- ✓Revisions counted against what the SOW includes
- ✓A task template turns the milestones into tasks with owners and due dates
Download the free statement of work (SOW) template
The editable Word file with all 10 sections. Replace the brackets, add your branding and use it with every client.
This template is a free, editable starting point, not legal advice. Laws vary by region, so have a qualified lawyer review it for your jurisdiction before you rely on it.
Frequently asked questions
Is this Statement of Work template free to use?
Yes. There is no watermark and no cost. Open it in Google Docs or Word, adapt the sections to your engagement, and use it for every project you scope.
What is the difference between a SOW and a contract?
The contract (usually a master services agreement) sets the overarching legal terms, while the SOW describes one specific project's deliverables, timeline, and payment. One signed contract can carry many Statements of Work, and when the two conflict, the contract normally governs.
What is the difference between a SOW and a scope of work?
The scope of work is one section within the SOW; the SOW is the full, signable document that wraps that scope in acceptance criteria, a timeline, payment terms, and exclusions. See What Is a Statement of Work? above for a full breakdown.
What are acceptance criteria and why do they matter?
Acceptance criteria are the written, checkable conditions that define when a deliverable is complete and accepted. They matter because "this isn't what we wanted" is the most common project dispute, and acceptance criteria convert it from a matter of opinion into a check against an agreed standard. Pair each criterion with a review window so a deliverable cannot sit unaccepted indefinitely.
How do I stop scope creep with a SOW?
Two sections do the work: an explicit out-of-scope list that names what the project does not include, and a change control clause requiring any additional work to go through a written, approved change request before it begins. Together they turn every "can you also…" from a quiet unpaid addition into a visible, quotable decision.
Do I need a lawyer to draft a SOW?
Not necessarily, since a well-structured template like this one handles the core project detail. A quick legal check is still worthwhile for a high-value engagement, one involving IP ownership, or one sitting under a master agreement you haven't had reviewed, because the SOW is the operational layer and a lawyer handles the legal layer underneath.
Related Templates
If you scope projects for clients, these free templates pair well with the Statement of Work: More free, editable templates from the Agency Templates Library.
Agency Retainer Agreement
The core retainer contract, ready to brand.
CONTRACTClient Service Agreement (MSA)
The legal terms you sign once with every client.
ONBOARDINGProject Intake Questionnaire
The discovery questions to ask before you scope.
PROJECTChange Request Form
Turn scope creep into a priced, approved decision.
CHECKLISTClient Onboarding Checklist
The 3-phase onboarding checklist for any agency.
BRIEFCreative Brief
Align the team and the client before work starts.