A scope of work has two jobs, and most only do the first: win the signature. The second job starts a week later, when the requests arrive and someone has to answer "is this included?" — quickly, repeatedly, without a lawyer. Write for the second job and the first takes care of itself, because specific documents close deals faster than vague ones.
Photo: chimpwithcan, CC BY 2.0
Structure it as items, not prose
A referee-able SOW is a list of scope items, each with:
- A deliverable name a client would use ("homepage redesign", not "frontend phase 1")
- Acceptance criteria — 2–5 bullets that make "done" checkable
- What's near it but not in it — the explicit out-of-scope line
That last one does the heavy lifting. "Mobile-responsive website" silently implies a mobile app to some clients. One line — "native mobile apps are not included" — saves a five-figure argument.
Add the three clauses everyone forgets
- Revision rounds, counted. "Includes two rounds of revisions per deliverable."
- Assumption inventory. "Assumes client provides copy and brand assets by kickoff."
- The change path. Where out-of-scope requests go: a change process the client will actually follow, not a bureaucratic dead end.
Write it so software can read it
Here's the 2026 twist: a well-structured SOW isn't just for humans anymore. Items with acceptance criteria can be parsed, indexed and used to check every incoming request automatically — which means the document finally gets enforced at the moment it matters: when the ask lands in chat, not at the retro.
A vague SOW can't protect you, no matter who reads it. A structured one protects you even when nobody has time to.
← All posts