How to Write a Statement of Work (SOW): Template + Example

Most scope disputes are not really disagreements about the work. They are disagreements about what was agreed, argued months after the only document that could settle it was written too loosely to help. A statement of work is that document. Written well, it is the single page you point to when a client says "I thought that was included". Below is what a SOW is, the sections it actually needs, a copy-paste template, and a filled-out example.

This is a practical guide, not a legal one. The goal is a SOW you can write yourself for a normal client project and have it do its job: remove ambiguity now, so it does not become an argument later. For liability, IP, and jurisdiction wording on anything substantial, have a lawyer review the template once — after that, you reuse it.

What a statement of work actually is

A statement of work is the contractual document that pins down exactly what you will deliver, how it will be judged done, by when, and for how much. It is the point where a loose understanding of a project becomes specific, enforceable terms. Everything before it — the pitch, the discovery call, the brief — is about reaching agreement. The SOW is about recording that agreement in a form that holds up when memories differ.

The easiest way to place it is against the documents it sits between. A proposal wins the work and is written to persuade. A brief captures the shared understanding of what you are building and why. The SOW turns that understanding into a binding scope with deliverables, acceptance, and payment attached — and sign-off makes it enforceable. Confusing these is where trouble starts: a persuasive proposal is a bad contract, and a brief with no acceptance criteria settles nothing.

This is why the SOW reads differently from everything around it. A brief can be warm and exploratory; the SOW is precise and a little boring on purpose. When two people remember a conversation differently, the SOW is what they check — so every sentence in it is written to be checkable, not inspiring.

The sections a SOW needs (and the three that matter most)

A workable SOW has eleven parts. Most are straightforward — the parties, the objective, the timeline, the fees. Three of them are where projects are quietly won or lost, because they are the sections weak SOWs either skip or fill in vaguely. Get these three right and the document earns its place; get them wrong and you have a persuasive proposal wearing a contract's clothes.

1. 1Scope of work: the "out" list is the one that protects you. Everyone writes what is included. The section that prevents disputes is what is explicitly excluded — the things a reasonable client might assume are part of the job but are not. "No content migration, no third-party integrations, no ongoing maintenance" turns a later request for them into a change order and a conversation, not a silent assumption and an argument. An in-scope list without a matching out-of-scope list is only half a boundary.
2. 2Acceptance criteria: define "done" as something you can test. The most expensive phrase in project work is "that's not quite what I wanted" during the final week. Acceptance criteria pre-empt it by stating the objective test each deliverable must pass and the window the client has to accept or return it with written revisions. "The booking flow lets a user reserve a slot and receive a confirmation email" is testable; "a great booking experience" is an invitation to endless revision. This is the same discipline requirements engineering calls a verifiable requirement.
3. 3Change control: decide now how a new request is handled. Scope will change — that is normal, not a failure. What separates a healthy project from a death march is having agreed, in advance, what happens when it does: any request outside the scope section is quoted as a written change order and does not proceed until approved. This single clause converts scope creep from something that happens to you into a decision the client makes with a price attached.

The other eight sections still matter — a payment schedule tied to milestones protects your cash flow, client responsibilities put the timeline risk where it belongs, and an assumptions section lets you re-price honestly when a stated condition turns out false. But if you only had time to sharpen three lines in a SOW, sharpen scope-out, acceptance, and change control. They are where the money is.

The statement of work template

Copy everything in the block below. Each section has a one-line prompt in brackets telling you what belongs there; delete the prompt as you fill it in. Eleven sections looks like a lot, but most are a few lines — a real SOW for a small project fits on two to three pages.

STATEMENT OF WORK

Between:  [Your company / your name]  ("Provider")
And:  [Client company]  ("Client")
Project:  [Project name]
SOW date:  [Date]  ·  Effective from:  [Start date]

1. BACKGROUND & OBJECTIVE
[One short paragraph: what the Client needs and the outcome this work must achieve. Not a feature list — the result.]

2. SCOPE OF WORK
In scope:  [The specific work included, itemised. Be concrete.]
Out of scope:  [What is explicitly NOT included, so a later request becomes a change order, not an assumption.]

3. DELIVERABLES
[Each concrete thing you will hand over, with a one-line description of what "delivered" means for it.]

4. ACCEPTANCE CRITERIA
[How each deliverable is judged done: the objective test the Client applies. Include a review window, e.g. "5 business days to accept or return with written revisions".]

5. TIMELINE & MILESTONES
[Key dates and what is due at each. Note any dependency on the Client (content, access, approvals) and what happens to dates if it slips.]

6. CLIENT RESPONSIBILITIES
[What the Client must provide, and by when: content, brand assets, logins, feedback, a single decision-maker. Delays here move the timeline.]

7. FEES & PAYMENT SCHEDULE
[Total fee (fixed, or rate + estimate). Payment terms and milestones, e.g. 40% to start / 40% at milestone / 20% on acceptance. Invoicing and due days.]

8. CHANGE CONTROL
[How new or changed requirements are handled: any request outside Section 2 is quoted as a written change order and does not proceed until approved in writing.]

9. ASSUMPTIONS & DEPENDENCIES
[The conditions this SOW is priced against — third-party tools, existing systems, response times. If they turn out false, scope and price may change.]

10. TERM, TERMINATION & IP
[Duration, how either side ends it and notice, what is owed on termination, and when ownership/IP of the work transfers (typically on final payment).]

11. SIGN-OFF
Provider:  ____________________   Date: ________
Client (authorised signatory):  ____________________   Date: ________

That is the whole structure. The value, as always, is in the answers you put in it — a SOW full of "TBD" is not a contract, it is a promise to argue later. The rest of this post shows what the sections that matter look like filled in.

A filled-out example

Here is the template with real answers, for a familiar project: a three-location dental practice that wants a new marketing site with online booking. Only the load-bearing sections are shown filled — notice how each one carries a decision, not a placeholder.

STATEMENT OF WORK

Between:  Northlight Studio  ("Provider")
And:  Northgate Dental Ltd  ("Client")
Project:  New website + online booking
SOW date:  13 July 2026  ·  Effective from:  21 July 2026

2. SCOPE OF WORK
In scope:  5-page marketing site (home, about, 3 location pages),
  integration with the Client's existing Dentally booking account,
  responsive design, basic on-page SEO for 3 location terms.
Out of scope:  patient portal, online payments, multilingual content,
  content writing (Client provides copy), ongoing maintenance, hosting.

4. ACCEPTANCE CRITERIA
- Each page renders correctly on current Chrome, Safari, and mobile.
- A patient can complete a booking from the site and receive the
  Dentally confirmation email.
- Client has 5 business days from delivery to accept, or return one
  consolidated list of written revisions. Silence past 5 days = accepted.

7. FEES & PAYMENT SCHEDULE
Fixed fee: €6,400 + VAT.
  40% (€2,560) on signature to begin.
  40% (€2,560) at design sign-off.
  20% (€1,280) on acceptance. Net 14 days on each invoice.

8. CHANGE CONTROL
Any request outside Section 2 is quoted as a written change order
  (scope + fee + timeline impact) and does not begin until approved by
  email by the Client's authorised signatory.

Where the answers come from: the brief feeds the SOW

A SOW is only as good as the understanding behind it, and you cannot write a precise scope section from a vague sense of the project. The scope, deliverables, and assumptions in a good SOW are lifted almost directly from a good brief — which is why the reliable sequence is discovery first, brief second, SOW third. Skip the brief and you end up guessing at the scope section, which is exactly the guessing a SOW exists to eliminate.

Business analysts call the underlying work elicitation — actively drawing requirements out rather than waiting to receive them — and it is the step that makes acceptance criteria writable. You can only state that "a booking returns a confirmation email" as a test if you asked, during discovery, what a successful booking looks like to the client. The formal version of this discipline, ISO/IEC/IEEE 29148, is built on the idea that every requirement should be verifiable — which is precisely what an acceptance criterion is.

If your SOWs keep coming out vague, the problem is usually upstream: the brief was thin, so there was nothing precise to write down. Fixing the intake fixes the SOW. The full method is in how to write a project brief clients actually complete, and the structure to fill sits in the project brief template.

Three ways a SOW gets written badly

1. 1Copying the proposal into the SOW. The proposal was written to win the work, so it is optimistic and broad — "we'll deliver a best-in-class experience". Paste that into a SOW and you have promised something with no defined edge. The SOW is a different genre: narrow, testable, a little dull. Rewrite, don't copy.
2. 2Leaving acceptance and change control out because they feel awkward. Defining "done" and pricing changes are the conversations people avoid because they feel confrontational at signing. They are the opposite: they are what let you say yes to a change calmly later, because there is an agreed process. The awkward paragraph now prevents the tense email in week four.
3. 3Treating it as paperwork nobody will read. A SOW written to be filed and forgotten is written loosely, because why sweat a document no one reads. But the moment it matters is the one moment it is read very closely, by two people who now disagree. Write every SOW as if it will be read in a dispute, because the only ones that matter are.

Writing a SOW you can actually stand behind

However you produce it, the principle holds: a SOW is only as precise as the understanding behind it, and that understanding comes from a real conversation with the client, not a form they half-filled. This is the part ReqBrief handles. Instead of guessing at scope, you send the client a link and an AI interviews them one question at a time — goals, scope, what "done" looks like, stakeholders, constraints — following up on the thin answers, and hands you back a structured brief. From there the SOW almost writes itself, because the scope section, the deliverables, and the acceptance tests are already sitting in the brief. Unlike a blank ChatGPT prompt, it interviews the person who actually holds the answers. It is built for consultants and small agencies scoping client work.

Copy the template, use it by hand, and your projects will start on firmer ground. Feed it from a real interview instead of a vague sense of the work, and the SOW stops being the document you hope you never have to reread — and becomes the one that quietly settles the argument before it starts.

Frequently asked questions