A project scope document template, filled in for agency work.

A project scope is the document that names exactly what you're delivering, what you aren't, and what the excluded work costs if the client decides they want it anyway. For agency client work it needs four things the downloadable templates almost always skip: deliverables specific enough to count, an out-of-scope section with a price against every line, a written rule for what happens when a request arrives in week five, and one named person whose approval counts. The whole document is printed further down, filled in for a $32,000 website build, so you can copy it, change the numbers and send it this afternoon.

The reason the free templates feel unsatisfying isn't that they're badly made. It's that nearly all of them are written for a project manager inside a company, where the person adding work is a colleague and the budget is a shared internal number. An agency is in a different position entirely. The person adding work is the person paying the invoice, and every unbilled hour comes directly out of your margin rather than a departmental line item. That changes what the document has to do, and it changes which sections carry the weight.

What belongs in the project scope, and what belongs in the contract?

The scope describes the work, and the contract describes the deal around it. That's the cleanest way to hold the two apart when you're deciding where something goes. Deliverables, exclusions, assumptions, the schedule and the acceptance rule all describe work, so they live in the scope. The fee, the payment schedule, ownership of what you produce, liability and confidentiality all describe the deal, so they live in the signed agreement with the scope attached underneath it.

On a small project nobody minds if the two are one file, and plenty of agencies run that way happily for years. The split starts earning its keep somewhere above roughly $25,000, because reissuing version 1.3 of the scope in week six shouldn't leave anyone feeling like the contract has been reopened, which is a conversation you don't want to have twice on the same project.

If a client has asked you for one document and clearly meant the other, we wrote up scope of work vs statement of work separately, because the two terms get used interchangeably by people who mean quite different things by them.

What's the difference between a scope document and a scope statement?

They're the same document under two names, and the difference that matters is who ends up reading it. Scope statement is the wording the project management handbooks use, so it turns up inside companies where one manager writes the document for colleagues who share a budget. Scope document, or scoping document, is what most agencies say when they mean the file that sits underneath a client contract. The structure doesn't change between the two, because both of them name the work, draw the boundary around it and say what finished looks like.

What changes between them is the money. An internal scope statement can leave the excluded work unpriced, since a colleague who asks for an extra page was never going to be invoiced for it anyway. An agency scope document that leaves its exclusions unpriced has thrown away its one piece of protection, because the person adding work is the same person paying the invoice. That's why section 3 of the template below carries a dollar figure against every excluded line, and it's why a scope statement you download from a project management site usually needs that whole section rebuilt before you send it to a client.

What does a filled-in scope document sample look like?

Here's the whole document, ready to copy into a file or the body of an email. It's written for a nine-week website build at $32,000, which is a common enough shape that most of it will transfer to your projects with only the numbers changed. Anything in square brackets is specific to the engagement and gets replaced. Everything else, including every dollar figure and every review window, is filled in as a working default rather than left as a blank for you to guess at.

Most of the total length sits in sections 3, 6 and 7 on purpose, because those are the sections a client reads carefully once and you reread every time something moves. The numbering isn't decoration either, since writing "that's 3.4" in a reply is faster and far less confrontational than restating an argument from scratch, and a client who can find 3.4 in ten seconds usually stops pushing on it.

How do you write a deliverable someone can count?

Replace every adjective with a number, then add a sentence saying what finished looks like. That single habit does more for a scope document than any other change you can make to it. Compare "a modern, easy-to-manage website" against "nine page templates, adapting to screens from 360px to 1440px, editable by your team without developer help". The first one is a mood dressed up as a specification. The second is something you can point at in week seven and count together, which is the only property that matters when two reasonable people remember the same conversation differently.

The "done when" line underneath each deliverable is the part almost nobody includes, and it's the part that ends the most arguments. Without it, finished is a matter of opinion, and the client's opinion is the one attached to your invoice. With it, finished is a condition that either holds or doesn't. Notice that the conditions in section 2 are all things a person could check in an afternoon: the prototype covers nine templates, the pages render correctly in four named browsers, the 24 pages exist on staging with their content in place. None of them require judgment about quality, which is deliberate, because judgment about quality is exactly what the revision rounds are for.

Stating the revision count next to each deliverable rather than once at the bottom of the page matters more than it looks like it should. Buried in a terms section it reads as boilerplate nobody remembers agreeing to, and sitting directly under the deliverable it applies to, it reads as part of the work itself.

Why does the out-of-scope list need prices next to it?

Because a bare exclusion sounds like a refusal, and a priced one sounds like a menu. That's the whole difference, and it shows up in the tone of the conversation six weeks later. "Additional page templates are not included" invites the client to argue about whether a careers page really counts as additional. "Additional page templates are $1,800 each and add four business days" invites them to decide whether they want one, which is a completely different question and one they're entitled to answer either way.

Pricing the exclusions also does something quieter that pays off across a year of projects. It moves the negotiation to before the project starts, when the client is comparing you against other agencies on value and is in a generous frame of mind, rather than to week six, when they're comparing your invoice against their budget and are not. A client who approved $1,800 per extra template in March has very little appetite for relitigating it in May, and most don't try.

The arithmetic on a project this size decides the year. On a $32,000 build at a 30% target margin, you're working with roughly $9,600 of profit. Three unpriced additions of the kind that turn up on almost every website project, each costing you around eighteen hours of a $150 blended rate, come to about $8,100. That leaves $1,500 on a nine-week engagement, which is the difference between a decent year and a busy one that somehow produced no money. We put actual numbers against a full year of this pattern in what scope creep costs an agency.

A bare exclusion reads as a refusal. A priced one reads as a menu.

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

You check section 3 first, because if the request is already priced there, the answer is a number rather than a negotiation. Take a real shape of request on this project. On day 31, midway through the design phase, the client emails asking for a careers page template that was never discussed, and separately wants another look at the case study detail design after they've already used both rounds included in 2.2.

Neither item is in section 2, so both are changes. But 3.1 prices an extra template at $1,800 with four business days attached, and 3.3 prices a further revision round at $150 an hour, and you estimate six hours for the case study pass. The reply writes itself: $1,800 plus $900 comes to $2,700, and the delivery dates in section 5 move four business days. That reply takes about four minutes to write, contains no bad news that hasn't already been agreed to, and can be sent by anyone on the team rather than only by whoever owns the client relationship.

For the requests section 3 doesn't anticipate, and there are always a few, you need a short written record of the new work, its price, its effect on the date and the approval, which is exactly what a change request form template gives you to copy rather than rebuild every time. Refusing to start before the written yes arrives matters more than the form does, and there's more on running that conversation without damaging the relationship in how to handle scope creep.

Who approves the project scope, and what does approval mean?

One named person with budget authority, identified in the header of the document rather than assumed. When a marketing coordinator waves through a $2,700 addition on a call and a director says six weeks later that nobody authorized it, both of them are usually telling the truth as they understand it, and you're the one holding the unpaid hours. Naming the approver at the top of the scope, and repeating in 6.3 that their written yes is what starts work, closes most of that gap.

The other half of approval is acceptance, which is section 7 and works in the opposite direction. Without a review window, a delivered design sits unanswered for three weeks while the schedule quietly rots and nobody is technically at fault. The five-business-day rule in 7.1 means silence eventually counts as acceptance, which sounds aggressive until you've watched a project lose a month to an approver on vacation. Pair it with 7.2, requiring an objection to name the deliverable and the specific condition it fails, and you've removed the most expensive kind of feedback there is, which is the vague kind that arrives late and asks you to try again.

Both are far easier to introduce at kickoff than to retrofit in week four, and we wrote out the two-minute script for doing that in how to raise change orders at kickoff. The written trail you end up with isn't court-proof and nobody should sell it that way, but it beats a Slack message, and an approval that holds up settles almost every dispute in one reply.

What to fix first if your current scope document is thin

Start with the exclusions, because that section takes an hour and changes the most. Go through your last three finished projects, write down every request that arrived after signature, and put a price and a lead time against each one. That list is your section 3, drawn from your own history rather than from a template someone else wrote, which means it's already tuned to the specific ways your clients ask for more. If you're starting from nothing rather than fixing something thin, writing a scope of work from scratch covers the whole document.

Do the "done when" lines second. They take longer because they force you to decide what finished means for each thing you sell, and most agencies discover in the process that they've never actually decided. That discomfort is the point, and the hour it costs you comes back on the first project where a deliverable gets accepted on a condition instead of a feeling.

Leave the change-control paragraph until last, not because it matters least, but because you can copy section 6 above almost word for word and it will work. The document only earns its keep if it's the thing you actually reach for when a request lands, so the version worth having is the one you'll open in week five rather than the one that looks most thorough in a proposal. A two-page scope you use beats a nine-page scope you wrote once and never opened again.

Frequently asked questions