This statement of work template gives agency teams a clean, editable structure they can reuse on every engagement instead of starting from a blank page each time. It covers the eight sections that decide whether a project stays profitable or quietly bleeds margin: the parts most agencies skip are usually the parts that cost them the most.
A statement of work, or SOW, is the document that turns a proposal into a binding plan. It names what you will deliver, what the client is responsible for, what happens when things change, and how everyone agrees the work is finished. Done well, it becomes the single reference you both return to when a question comes up. Done poorly, it becomes the thing nobody reads until there is a dispute.
Below is the full template, section by section, with guidance on what to write and why each part matters.
What a statement of work actually does
A proposal sells the engagement. A contract sets the legal terms. The SOW sits between them and does the operational work: it translates "we will redesign your website" into a list of specific, deliverable, reviewable line items with owners and dates.
The reason this matters is interpretation. When a deliverable is described loosely, the client fills the gap with their own expectations, and those expectations are almost always larger than yours. A tight SOW removes the gap. The goal is not a longer document. It is a clearer one.
Rule of thumb: if a line in your SOW could be read two different ways by two reasonable people, it will be. Rewrite it until there is only one reading.
The statement of work template, section by section
Here is the structure to copy. Each heading is a section in your document. Keep the headings, replace the guidance with your specifics.
1. Project overview
Two or three sentences: who the client is, what you are building, and the business outcome it serves. This frames every decision that follows and gives anyone who picks up the document later the context to understand it.
2. Services and deliverables
The heart of the SOW. List every deliverable as a discrete line item, and make each one specific enough to pass a simple test: format, quantity, and specs. "Homepage design" is too vague. "Homepage design: 2 concepts, 1 final direction, desktop and mobile at 1440px and 375px, static Figma mockups, no animation" leaves nothing to argue about.
3. Assumptions
Write down what has to be true for this scope to hold. The client provides brand assets within five business days. The platform will not change mid-project. One named person gives final approval. When an assumption breaks, a documented assumption turns a fight into a calm conversation about a timeline or budget adjustment.
4. Exclusions
State plainly what is out of scope. Copywriting beyond the listed pages, custom photography, third-party licensing, post-launch maintenance. Exclusions close interpretive gaps before they open and create a natural on-ramp to a change order when the client wants the excluded work.
5. Timeline and milestones
Tie dates to deliverables and to the client inputs they depend on. Milestones should be observable events ("design approved", "staging live"), not vague phases. Note explicitly that client delays move dependent dates.
6. Roles and responsibilities
Name who does what on both sides. Who is the client's single point of contact and approver. Who on your team owns delivery. Ambiguity here is where feedback loops multiply and decisions stall.
7. Change order policy
Define the tripwire. Spell out the conditions that trigger a change order, the most important being any change to a deliverable after sign-off, and state that new work begins only after written approval. This is the clause that protects you from quiet scope expansion.
8. Acceptance criteria and payment
Define "done" for each deliverable so acceptance is objective, not a matter of taste. Then tie payment to milestones or acceptance so cash flow tracks delivered work. End with revision limits: how many rounds are included, what counts as a round, and the rate for additional rounds.
A quick-reference table for the eight sections
If you want the template at a glance, here is what each section is for and the single mistake to avoid in it.
| Section | What it locks down | Most common mistake |
|---|---|---|
| Project overview | Context and the business goal | Skipping it, so later readers lack context |
| Services and deliverables | Exactly what you will produce | Vague line items open to interpretation |
| Assumptions | What must be true for the scope to hold | Leaving dependencies unstated |
| Exclusions | What is explicitly out of scope | Omitting the section entirely |
| Timeline and milestones | Dates tied to deliverables and inputs | Dates that ignore client delays |
| Roles and responsibilities | Who decides and who delivers | No single named approver |
| Change order policy | The trigger for new work and budget | No mention of post sign-off changes |
| Acceptance and payment | How "done" and "paid" are defined | Subjective acceptance, no revision cap |
How to fill the statement of work template in under ten minutes
The structure is reusable. The content is not. Here is a fast path that keeps the document tight without making it a research project every time:
- Start from your last similar SOW, not a blank page. Keep the section headings and your standard assumptions, exclusions, and change-order language fixed across engagements.
- Rewrite only the deliverables and timeline for the specific project. This is the 20% that changes; the other 80% should be boilerplate you trust.
- Run the specificity test on each line item before you send. If a deliverable could be read two ways, add format, quantity, or specs until it cannot.
- Set the revision number explicitly. Two rounds is standard for most agency deliverables. "Unlimited" is not a number, and it is the most expensive phrase in the document.
For the deeper logic behind each clause, our scope of work guide walks through the specificity test, assumption documentation, and revision limits in detail. And if you want a version tuned specifically to head off disagreements, see our agency SOW template for preventing scope disputes.
The fastest agencies do not write each SOW from scratch. They templatize ruthlessly: a strong starting document gets them 80% of the way in a few minutes, and they spend their time only on the details that make the engagement unique. That is where ScopeStack comes in. We audit how you scope today and build that repeatable process into the tools you already use, so a structured statement of work is ready to review and send instead of typed from nothing.
Frequently asked questions
What is the difference between a statement of work and a contract?
A contract sets the legal and commercial terms of the relationship: liability, payment terms, termination, intellectual property. A statement of work defines the specific project: the deliverables, timeline, assumptions, and acceptance criteria. The contract usually governs the SOW, and a single contract can have multiple SOWs attached for different projects.
How detailed should a statement of work template be?
Detailed enough that no deliverable can be interpreted two ways, and no more. Tightness beats length. A two-page SOW where every line item passes the specificity test protects you better than a ten-page document full of broad promises. Add detail where you have lost money before, and keep the rest lean.
Can I reuse the same statement of work template for every client?
Yes, and you should. The section structure, your standard assumptions, your exclusions list, and your change-order language should stay consistent across engagements. Only the deliverables, timeline, and project-specific details change. Reusing a trusted template is what makes scoping fast and consistent instead of a fresh judgment call each time.
Start with the section that has burned you
You do not need to perfect all eight sections at once. Look at your last three projects that went over budget or over schedule. The clause that would have prevented each one is the clause to tighten first. If a client demanded changes after approval, sharpen the change order policy. If "website" meant something bigger to them than to you, sharpen your deliverables. If a project stalled waiting on assets, add an assumptions section.
One tight clause is worth more than five vague ones. Use this statement of work template as your baseline, patch the holes where you have lost money before, and you will spend far less time arguing about what was agreed, because it will already be written down.