Statement of Work (SOW) Template

A statement of work template gives you a ready structure for the document that sets out what a project will deliver, by when, and for how much. Project managers usually write it with their team, and the client signs it before any work starts. Once both sides sign it, the SOW is the record you check when questions about scope, dates, or cost come up.

What is a statement of work template?

A statement of work, or SOW, is a formal document that describes the work a vendor or team will do for a client. It covers the scope, the deliverables, the timeline, the cost, and how the work will be accepted. It sits alongside the contract, which covers the legal terms such as liability and confidentiality.

A statement of work template lists the sections a SOW needs, so you can go straight to the details of your project. Most SOWs fit in a few pages. If yours runs much longer, move background material to an appendix.

You write the SOW at the very start of a project, before the project charter and the detailed plan. For a deeper look at how it works in practice, read our guide to the statement of work.

What does a statement of work include?

A statement of work template covers eight parts: the project overview, scope, deliverables, timeline, tasks and owners, budget, acceptance criteria, and the change process.

Project overview and purpose

The project name, client, vendor, project manager, and dates. Add two or three lines on the problem you are solving and why it matters now.

Scope of work

What the project includes and what it leaves out. The scope of work section below explains what to put in it.

Deliverables

Each thing the client will receive, described clearly enough that both sides can tell when it is delivered. For example: "a 20-page brand guidelines PDF and source files."

Timeline and milestones

The start date, end date, and key milestones in between. A simple table with milestone, date, and owner works well.

Tasks and owners

The work broken into tasks and sub-tasks, with one named owner for each. Note which tasks depend on the client, like providing content or approving designs.

Budget and payment terms

The total cost, how it is split, and when payments are due. Say whether the price is fixed or based on time and materials, and how invoices are approved.

Acceptance criteria

How the client will review and approve each deliverable, who signs off, and how many days they have to respond. Say whether a deliverable counts as accepted if the client does not reply in that time.

Change process and sign-off

How either side asks for a change once work has started, and who approves it. Note how each change affects the timeline and budget. End with signature lines for both parties.

Scope of work vs statement of work: what goes in the scope of work section?

People often mix these up because both get shortened to "SOW". The statement of work is the full agreement between you and the client. The scope of work is one section inside it. It describes exactly what falls inside the project and what does not, also known as the project scope.

The scope of work section usually covers:

• Goals and assumptions: what the project should achieve and what you are taking for granted, like access to systems or timely feedback.
• Goods and services: what you will provide, as a short list.
• Work breakdown: the main phases and the tasks inside each one.
• Location and tools: where the work happens and any systems the team needs.
• Out of scope: tasks that are not included. Be specific. "Ongoing maintenance after launch" is clearer than "extra work".

If you only need to define scope for an internal project, our project scope template is a lighter option.

How a clear scope prevents scope creep

Scope creep happens when the work slowly grows past what both sides agreed on, through small extra requests and changes that add time and cost.

When a new request comes in, check it against the signed scope section. If it is already covered, do it. If it is not, raise a change request with the extra time and cost, and let the client decide.

A few habits help:

• Write the out of scope list before the in scope list, so the limits of the project are settled first.
• Use numbers where you can: rounds of revisions, number of pages, hours of support.
• Log every change request in the same doc, with the date and decision.

How to write a statement of work

Writing a statement of work takes five steps: a kickoff with the client, the scope, the deliverables, the timeline and budget, then review and signatures.

1. Meet with the client first

Hold a kickoff call before you write anything. Talk through goals, budget, deadlines, and who signs off. Take notes in the template so the first draft is already close to what the client expects.

2. Define the scope and the out of scope list

Write down what is included and what is not. Check each item with the people who will do the work, so you don't promise something the team can't deliver.

3. List deliverables and acceptance criteria

For each deliverable, add what "done" looks like, who approves it, and how many days they have to review it.

4. Build the timeline and budget

Add milestones with dates and owners, then match payments to milestones. Check resources and deadlines with your team before you commit to dates.

5. Review, then get signatures

Ask a teammate who was not on the kickoff call to read the draft and mark anything unclear. Fix those parts, send it to the client, and collect signatures before work starts.

Tip: write for the least technical reader. Finance, legal, and the client's team will all read it, so use plain language and define any terms.

What can a statement of work do for me?

A good SOW makes the rest of the project easier, for you and for the client.

• Shared expectations. Both sides agree in writing on what will be delivered, when, and for how much.
• Protection against scope creep. You have a clear reference when requests go beyond the agreement.
• A base for planning. The tasks, owners, and milestones feed straight into your project plan.
• Faster onboarding. New team members can read one doc to understand the project.
• Cleaner closure. Acceptance criteria tell you when the project is finished and the final invoice can go out.

Keep the SOW in the same place as the rest of your project docs, and update it when a change request is approved. Tools like self-maintaining documentation help flag pages that go out of date.

How can I get started with the free statement of work template?

Duplicate the free template into your Slite workspace and rename it for your project. Fill in the sections with your team, starting with the scope and the out of scope list. When the draft is ready, share it with the client for review and comments in the same doc. Once both sides sign, keep it next to your project plan so everyone works from the same version.