1. Deliverables & specifications — exactly what you’re producing
The deliverables section is the heart of the SOW: it defines what you are actually on the hook to produce. Vague deliverables are where scope creep starts — "a website," "a marketing plan," "the designs" can each mean wildly different amounts of work. The tighter the specification — number of pages, rounds of revision, formats, quantities — the harder it is for expectations to quietly expand after you have agreed a price. If it is not written down as a deliverable, it should not be assumed as one by either side.
Watch for: Deliverables described in a sentence or two with no detail, open-ended phrases like "and related materials," unlimited or unspecified revision rounds, and anything that leaves the exact quantity or format of the work undefined.
Ask for: Deliverables listed specifically — with quantities, formats, and a defined number of revision rounds — plus an explicit note that anything not listed is out of scope and handled as a change.
2. Acceptance criteria & sign-off — what "done" means
Acceptance is how work gets formally approved and payment gets unlocked, so how it is defined matters a lot. Weak acceptance terms let a client withhold sign-off on subjective grounds — "it’s just not what I pictured" — and keep you revising indefinitely. Strong ones define objective criteria for what "done" looks like, give the client a set window to review, and treat the work as accepted if they do not respond or raise specific, listed issues within that window. Without this, "complete" becomes whatever the client decides on the day, and final payment drifts out of reach.
Watch for: Acceptance based on the client’s "satisfaction" or "sole discretion," no review deadline, no deemed-acceptance if the client goes silent, and rejection rights with no requirement to specify what is actually wrong.
Ask for: Objective acceptance criteria, a defined review period, deemed acceptance if the client does not respond in time, and a requirement that any rejection identify specific, fixable issues tied to the agreed spec.
3. Change orders & out-of-scope requests
Almost every project grows. The question is whether that growth is paid or absorbed. A change-order process is the mechanism: when the client asks for something beyond the agreed deliverables, it triggers a written change order covering the added scope, cost, and timeline before you do the work. Without one, "just one more thing" requests pile up and you end up doing a materially bigger project for the original price. A clear change process is what lets you say yes to extra work without giving it away.
Watch for: No change-order process at all, language obligating you to accommodate "reasonable" additional requests at no cost, and change terms that let the client add scope without a corresponding adjustment to fee or deadline.
Ask for: A written change-order process where any out-of-scope request is documented and agreed — with its own price and timeline impact — before the work begins, so added scope always comes with added terms.
4. Milestones, timeline & payment schedule
The SOW is usually where the actual dates and payment triggers live, even when the master agreement is silent on them. You want the timeline and the payment schedule to line up: payments tied to milestones you control, not to events that depend on the client or on distant final delivery. Watch for a schedule where most of the fee is back-loaded to the very end, which concentrates your risk, and for client dependencies that can push your dates without extending the deadline you are held to.
Watch for: Payment weighted heavily toward final delivery, milestones defined by client-side events you cannot control, deadlines that do not move when the client is late, and penalties for delays that are not your fault.
Ask for: A payment schedule with a deposit and milestone payments across the project, milestones tied to your deliverables rather than client actions, and timeline relief when client delays or missing inputs hold you up.
5. IP, dependencies & assumptions
The last cluster is easy to skim and often the most consequential. Intellectual property terms decide who owns the work and when — commonly on full payment rather than on delivery — and whether you keep any rights to your tools or reusable components. Dependencies and assumptions spell out what the client must provide (content, access, approvals, source files) and by when, and what happens if they are late. Stating these plainly protects you: if a project stalls because the client never sent what they promised, the assumptions section is what shows the delay was not yours.
Watch for: IP assigning on delivery rather than on payment, no carve-out for your pre-existing tools or reusable components, and no list of client dependencies — so a client’s own delays can be blamed on you.
Ask for: IP transferring on full payment with a carve-out for your reusable tools, plus a clear list of client dependencies and assumptions with dates — and language that shifts the timeline if the client misses them.
Before you sign that SOW...
Upload it and Initialed flags the parts that cause disputes — vague deliverables, subjective acceptance, a missing change-order process, back-loaded payments — in about two minutes. Your first credit is free.
Review your SOW freeFrequently asked
What’s the difference between an SOW and an MSA?
A Master Services Agreement (MSA) sets the overarching legal terms of the relationship — liability, IP, confidentiality, dispute resolution — that stay constant across projects. A Statement of Work (SOW) sits under it and covers the specifics of one project: deliverables, timeline, acceptance, and price. The MSA is the framework; the SOW is where the actual project — and most of the day-to-day risk of scope and payment — is defined.
What makes a good SOW?
A good SOW is specific where it counts: clearly defined deliverables, objective acceptance criteria, a change-order process for out-of-scope requests, a payment schedule tied to milestones you control, and a plain list of what the client must provide and by when. The goal is to leave as little as possible to "we’ll figure it out later," because that is where scope creep and payment disputes tend to begin.
Who should write the SOW?
Either side can draft it, and whoever does tends to frame it in their own favor — so the more important point is that you read and shape it regardless of who writes it. If the client provides the SOW, treat it as a starting draft to negotiate, not a fixed document. If you write it, you get to define scope and acceptance on clear terms from the start, which is often the stronger position.
Keep reading
All guides →Repairs, auto-renewal, uncapped rent, personal guaranties, and early-termination traps — what to watch for before you sign a lease.
The five clauses that decide whether a freelancer gets paid — scope, payment, IP, termination, and liability.
Comp and clawbacks, equity and vesting, IP assignment, non-competes, and arbitration — what to check before you accept a job offer.
Duration, geography, scope, and enforceability — how to read a non-compete before you sign (and why it varies so much by state).
Property, support, custody, and retirement — the terms in a divorce settlement that most often come back to bite.
The clauses that quietly decide what happens to a home, a business, or a career years from now — in plain English.
This guide is general information, not legal advice, and Initialed AI is not a law firm. How a Statement of Work is interpreted and enforced varies by jurisdiction and by the master agreement it sits under. For a high-value project, consult a qualified attorney before you sign.