Scope creep gets blamed on clients who keep asking for more. That explanation survives because it is comfortable, and it is wrong in a way that makes it impossible to fix. Clients ask for more on every project that has ever run. What varies between agencies is whether asking produces a decision or produces silence, and that is entirely within your control.
This is about project work with a fixed scope. If the problem is a monthly retainer quietly absorbing extras, that is a related but different failure, covered in how to stop over-servicing retainer clients.
Why does your team absorb changes instead of raising them?
Because they are doing the arithmetic, and the arithmetic is correct. Raising a change properly costs a form, an email, an estimate, a wait, and an uncomfortable conversation — call it three days. Absorbing it costs forty minutes and makes them look helpful. Nobody is being lax. The process is losing a fair fight.
This is why exhortation does not work. Telling the team to be disciplined about scope asks them to choose the expensive path out of loyalty, several times a week, forever. A few people will comply for a month. The process will win in the end, because processes always do.
Scope creep is what you get when the compliant path costs more than the non-compliant one. Nobody is going to fix that with willpower.
What does a change request actually need to contain?
Four things, and the discipline is in what you leave out. What changed, what it does to the plan, what the trade is, and who decides. That fits on a card and takes thirty seconds, which is the entire point — it has to be cheaper than absorbing the work.
Most change-request templates fail because they were designed by someone protecting the agency legally rather than someone who has to fill one in on a Tuesday afternoon. A form with fourteen fields is a form that gets skipped, and a skipped form protects nobody.
- What changed — one sentence, in the client's words if possible.
- Effect on the plan — time, not a lecture. Half a day, pushes launch to Thursday.
- The trade — the part everyone omits. Add it, or take something out.
- Who decides — named. If nobody is named, the answer defaults to yes.
Isn't this just going to annoy the client?
Less than the alternative, and the alternative is what actually damages the relationship. A change that quietly consumes the buffer shows up later as a missed date the client did not agree to, and that conversation is far worse than the one where you offered them a choice.
Offering a trade also reframes the exchange. "That is out of scope" sounds like a refusal. "We can add it — it pushes launch to Thursday, or we can swap it for the email template" sounds like a plan, and most clients pick one without drama. They are not trying to get free work; they usually have no idea the request costs anything.
What are the three endings, and are any of them bad?
Approved, swapped, or declined — and all three are better than the fourth one, which is absorbed and never mentioned. Even a declined request has paid for itself, because the client now knows the request existed and that you priced it rather than refusing it.
| Outcome | What it gets you |
|---|---|
| Approved | The work, billed, and the date moved on the record |
| Swapped | Scope holds, and the client chose what to drop |
| Declined | A record that you offered, which protects the deadline |
| Absorbed silently | Forty minutes now, and a date you cannot defend later |
The fourth row is the default, and it is the only one with no upside. Notice that it costs the same forty minutes as the first three — the difference is entirely in whether anyone decided.
Where should the change request live?
On the work, not in a document. A change request that lives in a shared drive or an email thread is invisible at the moment someone is deciding whether to bother, which is the only moment that matters.
| Dimension | A change request document | Atwork |
|---|---|---|
| Where it lives | A folder, or an email thread | An item on the same board as the work |
| Time to raise one | Minutes, plus finding the template | Seconds, from the item it affects |
| Visible when deciding | No | Yes, next to the task |
| Shows the running total | Only if someone maintains a log | Yes, as a view |
| Stops a determined client | No | No — this is a decision record, not a shield |
The running total is the part that changes conversations. Four small approved changes look like nothing individually and like a fortnight when they are listed together, and that list is what turns a vague sense of lateness into a shared fact. What to put in a monthly client report covers how to present it.
Where should you start this week?
Time your own change process. Actually do it — take the next change that comes in, follow your official route, and note how long it takes from request to decision. If the answer is more than an hour of effort spread over more than a day, you have found the reason nobody uses it.
Then cut it to four fields on the item itself and tell the team the new rule is that changes get logged, not that changes get refused. Logging is a low bar and it is the only bar that matters, because a logged change can be priced later while an absorbed one cannot be recovered at all.
The Agency Client Delivery template ships the board this runs on, and the agencies overview covers the wider setup. If the deeper issue is that the team has no room to absorb anything, agency capacity planning is the companion piece.
Time your own change request process end to end. Whatever that number is, it is why your team absorbs changes instead. Start free