Statement of Work for Agencies: What to Define Before the Project Starts
When a project grows beyond what was agreed, the cause is often a shared conversation that each side remembers a little differently. A statement of work turns that conversation into a document everyone can point to.
A statement of work (SOW) for an agency engagement should name the deliverables with acceptance criteria, state what’s out of scope, list assumptions and client responsibilities, set milestones and review windows, and define how changes are requested, priced, and approved. The exclusions and the change process are what keep a project from drifting, and they’re the sections teams most often leave vague. A short document works best, since both sides are more likely to reread it when a disagreement starts.
A statement of work turns a conversation into a record
A proposal pitches the work, and a statement of work commits to it. It usually sits under a master services agreement that holds the legal terms, and it covers what will be delivered, when, how it's approved, and what happens when things change.
For a sense of what "complete" means, US federal rules require a statement of work to include a description of the work, its location, the period of performance, a deliverable schedule, applicable performance standards, and any special requirements. Agency work is simpler than a government contract, but the checklist is a useful reference point.
Give every deliverable acceptance criteria
A deliverable names the output, its format, the quantity, the number of revision rounds, and how it's judged done. "Homepage and nine templates designed in Figma, two revision rounds, approved by the marketing lead within five business days" can be checked, but "website design" can only be argued about.
Acceptance criteria answer who approves, how long they have to review, and what "approved" means. If the answer to the last one is "when everyone is happy," the deliverable is never-ending. Our guide to how to evaluate a B2B agency includes the scope questions worth asking before you sign.
Say what's out of scope, and what you're assuming
A SOW that only lists what's included invites guesses about everything else. Add a short exclusions list covering items such as copywriting, photography, content migration, integrations, ongoing support, translations, extra revision rounds, or whatever applies to the engagement.
Then add assumptions and client responsibilities. If the plan depends on the client supplying content by a certain date, giving access to systems, naming one point of contact, or consolidating feedback into a single round, write it down. If something isn’t listed as in or out, it’s a negotiation waiting to happen.
Make changes easy to request and visible when they happen
Changes happen. The problem is changing scope without changing the plan. A change process can be simple, with the request made in writing, the agency assessing the effect on timeline and cost, and both sides approving it in writing before the extra work starts. A short log of approved changes keeps everyone looking at the same version of the scope.
Set a threshold for what counts as a change and what counts as a clarification, so small questions don't require paperwork. And if the work keeps changing, repeated change orders are a sign the engagement model may not fit. Our guide to retainer vs. project engagements covers when ongoing work needs a different structure. A strong brief up front also heads off many early changes, which is why we wrote about how to brief a B2B design agency.
Put timelines, approvals, and decision owners in writing
Tie each milestone to a deliverable as well as a date, and state the review window for each. Say what happens if feedback arrives late. Delay on either side moves the date, and the SOW should say so plainly. Name a decision owner on each side, the person who can say yes, so approvals don't stall in a committee.
Review it at kickoff and whenever scope moves
A SOW only keeps a project on track if people read it. Walk through it together at kickoff, section by section, and agree on each one. Then revisit it at natural checkpoints, and amend it when scope moves, instead of letting the document and the work drift apart. This isn't legal advice, so have counsel review the final terms.
Start with a scope you can both point to
A clear scope protects both sides, the client who needs to know what they're getting and the agency that needs to deliver it well. At BRIGHTSCOUT, our process starts with discovery and alignment, and the scope is written down before work begins.
FAQs
What is a statement of work (SOW)?
A statement of work is a document that defines one engagement. It includes the deliverables, timeline, acceptance criteria, responsibilities, and how changes are handled. It's usually signed under a master services agreement.
What's the difference between a SOW and a scope of work?
A scope of work describes what's in and out of the engagement. A statement of work is the broader document that includes the scope plus the timeline, acceptance process, responsibilities, and terms for that project. The two terms are often used interchangeably, so check what a given document contains.
What should a statement of work for an agency include?
Objectives, named deliverables with acceptance criteria, explicit exclusions, assumptions and client responsibilities, milestones and review windows, roles and decision-makers, a change process, and the payment or invoicing structure.
How does a SOW prevent scope creep?
By making the boundary written and checkable. Named deliverables and exclusions show what's in and out, and a change process turns new requests into priced, scheduled, approved changes instead of silent additions.
What is a change order?
A change order is a written agreement to change scope, timeline, or cost after work has started. It records the request, its effect, and who approved it, before the extra work begins.
How detailed should a SOW be?
Detailed enough to settle a disagreement, and short enough that both sides will reread it. Name deliverables and exclusions precisely, and keep the process language light.
Who should write the SOW?
Usually the agency drafts it and the client reviews it against their goals and constraints. Either way, both sides should walk through it at kickoff and agree on every section.
What happens if the client changes their mind mid-project?
The change should go through the change process. Record the request, assess its effect on timeline and cost, and approve it in writing before work continues. Changes happen, but changing scope without changing the plan is where problems start.
Is a SOW legally binding?
It's often part of a binding contract, especially when signed under a services agreement, but the legal effect depends on the agreement. This isn't legal advice, so have counsel review it.