Statement of Work

What a statement of work is

A statement of work (SOW) is the document that turns an agreed deal into a precise plan of action. It spells out exactly what will be done, what the client will receive, when each piece lands, how everyone will know it is finished, and what it costs. Where a proposal persuades, an SOW commits — both sides sign it and then point to it whenever a question comes up about who is doing what.

A strong SOW removes ambiguity. After reading it, the client, the delivery team, and anyone who joins later should all picture the same engagement: the same boundaries, the same deadlines, and the same definition of done.

When you need a statement of work

Reach for an SOW once a deal is agreed in principle and work is about to start, particularly when the engagement is project-based, has real money or deadlines attached, or involves several deliverables that must be accepted in stages. Agencies, consultants, freelancers, and professional-services firms use SOWs to convert a handshake into an accountable plan. For a tiny, single-output job a short order or accepted quote may be enough; the moment scope, schedule, and sign-off start to matter, an SOW pays for itself.

SOW vs proposal vs master agreement

These three documents are often confused, but they do different jobs and frequently sit side by side.

• A sales proposal (or a consulting proposal) comes first. It frames the problem and sells the solution, but its scope and numbers are still an offer, not a binding plan.
• A master agreement — often a service agreement or master services agreement — sets the legal terms that govern the whole relationship: liability, confidentiality, intellectual property, termination, and dispute handling. It is signed once and reused.
• The SOW sits underneath that agreement and describes one specific engagement: the actual scope, deliverables, schedule, and price. Many SOWs can hang off a single master agreement over time.

A practical rule: the master agreement answers "how we work together"; the SOW answers "what we are doing this time, by when, and for how much."

The key sections of a statement of work

Most SOWs are built from the same load-bearing parts. Skip one and disputes tend to grow there.

• Scope — the plain-language description of the work and, just as importantly, what is explicitly out of scope. This is the heart of the document.
• Deliverables — the concrete, named outputs the client receives, ideally in a table with owners and formats so nothing is left to interpretation.
• Timeline and milestones — the schedule broken into phases or milestones, each with a target date so progress is measurable rather than vibes-based.
• Acceptance criteria — the objective tests a deliverable must pass to be considered complete, plus how long the client has to review and how revisions are handled.
• Pricing and payment — the fee, the structure (fixed price, time and materials, or milestone-based), and a payment schedule tied to dates or accepted milestones.
• Assumptions and dependencies — the conditions the plan relies on, such as timely client feedback, access to systems, or third parties delivering on time.
• Change control — the agreed process for handling new requests once work has started, so scope creep becomes a deliberate, priced decision rather than a quiet drift.

How to write a scope section that holds up

The scope section is where most engagements succeed or unravel, so write it for a sceptical reader.

• Be specific and countable. "Build the marketing site" invites argument; "design and build a six-page marketing site (Home, Product, Pricing, About, Blog index, Contact)" does not.
• Name what is out of scope. An explicit exclusion list ("copywriting, photography, and ongoing hosting are not included") prevents the most common and most expensive misunderstandings.
• Tie scope to deliverables. Every promise in the scope narrative should reappear as a named item in the deliverables table, and nothing should appear in one place but not the other.
• State the inputs you need. If the work depends on client-supplied content, logins, or approvals, say so here and in assumptions — that is what protects the timeline.
• Avoid open-ended verbs. Words like "support", "optimise", and "as needed" have no edge. Bound them with a number, a count, or a date.

Common mistakes to avoid

• Vague acceptance criteria. If "done" is a matter of opinion, sign-off stalls. Make completion testable: a checklist, a passing demo, or a measurable threshold.
• No change-control process. Without one, every new ask either erodes your margin or sours the relationship. Agree the process before you need it.
• Payment untied from progress. Tie invoices to milestones or accepted deliverables so cash flow tracks the work rather than the calendar alone.
• Hidden assumptions. If the plan quietly relies on the client reviewing within three days, write it down — otherwise the slip becomes your problem, not theirs.
• Copy-paste scope. Reusing a previous SOW without re-reading the scope is how teams promise work that does not match this engagement. Tailor every time.
• Mixing pricing models without saying so. If part is fixed and part is time and materials, label each clearly and explain how the time-and-materials portion is estimated and capped.