Statement of work
A statement of work template covering scope, deliverables, what's excluded, the timeline, payment schedule, and how change requests are handled.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your document
How to use it well
- →The out-of-scope list is the part that actually prevents disputes - write down the requests you expect to get asked for, not just a generic "anything not listed above."
- →Tie each payment to a deliverable that has a visible, checkable finish line, not a calendar date - "on catalog migration complete" survives a slipping schedule better than "by week 3."
- →A change-request clause only works if both sides sign the addendum before the extra work starts; retroactively invoking it after scope has already crept is a negotiation, not a policy.
Part by part
- ## Out of scope
- The section that prevents most disputes. Scope creep enters through work that was never explicitly excluded, not through work that was.
- ## Deliverables
- Separate from scope, because scope describes the work and deliverables describe what is handed over. Conflating them is how a project ends with nothing to sign off.
- ## Payment schedule
- Tied to deliverables rather than to time, where possible. A schedule keyed only to dates pays for elapsed time rather than for progress.
- ## Change requests
- The mechanism agreed in advance. Without a stated process, every change becomes a negotiation conducted under time pressure mid-project.
Common mistakes
Leaving out the out-of-scope section.Everything not written down is arguable, and reasonable additions accumulate. Naming exclusions turns each one into a change request rather than a favour.
Deliverables described as activities.Provide consulting support cannot be signed off, so the engagement has no end. A deliverable is a thing that is handed over and either exists or does not.
No change process, on the assumption it will be handled reasonably.It will be handled under pressure with money at stake, which is the worst moment to invent a process. Agreeing it while everyone is happy costs one paragraph.
Questions
How specific should out-of-scope be?
Specific enough to name the things a client would plausibly assume are included — content migration, training, ongoing support, third-party licences. Generic exclusions protect nobody.
Should payment be tied to milestones?
Usually yes, since it aligns both sides on progress rather than on elapsed time. Keep at least one payment after final delivery, or the last stretch has no leverage behind it.
Is this a contract?
It is usually an exhibit to one, not a substitute for it. A statement of work defines the work; the master agreement covers liability, IP and termination — and you want both.
What if the client wants to skip it?
Treat that as information. The document exists to protect both sides, and reluctance to define scope usually signals an expectation of flexibility you have not agreed to fund.