The change request process that protects margin without annoying clients

Agencies don't lose margin to one big scope change. They lose it to six small ones, each of which felt too minor to raise an invoice for.

The fix isn't a stricter attitude. It's a process light enough that raising a change request costs you less effort than absorbing the work — and predictable enough that the client stops experiencing it as a fight.

What six small changes actually cost

Take the hypothetical brand and campaign project from earlier in this series: quoted at $48,000, scoped at 252 hours, loaded cost $95 an hour, so $23,940 of delivery cost and 50.1% margin.

Over three months, six requests arrive. None of them is unreasonable. None of them is big.

Request	Hours	At $150/h
Extra landing page variant	6	$900
Second retouching pass on the shoot	4	$600
Three extra platform cut-downs	9	$1,350
Added stakeholder workshop	5	$750
Copy rewrite after the repositioning	12	$1,800
Extra reporting dashboard	8	$1,200
Total	44	$6,600

Two ways this project can end:

	Revenue	Cost	Margin
Changes absorbed	$48,000	$28,120	41.4%
Changes billed	$54,600	$28,120	48.5%

Absorbing them costs 8.7 margin points on a single project. And notice the second row: even billed at your normal rate, the project comes in slightly below the original 50.1%, because change work carries coordination overhead you didn't quote for. Billing changes isn't opportunism. It's how you stay where you started.

The process, in four steps

1. Name it in the moment, not in the invoice. The instant a request lands outside scope, say so — in the meeting, in the reply, same day. "That's outside what we scoped, so I'll put a quick change request together." Neutral, immediate, no apology and no accusation.

The killer mistake is doing the work and mentioning the cost later. That converts a routine commercial exchange into an unpleasant surprise, and clients are right to be annoyed by it.

2. Write it in five lines. A change request that takes an hour to produce will not get produced. The whole document is:

What's changing:   one sentence
Why it's outside scope: reference to SOW section or assumption
Effort:            hours
Price:             hours × rate
Timeline impact:   days added, or "none"
Approve by:        date after which the timeline moves

That's it. One email, five minutes.

3. Always give the timeline impact. Cost is the part clients argue about. Timeline is the part they care about. A change request that says "$1,350, adds four days" gets a faster decision than one that only says $1,350, because it lets them weigh the trade-off themselves.

Include "none" when it's none. It builds credibility for the times it isn't.

4. Get written approval before starting. "Yes, go ahead" in an email thread is enough. A verbal yes on a call that you summarise in writing afterwards is enough. Nothing is not enough, however obviously they wanted it.

Give them options, not a bill

The single biggest change to how these land is offering a choice instead of a charge. For anything meaningful, present three routes:

• Add it. $1,800, adds one week.
• Swap it. We do this instead of the second concept round — no cost, no delay.
• Defer it. Park it for a phase two after launch.

Now the client is making a decision about their own priorities rather than responding to a demand for more money. Swap is underused and often the best answer: it costs you nothing, it gets them what they now want more, and it makes clear that scope is a budget rather than a bucket.

Set a threshold so small things stay easy

If every fifteen-minute request generates paperwork, you'll be insufferable to work with and the process will die within a month.

Set an explicit tolerance — say, anything under two hours gets absorbed, tracked, and reported. Tell the client it exists. "Small things we just do; anything over a couple of hours I'll put a note together for."

Then track the absorbed work anyway. At the monthly check-in: "we've absorbed about 9 hours of extras this month, which is fine, just so you can see it." Two things happen. The client learns that free work is real work rather than invisible. And when the eleventh small request comes, you've already built the case without ever having been difficult.

Where the process breaks

The person who spots the change isn't the person who can raise one. A designer notices scope drift, a project manager owns commercials, and by the time it's escalated the work is done. Give delivery people the authority to say "that sounds like a change request, let me check" — not to price it, just to pause it.

Change requests get batched. Saving them up for a monthly summary produces one large uncomfortable number instead of six small routine ones. Raise them the day they occur.

Nobody knows what's in scope. If the delivery team hasn't read the SOW, they can't identify a deviation from it. Ten minutes at kickoff walking through the deliverables and out-of-scope list solves this permanently.

The first one is skipped. Whatever you let through in week two defines the project's norms. The first change request is the hardest and the most valuable — after it, the process is just how you work together.

What clients actually dislike

Not being charged for extra work. Clients buy things all the time and understand that more work costs more money.

What they dislike is unpredictability: finding out at the end, being charged for something they thought was included, or discovering the goalposts are wherever you say they are. A change request raised the same day, with a fixed price and a clear timeline impact, is the opposite of that. Done consistently, it makes you look more organised than the agency that quietly absorbs everything and then asks for a big uplift at renewal.

Start on your current project

Pick the project you're most worried about and, for the next two weeks, write down every request that falls outside the original scope — with an hours figure next to it. Don't invoice anything yet.

At the end of the fortnight you'll have a number. It's usually larger than anyone expected, and it's the easiest possible way to make the case internally for raising the first change request on the next one.