Statements of Work for Agencies: Structure, Signatures, and Scope Protection

Write a statement of work by naming each deliverable precisely, listing what sits just outside it, attaching acceptance criteria and a change process to both, then getting it signed by someone who can approve the spend. The commercial protection is concentrated in three sections: exclusions, assumptions and change control. The rest describes the job.

Written for account and delivery leads who already know what an SOW is and keep losing days to work nobody priced. It covers the drafting order, where the document sits against the contract, the two sections that decide whether extra work gets paid for, and what the signature has to carry.

How do you write a statement of work?

Write it deliverable by deliverable, defining each one’s boundary as you go rather than drafting a scope narrative and bolting exclusions on at the end. The order below is deliberate: each step closes off one class of argument.

1. List deliverables as countable objects with their format. “Six email templates, responsive, built in Klaviyo” can be checked off. “Email programme” cannot. A deliverable with no unit attached to it has no finish line, only a client’s sense of when it feels done.
2. Write each exclusion next to the deliverable it belongs to. Exclusions buried in an appendix get skimmed at signature and disputed later. Sitting beside the thing they qualify, they get read while the client still has the pen.
3. Attach acceptance to every deliverable. Say who approves it, how many working days they have, and what happens when the window passes without comment. Name one approver per deliverable. Approval by committee is approval by nobody.
4. Turn assumptions into dated client obligations. “We assume timely client feedback” protects nothing. “Client returns one consolidated set of comments within three working days of delivery, and each additional day moves the final date by a day” is something you can point at in week six.
5. Price the change process, not only the project. Include the rate card, the minimum billable increment, and who on the client side can authorise additional spend.
6. Set out the dependency list and what breaks. Brand assets, API access, product photography, legal sign-off, a named client contact who is not on leave in August. Say what slips if each one is late.
7. Version and date the document. Number the draft, date the pricing, and keep the executed file separate from the working copy. Every change order should reference that version number.

Two people should read it before it leaves the building: whoever sold the work, and whoever has to deliver it. The gap between those two readings is where most unpriced work is born. For the scoping work that feeds the document, our guide to scoping a client project covers scope statements in more depth.

What comes first, RFP or SOW?

The RFP comes first, often months first, and the SOW is written after you have won. A request for proposal (RFP) is a client canvassing the market. A statement of work is the selected agency committing to specifics. In between sit your proposal, the client’s selection, and usually a contract or master services agreement.

Plenty of agency work skips the RFP entirely and starts with a phone call, which changes nothing about the SOW’s job. Where an RFP does exist, use it as a checklist before you finalise the document. Take every requirement the client wrote down and mark it included, excluded, or priced separately. The dangerous ones are the requirements that sat in the RFP, went unmentioned in your proposal, and never reached the SOW at all. Those resurface at acceptance, and the client is not being cynical when they raise them. They wrote it down at the start and nobody told them it had gone. Our breakdown of agency proposal types covers what belongs in the document that precedes this one.

Is a statement of work the same as a contract?

No. A contract or master services agreement (MSA) governs the commercial relationship between two businesses. A statement of work governs one project inside it. A signed SOW can be legally binding in its own right, which is why an SOW sent without a contract behind it still needs care rather than less of it.

The practical question is which clause belongs in which document.

Clause	Contract or MSA	Statement of work	Change order
Liability cap, indemnities, insurance	Yes	Cross-reference only	No
IP ownership and licensing	Yes	Cross-reference only	Only if the change creates new IP
Confidentiality and data handling	Yes	No	No
Deliverables and exclusions	No	Yes	Yes, as an amendment
Acceptance criteria and review windows	No	Yes	Yes, for the new item
Fee, payment schedule, rate card	Rate card optional	Yes	The difference only
Termination and notice	Yes	Project notice period	No
Change process	Sets the rule	Names the approvers	Is the output

Most agencies end up with one MSA per client and a fresh SOW per project, which keeps the slow legal negotiation to once per relationship instead of once per brief. Standalone SOWs with no MSA behind them are normal on small jobs and expensive on large ones, because everything the SOW does not mention defaults to whatever the client’s own terms say. None of this is legal advice. Pay a solicitor once for a structure you can reuse, and stop redrafting terms you are not qualified to write.

What should the out-of-scope list actually say?

It should name the specific things a reasonable client would assume are included, and say plainly that they are not. Generic exclusions such as “anything not listed above” achieve nothing, because the argument is never about work nobody thought of. It is about work the client sincerely believed was covered.

Write exclusions in five categories:

• Adjacent formats and variants. Extra sizes, additional languages, print adaptations, a version for the trade show stand.
• Volume limits. Number of concepts, revision rounds, pages, templates, interview participants. Put numbers on all of them.
• Timing. Out of hours support, expedited turnarounds, work during the client’s own launch week.
• Client-supplied inputs. Copy, translation, stock licensing, product data, legal review. Say who pays for each.
• After delivery. Hosting, maintenance, training, ongoing edits, analytics reporting past the final milestone.

A worked pair reads like this. Included: three concept routes, one developed to final artwork, two rounds of consolidated feedback. Not included: additional routes, resizing for paid social placements not listed in the media schedule, or amends after final artwork is approved.

Clients do not read the exclusions list at signature. They read it during the disagreement, which is precisely the moment it exists for.

Getting that list out of people’s heads is a conversation, not a drafting exercise, because the account lead knows what the pitch implied and the delivery lead knows what will actually get asked for in week four. If you want it structured rather than improvised, Projan will work through it deliverable by deliverable inside Slack, asking where each boundary sits and who approves it, with the result exportable to Asana or Trello as tasks. Have it before the document goes out, not after the client queries an invoice.

What are two common causes of scope creep?

The two causes that account for most agency scope creep are deliverables described in adjectives rather than counts, and a change process that everyone bypasses because saying yes is faster.

1. Undefined deliverable boundaries. Words like “full”, “complete”, “launch-ready” and “final” carry a different meaning for each reader, and the client’s meaning is always the larger one. Every quantity you leave off the page is a number the client gets to imagine, and nobody imagines conservatively.
2. Change requests handled informally. A request arrives in a Slack thread or at the end of a status call, someone agrees to take a look, and the work enters the project without a quote, a date change or an approval. Nothing about that moment feels like a loss. It feels like good service, which is why it is so hard to stop.

Other causes are real and less common: client-side reorganisation, a new stakeholder arriving at week five, and your own team gold-plating work nobody asked for. All three are easier to manage once the first two are closed off. For the relationship side of this, once creep is already happening, see how to push back on scope creep without damaging the client relationship.

How does a change request become a change order?

By being logged, quoted and signed before any work on it starts. The mechanism is simple and it fails for social reasons, not technical ones, so make the compliant path the easy one.

A workable change order states the requested change in the client’s own words, the additional fee at the agreed rate card, the effect on the delivery dates, the effect on any deliverable already in progress, and the name of the person authorising it. One page. Same version reference as the SOW.

Two details make the difference between a process that runs and a process that gets skipped. First, set a small allowance for trivial requests, say a fixed number of hours per month, so nobody has to raise paperwork for a twenty minute favour. Without it, the whole process gets bypassed for small things and the habit spreads to large ones. Second, agree at kickoff who on the client side can approve additional spend, and confirm that the day-to-day contact usually cannot. Discovering that during a dispute is worse than asking an awkward question in week one.

Does a statement of work need to be signed?

Yes, and before the first hour is billed. Until it is executed the document records your intentions and nobody else’s obligations, which is a poor position from which to defend an invoice. The signature is what converts your exclusions list from an internal view into a term the client accepted.

Three things to get right:

• Signed by someone who controls the budget. Your day-to-day contact may have agreed every line of the scope and still have no authority over the spend. Establish who signs while you are still drafting, not on the day you send it.
• Signed even when an MSA exists. An MSA in place is not consent to this project’s deliverables, dates or fee, and those three are what clients challenge.
• Signed version kept and referenced. Electronic signature is ordinary practice for commercial agreements in the UK, and platforms such as DocuSign are standard. Archive the executed file under its version number so a change order amends a specific document rather than a general understanding.

Work does sometimes start on a verbal go-ahead, usually because the client’s procurement is slower than their launch date. If you accept that, cap it in writing the same day: what you are starting, up to what value, and that it is subject to the SOW being executed. Anything you build before signature is funded entirely out of your own margin, and it is the only work an agency does with no route to an invoice.

Frequently asked questions

Can you add exclusions to an SOW after it has been signed? Only by agreement, through a signed amendment or change order that both parties accept. You cannot narrow an agreed scope unilaterally. If you spot a missing exclusion during delivery, raise it at the next review rather than in an invoice dispute, and price the work properly if the client wants it kept in.

How many revision rounds should an SOW specify? Name a number and define what a round is. Two rounds of consolidated feedback per deliverable is a common agency default. The definition matters more than the count: a round is one set of comments from one named approver, not four people sending notes across a fortnight. State the cost of an extra round in the same paragraph.

Should the rate card go in the statement of work? Yes, or in a schedule the SOW refers to. Without agreed day rates, every change order becomes a fresh price negotiation while the work is already late. Include the roles you actually bill, the rates, and any minimum increment such as a half day. Note how long the rates hold for.

Who inside the agency should review the SOW before it goes to the client? The person who sold the work, the person who will run it, and whoever carries the commercial risk. The delivery lead catches deliverables that cannot be built as described. Finance or operations catches payment terms that will not be met. Sending an SOW that the delivery team has never read is how implied promises reach the client unchallenged.

Should an SOW have an expiry date? Put a validity date on the pricing. Agency estimates assume a team, a schedule and a cost base that change within months. A quote accepted five months after it was written commits you to last year’s rates and a team that is now booked. A short line stating the offer is valid for thirty days is enough.

An SOW protects margin only where it is specific. Put numbers on every quantity, write the exclusions beside the deliverables they qualify, and make the change order the cheapest path for both sides rather than the slowest.