In scope vs out of scope, and who decides the line.

In scope is the work your scope document names and prices, and out of scope is everything else, including the work that would obviously improve the project and the work your client quietly assumed was coming. That distinction only earns its keep if both lists exist in writing before the first invoice goes out, because a request sitting on neither list gets settled by whoever sounds more certain in the moment, and on a fixed-price project that person is rarely the agency.

Most explanations stop at the two definitions and then advise you to set clear boundaries, which is something you can agree with completely and still not act on. What decides real money is the wording on both lists, the test for the requests that sit between them, and the rule your document names for settling those, all written out below against a $21,800 e-commerce replatform and downloadable as Word or PDF.

What does out of scope actually mean on a paid project?

Out of scope means the work isn't covered by the fee both sides already agreed, and it means nothing more dramatic than that. It isn't a verdict on whether the request is reasonable, and treating it as one is where most of these conversations start going badly.

A client asking for something out of scope has usually had a decent idea, and the second payment provider they want probably would convert better than the one you configured. That doesn't change the fact that the $21,800 was assembled from a list which didn't contain it, so the work needs a price and a written yes before anybody opens a file, or it comes straight out of your margin.

The framing matters because it's the sentence you'll say out loud, and "that's out of scope" lands as a refusal that invites an argument about fairness, while the same information with a price and a date attached lands as an offer. The whole message is written out further down. Agencies that handle scope creep without losing the client have made that second phrasing a reflex rather than a decision they take request by request.

Why does the line move even when both lists are written down?

Because scope documents usually describe the work at a level of detail that leaves the edges open to interpretation, and every real disagreement lives at the edges. Nobody argues about whether building the checkout page was included. They argue about whether the checkout page was supposed to include express-pay buttons.

A single line like "product page template" reads as one item to the agency that priced it and as a whole family of behaviors to the client who approved it, who pictures the image gallery zooming, the size selector remembering what they chose last time, and the stock counter updating without a page reload. None of that was named or priced or excluded, which leaves the request in the space where the loudest reading wins.

What fixes it is countable detail in the lines you already have, so "product page template" becomes "product page template, with a four-image gallery, one variant selector and a stock indicator", and the request for a size guide that opens in a panel is visibly a fifth thing rather than an implied sixth. The same discipline that makes a scope of work clients can't misread keeps the two lists from blurring into each other in month two.

What do the two lists look like on a real project?

They sit next to each other as two numbered sections, and the out-of-scope list carries prices in exactly the way the in-scope list does. Here's a ten-week storefront replatform for a hardware retailer, with both sections written out as they'd appear in the document, and the Word or PDF copy underneath it for you to swap the lines for your own.

Every number on the second list came out of the first one rather than being invented for the occasion. The $10 per extra product is the migration line divided by its own count, since $4,800 across 480 products is $10 each and the client can do that division as easily as you can, and the $1,400 for a seventh template is $8,400 divided by six. Pricing exclusions this way removes the one objection you'd otherwise get, that the extras were priced to punish the request.

An exclusion with no number next to it is a complaint. An exclusion with a number next to it is an offer.

Eight exclusions on a $21,800 job is roughly the right density, and each one is a near miss rather than an absurdity, which is what separates a useful project exclusion from a list of things nobody was going to ask for. Nobody needed telling that Larkspur's warehouse software isn't included, and they did need telling that product copy isn't, because a client handing over 480 rough descriptions believes cleaning those up is part of moving them across.

What about the requests that sit between the two lists?

They belong in a third section, and leaving it out is the most common reason a well-written scope still ends in a disagreement. These are the items that are in scope on a condition the client controls, so they're neither exclusions nor unconditional promises.

The migration price assumes one clean export in the agreed format, the revision rounds assume feedback arrives consolidated from one person rather than in fragments from four, and the redirect map assumes the content page count stays at the 22 you counted. You fully intend to do all of it, and what each one costs you depends on somebody else's behavior.

That last sentence does the most work, because it converts an awkward mid-project conversation into a step both sides already signed up for, and a second export in week five stops being a favor you either grant or refuse and becomes a $600 line you mention on the day it arrives. The version that fails is a scope listing its assumptions with no consequence attached, which reads as background information and gets treated that way.

What makes a task out of scope?

A task is out of scope when finishing it would spend hours or dollars the agreed fee never counted, which makes it a question about your pricing rather than about the request itself. Three checks settle almost every borderline item, in this order. Anything named in section 2 is in, however much it has grown since you wrote it. Anything that's one more countable unit of something section 2 lists prices itself, because a seventh template and a 481st product both have a rate in section 3, at $1,400 and $10. And anything that changes a number the fee was built from is out even when it isn't a new item at all, which catches a request to rebuild an approved checkout template.

The test tells you which side a request belongs on, and the rule in the next section tells you whose reading of it counts on the day you disagree.

Who decides which side a request lands on?

The document decides, as long as you wrote a default rule into it. Without that rule the decision falls to whoever is more insistent, and a client who has already spent $21,800 tends to be reasonably insistent.

The rule fits in one sentence and belongs immediately after the deliverables: work not named in section 2 falls outside the fixed fee and is quoted as a change before it starts. That single line flips the question from a matter of opinion to a matter of looking something up. Somebody asks whether the size guide panel was included, both of you read section 2, and the answer is visible to both parties at the same moment instead of being asserted by one of them.

Two supporting details make the rule usable. One named person on each side gives the answer, so a developer replying to a marketing coordinator in a chat thread never quietly becomes the agency's position, and that answer goes back in writing within two business days, because the requests that turn expensive are the ones that sat unanswered long enough for the client to assume a yes. A change request form exists mostly to make that two-day reply cheap enough that it always happens.

How do you politely say out of scope?

Quote the request rather than refusing it, and keep the phrase itself out of the message entirely. The wording that works names what they asked for, prices it from a line they've already seen, says what it does to the date, and ends with a question they can answer in one word.

Here's the whole reply to Larkspur asking for a second payment provider in week four: "Happy to add it alongside the one in section 2. A second provider is $650 under section 3, and it adds about two days to the payment setup, so launch moves from the 14th to the 18th. Want me to raise it as a change?" Nothing in that says no and nothing in it argues, and the exclusion does the work quietly, because the $650 came off a list Larkspur signed.

What keeps the message polite is everything it leaves out. There's no explanation of why the second provider wasn't included, no reminder of what was agreed in week one, and no apology for the price, all of which read as defensiveness and invite the client to reopen the principle instead of deciding on the number.

Can you bill for out-of-scope work you've already done?

Almost never, in practice, and that's the real reason the pricing conversation has to happen before the work does rather than after it. A client looking at finished work has very little reason to approve an invoice they were never shown.

Picture the size guide panel again, built quietly on a Thursday because it was faster than explaining why it wasn't included. A panel like that is roughly a quarter of the work in a template, so about $350 by the $1,400 figure section 3 already publishes. Raising it afterwards makes paying feel like being charged for a decision they didn't make, so you either absorb it or spend goodwill you were saving for something bigger, and both cost more than the two-minute message you could have sent on Thursday morning.

The same work priced in advance is an easy conversation, because the client weighs $350 against a feature they wanted and decides for themselves, and either answer beats doing it for free. Scope creep examples with the costs attached are almost all this shape, small pieces of work that were never refused and never priced.

Why is an exclusion only half written without a price?

Because the number is what turns a boundary into an offer, and the number that changes how Larkspur runs isn't $21,800, it's the $10 per product sitting in section 3 ready for the week-six message about 60 more products found in an old catalog. With the rate published that exchange lasts one message and ends in a $600 change nobody had to negotiate.

Docket handles the part that comes after the price. The request, the $600 and the written approval end up on one record attached to the project instead of scattered across a month of email, which is the difference between knowing what a change was worth and being able to show that somebody agreed to it. The project scope template shows where both lists and the assumptions section sit in a full document.

Frequently asked questions