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

In scope is the work your scope document names and prices. 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 of this 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. The part that decides real money is narrower than that. It's the wording on both lists, the requests that honestly sit between them, and the rule your document names for settling those requests. All three are written out below against a $21,800 e-commerce replatform, in the same shape they'd appear in the document itself.

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. The extra landing page they want probably would sell more hardware, and the second payment provider probably would convert better than the one you configured. Neither of those observations changes the fact that the $21,800 was assembled from a list that didn't contain them, 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. "That's out of scope" lands as a refusal and invites an argument about fairness. "That isn't in the current scope, so here's what it costs and here's what it does to the launch date" is the same information with the useful half attached, and it matches what your own document already says. Agencies that handle scope creep without losing the client tend to 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. They picture 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, none of it was priced, and none of it was excluded either, which leaves the request in the space where the loudest reading wins.

The fix isn't a longer document. It's putting the countable detail into 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". Now the request for a size guide that opens in a panel is visibly a fifth thing rather than an implied sixth, and the same discipline that makes a scope of work clients can't misread is what 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.

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. 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, which is that the extras look like they 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.

The list also tells you something before the project starts. Seven exclusions on a $21,800 job is roughly the right density, and each one is a near miss rather than an absurdity. Nobody needed to be told that Larkspur's warehouse software isn't included. They did need to be told that product copy isn't, because a client handing over a spreadsheet of 480 rough descriptions genuinely 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 that section out is the single most common reason a well-written scope still ends in a disagreement. These are the items that are in scope on a condition, where the condition is something the client controls.

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. The redirect map assumes the content page count stays at the 22 you counted. None of those are exclusions, because you fully intend to do the work, and none of them are unconditional promises either, because the cost depends on somebody else's behavior.

That last sentence is the one doing the most work, because it converts an awkward mid-project conversation into a step both sides already signed up for. 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 of this that fails is a scope listing its assumptions with no consequence attached, which reads as background information and gets treated that way.

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 answering a marketing coordinator in a chat thread never quietly becomes the agency's position. And the answer goes back in writing within two business days, which sounds like a courtesy and is actually protection, since 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.

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 puts the client in a position where paying feels like being charged for a decision they didn't make, so the realistic outcomes are that you absorb it or that you spend goodwill you were saving for something bigger. Both of those cost more than the two-minute message you could have sent on Thursday morning.

The same piece of work priced in advance is an easy conversation, because the client gets to weigh $350 against a feature they wanted and decide for themselves. Roughly half the time they'll say yes and the other half they'll drop it, and either answer is better for you than 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 an exclusion is only half written without a price

Go back to the two Larkspur lists and the number that changes how the project runs isn't $21,800. It's $10, the per-product migration rate that section 3 makes visible, because that's the figure sitting there ready when Larkspur mentions in week six that they've found another 60 products in an old catalog.

With the rate written down, that conversation lasts one message and ends in a $600 change everyone understood before it was raised. Without it, the same request becomes a negotiation about whether 60 more products is a big deal, conducted at a point where you're already six weeks into the relationship and reluctant to be difficult. The exclusion by itself doesn't save you there. The exclusion with a number next to it does, because it turns the boundary into an offer the client can accept, and an offer is much harder to be annoyed by than a rule.

Docket handles the part that comes after the price. When Larkspur asks for those 60 products, 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