Statement of work template

A good SOW is the difference between a clean engagement and a scope argument at invoice time. The writing is the easy part — the hard part is getting client sign-off before work starts. Draft it with your agent, share the Drafty link, and the client's comments land on the exact clause they're questioning, not buried in an email thread.

The thing most people get wrong

The out-of-scope list matters more than the in-scope list. Most freelancers and PMs write detailed deliverables, then leave "out of scope" blank or vague. That's where scope creep enters — through the silence. Every SOW should name at least three things you won't do. "Design does not include copywriting. Development does not include third-party integrations. Launch support does not include post-launch bug fixes." The client who was about to ask for those things reads the list and stops.

Generate it with your agent

Paste this into Claude, Cursor, or any agent:

See it on a real one

What goes in a statement of work

Seven sections. If the SOW can't answer "what exactly gets delivered and what doesn't," it's not ready to sign.

1. Project overview — the problem and the agreed outcome, in two sentences. This is the anchor; if something's ambiguous later, you come back here.
2. Scope of work — the specific tasks and deliverables. Concrete nouns only: "five landing page designs at 1440px and 375px" beats "landing page designs." The more specific the better — vague deliverables create negotiating room you don't want.
3. Out of scope — the explicit exclusions. Name the things a reasonable client might assume are included. This is the single highest-value sentence you'll write.
4. Timeline — milestone dates, not a day-by-day schedule. Kickoff, first delivery, review round, final delivery, sign-off. Flag which milestones have client dependencies (their approvals, their assets, their feedback).
5. Payment terms — the amount, the schedule, and what triggers each payment. Milestone-tied payments beat date-tied payments: you don't get paid for a review round until the review round is done.
6. Acceptance criteria — how both parties know a deliverable is complete. "Design is accepted when the client has reviewed one revision round and confirmed in writing." Without this, "done" is permanently negotiable.
7. Change order process — what happens when scope changes. One line: "Any work outside this SOW requires a written change order agreed by both parties before work begins."

SOW vs. proposal vs. contract

The three docs that get confused, in order:

• Proposal — persuasion before commitment. You're still making the case for your approach and price. Use it before the client has said yes.
• Statement of work — the agreed plan, after the yes. Defines exactly what's happening. This is the doc you're generating here.
• Contract / MSA — the legal framework: IP ownership, liability, termination, dispute resolution. Often a separate document that references the SOW, or the SOW functions as the contract for simpler engagements.

For most freelance and consultant engagements, the SOW does the job of all three. Just make sure it includes enough legal language (IP, confidentiality, termination) if there's no separate contract.

When a client asks to revise the SOW mid-project

They're asking for a change order, even if they don't call it that. The SOW's change order clause is what makes this a conversation rather than a confrontation. Acknowledge the request, confirm it's outside the original scope (citing the SOW by section), draft a change order with the additional time and cost, and get written sign-off before you start. The SOW is the evidence; the change order is the amendment.

FAQ

What's the difference between a statement of work and a scope of work? The scope of work is one section inside the statement of work — it describes the specific tasks. The SOW is the full document: it wraps the scope with timeline, payment terms, acceptance criteria, and the change order process. In practice, many people use the terms interchangeably for smaller engagements, but the distinction matters when there's a dispute.

Does a statement of work replace a contract? For simple freelance engagements, yes — if the SOW includes IP ownership, confidentiality, termination terms, and governing law. For larger projects, the SOW typically sits under a Master Services Agreement (MSA) that covers the legal framework once, while each SOW defines a specific project. When in doubt, check with a lawyer, not your template.

How specific do the deliverables need to be? As specific as a disagreement would require. If you can imagine a client reading the deliverable description and reasonably expecting something different from what you'd deliver, it's not specific enough. Name the file formats, the screen sizes, the number of revisions, the definition of done.

What should go in the out-of-scope section? Anything a client might reasonably assume is included but isn't. Common ones: copywriting, photography, third-party licenses, integrations not named in the scope, post-launch support, rounds of revision beyond the named limit, work for related products or subsidiaries. If you're a designer, say development is out of scope. If you're a developer, say design is out of scope. State it even if it feels obvious.

How do I handle a client who ignores the SOW and keeps adding work? Point to the SOW in writing, not in a call. "Per section 3 of our SOW, X is out of scope. Happy to add it — I'll send a change order with the revised cost and timeline." Having the SOW as a shared link your client can re-read at any point makes this easier than a PDF buried in their inbox.

Can I use the same SOW template for every project? The structure, yes. The content, no. Every SOW needs project-specific deliverables, dates, and payment amounts — and especially a project-specific out-of-scope list. A generic out-of-scope list is almost as useless as no list at all. The agent prompt above generates a fresh SOW for each engagement; the template is just the starting shape.