What Is a Statement of Work (SOW)?

A statement of work is where most client disputes are either prevented or created. The clauses that matter are rarely the ones people spend time on.

Quick answer: A statement of work is a document defining exactly what a supplier will deliver to a client — scope, deliverables, timeline, acceptance criteria, pricing and assumptions. It usually sits beneath a master services agreement, which covers legal terms, while the SOW covers the specific engagement.

The SOW, Defined

The SOW is the engagement-specific part of an agreement: what, when, how much, and how you will know it is done.

Where it sits in the contract

Ongoing client relationships usually have a master services agreement (MSA) setting the legal terms — liability, confidentiality, payment terms, intellectual property.

Each individual project then gets its own SOW under that MSA. This means legal terms are negotiated once, and each new piece of work only needs its scope agreed.

Who writes it

Usually the supplier drafts it, since they understand the work, and the client reviews and negotiates.

In procurement-led organisations the client sometimes issues a SOW as part of a tender, and suppliers respond to it. Either way, both sides should read it as the document they will be held to.

Why it matters more than people think

When a disagreement arises about whether something was included, the SOW is what gets read.

A vague SOW does not avoid conflict — it postpones it to a point where both parties have invested heavily and changing course is expensive.

What a SOW Contains

Section Contains Why it matters Purpose and background Why the work is happening Context for interpreting everything else Scope What work is included Defines the boundary Out of scope What is explicitly excluded Prevents the most common disputes Deliverables Specific outputs, each named What the client is paying for

Acceptance criteria must be testable

How each deliverable is judged complete Defines "done" objectively Timeline and milestones Key dates and checkpoints Sets expectations and payment triggers

Roles and responsibilities What each party provides Client dependencies become visible Assumptions What is taken on trust Makes hidden risks explicit Pricing and payment Fee, basis, payment schedule Commercial terms for this engagement

No change process

How changes are raised, approved, priced Makes the first change procedural

SOW Compared With Related Documents

Document Purpose Legally binding? Covers

What is a statement of work?

Defines a specific engagement Usually, as part of the contract Scope, deliverables, acceptance, price Master services agreement Sets ongoing legal terms Yes Liability, IP, confidentiality, payment terms Project charter Authorises a project internally No, internal Objectives, sponsor, budget authority Scope of work Describes the work only Part of the SOW The work itself, without commercial terms Proposal Offers to do the work Usually not, until accepted Approach and price, persuasive in tone

This is general information, not legal advice — have contracts reviewed by a qualified professional in your jurisdiction.

Writing a SOW That Prevents Disputes

Three sections do most of the work: exclusions, acceptance criteria and the change process.

Exclusions are the most important section

List what a reasonable person might assume is included and is not. "Migration of existing content is out of scope." "Ongoing hosting is not included." "Two rounds of revisions; further rounds are billable."

Every dispute about scope traces back to an assumption nobody wrote down. Ten minutes on exclusions prevents weeks of argument later, and it is the section most often left thin.

Acceptance criteria must be testable "Website is completed to a high standard" cannot be tested. "All pages load in under three seconds on a standard connection, pass WCAG 2.1 AA checks, and render correctly in the current versions of Chrome, Safari and Firefox" can.

Each deliverable needs criteria that both parties could independently check and agree on.

Without them, "done" becomes a negotiation.

Define how change works

State how changes are requested, who approves them, how they are priced, and that they affect timeline.

Agreeing this before any change arises means the first change request is administrative rather than confrontational. Tracking agreed deliverables and client-owned dependencies as tasks with owners — Taskzin lets clients see these as free guests — keeps the SOW visible during delivery rather than filed at signature.

Common SOW Mistakes

Describing activity rather than outcomes, leaving acceptance vague, and omitting the change process.

Describing activity instead of deliverables

"Supplier will conduct research and design work" describes effort. It does not say what the client receives.

Name deliverables as outputs — "a research report of findings from twelve customer interviews", "three homepage design concepts" — so there is something concrete to accept.

Vague acceptance

Without testable criteria, acceptance depends on the client's mood on the day, and final payment depends on acceptance.

This is where suppliers lose money most often — not on pricing, but on endless revision cycles against an undefined standard.

No change process A SOW without a change process makes every change an informal negotiation, usually conducted under deadline pressure.

The result is typically absorbed work and a resentful supplier, or a dispute and a damaged relationship. Neither is necessary.