You won the deal. Three weeks into the work, the client asks for a second round of designs you never quoted, and the project you scoped for four weeks is quietly bleeding into six. A statement of work is the document that stops that from happening. This guide covers what a statement of work is, the nine parts every good one includes, a filled-in example, and how to write one that holds up when the work gets messy.
A statement of work, or SOW, is a document that defines the work in a project or service engagement: the deliverables, the timeline, the payment terms, and the acceptance criteria, plus what is explicitly out of scope. It turns a proposal-stage agreement into a precise, signable record that both sides can be held to. A contract sets the legal relationship. The SOW sets the work.
What is a statement of work?
A statement of work is the document a service provider and a client sign to agree exactly what will be done, by when, for how much, and how everyone will know it is finished. You see SOWs most in agencies, consultancies, professional services, IT, and construction, anywhere one company delivers a defined piece of work for another.
It is the bridge between selling and delivering. The proposal said what you could do. The SOW says what you will do, in enough detail that nobody has to guess later.
That detail is the point. Scope creep is not rare: a PMI study found that 52% of projects experience it, up from 43% five years earlier. A SOW is the cheapest insurance you can buy against it, because work that is written down and signed is work that nobody can quietly expand.
Statement of work vs scope of work, MSA, and contract
These four terms get used as if they mean the same thing. They do not.
- Scope of work is one section inside the statement of work: the description of the actual work. People often say "scope of work" when they mean the whole SOW, but technically the scope is the "what" and the SOW is the document that wraps it with timelines, payment, and acceptance.
- Master service agreement (MSA) is the umbrella legal contract that governs the whole relationship: liability, confidentiality, payment terms, dispute resolution. Many services contracts run on one MSA and then a separate SOW for each engagement, so the legal terms are agreed once and only the work changes.
- Contract is the binding legal agreement. A signed SOW usually is a contract, or part of one. If you are weighing the documents against each other, the difference between a proposal and a contract is a useful companion read.
If you want the lineage: the SOW comes from government procurement, where it is distinguished from a Performance Work Statement and a Statement of Objectives. For commercial work you rarely need that distinction. You need the work written down clearly and signed.
The 9 parts of a statement of work
Most teams know they should document scope and do not. In one industry survey, only about half of organizations said they "mostly" or "always" create a scoping document during planning. Here is the structure that makes it quick. Treat it as a skeleton you fill in, not a blank page you stare at.
- Background and objectives. Why this project exists and what outcome it serves. What good looks like: one short paragraph a new team member could read and understand the point of the work.
- Scope of work. The specific work, written as concrete tasks. What good looks like: verbs and nouns, not adjectives. "Design five landing pages," not "deliver a great web presence."
- Deliverables. The tangible things you hand over, each one defined. What good looks like: format and quantity spelled out, for example "five page designs delivered as Figma files."
- Out of scope. What you are explicitly not doing. What good looks like: this is the section that saves the project. Name the obvious adjacent asks (extra revisions, copywriting, hosting) and exclude them in writing.
- Timeline and milestones. Dates and checkpoints. What good looks like: milestones tied to deliverables, so progress is visible and not just a calendar.
- Payment schedule. Amounts, triggers, and terms. What good looks like: payments tied to milestones or acceptance, not only to dates, so getting paid tracks getting work approved.
- Acceptance criteria. How a deliverable is judged done. What good looks like: objective and testable, so "finished" is a fact, not an argument.
- Assumptions and dependencies. What you are relying on from the client: access, content, timely approvals. What good looks like: it names the client's homework, so a delay caused by the client is attributable to the client.
- Change control. How a change to scope gets requested, priced, and approved. What good looks like: a short written process, signed the same way the original SOW was. This is what turns "can you just also..." into a quick, paid amendment instead of a free afternoon.
A statement of work example
Here is the skeleton filled in for a small website-build engagement, trimmed to show the shape.
Project: Marketing site redesign for Northwind Co.
Objectives: Replace the current five-page site with a faster, on-brand site that supports lead capture.
Scope of work: Design and build five pages (home, product, pricing, about, contact). Migrate existing copy. Set up one lead form wired to the client's CRM.
Deliverables: Five page designs (Figma), a built site on the client's CMS, one connected lead form.
Out of scope: New copywriting, blog migration, ongoing hosting, SEO work, more than two rounds of design revisions.
Timeline: Kickoff week 1, designs week 3, build weeks 4 to 5, launch week 6.
Payment: 50% on signature, 50% on launch acceptance. Net 14.
Acceptance: Each page matches the approved design and loads in under two seconds on a standard connection.
Assumptions: Client provides logins, brand assets, and copy by end of week 1.
Change control: Any new request is scoped, priced, and added as a signed amendment before work starts.
Notice how the "out of scope" and "acceptance" lines do most of the protective work. They are the difference between a project that ends and one that drifts.
How to write a statement of work, step by step
- Start from what you already agreed. Pull the scope, price, and timeline from the proposal or quote. Do not reinvent terms you have already sold.
- Write the scope as tasks, then write what is out of scope. The exclusions are not rude. They are the clearest gift you can give a client, because they set honest expectations.
- Define each deliverable with its acceptance criteria. Pair every "we will deliver X" with "X is done when Y." This single habit prevents most end-of-project disputes.
- Tie milestones to payments. Map each payment to a milestone or an accepted deliverable, so cash flow follows progress.
- Add assumptions and a change-control clause. State what you need from the client and the exact process for handling new requests.
- Send it for signature before work starts. A SOW that is not signed is a wish. Getting it signed first is part of why disciplined teams deliver: across the industry, only 31% of projects come in on time, on budget, and to scope, and unsigned, unclear scope is a big reason why.
The mistakes that let scope creep in
Most scope problems trace back to the same few gaps:
- Vague deliverables. "A website" invites argument. "Five pages, these templates, this CMS" does not.
- No out-of-scope section. If you do not say what you are not doing, the client will assume you are.
- No acceptance criteria. Without a test for "done," every deliverable can be reopened.
- No change control. Without a written process, every new request becomes a negotiation, and usually a free one.
- No signature. An unsigned SOW protects no one.
These gaps are expensive. PMI has estimated that organizations waste close to 10% of every dollar they invest because of poor project performance. A tighter SOW is one of the cheapest ways to claw some of that back.
From a won deal to a signed SOW, without retyping
Most SOWs are still built by hand: open last client's document, find and replace the names, re-key the scope and the numbers, export a PDF, email it, chase the signature. Every step is a chance to ship the wrong figure.
The data you need is already sitting in your CRM. The deal you just closed has the client, the line items, the price, and the owner attached to it. Portant generates the statement of work from a template you already use, fills it with your HubSpot deal data and line items, and adds built-in eSignature, so the signed document syncs back to the deal record with its status tracked. You keep your own template and format. Nobody retypes a deal that already exists in the CRM. It is the same idea behind document automation generally: stop rebuilding documents you already have.
Frequently asked questions
What is a statement of work in project management?
In project management, the statement of work is the document that defines the project's scope, deliverables, schedule, and acceptance criteria before work begins. It is the reference everyone returns to when a question about scope comes up.
Who writes the statement of work?
Usually the service provider drafts it, because they know the work, and the client reviews and signs. On larger engagements a project manager or account lead owns it, often starting from the proposal the salesperson already agreed.
Is a statement of work legally binding?
A signed SOW is generally binding, either as a standalone contract or as the work order under a master service agreement. Have a lawyer review your contract template once, especially the payment, liability, and termination terms.
What is the difference between a statement of work and a purchase order?
A statement of work describes the work to be done and how it will be judged complete. A purchase order is the buyer's authorization to spend a set amount on it. The SOW defines the work; the PO commits the budget.
How long should a statement of work be?
As long as it needs to be to remove ambiguity, and no longer. A focused services SOW is often two to four pages. Clarity matters more than length: a tight three-page SOW beats a padded ten-page one.
If your SOWs live in a Google Doc you copy and re-edit for every client, you can wire that template to your CRM instead and send it for signature in one flow. See how Portant builds and sends a statement of work from a HubSpot document template.
