Reading a Statement of Work: what to actually check before signing

Most clients read a Statement of Work primarily for the total price and the delivery date, which are the two things that matter least once a project is actually underway and something inevitably needs clarifying. The clauses that actually protect a client through a real engagement are usually further down the document, less exciting, and skipped in the rush to get started.

"Includes revisions" with no further detail is a common source of later disputes. A real SOW should specify how many rounds of revision are included at each major stage, and clarify whether a revision round means "a single consolidated batch of feedback" or "unlimited back-and-forth until approved," since these are very different commitments with very different cost implications for the agency, and the vague version tends to get interpreted differently by each side once a disagreement actually happens.

A good SOW defines, in advance, what counts as new scope requiring a change order versus what's covered under the original agreement, ideally with specific examples relevant to the project type. Without this definition, every scope disagreement becomes a negotiation from scratch, which is slower and more adversarial than resolving it against a standard both sides already agreed to before the disagreement happened.

Confirm explicitly when code, designs, and content ownership transfers to the client, ideally on final payment rather than on project completion, which can leave ambiguous gaps if a dispute arises over final delivery. Also check whether any third-party licensed assets, fonts, stock photography, premium plugins, transfer with proper licensing or need to be separately licensed by the client going forward.

A kill clause, specifying what's owed and what's delivered if the project is paused or cancelled partway through, protects both sides. Without one, an early termination becomes an unstructured negotiation during what's often already a tense moment, exactly when neither side wants to be negotiating contract terms from scratch.

If this project hits a serious disagreement in month two, does this document actually tell us how to resolve it, or does it leave us negotiating from zero? If the honest answer is the latter, it's worth asking the agency to add specificity before signing, not after a disagreement has already made the conversation harder than it needed to be.

A payment schedule tied to specific, checkable milestones, a signed-off design phase, a completed development phase, protects both sides far better than a schedule tied purely to calendar dates, which can leave a client paying for a milestone that isn't actually done or an agency stalled while a client's slow feedback delays a deliverable through no fault of the agency's. We check that each payment milestone in an SOW maps to a concrete, mutually understood deliverable, not just a date on a calendar that may or may not still make sense once the project is actually underway.

Also worth checking: what happens to payments already made if the project is cancelled partway through, and whether any milestone payment is explicitly non-refundable. This is closely related to the kill clause discussed above, but it's specific enough, and disputed often enough in practice, that we treat it as its own separate line item to verify rather than assuming it's covered by the general cancellation language elsewhere in the document.

Agencies sometimes pitch with senior staff on the sales call and then staff the actual project with a more junior team, which isn't inherently a problem but should be disclosed rather than discovered midway through delivery. A well-written SOW names the specific people or roles assigned to the project, or at minimum commits to a specific seniority level for key roles, so a client isn't surprised later by who's actually doing the work they signed up for.

A well-written SOW lists what the agency is assuming will be true or provided by the client, timely feedback within a specific number of business days, access to specific accounts or systems, existing brand assets, since a delay on any of these on the client's side has direct downstream effects on the timeline that shouldn't be silently absorbed by the agency without discussion. We check this section specifically because it's the part most likely to be thin or missing entirely, and its absence is exactly what turns a client-caused delay into an argument about whose fault a missed deadline actually was.

A specific, named list of dependencies also protects the client: it makes clear exactly what they need to provide and by when, rather than discovering partway through that a delay on their end has quietly pushed back a launch date they weren't warned was at risk. We recommend clients ask directly for this section if it's missing, since a reputable agency should be able to produce it without hesitation, and reluctance to provide one is itself a useful signal worth noticing before signing anything, well before the first real disagreement puts the document to an actual test. This section, more than any other, is where a thorough SOW pays for itself, since it converts a whole category of future finger-pointing into a straightforward reference check against terms both sides already agreed to, rather than a fresh negotiation conducted under the added strain of a deadline that's already at risk. It's a short section to add and a genuinely painful one to be missing.

None of this is about expecting an engagement to go badly. Most don't. It's that a well-written SOW is cheap insurance against the specific minority of projects that do hit a real disagreement, and the document is far easier to negotiate calmly before either side has an emotional stake in a specific dispute than after. Read it that way, as a tool you hope never to need rather than a formality to skim past, and it's worth the extra half hour before signing.