Statement of work: the document that decides what you are actually delivering

A statement of work — usually shortened to SOW — describes what will be delivered, by when, for how much, and on what terms. It sits under a master agreement, which covers the legal relationship, and it is the document people actually argue about later: not the contract clauses, but whether a particular thing was included.

Most disputes between a supplier and a client are not about bad work. They are about two reasonable readings of a vague sentence, discovered at delivery. Everything useful in a SOW is aimed at removing those sentences before anyone has committed.

What a statement of work must contain

• The parties, dates, and which agreement governs it, so nobody has to reconstruct the relationship later.
• Background and objective in a short paragraph — what the client is trying to achieve, in their words.
• Scope: what is included, described specifically enough that a stranger could tell whether something falls inside it.
• Out of scope: what is explicitly excluded. This section prevents more disputes than every other one combined.
• Deliverables, listed individually, each with acceptance criteria — how the client will decide it is done.
• Assumptions the price depends on: data provided, access granted, decisions made within a stated time.
• Client responsibilities, with dates. Most delays are on the client side, and unnamed obligations cannot be pointed to.
• Timeline and milestones, and what happens if a dependency slips.
• Price, payment schedule and what triggers each invoice, plus how expenses are handled.
• How changes are handled — the change request route — because there will be changes.
• Sign-off: who accepts, in what timeframe, and what happens if they do not respond.

Write the out-of-scope section as carefully as the scope. Listing what you are not doing feels negative in a sales conversation and is the single most protective thing in the document: "content migration is not included", "one round of revisions, further rounds by change request", "training for up to five users". Every experienced supplier has learned this the expensive way.

Writing one that holds up

1. Start from the objective, not the task list. If you cannot state what the client is trying to achieve, the scope will be wrong regardless of detail.
2. Describe deliverables as nouns with acceptance criteria, not as activities. "A migrated database passing the agreed record-count check" is testable; "migration work" is not.
3. Add the exclusions as you write each scope item — the moment you describe something, the adjacent thing you are not doing becomes obvious.
4. State every assumption the estimate rests on, including the ones that feel obvious.
5. Give client responsibilities dates, and say what happens to the timeline when they slip.
6. Tie payments to milestones that are objectively verifiable rather than to elapsed time.
7. Include the change process with a named route and a note that changes may affect price and timeline.
8. Have someone who was not in the sales conversation read it and mark every sentence they could interpret two ways.
9. Get it signed before work starts — not because of the legal weight, but because signing forces the client to read it.

Acceptance is where money gets stuck

The clause people forget is what happens when a client does not respond. Work is delivered, review is promised, weeks pass, and the milestone payment is unpayable because nothing was formally accepted. The fix is a deemed-acceptance clause: if no written objection arrives within a stated number of working days, the deliverable is accepted. It is unremarkable in most industries, and having it turns an awkward chase into a reference to a paragraph both sides agreed to.

In Ettex, the SOW itself lives in Ettex Docs — a template so every engagement starts from the same structure, threaded comments with @mentions while the scope is negotiated internally, and version history so you can see exactly which version was signed when the argument arrives. Signature goes through Ettex Signature with an audit trail, deliverables and milestones become cards in Ettex Board with owners and due dates, the payment schedule turns into invoices in Ettex Invoices with the milestone in the terms field, and change requests come in through Ettex Forms.

The boundary, plainly: this is not legal advice and Ettex is not a contract system. There is no clause library, no contract lifecycle management, no obligation tracking, no renewal alerts and no legal review. A SOW sits under a master agreement whose terms — liability, IP, termination — should be drafted or reviewed by a lawyer in your jurisdiction. What Ettex gives you is the document, its history, and a signature with an audit trail.

How statements of work fail

• No out-of-scope section, leaving every adjacent request arguable.
• Deliverables written as activities, so "done" is a matter of opinion.
• No acceptance criteria, which is the same problem stated differently.
• Assumptions unstated, so a missing input becomes your delay rather than theirs.
• Client responsibilities without dates.
• Payments tied to dates instead of milestones, which pays for elapsed time rather than progress.
• No change process, so every change becomes a negotiation about whether it is a change.
• No deemed-acceptance clause, leaving milestone payments hostage to silence.
• Signed after work started, which means nobody read it.

A statement of work earns its keep in the exclusions, the acceptance criteria and the change route. Describe deliverables as testable nouns, date the client's obligations, and get it signed before anyone starts.