How to Write a Statement of Work: What to Include and Common Mistakes

A statement of work (SOW) is the document that turns a handshake agreement into a project that actually gets done on time and on budget. It defines exactly what you’re delivering, when, for how much, and what “done” looks like. Skip it, and you’re asking for scope creep, late payments, and arguments over whether that extra revision was included.

This guide covers what to put in your SOW, how to write one without overcomplicating it, and the mistakes that trip up most business owners.

What to Include in a Statement of Work

Every SOW needs these ten sections. Industry-specific clauses (security, compliance, insurance) get added on top, but this is your baseline.

• Project overview: One paragraph in plain language. Who’s the client, who’s the vendor, what business problem does this solve. Example: “Acme Corp engages Bright Agency to redesign their customer onboarding flow, reducing time-to-first-value from 14 days to 5.”
• Scope of work: Every task and service included. Be specific. “Design 12 email templates” not “handle email design.”
• Out-of-scope items: This list is just as important. If you don’t say it’s excluded, someone will assume it’s included. “Social media content creation, paid ad management, and ongoing maintenance are out of scope.”
• Deliverables and acceptance criteria: For each deliverable, state format, quality standard, review process, and approval deadline. “Deliverable: Mobile-responsive landing page. Format: Figma file + HTML/CSS. Review: Client has 5 business days. Approval: Written sign-off from project sponsor.”
• Timeline and milestones: Include start date, end date, and key milestones. Use dates, not “upon approval.”
• Payment terms: Amount, schedule (fixed fee, hourly, milestone-based), invoicing process, and late payment penalties.
• Roles and responsibilities: Who does what. “Client provides brand assets within 3 days of kickoff. Vendor delivers first draft within 10 business days.”
• Location and environment: Where the work happens. Remote, on-site, specific software or tools required.
• Change management procedure: How scope changes get requested, approved, and priced. Without this, every client request becomes a negotiation.
• Sign-off and acceptance: Who has authority to approve, and what happens if deliverables are rejected.

How to Write a Statement of Work

Start before you open a document. Talk to every stakeholder—client, delivery leads, legal, finance. Run a quick scope workshop where you capture requirements and link them to specific deliverables. If you can’t list the deliverables after that meeting, you’re not ready to write.

Write the project overview first. Keep it to one paragraph, plain language. No marketing fluff. “Improve customer support response time from 24 hours to under 2 hours” is better than “drive operational excellence through transformative service delivery.”

Then define scope and out-of-scope items side by side. Use a table if it helps. For each in-scope item, ask: What format? Who reviews it? What quality standard? What’s the approval deadline? Write that down as your deliverable description.

Set the timeline backward from the final deadline. If the project ends June 30, work back to milestones for draft delivery, client review, revisions, and final approval. Add buffer for review cycles—clients rarely approve on day one.

Common Mistakes to Avoid

Leaving out the out-of-scope list. This is the number one cause of scope creep. Clients assume everything related is included unless you explicitly say it isn’t. “Ongoing maintenance, training, and data migration are out of scope” saves you from awkward conversations later.

Using vague language. “Regular updates” means nothing. “Weekly status report every Friday at 3 PM” means something. “High quality” is subjective. “Passes WCAG 2.1 AA compliance testing” is measurable.

Skipping the change management process. Projects change. That’s normal. What’s not normal is doing extra work without a formal change request and price adjustment. Include a simple process: client submits change request, you estimate impact on timeline and cost, both parties sign before work starts.

Forgetting acceptance criteria. Without clear criteria, “done” is whatever the client decides it is that day. Spell out exactly what passes and what doesn’t. “Three rounds of revisions included. Additional rounds billed at $150/hour.”

Treating the SOW like a one-time document. Update it when scope changes. If you add a deliverable, issue a revised SOW or a change order. The document is only useful if it reflects reality.

Statement of Work vs Related Documents

The SOW is often confused with three other documents. Here’s the difference:

• SOW vs scope of work: Scope of work is just the tasks and deliverables. The SOW is the full document—scope, timeline, payment, responsibilities, acceptance criteria.
• SOW vs contract: The contract is the overarching legal agreement (terms, liabilities, governing law). The SOW is an attachment that provides the detailed project specs.
• SOW vs project charter: The charter authorizes the project and names the project manager. The SOW defines the work itself. You need both.

If you have a Master Service Agreement (MSA) with a client, each project gets its own SOW under that MSA. The MSA says how you work together. The SOW says what you’re building right now.

Write your SOW before you start work. Update it when things change. And never, ever assume “we’ll figure it out as we go” is a substitute.