What a statement of work is and why it matters

A statement of work is the document that defines what your agency will deliver, when you'll deliver it, and how much it will cost. It's the bridge between the sales conversation and the actual project. Without one, both sides are working from memory, assumptions, and good intentions, which is a recipe for disputes.

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

Despite how important it is, many small agencies treat the SOW as an afterthought. They send a one-page proposal with vague deliverables, get a verbal "looks good," and start working. Then three months later, when the client says "I thought the logo redesign was included" and the agency says "that was never discussed," there's no document to settle the disagreement. We've been on both sides of that conversation, and it's painful every time.

A good SOW takes time to write. Worth it. That time is an investment that pays for itself on every project.

Project overview and objectives

Start with a brief section that frames the engagement. This isn't the detailed scope. It's the context that helps everyone understand why the project exists.

Include:

Background. One to two paragraphs about the client's situation and what prompted this project. "Acme Corp is a B2B SaaS company preparing to launch a new product line. Their current website doesn't effectively communicate the expanded offering and needs to be redesigned to support the launch."
Objectives. What does success look like? Be specific. "Redesign the corporate website to clearly communicate the expanded product portfolio, improve lead generation conversion rates, and support the Q3 product launch."
Key stakeholders. List the decision-makers on both sides. Who approves deliverables? Who provides feedback? Who's the day-to-day point of contact?

This section sets the tone for the entire document. It shows the client that you understand their business, not just the tactical work.

Scope of work and deliverables

This is the most important section of the document. It defines exactly what you'll deliver and, equally important, what you won't.

Structure your deliverables in phases when possible.

What it is. Be precise. "Design of 10 unique page templates" not "website design."
Quantity. How many pages, how many concepts, how many rounds of revision.
Format. Figma files, WordPress theme, static HTML, whatever applies.
Acceptance criteria. What does "done" look like? "Client sign-off on final design files" or "All pages passing accessibility audit at WCAG 2.1 AA."

An example deliverables section for a website project might look like:

Phase 1: Discovery and Strategy

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

Phase 2: Design

Wireframes for 10 page templates (2 rounds of revisions included)
Visual design for 10 page templates (2 rounds of revisions included)
Mobile responsive versions of all templates
Design system documentation
Deliverable: Final approved design files in Figma

Phase 3: Development

WordPress theme development based on approved designs
CMS setup and content type configuration
Contact form integration with client's existing CRM
Deliverable: Staging site for client review

Phase 4: QA and Launch

Cross-browser testing (Chrome, Firefox, Safari, Edge)
Mobile device testing (iOS and Android)
Performance optimization to achieve sub-3-second load times
Client UAT period (5 business days)
Production deployment
Deliverable: Live website

After the deliverables, include an exclusions section. This is where you explicitly state what isn't part of this engagement. Common exclusions include content writing, photography, ongoing maintenance, SEO optimization, third-party software licensing, and hosting setup. Stating exclusions prevents the "I assumed that was included" conversation. I've started putting exclusions in bold, actually, because people skim and miss them otherwise.

Timeline and milestones

Lay out the project schedule with specific dates or durations for each phase. If exact dates depend on a signed contract or kickoff date, use relative timing ("Phase 1 begins within 5 business days of contract execution").

For each milestone, specify:

Target date or duration
Deliverable due at that milestone
Client dependencies , what the client needs to provide and by when

Be explicit about what happens when client dependencies are late. A typical clause: "Timeline milestones assume timely client feedback within 5 business days. Delays in client feedback will shift subsequent milestones by an equivalent duration."

This protects you from a situation where the client takes three weeks to review designs and then expects the launch date to stay the same. Happens more than you'd think.

Budget and payment terms

Specify the total project cost and how it's structured. For fixed-price projects, break the budget down by phase so the client understands where their money goes. For time-and-materials work, specify the rate card and any budget caps or estimates.

Include payment terms:

Payment schedule. Common structures include 50/25/25 (50% upfront, 25% at midpoint, 25% at completion) or monthly invoicing for longer engagements. We've landed on 50/25/25 after years of trying other splits, and it just works.
Payment terms. Net 15, Net 30, whatever your standard terms are.
Late payment policy. What happens if invoices aren't paid on time? Many agencies include a clause that work will pause if invoices are more than 15 days overdue.

Also name what's not included in the budget: travel expenses, third-party software costs, stock photography, or any other costs the client should expect to pay separately.

Assumptions and constraints

Every estimate is built on assumptions. Document them. This section protects you when assumptions turn out to be wrong.

Common assumptions include:

The client will provide all written content in final form by a specific date
The existing hosting environment meets technical requirements for the new site
The client's team is available for feedback within a defined response window
No more than a specified number of stakeholders will be involved in review cycles
The project will use specified technology platforms

When an assumption proves incorrect, you have a documented basis for adjusting the timeline or budget. Without this section, you're absorbing the impact of things that were never your responsibility.

Change management process

Include a clear description of how changes to scope will be handled.

How change requests should be submitted
How the agency will assess impact on timeline and budget
The approval process required before out-of-scope work begins
How approved changes will be documented (usually an amendment to the SOW)

This section sets the expectation from the very beginning that changes are normal and welcome, but they go through a process. Clients who see this in the SOW before signing are far more receptive to the process during the project. But honestly? The agencies that skip this section are the same ones complaining about scope creep on Twitter every week.

Common mistakes to avoid

Being vague to win the deal. It's tempting to keep scope loose during the sales process because specificity might scare the client or lose the deal. This always backfires. If a client won't agree to a clear scope, that's a red flag about the engagement, not a reason to be vague.

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

Not defining "done." Without acceptance criteria, projects can drag on indefinitely. The client always has one more tweak. Define what constitutes completion and the sign-off process.

Using legal jargon. The SOW should be written in plain language that everyone understands. Save the legal language for the master service agreement. The SOW is a working document that project managers and clients will reference throughout the engagement.

Copying and pasting without customizing. Templates are great starting points, but every SOW needs to be tailored to the specific project. Generic deliverables and boilerplate language signal to the client that you haven't thought carefully about their project.

How the SOW protects both parties

A well-written SOW isn't adversarial. It protects the client just as much as it protects the agency.

The client gets a clear understanding of what they're buying, when they'll get it, and what it will cost. They can plan their internal resources, set expectations with their stakeholders, and budget accurately. The SOW provides the basis for accountability if the agency underdelivers.

The agency gets a defined scope to plan and deliver against, a documented basis for managing change requests, and a clear payment schedule tied to deliverables. If the client's expectations expand beyond what was agreed, the SOW provides the basis for a productive conversation.

Both parties get a shared reference point that reduces ambiguity, prevents misunderstandings, and makes the working relationship more professional. The fifteen to twenty minutes it takes to write a thorough SOW is some of the highest-value time you'll spend on any project.

How to Write a Statement of Work for Agency Projects