SOW / Proposal

How to Write a Statement of Work That Protects Both Sides

A statement of work is the single most important document in a consulting engagement. It defines what you'll deliver, when, and for how much — and just as importantly, what you won't deliver. A vague SOW leads to scope creep, late payments, and damaged relationships. A tight one creates clarity and trust.

Start With the Problem, Not the Solution

The most common mistake in SOW writing is jumping straight to deliverables. Before listing what you'll build, articulate why. What business problem does this solve? What does success look like? When both sides agree on the problem statement, the rest of the SOW writes itself — and it gives you something to point to when scope conversations get fuzzy.

Be Specific About Scope Boundaries

"Redesign the website" means different things to different people. Does it include content migration? SEO? Analytics setup? The scope section should explicitly state what's included and what's excluded. Use the "in scope / out of scope" format. It feels redundant, but it prevents the most common source of consulting disputes.

Deliverables Should Be Nouns, Not Verbs

"Conduct user research" is an activity. "User research report with findings and recommendations" is a deliverable. The difference matters because deliverables are what you hand over and what the client signs off on. If you can't put it in a folder and send it, it's not a deliverable — it's a task.

Timeline Needs Milestones and Dependencies

A single end date isn't a timeline. Break the project into phases with clear milestones. More importantly, flag dependencies — things that must happen before you can proceed. "Wireframes due March 15, contingent on client providing content brief by March 1." This protects you when delays happen on the client side.

Assumptions Are Your Safety Net

Every SOW should have an assumptions section. This is where you document the conditions under which your timeline and budget are valid. "Client provides feedback within 5 business days." "Existing API documentation is accurate." When assumptions break, you have a documented basis for timeline or budget adjustments.

Struq Makes This Instant

Instead of starting from a blank Google Doc every time, paste your call notes or project brief into Struq. The SOW template extracts the structured fields — scope, deliverables, timeline, budget, assumptions, and constraints — from your raw notes. Export as markdown or pipe it to your document tool. A 90-minute formatting exercise becomes a 30-second paste.