Is a statement of work the same as a contract?

Not quite. The contract covers the legal relationship — liability, intellectual property, termination, payment terms. The SoW covers this specific piece of work. Small engagements often merge them into one document, which is fine, but the distinction matters once a client relationship spans several projects under one master agreement.

Is it worth writing one for a small job?

For anything beyond a few hours, yes — and it need not be long. A short email listing deliverables, exclusions, price and what you need from the client, sent and acknowledged before starting, is a statement of work in every way that matters. The formality is irrelevant; the written, agreed record is the point.

Statement of work (SoW) — what to put in one

Statement of Work (SoW)

Also: SoW, scope document, work order, project agreement

A statement of work is the document that fixes what will be delivered, by when, for how much, and — most usefully — what is explicitly not included, converting a shared understanding into something that can be checked.

The exclusions do the work

Most statements of work describe deliverables well and exclusions barely at all, which is precisely backwards. Both parties already broadly agree on what is being built; disputes come from the grey area nobody wrote down. An explicit "not included: content writing, photography, ongoing hosting, more than two revision rounds" prevents more trouble than another paragraph of deliverable description ever will.

A workable SoW answers five things: deliverables (what exists at the end), acceptance (how we know it is done), timeline with dependencies on the client, price and payment schedule, and exclusions. The acceptance criteria matter more than their dullness suggests — "done" without a definition is where scope creep enters, because there is no agreed point at which work stops.

Client dependencies are deadlines too

Name what you need from the client and when: copy, logins, sign-off windows. Projects slip on missing content at least as often as on the supplier's work, and an SoW that fixes only your obligations quietly makes you accountable for their delays. Stating the dependency is not defensive — it lets both sides plan.

Key takeaways

→The exclusions section prevents more disputes than the deliverables section, and is usually the one that gets skipped.
→Acceptance criteria define when work stops. Without them, "done" is negotiable indefinitely.

FAQ

Is a statement of work the same as a contract?: Not quite. The contract covers the legal relationship — liability, intellectual property, termination, payment terms. The SoW covers this specific piece of work. Small engagements often merge them into one document, which is fine, but the distinction matters once a client relationship spans several projects under one master agreement.
Is it worth writing one for a small job?: For anything beyond a few hours, yes — and it need not be long. A short email listing deliverables, exclusions, price and what you need from the client, sent and acknowledged before starting, is a statement of work in every way that matters. The formality is irrelevant; the written, agreed record is the point.