Scope creep or a reasonable revision: how to tell, and what to send back

A revision changes how something you already agreed to gets executed. Scope creep changes what you agreed to deliver, or how many times you deliver it, and every hour spent on that second category is worked at an effective rate of zero until somebody re-prices it.

Every article on scope creep tells you to define scope up front and put it in the contract. That advice is correct and useless at the moment you need it, because the request is already in your inbox, the contract is signed, and the client sincerely believes they are asking for something small. Prevention was last month's problem. Today's is classification: which side of the line this request falls on, and what you send back before lunch.

Qualification settles part of this before you accept, which is what the five questions that predict whether a project will be profitable are for. This post starts after the signature.

The line runs between execution and definition

The test in one sentence: a request is a revision if it changes how an agreed deliverable is executed, and scope creep if it changes what the deliverable is, or how many times you produce it.

That resolves most requests in seconds. It fails in three recognizable places.

The new reference. At round two the client sends a link: "can we make it feel more like this?" Surface treatment is execution. A reference that implies a structure you already built and had signed off reverses an approved decision, which is redefinition. You cannot classify the message as sent, because the client described a feeling rather than a change list. So the first reply is never a price and never a yes; it is "which parts of that do you mean," and the answer is what you classify.

The extra format. "Can we also get it as X?" is ten minutes if it is an export and two days if the deliverable has to be re-authored for another medium. One sentence describes both jobs, and the client cannot see which one they asked for. The line is not in the request, it is in your file.

The correction against a brief that was silent. If the delivered work contradicts the written brief, it is a defect in your execution: fix it, don't invoice it. If the brief said nothing, both of you left it unsaid, and the work is a change. Most briefs are silent on the exact thing being argued about, which is why this case burns the most goodwill. The tiebreak that holds up: the first silent-brief fix on an item is a revision, the second on the same item is a change, because by then the client is deciding rather than correcting.

Six requests that recur, and which side each falls on

The last row is the one people get wrong most often: the new person is usually senior, answering feels like service, and it creates a second client who has agreed to nothing.

Drift is the expensive one because nothing ever triggers an invoice

A single large out-of-scope request is a good problem: visible, priceable, and it starts a conversation on its own. The expensive version is the accumulation of items each genuinely too small to invoice, and the mechanism is your own threshold. Below some size, writing a change note costs more than the work, so those items get absorbed, and absorbing one prices it at zero. The observed price of the last request becomes the expected price of the next. Nothing in the sequence is ever big enough to trigger the process you built for big things, so the process never runs.

The fix is a budget you compute once per project and then watch. Divide the fee by your floor rate, the hourly figure below which the work stops being worth doing, built from costs, tax reserve and honest non-billable time. That gives the hours the project can consume before it stops paying. Subtract the hours you estimated. What is left is your absorb budget.

Illustration, not observed data. A fixed fee of €3,200, estimated at 40 hours, quoted at €80 an hour, against a floor of €65. The project can run to 3,200 ÷ 65 = 49.2 hours before it hits the floor. Minus the 40 estimated, the absorb budget is 9.2 hours, or 23% of the estimate. Re-quote at half of that: about 4.5 hours, roughly 11%. Quote at your floor with no gap and the absorb budget is zero hours, so the first out-of-scope request is a re-quote.

Two things trigger the conversation, whichever comes first: half the absorb budget in hours, or the third out-of-scope item in one phase. The count matters on its own, because three items establish a rate of arrival, and that rate predicts the rest of the project better than the hours consumed so far.

If the estimate was a guess because you had never done the work before, the absorb budget is fiction and the prior problem is estimation, which pricing work you have never done before treats as a spread rather than a rate.

You cannot classify what you did not record

Track one extra thing. Every time entry already carries a project; add a flag for whether the item was in the signed scope or arrived after signature. Two buckets, set when the timer starts rather than reconstructed later.

The number to watch weekly is post-signature hours divided by estimated hours, compared against your own absorb budget ratio, 23% in the illustration above: notice at half, act at the whole. Any figure someone asserts for you was computed from their floor and their quote gap, not yours.

Timing is the whole value. Your effective hourly rate on the finished project prices the drift after the money is set, which helps the next quote and does nothing for this one. The running ratio tells you in week two, while a phase is still left to re-quote. That works only if hours are captured as the work happens, the point of time tracking that treats every logged hour as billable by default, and if the budget sits on the project rather than in your head, which is what project budgets with time logged against them are for.

A standalone timer tells you a project has passed its budget. It does not tell you which side of the line the extra hours came from, or turn that into a change note somebody can approve, which is the argument made on the Harvest alternative page.

Two replies: one prices the change, one counts it

The first is the message everybody writes badly. The second almost nobody writes, and it is the more valuable.

Template A: pricing a change

Subject: Pricing table above the fold — quick scope note

Hi [name],

Happy to do it. Moving the pricing table above the fold means
rebuilding the hero and re-cutting the two images inside it, so
it lands as a change rather than a revision.

Additional: 3 hours at €80, so €240. It also adds a working day,
moving delivery from Friday to Monday.

Reply yes and I'll start this afternoon. If Friday matters more,
we ship as approved and I'll quote this as a follow-up.

[you]

Line by line. "Happy to do it" goes first so the answer is a yes and nothing after it reads as resistance. The middle sentence names a mechanical consequence rather than a category: "rebuilding the hero" is a fact, "that's out of scope" is a verdict, and verdicts get argued with. The classification arrives after the reason, so it reads as a conclusion instead of a policy. Price and calendar sit together, because a change costing money and no days gets approved carelessly, while one costing a day gets thought about. Both closing options are a yes. No apology, no explanation of your business model, no reference to what the last change cost you.

If the change needs a document rather than a paragraph, put it on a dated quote with a valid-until line. The quote generator builds one in the browser, no signup and no watermark, and the valid-until date stops an approved change being approved three weeks later at the old price.

Template B: accepting a small one, on the record

Subject: Done — and where we are on the small stuff

Hi [name],

CTA copy is swapped and live. No charge.

For the record, that's the fourth small change since we signed
scope on 6 July: footer links, the two icon swaps, the testimonial
reorder, and this one. About three hours in total, absorbed.

Flagging it now rather than at the end. There's roughly four
hours of that left in this phase before I'd need to re-quote. If
more are coming, send them together and I'll price them as a
block, which works out cheaper for you than one at a time.

[you]

Line by line. The favor is delivered before the count, because a count that arrives first reads as a bill. "For the record" states the purpose, so nobody has to work out whether you are annoyed. The list is itemized against the date scope was signed: four remembered items beat "several small changes," which the client will dispute and you will lose. The hours are marked absorbed, because nobody thanks you for a discount they never knew about. The remaining budget is named before it is gone, which is the whole function of the message: the fifth request arrives with the price already visible to both of you. The closing line is a real discount rather than a warning, since batched changes genuinely are cheaper to do, and it makes the client volunteer the rest of the list. No question mark anywhere. You are not asking permission to be paid.

Absorbing it is sometimes the correct commercial decision

Eating a small request sometimes buys a renewal worth more than the hours, and pretending the answer is always to charge is bad advice. Four conditions have to hold at once.

The hours fit inside the remaining absorb budget, so the project still clears your floor. There is a next engagement with a date, or a renewal decision inside a known window, because "more work coming" is a hope rather than a condition. The person asking decides on that renewal or reports to whoever does, since absorbing for a bystander with no budget authority buys nothing. And you record it and say you absorbed it, which is what Template B is for.

Price it as what it is. Illustration: three absorbed hours at €80 cost €240 of sellable capacity. If you would spend an unpaid half-day writing a proposal to win that renewal, €240 on a client already talking to you is the cheaper channel and converts better. If you would not spend the half-day, charge.

A client who has absorbed a year of free work is not one to resent, it is one whose price is wrong. The renewal is where that gets corrected, and raising a rate with an existing client is the instrument.

Three things to change this week

1. Compute the absorb budget for every open project. Fee divided by your floor rate, minus estimated hours, written at the top of the project file. Half of it is your re-quote trigger.
2. Add the in-scope flag to your time entries, starting today. Two values only. Do not backfill last month; reconstructed classification is guesswork and reads as noise in the ratio.
3. Put Template B in your snippets and send it the next time you absorb something. The first one feels awkward. The fourth is why nobody argues about the final invoice.

Worklyn's Scope Watch flags a project against its budget while there is still budget left to defend, using the hours already logged against that project. Finding out in week two is a re-quote; finding out at the invoice is a write-off.