What is a statement of work? A guide with 10 steps

A statement of work is where a project either gets off to a clean start or quietly sets itself up to fall apart.

Done well, it tells everyone (client and provider) exactly what's being delivered, by when, and for how much.

Left vague, it's an open invitation to scope creep, missed deliverables, and the "that was never in the agreement" conversation a few weeks in.

This guide walks through what a statement of work is, the main types, how it differs from a scope of work and a project plan, and how to write one step by step.

You'll also find a free template and a complete, filled-in SoW example you can copy.

Key takeaways

• A statement of work is the document that defines what a project will deliver: its scope, deliverables, timeline, payment terms, and acceptance criteria.
• It typically forms part of the contractual agreement between the two parties, often attached to a master service agreement, and becomes binding once both sides sign it.
• A statement of work, a scope of work, and a project plan are related but distinct: the scope of work is a section inside the SOW, and the SOW is usually a section inside the project plan.
• Write it at the very start of a project, after the initial scoping conversation but before work begins.
• Keep it current. A signed SOW that drifts out of date is the version your team stops trusting, so plan for how it gets reviewed and re-verified as the project changes.

What is a statement of work (SoW)?

A Statement of Work (or SoW) is an important project management tool that outlines a project's work requirements.

It touches on timelines, project-specific services & activities, deliverables, and budgetary information.

An SoW contract is one of the first documents exchanged between company and client and acts as an informal work contract.

What does a statement of work do?

A statement of work sets out exactly what a project includes, what it doesn't, and the terms both parties have agreed to.

That single source of agreement is what makes everything else on the project run smoother.

The benefits stack up quickly:

• Organization: it gives teams a shared reference for what's in scope and who's doing what.
• Communication: it raises the quality of communication between everyone involved in the project.
• Planning: it informs the rest of your project planning process.
• Transparency: both client and company can see the full bounds of the project, which is the foundation of any successful engagement.
• Scope control: it prevents scope creep by fixing what's in and out of the project up front.

That transparency is the most important thing an SoW offers.

Both parties being happy is the essential foundation of any successful project, and a clear SoW is what makes that happen. It sets clear expectations for deliverables, outcomes, communications, and timelines on both sides, a step ahead of a simple project proposal.

Types of statement of work

Most statements of work fall into one of three types. Which one you reach for depends on how predictable the work is and how you're pricing it.

• Design / detail SOW: spells out exactly how the work will be done, with precise requirements, processes, and conformance standards. Use this when the deliverable is well-defined and you need tight control over the method, like a build to a fixed specification.
• Level-of-effort SOW: prices the work by hours or units of effort over a set period rather than by a fixed deliverable. Use this when the work is ongoing or hard to scope precisely up front, like staff augmentation or support retainers.
• Performance-based SOW: defines the outcomes and success criteria and leaves the method to the provider. Use this when you care about the result more than the process and want to tie payment to measurable performance.

Scope of work vs statement of work

Statements of work, scopes of work, and project plans get talked about together, but they're not the same thing and only the statement of work should be abbreviated "SoW."

Here's how they relate:

SoWs are usually written before project plans, so they're often useful in laying the groundwork for a project plan.

In addition, both documents are usually written (or at least led) by the project manager.

Who writes the statement of work?

Like most project management documents, SoWs are best written collaboratively, but two parties matter most.

• On the provider side, the project manager usually drafts the SoW, often assigning sections to the team members closest to each area so the document is thorough and accurate.
• On the client side, it's typically reviewed and signed off by several senior stakeholders, with one main contact leading the relationship through the project. Both sides need to approve it before work really begins.

When is the best time to write a Statement of Work?

The SoW is one of the very first official documents of a project. It comes after your initial meeting with a company, once you've discussed project details and perhaps agreed on a quote.

SoWs carry a fair amount of detail, so you'll need to work through every element that goes into one before you start writing. That often means scheduling a dedicated scoping meeting.

Draft, write, finalize, and send your statement of work as early as you can. It lays the foundation for a lot of other project documentation down the line, so get it out of the way at the start.

How to write a Statement of Work: step by step guide

The exact contents flex by industry and project, but a solid SoW almost always works through the same ten steps:

Many teams now collect those approvals with e-signature tools rather than printing and scanning the signature page.

What to include in a statement of work

Pulled out of the steps above, here's the full component list a complete statement of work usually carries:

• Overview: a short summary of the project, its context, and the stakeholders involved.
• Scope: what work is in scope and, just as importantly, what isn't.
• Deliverables: what gets produced, and who verifies each one.
• Milestones & schedule: start and end dates tied to each task and deliverable.
• Budget & payment terms: costs, payment schedule, and methods.
• Acceptance criteria: the specific conditions that mark the project as complete.
• Assumptions & constraints: the conditions you're relying on and the limits you're working within.
• Signatures: the sign-off block that makes the agreement binding.

The template below gives you this structure to start from, and the worked example after it shows each component filled in.

Slite's free statement of work (SoW) template

Getting started on a statement of work can be intimidating, especially if you don't have much experience writing them or are kicking off a particularly high stakes project.

Above all, you want to ensure that you produce a clear, high-quality piece of documentation that isn't missing any key elements or deliverables.

Slite's free statement of work template gives collaborative teams a structured starting point you can fill in together, and it pairs with the worked example below so you can see what a finished SoW looks like before you write your own.

It's easy to customize: drop in the videos, images, tables, document links, and examples your project needs.

We build documentation tools for teams that have to keep their knowledge accurate as projects change, and an SoW is exactly that kind of living document. Whether you need to start one right now or have one coming down the pipe, take the template and adapt it.

Once your SoW is ready, you can move on to a project charter and share it with stakeholders.

Statement of work example

Here's a short, filled-in SoW for a consulting-style engagement: an external partnerships consultancy building out a referral and affiliate program for a software client.

It's genericized, but the structure mirrors a real scope doc, so you can lift the shape and swap in your own details.

You can keep a copy like this in Word, PDF, or Google Docs, or build it straight from Slite's free template.

Project overview

ClientCo is engaging Partner Consultancy to design and launch a partner program. The program will consist of five groups: affiliates, a referral widget, partners, co-marketing, and marketplace partners. These groups bring in customers via referral links powered by a JavaScript snippet and API integration. The program will be built in five modules with a set of integration calls.

Scope

In scope: program design, configuration of the five partner groups, referral-link and API integration setup, and partner onboarding flows. Out of scope: paid media spend, net-new product engineering, and any group not listed above. Changes to this scope follow the change-control clause below.

Stakeholders

Deliverables

Milestones and timeline

• Module 1 (program foundations and stakeholder sign-off): week 1
• Modules 2-3 (group configuration and referral-link integration): weeks 2-4
• Module 4 (co-marketing and marketplace setup): week 5
• Module 5 (testing, verification, launch): week 6

Payment terms

A deposit is due on signature, with the balance split across milestone completions. Reward percentages paid to partners are defined per group in a separate rewards schedule. Late milestone sign-off shifts the launch date by the same number of days.

Acceptance criteria

The engagement is accepted when all five groups are configured and verified, the referral-link flow passes end-to-end testing, and the integrations checklist is fully signed off by the named owners above.

Sign-off and change control

Any change to the initial scope will impact the program's days-to-launch timeline. Any scope change must be acknowledged and approved by the Project Leader before work continues. Signatures below bind both parties to this statement of work.

Our top tips for creating a Statement of Work effectively

A few principles separate a SoW that holds up from one that causes arguments later:

• Develop it collaboratively. Don't write the whole thing alone. Have whoever owns each area (scope, budget, technical work) draft their part, so the document is consistent and the load isn't on one person.
• Start from a template. It gives you structure, direction, and a format to build from, so you don't miss tasks, deliverables, or terms. Use Slite's free template to get going.
• Balance detail with length. Be thorough but concise; a few pages is ideal where possible, without dropping any key details about the work.
• Use clear, plain language. Many people from different functions will review and sign it, so write so anyone involved can understand it.
• Account for future changes. Agree change-control criteria with your client up front, and keep the SoW somewhere it stays current.
• Review it, then keep reviewing it. Get several pairs of eyes on it before sign-off, and assign a named owner and a verification cadence so the signed version doesn't quietly drift out of date.

Keep your statement of work from going stale

A signed SoW is one of the documents you can least afford to let drift. The moment people stop trusting it's current, they route around it: back to Slack, back to asking whoever wrote it.

Slite is a self-maintaining knowledge base: a structured, verified workspace where your SoW and the docs around it stay current as the project changes.

The mechanism is concrete. Assign a named owner to each document and set a verification cadence (every six months, a year, or tighter for high-churn docs like SoWs and specs).

Slite Agent then cross-references your docs against the tools where work actually happens, including Slack, Linear, GitHub, and 20-plus connected tools, and flags when a document has drifted from reality.

Every proposed change routes through human approval before it becomes truth, so nothing is auto-applied behind your back.

This matters more in 2026 than it used to.

As one aerospace engineering lead put it, a stale doc used to be a human inconvenience; now it's an infrastructure risk. AI agents read documents like SoWs and act on what they say, so an out-of-date clause is wrong at scale, not just inconvenient for the next person who opens it.

See how Slite Agent keeps your documentation trustworthy as your project evolves.

Conclusion

A good statement of work is mostly front-loaded work: a clear scope, honest timelines, deliverables both sides have signed off on, and a plan to keep the document current once the project is moving. Get those right and the SoW does its job, keeping everyone pointed at the same outcome from kickoff to closure.

Start from Slite's free statement of work template, adapt the example above to your project, and decide up front who owns the document and how often it gets re-verified.

FAQ

Is a statement of work legally binding?

Yes, once it's signed. A statement of work is typically a contractual document, usually executed under or alongside a master service agreement (MSA), and it becomes binding on both parties once they sign it. The earlier "informal work contract" framing is common, but in practice a signed SoW carries real contractual weight, which is exactly why the scope, deliverables, and acceptance criteria need to be precise.

What's the difference between an SOW and an MSA?

A master service agreement sets the overarching legal and commercial terms of the relationship between two parties: liability, payment terms, confidentiality, and dispute resolution. A statement of work sits underneath it and defines a specific piece of work: scope, deliverables, timeline, and acceptance criteria. One MSA can cover many SoWs, which is why teams often sign the MSA once and then issue a new SoW per project.

Who prepares a statement of work?

On the provider side, the project manager usually drafts the SoW, often assigning sections to the team members closest to each area. On the client side, it's reviewed and signed off by several senior stakeholders, typically with one main contact leading the relationship. The best SoWs are written collaboratively rather than by one person in isolation.

What does a statement of work look like?

A statement of work is a structured document with clear sections: an overview, scope, deliverables, milestones and timeline, payment terms, acceptance criteria, and a sign-off block. You can see a complete, filled-in version in the statement of work example above, or start from Slite's free template.