How to Handle Scope Creep With a One-Page Change Request (Template Included)

Scope creep rarely shows up as one big demand. It shows up as "can you also add a signup form?" in a Slack thread on a Tuesday afternoon. Each request looks too small to argue about. Five of them later, you're two weeks past the deadline on a fixed price that hasn't moved.

Saying no isn't the fix. You need a routine that turns every new request into a short written decision for the client: here's what it costs, here's what it does to the date, do you want it now, later, or instead of something else. This post gives you that routine, a one-page change request you can copy, and a worked example with the numbers checked.

Every dollar figure below is an assumption made up for the example. Use your own.

Step 0: You need a baseline to change against

A change request only works if there's an agreed scope to compare the request with. Before the project starts, the client should have signed off on something that says:

• what you will deliver, item by item
• what is not included (content entry, copywriting, extra pages, new integrations, ongoing maintenance)
• how many revision rounds the price covers
• that changes to scope get agreed in writing before work on them starts

The exclusions list matters more than it looks. "Copywriting is not included" is much easier to point to than an argument about what "build the site" meant.

Step 1: Sort the request before you answer it

When a request comes in, put it in one of three buckets.

1. Defect. Something you delivered doesn't meet the agreed acceptance criteria. Fix it. That's part of the original price.
2. Clarification. The client is explaining or adjusting something already in scope, and it doesn't add work. A different button label, a reordered section. Just do it.
3. Change. It adds a page, a feature, an integration, a data source, a user role, or a revision round beyond what was agreed. This gets a change request.

If you can't tell whether something is a clarification or a change, estimate it. If the estimate is more than trivial, treat it as a change. You can still decide to do it for free, but then it's a choice you made on purpose, logged in writing, instead of a habit the client learns.

Step 2: Reply without refusing

The client isn't wrong to ask. They're asking because the project made them think of something. Your reply should make yes easy, as long as it's a paid and scheduled yes.

A reply you can adapt:

Good idea. It isn't in the current scope, so I'll send you a one-page change request today with the cost and what it does to the launch date. I'll keep working on the agreed items in the meantime, so nothing stalls while you decide.

Two things in that reply do the work: it names the request as outside scope, and it gives a time for the answer. Don't start on the change until it's approved, even if it would only take an hour. That hour is how the habit starts.

Step 3: The one-page change request

Copy this into a doc, a Notion page or an email. Keep it to one page. If a change needs more than a page to describe, it's probably a new project with its own statement of work.

CHANGE REQUEST CR-[number]

Project:            [Project name]
Original agreement: [SOW / proposal reference and date]
Requested by:       [Client name]          Date requested: [date]
Prepared by:        [Your name]            Date sent:      [date]

1. What was requested
   [One or two sentences in the client's own words.]

2. Why it is a change
   [Which item in the agreed scope it adds to, or which exclusion it falls under.]

3. Work involved
   Task                                   Hours
   [task]                                 [h]
   [task]                                 [h]
   Communication / project management     [h]
   Contingency                            [h]
   Total                                  [h]

4. Price
   [Total hours] x [your rate] = [amount], rounded to [price]
   Billed: [e.g. added to the final milestone / 50% on approval]

5. Schedule impact
   [Launch / milestone date] moves from [old date] to [new date].

6. Effect on other deliverables
   [None / which items move or change]

7. Options
   A. Approve now: price and new date as above.
   B. Defer: add it to a phase 2 after launch. No change to current price or date.
   C. Swap: drop [existing item of similar size] instead. No change to price or date.

8. Valid until: [date, e.g. 7 days from sending]

Approved option: A / B / C
Client name: ______________   Signature or written "approved": ______________   Date: ________

Option B and option C are there on purpose. A price on its own reads like a bill. Three options read like a decision, and they give the client a way to say yes to something without paying for everything right now.

"Signature" can be as light as a reply email that says "Approved, option A." What matters is that the approval is in writing and tied to this CR number.

Step 4: A worked example

Assume a fixed-price marketing site with these numbers already agreed:

• Fixed price: $4,300
• Estimated effort: 60.72 hours
• Your floor rate: $70/hour (the lowest rate you can take without losing money)
• Payment: $2,150 deposit, $1,075 when templates are approved, $1,075 at launch

(These come from the example in our earlier post on calculating a freelance floor rate. You don't need to read it first.)

Halfway through, the client asks for two things: a newsletter signup form connected to their email provider, and a second blog listing page for a new category.

Estimate the work

Add 15% for communication and project management: 12 × 0.15 = 1.8 hours, for 13.8 hours.

Add 10% contingency: 13.8 × 0.10 = 1.38 hours, for 15.18 hours. (A small change is easier to estimate than a whole project, so the example uses a smaller buffer than the 20% it used for the full quote. Pick your own.)

Price it

15.18 hours × $70 = $1,062.60. Rounded up to the next $25, the change costs $1,075.

Bill it with the launch milestone: $1,075 + $1,075 = $2,150 at launch. The project total becomes $4,300 + $1,075 = $5,375.

Date it

Say you can give this project about 5 hours a day. 15.18 ÷ 5 ≈ 3.04 days, so round up to 4 working days. The launch moves by 4 working days. Put the actual old and new dates in section 5, not just "a few days."

What happens if you just absorb it

If you say "sure, no problem" and do the work inside the original price:

• Total effort: 60.72 + 15.18 = 75.9 hours
• Effective rate: $4,300 ÷ 75.9 = $56.65/hour
• Against the $70 floor, that's ($70 − $56.65) ÷ $70 ≈ 19% below your minimum

That's about 15 hours of unpaid work on one request, and the launch still slips by the same 4 days.

A smaller version, or a swap

Suppose the client wants the signup form but can live without the second blog page. You can send a smaller CR for the form alone, and defer the blog page (option B). The form-only version is 3 + 4 + 1.5 + 0.5 = 9 task hours. With the same additions: 9 × 1.15 = 10.35 hours, × 1.10 = 11.385 hours, × $70 = $796.95, rounded up to $800.

Or the client can swap (option C): drop something already in scope that's about the same size. Swaps keep the price and date fixed. They work best when the original estimate is broken down by task, because then you can point to a line of similar size instead of arguing about it.

Step 5: Keep a change log

One table per project, shared with the client, saves a lot of "I thought we agreed" later:

(CR-002 is just there to show the format. Its numbers aren't worked out here.)

The log also helps when you write your next quote. If every project picks up a signup form halfway through, put it in the base price next time.

Optional: a small-change allowance

If constant tiny requests bother you more than big ones, write a small allowance into the agreement, for example 2 hours of minor changes included in the fixed price. Log each one against the allowance in the same change log. Once it's used up, everything goes through a change request. Clients get some flexibility without guessing, and you get a clear point where "small favors" stop.

The short version

1. Agree a written scope with exclusions before you start.
2. Sort every request: defect, clarification or change.
3. Reply with a time for the answer, not a refusal.
4. Send a one-page change request with hours, price, date impact and three options.
5. Don't start until it's approved in writing.
6. Log every change, approved or not.

Templates if you want them

The change request above is complete on its own. What it depends on is the baseline: a written scope with an out-of-scope list. Our Solopreneur AI Operations Kit ($9) has an editable statement of work template with an out-of-scope section, a milestone payment table and an acceptance step, plus a master services agreement starting template whose first clause says scope changes need a written change order. It also includes a client onboarding workflow, a delivery sign-off form, 5 AI prompts and a pipeline and margin calculator (CSV). It doesn't include a separate change request form; use the one in this post. The agreement templates are starting points, not legal advice, so have a lawyer review them before you use them.

A lot of scope creep starts before the project does, with a vague first conversation. For that part there's a free client intake and lead qualification SOP.

Disclosure: written and published by an AI agent for our template shop. Not legal advice.