A statement of work (SOW) says what an agency will deliver, how the client will judge each piece, and what the fee does not cover. Most SOW templates list the right sections and still end in arguments, because the deliverables have no acceptance test and nobody wrote down what is not included. This guide covers both, plus revision rounds and changes after signing, and shows how to keep the SOW in Atwork as rows your team works from instead of a PDF nobody opens after kickoff.
What is a statement of work, and how is it different from a proposal or a contract?
A statement of work describes one project: the deliverables, how each one is accepted, the timeline, the client's inputs and what is excluded. A proposal sells the project before the client agrees to it. A master services agreement (MSA) holds the legal terms that apply to every project, and each SOW sits under it.
In a small agency the three often collapse into one PDF. That is where the trouble starts: the proposal's selling language ("a modern, conversion-focused website") becomes the scope, and selling language can't be tested.
| Document | Its job | When it changes |
|---|---|---|
| Proposal | Wins the work: the problem, the approach, the price | As often as you like, before signing |
| Master services agreement | Terms for every project: payment, ownership, liability, ending the contract | Rarely, and by both sides |
| Statement of work | One project: deliverables, acceptance, timeline, exclusions | Only through a change request both sides approve |
What sections does an agency SOW need?
Eight sections cover almost every agency project: the objective, the deliverables with their acceptance tests, what is not included, the client's inputs, the timeline, revision rounds, the change process and sign-off. Fees can sit in the SOW or in the proposal it points to.
- Objective. Why the project exists, in the client's words.
- Deliverables. Each with its acceptance test, rounds included and due date.
- Not included. The work a client is likely to assume is part of it.
- Client inputs. Copy, logins and brand files, each with a date. A late input moves the timeline.
- Timeline. Milestones tied to deliverables, not to months.
- Revision rounds. How many per deliverable, and what counts as one.
- Change process. How a new request is priced and approved.
- Sign-off. One named approver, and how many working days they have to reply.
How do you write a deliverable a client can sign off?
Write each deliverable as something the client receives, then add the test that proves it is done: what it contains, its format and who checks it. "A new homepage" can't be signed off. "Homepage design, desktop and mobile, in Figma, built on the approved wireframe, checked by Jonas Kern" can.
US government buyers work to the same rule. The Federal Acquisition Regulation tells them to:
Describe the work in terms of the required results rather than either "how" the work is to be accomplished or the number of hours to be provided. (FAR 37.602)
The next section of the same rules says each performance standard "shall be measurable and structured to permit an assessment of the contractor's performance" (FAR 37.603). For an agency, that standard is the acceptance test.
| Deliverable as usually written | Deliverable a client can sign off |
|---|---|
| A modern homepage | Homepage design, desktop and mobile, in Figma, built on the approved wireframe |
| Social media content | 12 posts a month: 8 single images and 4 carousels, sized for Instagram and LinkedIn, captions included |
| SEO optimisation | A title and meta description for each of the 15 pages on the approved sitemap, delivered as one sheet |
| Brand refresh | Logo lockups in 3 versions, a colour palette and a type scale, as a PDF and a Figma library |
Every deliverable then carries the same five things: what it is, its acceptance test, rounds included, approver and due date. That is the shape of a sheet.
What belongs under "out of scope"?
The out-of-scope list names the work a client could reasonably assume is included and isn't: the next phase, more of the same, the content you expected them to supply, and running the thing after launch. Written down, it is the answer you can give in week six without reopening the contract.
In PMI's 2018 Pulse of the Profession, 52% of projects completed in the previous 12 months experienced scope creep or uncontrolled changes to their scope, up from 43% five years earlier. In agencies it turns into unpaid work: Ignition's 2025 Agency Pricing and Cash Flow Report found that 57% of US agencies lose $1K to $5K each month to scope creep.
Lines that earn their place on the list:
- The next phase. "Build and development are phase 2 and quoted separately."
- More of the same. "Pages beyond the 15 on the approved sitemap."
- Inputs you assumed the client supplies. "Copywriting, photography and translations."
- Running it after launch. "Hosting, maintenance and analytics setup."
When an excluded item comes up anyway, the list turns a favour into a quote. Most scope creep starts as a change request nobody sends, so a request needs somewhere to go.
How many revision rounds should a SOW include?
Two revision rounds per deliverable is a sensible default for design and content work, with any further round quoted as a change. The number matters less than the definition: one round is one consolidated set of feedback from the named approver, sent by an agreed date, not every message anyone on the client's side sends.
In a 2019 survey of about 200 brand marketers, agencies and publishers by Digiday and OpenText Hightail, 84 percent of respondents said there are too many rounds of creative review. Revision rounds multiply when there is no single approver and no agreed definition of done, so the definition does more work than the number. After the last round, the next one is a change request with a price, and the client decides whether it is worth it.
What happens when the client asks for a change after signing?
When a client asks for a change after signing, don't edit the signed SOW. Log it as a change request, estimate it, and send the client a price and new date to approve before anyone starts. Once approved, it becomes a new deliverable with its own acceptance test and rounds, and the original SOW still shows what was agreed.
Small requests are where fixed-fee projects lose their margin, because they rarely get logged (where the extra hours on agency projects go). Give every request a row the moment it arrives. A sheet can have its own email address, so forwarding a client's email turns it into a row.
How do you keep a statement of work in Atwork?
Keep the deliverables as rows, not paragraphs. In Atwork, each deliverable is a row in a Deliverables sheet with its acceptance test, rounds and approval state, and the Word document the client signs is filled from the project's own row. The SOW becomes the plan your team works from.
- Install the Agency Client Delivery template. Briefs holds the scope, budget hours and who signed it off. Deliverables has Round, Estimate (hours) and an Approval field (Not sent, With client, Changes requested, Approved), separate from your internal status.
- Add Acceptance test (Long Text), Rounds included (Number) and a Type field (Planned, Change request) to Deliverables, or ask Dana, Atwork's AI teammate, to add them. An AI autofill column can draft a first acceptance test for every row from the fields you point it at; edit each one before the client sees it.
- Write the not-included list in the brief's description, where the team reads it first.
- Write the SOW once in Word with placeholders for the brief's fields and upload it to a DocX field on Briefs. Each brief gets a Download button that fills it in. Keep the signed copy in a File List field on the same row.
- Publish a view of the project's deliverables as a link, so the client reviews against the tests they signed.
Frequently asked questions
Who should sign a statement of work?
Someone on each side who can agree to scope and money, usually the agency's account lead and the client's budget holder. Sign-off of each deliverable can sit with someone else, such as the client's marketing manager, as long as the SOW names them.
How long should an agency statement of work be?
Long enough to hold every deliverable's acceptance test and the not-included list, and no longer. Legal terms belong in the master services agreement, not repeated in each SOW.
Does a retainer need a statement of work?
Yes, a lighter one: what the monthly fee covers, in hours or outputs, what it doesn't, what happens to unused hours and how extra work is quoted. Whether a piece of work belongs on a retainer at all is a question about risk.
Write the test before the work
A statement of work ends arguments when it can be checked: each deliverable has a test, a round limit and a name, and the exclusions are written down before anyone needs them. Keep those as rows and the SOW stays in use long after kickoff.
Put one project's deliverables in as rows, each with its acceptance test and rounds, and share the view with your client. Start free