Change Requests Without the Fight: A Scope-Control System for Non-Technical Clients

Every agency project dies the same way: not from a single bad decision, but from forty small ones nobody wrote down. A client asks for "just a small tweak" in Slack, an engineer nods on a call, and three weeks later the timeline is smoke and nobody can point to when it happened.

This is a system we've refined across dozens of engagements for handling change requests with clients who don't read Jira, don't want to read Jira, and shouldn't have to. It works for fixed-price, it works for T&M, and it holds up when the relationship gets tense.

Why "just track it in Jira" fails

Engineers love ticket hygiene. Clients don't. When you tell a non-technical founder to "open a ticket," one of three things happens:

1. They don't, and the request lives in a DM until someone builds it anyway.
2. They do, and it's a three-word title with no acceptance criteria.
3. They do, and they expect it done this sprint because they filed it.

None of these are the client's fault. Your process is asking them to be a project manager on a system they didn't buy. The job of scope control is to make the right behaviour the easy behaviour for someone who has never shipped software.

The two things a client actually needs to know

Strip everything else away and a non-technical client needs two answers when they ask for something new:

• Does this change what I'm paying?
• Does this change when I get it?

If your system answers those two questions within 24 hours of any request, you will not have a scope fight. If it doesn't, you will.

The change request lifecycle we use

We run every request — from "can we move this button" to "can we add multi-tenancy" — through the same five states. Same states, different weight.

RECEIVED → TRIAGED → COSTED → DECIDED → ABSORBED

Each state has an owner and a maximum dwell time. No request skips a step, even the trivial ones. Especially the trivial ones — those are the ones that quietly eat margin.

Received

Anything a client says that isn't already in the signed scope is a request. Slack message, email, offhand comment on a demo call. The project lead's job is to capture it, in writing, in one place, within the same working day.

We use a single shared doc per project called the Change Log. Not a tool. A doc. Clients open docs. They don't open tools.

Triaged

Within 24 hours, the request gets a category:

• Clarification — it was always in scope, we just didn't specify. Free.
• Trade — in scope, but the client wants to swap it for something else. Free, with a written swap.
• Change — genuinely new work. Needs costing.
• Bug — our fault. Free, and we say so plainly.

Calling this out early matters. Half of what feels like scope creep is actually clarification, and pretending otherwise makes you look greedy. Half of what feels like a favour is actually a change, and pretending otherwise bankrupts you.

Costed

For anything tagged Change, an engineer produces an estimate within two working days. We estimate in ranges, never point values, and we quote in the client's currency of choice: money, days, or both.

## CR-034: Bulk CSV import for customer records

Category: Change
Estimate: 4 – 6 engineering days
Cost: £4,800 – £7,200 (fixed) or T&M at agreed rate
Timeline impact: pushes launch by ~1 week if approved this sprint
Dependencies: requires the auth work in CR-029 to be merged first
Risks: file size limits on current infra; may need a queue worker

That's the whole template. No essays. A non-technical client can read it in thirty seconds and know exactly what they're deciding.

Decided

The client says yes, no, or later. Later is a valid answer and we track it explicitly — nothing rots faster than a "maybe" pile. Decisions go in writing, in the same doc, with a date and a name.

If the request is approved, it becomes a line item. If it's rejected, it stays in the log so nobody re-litigates it in month four.

Absorbed

Once approved, the work enters the actual backlog with acceptance criteria the engineers wrote, not the client. This is where Jira or Linear finally shows up. The client never has to see it.

Pricing changes without poisoning the relationship

The fastest way to make a client feel nickel-and-dimed is to itemise every five-minute favour. The fastest way to go broke is to itemise nothing. The middle path is a change budget.

At kickoff on any fixed-price engagement, we bake in a change budget — typically 10 – 15% of the contract value — that the client can spend on small changes without a new SOW. Below a threshold (say, half a day of work), changes just get logged and drawn from the budget. Above it, they go through full costing.

This does three useful things:

• It signals from day one that changes cost something, without making every request a negotiation.
• It gives the client a real budget to manage, which is a language founders understand.
• It gives you an honest buffer for the small stuff that would otherwise erode margin.

When the change budget runs out, you have a natural, non-confrontational moment to talk about a scope amendment. "We've used the change allowance — here's what's left in the original scope and here's what we've added. How do you want to proceed?" That conversation is a hundred times easier than "we need to talk about scope."

What to never charge for

A short list, and we hold to it:

• Anything ambiguous in the original SOW. If two reasonable people could read it differently, that's on us.
• Bugs in work we shipped.
• The first fifteen minutes of any "can you just look at this" request.
• Meetings we called.

Being generous on the small stuff earns the credibility you need when you have to be firm on the big stuff.

Handling the "but you said" moment

Every long project has one: the client remembers a conversation differently than you do. If your change log is up to date, this is a two-minute conversation. If it isn't, it's a two-week crisis.

We write a weekly recap — five bullets, sent every Friday, covering what shipped, what's in flight, what's blocked, what changed in scope this week, and what we need from the client next week. It goes to every stakeholder, including the ones who don't come to standups.

That recap is the single most valuable artefact on any project. It creates a written record neither side has to search for, and it forces us to notice scope drift while it's still small. When someone eventually says "but you said," you both open Friday's email.

When to walk away from a change request

Sometimes the right answer is no, even when the client is willing to pay. Reasons we've said no:

• The change breaks the architecture in a way we can't defend six months later.
• The change is technically fine but pushes the launch past a date the client needs for reasons they haven't fully thought through.
• The change is a symptom of a product decision the client hasn't actually made yet, and building it now locks them in.

Saying no is easier when you've been generous on the small stuff and precise on the big stuff. Clients trust an agency that occasionally pushes back more than one that says yes to everything and then misses dates.

Where we'd start

If you're running a project right now with no scope system, don't try to install all of this on Monday. Do two things this week:

1. Open a shared Change Log doc, backfill every request from the last month, and share it with the client with a short note explaining what it's for.
2. Send a Friday recap this Friday, even if it's ugly. Keep sending it.

Those two habits alone will surface 80% of the scope problems you currently can't see, and they cost you an hour a week. The rest of the system — categories, change budgets, cost templates — you can layer on as the project demands it. What matters is that from now on, no request lives only in someone's memory.

If you want to see how we structure this into contracts and statements of work, our engagement models page has more on how we scope and price agency builds.