Statement of work for agencies: the practical guide
Share
The short version
A statement of work is the document that defines what an agency will deliver, on what timeline, for what price, and what counts as done. It is the reference both sides point back to when a request feels like it might be extra. A vague statement of work is where most delivery disputes start, because there is no agreed line between what was promised and what was not. This guide covers what a statement of work must contain, how to write each section so it holds up under pressure, and how a clear one sets up clean delivery and makes change orders easy to raise when scope legitimately moves.
What a statement of work is and what it must contain
A statement of work, or SOW, is a document that defines the scope, deliverables, timeline, and commercial terms of a specific engagement. It is the operational agreement that sits underneath the contract and tells everyone what the project actually is. Where the contract governs the legal relationship, the SOW governs the work, and it is the artifact your delivery team and the client both read when they need to know what was agreed.
A complete statement of work contains a fixed set of parts. Each one exists to remove a specific ambiguity that would otherwise turn into an argument mid-project.
| SOW section | What it locks down | Risk if vague |
|---|---|---|
| Scope and objectives | What the project covers and what it is meant to achieve | Every new request feels in scope, because the boundary was never drawn |
| Deliverables | The concrete items the client receives | Disputes over what "done" includes and whether an item was promised |
| Acceptance criteria | How each deliverable is judged complete | Endless revision rounds with no agreed finish line |
| Timeline and milestones | When work happens and when it is reviewed | Slippage with no checkpoint to catch it, and blame over whose delay it was |
| Assumptions and exclusions | What the estimate depends on and what is not included | Absorbed work, because anything unstated defaults to included |
| Pricing and payment terms | The fee, the billing model, and when invoices are raised | Late payment, disputed invoices, and cash flow gaps |
| Change process | How out-of-scope work gets priced and approved | Scope creep, because there is no route to bill extra work |
The sections reinforce each other. Acceptance criteria are only enforceable if the deliverables are named precisely. Exclusions only protect you if the scope they carve away from is defined. Treat the statement of work as one connected document rather than a checklist of parts, because a gap in any one section is where a dispute finds its way in.
Scope, deliverables, and acceptance criteria
Write scope as a clear boundary that says both what is included and what is excluded. Scope defined only in the positive leaves everything unstated open to interpretation, and clients reasonably assume that anything reasonable falls inside the fee. An explicit exclusions list is the single highest-value part of a statement of work, because it turns "we assumed that was part of it" into a question you already answered.
Deliverables are the concrete items the client receives, named specifically enough that anyone can tell whether they exist. "A website" is not a deliverable. "Five responsive page templates, a component library, and a deployed staging environment" is. The more precisely you name each deliverable, the less room there is to argue later that something extra was implied by the brief.
Acceptance criteria define how a deliverable is judged complete, and they are what stop revision rounds running forever. For each deliverable, state the standard it has to meet and the process for signing it off. That might be a fixed number of revision rounds, a functional checklist, or a review against the agreed brief. Without acceptance criteria, "done" becomes whatever the client feels like on a given day, and the extra rounds come straight out of your margin. With them, you have an agreed finish line and a clear point at which further changes become a priced change order rather than free rework.
Timeline, milestones, and assumptions
State the timeline as milestones tied to client dependencies, not as a single end date. A lone deadline hides the fact that most delays are shared. When you break the project into milestones with review points, a slipped date has a visible cause, and it is clear whether the delay came from your side or from a client input that arrived late.
The part of the timeline section that protects you most is assumptions. Every estimate rests on things being true: that content arrives by a certain date, that one round of stakeholder review is enough, that a third-party system behaves as documented. Write those assumptions down. When an assumption breaks, and on most projects at least one does, you have a documented basis to reset the timeline or raise a change order rather than silently absorbing the delay. Unwritten assumptions default to your problem, because there is no record that the plan depended on them.
Tie milestones to the same record your team logs time against, so plan and reality stay in one place. When milestones live in the statement of work but progress lives in someone's head, the first sign of slippage is usually a missed deadline. When you track delivery against the planned milestones in your project workspace, you can see a milestone drifting while there is still time to act on it.
Pricing and payment terms
State the fee, the billing model, and the invoicing schedule explicitly, because payment disputes almost always trace back to a term that was assumed rather than written. The pricing section should say what the client pays, how that price is structured, and when each invoice is raised.
Name the billing model directly. A fixed fee, time and materials, a retainer, and a capped time-and-materials arrangement each carry different risk for both sides, and the client needs to know which one governs the engagement. If the model is fixed fee, the scope and exclusions sections are what protect that fee, so they have to be tight. If it is time and materials, the SOW should state the rates and any estimate or cap, so the client is not surprised by the running total.
Payment terms are the part clients skim and later dispute, so make them specific. State the invoicing cadence, whether you bill on milestones or on a schedule, the payment window, and what happens if an invoice runs late. A deposit or milestone-based billing protects your cash flow on longer projects and signals commitment from the client. The clearer these terms are in the statement of work, the less time you spend chasing clarification once invoices start going out.
How a clear SOW prevents scope disputes
A clear statement of work prevents disputes by giving both sides a single agreed reference for what was promised, so a disagreement becomes a lookup rather than an argument. Most delivery disputes are not really about the extra work itself. They are about whether the work was ever in scope, and that question only has a clean answer when the scope was written down precisely at the start.
This is where the statement of work and change control work together. The SOW draws the line; a change order handles what falls on the other side of it. When a request comes in, you check it against the scope and exclusions. If it is inside, you do it. If it is outside, you have a documented basis to raise a change order, and the conversation is factual because the boundary is already agreed. Without a clear SOW, every request becomes a negotiation about what the fee "should" have covered, which is exactly the ambiguity that lets scope creep absorb your margin one small favour at a time.
A tight statement of work does not make you rigid with clients. It makes the change conversation easy, because you are not arguing about the past. You are pointing at an agreement you both signed and deciding how to handle something genuinely new. Clients accept that far more readily than a vague sense that the bill is creeping upward for reasons no one wrote down.
SOW vs contract vs proposal
A proposal sells the work, a contract governs the legal relationship, and a statement of work defines the work itself. The three documents overlap in practice, which is why teams confuse them, but they do different jobs and mixing them up is where problems start.
A proposal is a sales document. Its purpose is to win the engagement, so it leads with outcomes, approach, and why the client should choose you. A proposal is written to persuade, which means it is usually optimistic about scope and light on exclusions. Signing a proposal and treating it as the scope agreement is a common way to inherit an argument later, because the persuasive framing was never meant to survive contact with delivery.
A contract, sometimes a master services agreement, governs the legal terms of the relationship: liability, intellectual property, confidentiality, termination, and dispute resolution. It is built to last across multiple projects and rarely changes. The contract does not usually contain project specifics, which is exactly why the statement of work exists.
A statement of work defines a single engagement in operational detail: scope, deliverables, acceptance criteria, timeline, and commercial terms. It is the document your delivery team works from and the one both sides return to when a question about scope comes up. On many agency engagements the SOW sits under a master services agreement, so the contract sets the legal frame once and each new project gets its own statement of work. Getting this separation right means the persuasive language stays in the proposal, the legal terms stay in the contract, and the operational agreement that actually runs the project stays clear and specific in the SOW.
Where Pike fits
A statement of work is only useful if the project runs against it. Pike keeps the scope, the plan, and the delivery in one place, so the agreement you wrote does not drift away from the work as it happens. You can hold each engagement as a project with its scope and milestones, track time and budget burn against that scope in real time, and see the moment a request starts pushing past what the SOW covers. When that happens, raising a change order is a small step from a system that already knows the original scope, rather than a scramble to reconstruct what was agreed.
Frequently asked questions
See your scope stay connected to delivery
If projects keep drifting from what the statement of work agreed, it is worth having the scope, the plan, and the time all logged against the same project.
Book a demo at cal.com/usepike/demo and we will show you how Pike keeps delivery tied to the scope you agreed.
Share
