Scope changes are not the enemy. Done right, they’re a revenue opportunity. A client who asks for more work mid-project is a client who trusts you and wants to invest more. The problem isn’t that scope changes happen — it’s that most agencies have no repeatable system for handling them, so the money evaporates anyway. This is the framework to fix that.
Scope Changes Are Not the Same as Scope Creep
This distinction matters because the two problems require different responses. Scope creep is the gradual erosion of project boundaries through accumulated small requests — each individually harmless-looking, collectively ruinous. Scope changes are something different: a deliberate, acknowledged modification to what the project will deliver. The client wants a new feature. The brief has shifted. A technical dependency emerged that nobody anticipated.
Scope creep happens when you don’t have a process. Scope changes happen regardless — but without a process, they behave like scope creep. They get absorbed, under-billed, or awkwardly invoiced after the fact in a way that damages the client relationship. The goal isn’t to eliminate scope changes; it’s to handle them so cleanly that they become a normal, even welcome, part of how you work with clients.
Well-managed scope changes should actually increase your project revenue on average. A 10-person agency running 30 active projects at any given time, where half of those projects generate one approved change request at an average of £800, is looking at £12,000 in additional revenue per project cycle — revenue that effectively didn’t exist before they installed the process. The work was happening anyway. They just weren’t getting paid for it.
Identify Scope Changes the Moment They Occur
Most scope change problems are actually recognition problems. The additional work starts, gets completed, and only surfaces when someone reviews the hours at invoice time — by which point the conversation is uncomfortable at best and confrontational at worst. The fix is to catch scope changes at the point of request, not the point of delivery.
Your team needs a shared definition of what constitutes a scope change. A useful working definition: anything that isn’t explicitly listed in the original project brief or contract is a potential scope change. Not automatically billable — some things genuinely are minor enough to absorb as goodwill — but explicitly considered rather than silently executed. The decision to absorb or charge should be a conscious choice, not something that happens by default.
Practically, this means training your project managers to ask one question every time a new request arrives from a client: “Is this in the original spec?” If the honest answer is no, it goes through the change request process. This sounds simple, but it requires building a habit that runs counter to the natural impulse to just get the work done. Account managers and PMs are often conflict-averse; they’d rather quietly handle a request than have a procedural conversation about it. That instinct, however well-intentioned, is where the money goes.
The moment to raise a change request is when a client asks for something new — not when you’re writing the invoice. By then, the work is done and your leverage is gone.
The Change Request Process That Actually Works
A usable change request process has four stages: identification, scoping, approval, and delivery. Each stage needs to be fast enough that neither you nor the client finds it burdensome. A process that takes longer to administer than the work takes to do will be bypassed — not out of bad faith, but because people are busy.
Stage 1 — Identification. The PM or account handler recognises that a request falls outside the original scope. They tell the client: “This looks like it falls outside our current project scope. I’ll put together a change request so we can get it formally agreed and scheduled.” That sentence matters: it sets the expectation that the work is coming, just through a process. It doesn’t say no. It doesn’t create friction. It simply signals that you’re treating the request professionally.
Stage 2 — Scoping. The change request gets written up. Not a five-page document — a brief that includes: what the change is, what’s involved, the estimated time, the cost, and any impact on the existing delivery timeline. Aim to turn this around within 24 hours of the request. A change request that takes a week to arrive trains clients that your process is slow and encourages them to push for informal agreement instead.
Stage 3 — Approval. The client reviews and approves the change request in writing. “In writing” here means email confirmation at minimum, e-sign at best. The reason written approval matters: three months down the line when the invoice arrives, nobody can say “I didn’t know this was going to cost extra.” The paper trail is your protection — and most clients don’t resent the process once they’ve experienced it a couple of times, because it also protects them from unexpected invoices.
Stage 4 — Delivery. Work starts only after approval. This is the part where most agencies slip. The client says “yes, go for it” verbally, and the PM starts work immediately because the project is live and the request is urgent. Then the formal approval email takes a week to arrive, or doesn’t arrive at all. The rule should be: no written approval, no work. Build the template response — “Thanks, I’ll get this kicked off as soon as the change request is signed off” — and use it every time.
Pricing Change Requests Correctly
The failure mode here isn’t undercharging on a single change request — it’s consistently mispricing because you haven’t thought through how to value additional work relative to the original project economics.
Hourly rates are the most common approach, and they’re fine for most changes. But consider the context: if the original project was sold at a fixed price that implied an effective rate of £90/hour, and your change requests are priced at your standard £75/hour day rate equivalent, you’re actually cheaper for out-of-scope work than for in-scope work. That doesn’t make sense. Changes add project management overhead, context-switching costs, and often create downstream timeline complications. Price them accordingly.
A useful heuristic: add 15–20% to your base labour cost for any change request that requires rework of something already completed, or that affects the project timeline. A client who asks for a new page on a website is adding straightforward work. A client who asks to change the navigation architecture two weeks before launch is adding work that creates risk and additional PM overhead — and should be priced at a premium that reflects that.
For larger changes — anything over roughly four hours of work — it’s worth also flagging the timeline impact explicitly. “This will take approximately 6 hours and will push the current go-live date back by 3 days, or we can schedule it as post-launch work at no timeline impact.” Giving clients options is professional; it also demonstrates that you’re managing the project tightly rather than just absorbing requests without thought.
Track Change Requests Over Time — the Data Is Valuable
Most agencies treat change requests as one-off transactional events. The smarter approach is to track them as a dataset and use what you find. Over time, patterns emerge that are commercially useful.
Which clients generate the most change requests? If a client consistently generates four or five change requests per project, there are two possible explanations: they’re genuinely poor at writing briefs and need more structured discovery upfront, or they’re using change requests as a way to incrementally expand a project they knew was under-scoped when they signed off on it. Either way, your intake process for that client needs adjusting — and your pricing for their next project should account for the change request rate you’ve observed historically.
Which project types generate the most changes? Web builds typically generate more than ongoing retainer work, because project-based work involves more upfront unknowns. If your branding projects consistently generate two or three change requests at the final presentation stage, that’s a signal to either charge a discovery phase premium or build more revision rounds into the base scope so they stop appearing as extras.
Change requests also tell you about the quality of your brief-writing. A team that consistently generates scope changes from “forgotten” requirements — integrations, form functionality, analytics setup — is a team whose discovery and scoping process needs work. The fix isn’t better change request management; it’s a more thorough project kickoff that surfaces these requirements before the contract is signed. Tracking change requests by type helps you identify and close those gaps systematically.
Managing Change Requests in Your Project Management System
Change requests managed in email threads are invisible. By the time the project completes, nobody has a clear picture of how many changes were approved, which ones are outstanding, or what the total value of additional work was. That information matters — for invoicing, for project post-mortems, and for the conversation when the client questions their bill.
A project management system that handles change requests as first-class objects — not just notes or emails — gives you a running log against each project: the original scope value, the changes approved, the changes declined, the changes pending approval, and the revised project total. When you’re writing the final invoice, you’re not piecing together a history from three email threads and a Slack channel. It’s already there.
Marque CRM connects project budgets, time tracking, and invoicing so that approved change requests flow directly into the project record and the invoice when it’s raised. There’s no manual reconciliation, and no gap between what was agreed and what gets billed. For agencies managing five or more concurrent projects, that kind of system coherence pays for itself quickly — the alternative is usually someone spending half a day before each invoice run piecing together what was agreed and when.
Beyond the operational efficiency, having change requests tracked in your CRM builds a complete client history. If a client disputes an invoice, you can show them the approved change request with the date, the description, and the price they signed off on. That documentation ends disputes quickly. In the rare cases where a client is acting in bad faith, it’s also the evidence you need.
When to Absorb and When to Charge
Not every out-of-scope item should be billed. Absorbing small things strategically is part of good client relationship management — but the operating word is “strategically.” The decision should always be conscious, not default.
A useful framework: absorb changes where the goodwill value clearly exceeds the cost, and where absorbing won’t create a precedent that invites future behaviour. Adding one extra slide to a deck for a client who’s been with you for three years and has never queried an invoice: absorb it. Reworking a logo because the client’s CEO didn’t see the brief until after sign-off: charge for it. The first is a relationship investment; the second is absorbing the cost of someone else’s process failure.
When you do decide to absorb something, tell the client. “We’ll take care of that one — it’s a small addition and you’ve been great to work with on this project” is a more powerful client relationship moment than silently doing extra work. It registers as a deliberate act of generosity rather than an entitlement, and it sets the expectation that the norm is to charge for extras. That framing makes the conversation easier when you do need to raise a change request next time.
Be wary of patterns across the team. If three different account managers are all “absorbing” small items across multiple clients, and nobody is tracking it, the aggregate cost can be significant. A five-person agency each absorbing three hours of unscoped work per week is gifting away 15 hours weekly — roughly £1,000 at typical agency rates. Tracked and reviewed, that number prompts process conversations. Untracked, it just disappears into margin compression.
The Bottom Line
Scope changes are inevitable, but losing money on them is a choice — specifically, the choice not to build a process. The framework above isn’t complicated: catch changes early, scope them quickly, get written approval, track everything, and use the data to improve your upfront scoping over time. Most agencies that implement it see an immediate improvement in project revenue without any increase in workload, because they were already doing the work — they just weren’t getting paid for it.
The cultural piece matters as much as the operational one. Your team needs to understand that raising a change request isn’t being difficult with a client — it’s being professional. Clients who’ve experienced well-run agencies actually expect this process; it signals that you’re organised and that your projects don’t quietly overrun. The ones who push back on it are often the ones generating the most scope changes in the first place.
Start by auditing your last five projects. For each one, count the hours logged against work that wasn’t in the original spec, and calculate what those hours would have been worth if billed. That number will tell you how urgently you need a change request process — and what it’ll be worth when you have one.