What is a scope of work, and who pays when it changes.

A scope of work is the document that describes exactly what an agency is delivering on a project: the work itself, what's excluded from it, when each piece arrives, and what has to be true before a piece counts as finished. It gets written as a planning document and it gets used as a payment document. The first time a client asks for something the scope never named, whatever that document says decides whether the next three weeks get billed or absorbed.

That second job is the one worth designing for. What follows is what belongs in a scope of work, worked through against a $19,700 project, along with the wording that turns a list of work into an answer to the question nobody asks until week six.

What is a scope of work?

A scope of work is a written description of the work a client is buying, specific enough that either side can check a later request against it. It names the deliverables, draws the boundary around them, sets the dates they arrive on and states the standard each one has to meet. In agency work it rarely stands alone. It usually sits inside a statement of work, or attaches to a contract as an appendix, describing the work itself while the surrounding paperwork handles payment terms, ownership and what happens if either side walks away.

The term gets used loosely enough that naming what a scope of work isn't does about as much work as the definition. An estimate prices work nobody has described closely enough to price properly, and a proposal argues for an approach while the client is still deciding, whereas a scope of work assumes the deciding is finished and the number is fixed. It also isn't the contract, though it almost always travels attached to one, and knowing how those two documents connect is what settles things when they appear to say different things.

One more distinction is worth getting right early, because these two terms get treated as synonyms constantly. A scope of work covers what gets built. A statement of work wraps that same description in the commercial terms, so it carries the fee schedule, the invoicing dates and the rules about whose approval counts. Plenty of small agencies write one document and use either name for it, which is fine as long as the sections that decide money are genuinely in there, and where the two documents actually diverge is written up separately.

What does a scope of work actually decide?

It decides who pays for the next request. The clearer expectations and the calmer planning that everyone attributes to a good scope are downstream of that single function, and it's the function that goes missing whenever the document gets described as a planning tool.

The mechanism behind that is plain enough. Some weeks after the work starts a client asks for something, somebody on your side opens the scope of work to see whether it's covered, and one of two things is true. Either the description is loose enough that the request can be read as included, in which case you build it for nothing and tell yourself it was small, or the description is specific enough that the request sits visibly outside it, in which case you price it, the client approves it, and the project total moves. It only turns adversarial when the document was too vague to answer the question and both people end up arguing from memory.

Money leaks through that gap continuously rather than dramatically, which is why it so rarely gets fixed. One absorbed request feels like goodwill, while the same request arriving on every project for a year is a line item you never billed, and what that pattern costs an agency is worth reading with your own numbers next to it.

A scope of work is written to plan the project and read to price an argument.

What should be included in a scope of work?

Seven sections cover it, and whether each one is countable matters far more than the order they appear in. You need the objective, one paragraph on what the client is trying to achieve, so that later judgment calls have something to be judged against. You need the deliverables named and counted rather than described, because six tracking screens is checkable and a tracking experience is not. You need the exclusions, which do the most work and get the least attention. You need the schedule, with dates attached to deliverables rather than to weeks. You need acceptance criteria, meaning the test each deliverable has to pass before it counts as done. You need the responsibilities on both sides, especially the client's, because timelines usually slip on content or access that never arrived from their end. And you need the change path, one paragraph stating what happens when somebody asks for work that isn't on the list.

Two of those get written badly almost everywhere. Deliverables get described instead of counted, and exclusions get written as a list of refusals instead of a priced menu. For the section by section version, with the vague line sitting next to the rewritten line that holds, how to write a scope of work covers each one in order, and a scope of work format filled in as a sample shows the finished shape on the page.

What does a scope of work look like on a real project?

Take Halden Freight Co., a regional shipping company whose customers currently call a phone line to ask where a container is. They want a portal those customers can sign into instead. The engagement is nine weeks at $19,700 fixed, and the deliverables section reads as four priced lines rather than as a paragraph about a portal.

Every number in there is doing a second job. The per screen rate exists so that a seventh screen already has a price before anybody asks for one, and the four lines together mean that when a request arrives there's a unit sitting ready to attach it to. A scope that says build a customer portal for $19,700 contains exactly the same commercial deal and answers none of the questions the project is about to raise. Halden's portal is a software build, and the same four lines carried through a larger one, with the acceptance and change wording a development engagement needs, are written out in our software development scope of work template.

What happens when the client asks for something the scope doesn't name?

You price it, the client approves it in writing, and the work starts after that rather than before it. On the Halden project the request lands in week six and it's a perfectly reasonable one: since customers are signing in anyway, can they see their invoices in here and pay them?

Read against a scope that promised a customer portal, that request is arguably included, and the argument is unwinnable because both readings are honest. Read against the four lines above, it's two screens the scope never listed plus a payment connection nobody priced, which comes to $2,900 for the screens at the stated rate and $1,200 for the payment work. That's $4,100, a little over a fifth of the original fee, and two weeks added to a nine week schedule. The difference between billing that and swallowing it isn't the client's goodwill on the day. It's one paragraph written seven weeks earlier.

Written that way, the exclusion stops being a refusal and becomes a price the client can say yes to. Somebody who reads that line in week one has been told the feature exists and what it costs, so the week six conversation is a purchase rather than a disappointment, which is why the line between in scope and out of scope is worth drawing while everyone is still relaxed about it.

The change path paragraph is the other half of the same mechanism, and it states that requests outside this scope get quoted in writing, that work begins after written approval, and that approval means a reply from a named person rather than a nod in a status call. Agencies running a standing change request form tend to get this part right, because the form makes the priced and approved sequence the default instead of something you have to remember while a client waits on the phone.

Does every project need a scope of work?

No, and writing a full one for every job is how agencies end up with a template nobody fills in properly. The threshold sits roughly here: one deliverable, under about $5,000, under two weeks, one person on the client side who can approve things. Below all four of those, a paragraph in the email confirming the job does the same work, provided it names the deliverable, the number of revision rounds included and what another round costs.

Above that line the document earns the hour it takes, and one condition overrides the money entirely: the moment more than one person on the client side has an opinion about the work, you need the scope written down, because the version in your head and the version in the marketing manager's head will not survive their director reading the invoice.

A scope of work is a payment document that reads like a plan

Write it with that in mind and the sections stop being a checklist to get through. The deliverables get counted because a count is the thing you bill against, the exclusions carry prices because a price is something a client can accept where a refusal is only something they can resent, and the acceptance criteria exist because otherwise finished becomes an opinion held by whoever is least satisfied.

None of that makes the document enforceable on its own, and enforceability isn't the job it's doing. What it does is strip out the ambiguity that turns a routine request into a negotiation, so the week six conversation on the Halden project is a $4,100 quote instead of a disagreement about what the word portal meant back in March. If you're starting from a blank page, the section by section version is the next thing to read, and a project scope printed in full shows what a finished one looks like from top to bottom.

Frequently asked questions