Statement of Work Template

A statement of work (SOW) is a project-specific document that defines what work will be done, how it will be done, when it will be delivered, and what each party is responsible for. It usually sits underneath a master services agreement or consulting contract, which sets the legal terms, while the SOW itself focuses on the project details — scope, deliverables, milestones, acceptance criteria, and pricing. Both client and provider sign the SOW so there is one shared definition of the project.

A solid SOW template covers eight core sections: a project overview that explains the goal in plain language, a scope of work that defines what is and is not included, deliverables that list every output the provider will produce, milestones and timelines that break the project into phases with target dates, acceptance criteria that explain how each deliverable will be approved, payment terms that link payment to milestones or invoices, a change-control process for when scope shifts, and signatures from both parties. Add IP ownership, confidentiality, and governing-law clauses if they are not already covered in the master agreement.

A contract is the master legal agreement between two parties — it covers things like governing law, liability, IP ownership, and dispute resolution. A statement of work sits under that contract and defines a single piece of project work. The contract is signed once, often at the start of a relationship; the SOW is signed for each new engagement. Together they form the full agreement: the contract handles the legal framework, the SOW handles the project specifics.

Write the scope as a numbered or bulleted list of specific outcomes, not activities. "Deliver a five-page brand identity guide including logo, colour palette, typography, and usage rules" is clearer than "design a brand identity." Then add an explicit out-of-scope list — anything you do not want to be on the hook for, like additional rounds of revisions, extra page counts, or related work the client may assume is included. The out-of-scope list is what protects you from scope creep later.

Yes — the structure of an SOW is the same whether you are scoping a software build, a consulting engagement, a marketing campaign, or a freelance design project. The deliverables, milestones, and acceptance criteria change with each project, but the framework does not. Save one SOW template, then duplicate and adjust for each engagement. With Portant, you can take this further: connect the template to a Google Sheet of project data and have a custom SOW generated automatically for every new row.

Include a change-control section in the SOW that explains the process: changes must be requested in writing, the provider responds with a cost and timeline impact, and both parties sign a written change order before work begins on the change. This keeps small requests from quietly expanding the scope and gives you a clean paper trail if disputes come up later. Reference the change-control process from the start of the project so clients know what to expect.

Yes. Both client and provider should sign the SOW so there is a clear record that both sides have agreed to the same scope, deliverables, dates, and price. Without signatures, an SOW is just a draft proposal and is hard to enforce if the project goes wrong. Use eSignatures via Portant to send the SOW directly from the document — the signed copy is saved automatically and you do not have to chase paperwork.