Statement of Work Template: How to Write One

A statement of work (SOW) is the document that turns a vague "we'll build you a website" into something both sides can hold each other to. It spells out what gets done, when, for how much, and how everyone agrees it's finished. When a project ends in an argument, the SOW is almost always where the answer lives, or where the gap that caused the argument was hiding.

This guide walks through what an SOW is, how it differs from a master service agreement, the sections every SOW needs, and the mistakes that quietly create scope disputes months later.

What Is a Statement of Work?

A statement of work is a contract document that defines the work a service provider will perform for a client on a specific project. It describes the deliverables, the schedule, the price, and the standard the work has to meet before it counts as complete.

You'll see SOWs in software development, consulting, marketing, construction, design, and just about any field where one company hires another to deliver a defined result. They go by a few names depending on the industry: scope document, work order, project brief, or schedule of work. The function is the same: take a fuzzy intention and pin it down in writing.

An SOW can stand on its own as a complete contract, or it can attach to a broader agreement that already covers the legal terms. The second approach is far more common in ongoing business relationships, and understanding why is the key to writing a good one.

How an SOW Fits With a Master Service Agreement

Most professional service relationships use a two-document structure:

• A master service agreement (MSA) handles the legal foundation: confidentiality, intellectual property ownership, liability limits, insurance, indemnification, payment terms, and how disputes get resolved. You negotiate it once.
• A statement of work handles the project specifics: what's being built, by when, for what fee. You write a new one for each project.

This split exists for a practical reason. Negotiating liability caps and IP clauses takes time and lawyers. You don't want to repeat that every time you start a new project with the same client. So you settle the heavy legal terms in the master service agreement, then drop in a lightweight SOW whenever there's new work to do.

If you don't have an MSA in place, your SOW has to carry all of that weight itself. That's fine for a one-off engagement, but it makes the document longer and the negotiation slower. For a single project with a new client, you might fold everything into one service agreement instead of separating the legal terms from the project terms.

A quick way to decide: if you expect to work with this client more than once, set up an MSA and keep your SOWs short. If it's a single defined job, a standalone SOW or service agreement is simpler.

The Sections Every Statement of Work Needs

A strong SOW reads in a logical order, from why the project exists down to who signs. Here are the sections that belong in almost every one.

1. Parties and Reference to the Governing Agreement

Name both parties with their full legal names and entity types. If the SOW operates under an MSA, reference that agreement by name and date, and state that the MSA's terms control if anything conflicts. This one line prevents a lot of confusion about which document wins.

2. Background and Objectives

A short paragraph on why the project exists and what success looks like. This isn't legal boilerplate; it gives anyone reading the SOW later (including a judge) the context to interpret the rest. "The Client is launching a direct-to-consumer storefront and needs a checkout flow that supports Apple Pay" tells a reader more than a list of tasks ever will.

3. Scope of Work

The core of the document. List the specific tasks and activities the provider will perform. Be concrete: instead of "design work," write "design three homepage concepts, deliver the chosen concept as a Figma file, and produce a responsive layout for mobile and desktop."

Just as important is what's out of scope. Spelling out what's excluded is what stops most scope-creep arguments before they start. If content writing, hosting setup, or ongoing maintenance aren't included, say so here.

4. Deliverables

A deliverable is a tangible output the client receives. Separate them from tasks. "Conduct user interviews" is a task; "a research summary with five prioritized findings" is the deliverable. For each one, note the format and how it will be delivered.

5. Timeline and Milestones

Lay out the schedule with dates or durations tied to project start. Break the work into milestones, since milestones are what you'll attach payments and reviews to. Note any dependencies on the client, like delivering brand assets or granting system access, and what happens to the timeline if those slip.

6. Acceptance Criteria

This is the section people skip and regret. Acceptance criteria define how a deliverable gets approved. Spell out who reviews it, how long they have, what counts as acceptance, and what happens if they request changes. A common structure: the client has ten business days to accept or send written feedback, and silence after that period counts as acceptance. Without this, "done" becomes a matter of opinion, and the provider can't get paid.

7. Pricing and Payment Schedule

State the total price or the rate structure (fixed fee, time and materials, or a hybrid), and tie payments to milestones or dates. Cover expenses, who approves them, and any cap. If the MSA already sets invoicing and late-payment terms, you can reference it instead of repeating it.

8. Assumptions

List what the estimate depends on: the client's responsiveness, the availability of a test environment, third-party tools being licensed, and so on. If an assumption turns out to be wrong, this section is what justifies a change order rather than swallowing the cost.

9. Change Management

Describe how either party requests a change to scope, schedule, or price, and how those changes get approved in writing. Most disputes come from informal "can you just add one more thing" requests that never made it into the contract. A change order process closes that gap.

10. Signatures

Both parties sign, and the signatories need authority to bind their companies. An unsigned SOW is a proposal, not a contract.

How to Write a Statement of Work: Step by Step

Step 1: Confirm the underlying agreement. Decide whether this SOW sits under an MSA or stands alone. That determines how much legal language you need to include versus reference.

Step 2: Write the objective first. Before listing tasks, write one or two sentences on what the client is actually trying to achieve. Everything else should serve that goal, and writing it first keeps the scope honest.

Step 3: Translate the objective into deliverables. Work backward from the result. What does the client need to hold in their hands at the end? List those outputs, then list the tasks required to produce each one.

Step 4: Draw the boundary. For every deliverable, decide what's included and what isn't. Write the out-of-scope list at the same time as the scope. It's much harder to add exclusions later, when the client already assumes something is covered.

Step 5: Build the schedule around milestones. Group deliverables into milestones, set realistic dates, and flag every point where you depend on the client to do something.

Step 6: Define acceptance for each milestone. Decide who signs off, how long they have, and what acceptance means. Connect payment to acceptance so the incentive to review promptly is built in.

Step 7: Price it and set the payment schedule. Match payments to milestones. A deposit up front, progress payments at milestones, and a final payment on acceptance is a standard structure that keeps both sides motivated.

Step 8: Add assumptions and the change process. Write down what your estimate relies on, then describe how changes get requested and approved. These two sections protect the price you just set.

Step 9: Review against the objective. Read the whole thing back against Step 2. If a task doesn't serve the objective, cut it. If the objective needs something the scope doesn't cover, add it.

Common Statement of Work Mistakes

Vague scope language. Words like "etc.," "and related tasks," or "as needed" are invitations to a dispute. Every one of them lets the client read in more than the provider intended. Replace them with specific items or an explicit exclusion.

No acceptance criteria. If the SOW never says how a deliverable gets approved, the project has no finish line. The client can withhold sign-off indefinitely, and the provider has no clean way to invoice the final payment.

Skipping the out-of-scope list. Listing only what's included leaves a gray area, and clients reasonably assume the gray area is covered. Naming what's excluded costs you one paragraph and saves you the argument later.

Confusing tasks with deliverables. A list of activities doesn't tell the client what they're getting. Tie every block of work to a concrete output they can point to.

Ignoring client dependencies. Most missed deadlines are caused by the client, not the provider: late feedback, missing assets, delayed access. If the SOW doesn't note these dependencies, the provider absorbs the blame for delays they didn't cause.

Treating it as paperwork. An SOW written by copying the last one and swapping names usually carries over assumptions that don't fit the new project. The structure can repeat; the substance shouldn't.

SOW vs. Related Documents

It helps to know where the SOW sits among its neighbors:

• Scope of work is a section inside the SOW, not a separate document.
• A service level agreement defines ongoing performance standards (uptime, response times) and usually applies to recurring services rather than a one-time project.
• A consulting agreement covers advisory work and may use an SOW to define each engagement.
• A proposal is a pre-contract sales document; the SOW is what you sign once the proposal is accepted.

Getting these straight matters because clients often ask for "an SOW" when they really need an SLA, or vice versa. Match the document to whether the work is a defined project (SOW) or an ongoing service standard (SLA).

When You Need a Statement of Work

• Starting a defined project with a deliverable and an end date, especially under an existing MSA
• Hiring an agency or contractor where the price depends on a specific scope
• Phasing a large engagement into discrete chunks, each with its own milestones and payments
• Working with a repeat client where you want to skip re-negotiating legal terms and just define the new work
• Any project where "done" is debatable, which is most of them

Generate Your Statement of Work with Contractable

Writing a statement of work is mostly about discipline: name the deliverables, draw the boundary, define acceptance, and connect payment to milestones. The structure is the same whether you're building software or repainting an office.

Contractable generates a customized statement of work in seconds, with the right scope, acceptance, and payment sections for your project, and it pairs cleanly with a master service agreement when you need one. No lawyers or legal knowledge required.