What a statement of work is and why it matters

A statement of work (SOW) defines what your agency will deliver, when, and for how much. It's the bridge between the sales conversation and the project. Without one, both sides are working from memory, assumptions, and good intentions, and that ends in a dispute.

For agencies, the SOW does two jobs. It protects you from scope creep and unbounded work. It protects the client by giving them a clear picture of what they're paying for and when they'll get it.

Plenty of small agencies still treat it as an afterthought. A one-page proposal with vague deliverables, a verbal "looks good," and work starts. Three months later the client says "I thought the logo redesign was included," the agency says "that was never discussed," and there's no document to settle it.

A good SOW takes an hour or two to write properly. That's the best hour you'll spend on the project. Below is a statement of work template you can copy, with each section explained, and a worked example for a website build.

The template

Copy this skeleton and fill it in. The sections that follow explain what goes in each.

STATEMENT OF WORK
Client: [Client name]        Agency: [Agency name]
SOW #: [number]              Date: [date]
Governed by MSA dated: [date]

1. PROJECT OVERVIEW
   Background:
   Objectives:
   Stakeholders (client): [name, role, approves what]
   Stakeholders (agency): [name, role]

2. SCOPE OF WORK AND DELIVERABLES
   Phase 1: [name]
     - [deliverable, quantity, format, revision rounds]
     - Acceptance criteria:
   Phase 2: [name]
     - ...
   Exclusions (not included in this SOW):
     - ...

3. TIMELINE AND MILESTONES
   | Milestone | Target date / duration | Deliverable | Client dependency |
   Timeline assumes client feedback within [5] business days. Delays shift later milestones by the same duration.

4. FEES AND PAYMENT TERMS
   Total fee: [amount]  (fixed price / time and materials at [rate card], capped at [amount])
   Payment schedule: [e.g., 50% on signature, 25% at design approval, 25% at launch]
   Terms: Net [15/30]. Work pauses if any invoice is more than [15] days overdue.
   Not included in fee: [travel, third-party software, stock imagery, hosting]

5. ASSUMPTIONS
   - ...

6. CHANGE MANAGEMENT
   Change requests submitted in writing to [name]. Agency assesses impact on timeline and fee within [3] business days. Out-of-scope work begins only after a signed change order.

7. ACCEPTANCE AND SIGN-OFF
   Deliverables are accepted on written approval or [5] business days after delivery without written objection.

Signatures: ____________________   ____________________

1. Project overview and objectives

Frame the engagement briefly. This isn't the detailed scope. It's the context that tells everyone why the project exists.

Background. A paragraph or two on the client's situation and what prompted the project. "Acme Corp is a B2B SaaS company preparing to launch a new product line. The current website doesn't communicate the expanded offering and needs a redesign to support the launch."
Objectives. What success looks like, specifically. "Redesign the corporate site to communicate the expanded portfolio, improve lead conversion, and support the Q3 launch."
Stakeholders. Decision-makers on both sides. Who approves deliverables, who gives feedback, who's the day-to-day contact.

It sets the tone. It shows the client you understand their business, not just the tasks.

2. Scope and deliverables

The most important section. It defines exactly what you'll deliver and, just as important, what you won't.

Break deliverables into phases where you can, and for each one state:

What it is. "Design of 10 unique page templates," not "website design."
Quantity. Pages, concepts, revision rounds.
Format. Figma files, a WordPress theme, static HTML.
Acceptance criteria. What "done" means. "Client sign-off on final design files." "All pages pass WCAG 2.1 AA."

A worked example for a website project:

Phase 1: Discovery and strategy

Stakeholder interviews (up to 4 sessions, 60 minutes each)
Competitive analysis covering 5 competitors
Sitemap and information architecture document
Deliverable: strategy brief for client approval

Phase 2: Design

Wireframes for 10 page templates (2 revision rounds)
Visual design for 10 page templates (2 revision rounds)
Responsive versions of all templates
Design system documentation
Deliverable: approved design files in Figma

Phase 3: Development

WordPress theme built to the approved designs
CMS setup and content types
Contact form connected to the client's CRM
Deliverable: staging site for review

Phase 4: QA and launch

Cross-browser testing (Chrome, Firefox, Safari, Edge)
Mobile testing (iOS and Android)
Performance work to reach sub-3-second loads
Client acceptance testing (5 business days)
Production deployment
Deliverable: live site

Then the exclusions. Say explicitly what isn't in this engagement. Common ones: content writing, photography, ongoing maintenance, SEO, third-party licenses, hosting setup. People skim, so put the exclusions where they can't be missed. This is the section that prevents "I assumed that was included."

3. Timeline and milestones

Lay out the schedule with dates or durations per phase. If dates depend on signature, use relative timing: "Phase 1 begins within 5 business days of contract execution."

For each milestone: the target date or duration, the deliverable due, and the client dependencies (what they need to provide, and by when).

Be explicit about what happens when the client is late. The standard clause: "Milestones assume client feedback within 5 business days. Delays in feedback shift later milestones by the same duration." That's what stops a client taking three weeks to review designs and still expecting the original launch date. It happens more than you'd think.

4. Fees and payment terms

State the total and how it's structured. For fixed price, break it down by phase so the client can see where the money goes. For time and materials, state the rate card and any cap or estimate.

Then the terms:

Schedule. 50/25/25 (half up front, a quarter at the midpoint, a quarter at completion) is common for projects. Monthly invoicing for longer engagements.
Terms. Net 15 or Net 30, whatever your standard is.
Late payment. Many agencies pause work when an invoice is more than 15 days overdue. Say so here, before it happens.

And name what's not in the fee: travel, third-party software, stock imagery, anything the client should expect to pay separately.

5. Assumptions

Every estimate rests on assumptions. Write them down. This is the section that protects you when one turns out wrong.

Typical ones:

The client provides all copy in final form by a set date
The existing hosting meets the technical requirements
The client's team responds to feedback requests within the defined window
No more than a set number of stakeholders join review cycles
The project uses the platforms named in the SOW

When an assumption fails, you have a documented basis for adjusting the timeline or the fee. Without it, you absorb the cost of things that were never yours.

6. Change management

Describe how scope changes get handled: how requests are submitted, how you'll assess the impact on time and cost, what approval is needed before out-of-scope work starts, and how approved changes are recorded (usually a change order or an SOW amendment).

This sets the expectation from day one that changes are normal and welcome, and that they go through a process. Clients who read this before signing are far more receptive to it during the project. The agencies that skip the section are the ones complaining about scope creep later. The scope creep post covers running the change order process day to day.

Mistakes that cause disputes

Being vague to win the deal. It's tempting to keep scope loose because specificity might scare the client. It always backfires. A client who won't agree to a clear scope is a warning about the engagement, not a reason to stay vague.

Forgetting revisions. Unlimited revisions is a promise no agency can keep profitably. Specify rounds for every deliverable that involves subjective review. Two is the common standard, and if someone needs more than that the brief was probably wrong.

Not defining done. Without acceptance criteria, projects drag. There's always one more tweak. Define completion and the sign-off process, including what happens if the client goes quiet.

Legal jargon. The SOW should be in plain language that project managers and clients will actually read. Keep the legal language in the MSA.

Copy-paste without customizing. Templates, including this one, are starting points. Generic deliverables and boilerplate tell the client you haven't thought about their project.

It protects both sides

A good SOW isn't adversarial. The client gets a clear understanding of what they're buying, when, and for how much, so they can plan resources, set expectations internally, and budget. It's also their basis for accountability if the agency underdelivers.

The agency gets a defined scope to plan against, a documented process for changes, and a payment schedule tied to deliverables. When expectations expand past what was agreed, the SOW is what turns that into a productive conversation instead of an argument.

In Nymble, the SOW's contents become the contract: services with their rates and quantities, change orders when scope moves, and a proposal and agreement the client signs online. Tracked time then rolls up against the contract, so "are we over scope on phase 2" is a report rather than a guess. The contracts docs show the setup.

Statement of Work Template for Agencies (With Example)