The Change Request Conversation: A Script for Non-Technical Clients

Every agency loses money the same way: not on the projects that go sideways in week one, but on the ones that quietly bleed through six weeks of "just one small thing." The fix isn't a tighter contract. It's a better conversation — one most engineers and PMs have never been taught to run.

This is the script we use, almost word for word, when a non-technical client asks for something that wasn't in the original scope. It works for fixed-bid, capped T&M, and even retainers where hours are tracked loosely.

Why "just track it as a change request" isn't enough

Most agencies have a change request (CR) process on paper. There's a template, a sign-off field, maybe a Notion page. It rarely gets used because the actual moment of a change request is socially awkward.

The client is excited. They've just had an idea in the shower. They're paying you a lot of money. And now you, the vendor, have to say: that costs extra. If your PM doesn't have a script, one of three bad things happens:

• They say yes and absorb it (margin dies)
• They say no and the client feels nickel-and-dimed (relationship dies)
• They say "let me check with the team" and disappear for four days (trust dies)

A script doesn't make the conversation robotic. It makes it predictable, which is what both sides actually want.

The three things a client is really asking

When a non-technical client says "can we also add X?", they're usually asking one of three different questions, and your response should depend on which one:

1. Is this technically possible? (They want a feasibility check)
2. Is this small enough that you'll throw it in? (They're testing the boundary)
3. How much would this cost and when could I have it? (They're genuinely budgeting)

Answering question 3 when they asked question 1 is how you accidentally commit to building something for free.

The script, in five moves

Here's the structure. We'll break each move down after.

1. ACKNOWLEDGE the request as legitimate
2. CLASSIFY it out loud (in-scope / change / new project)
3. ESTIMATE in ranges, not points
4. OFFER a decision, not a quote
5. WRITE it down before the call ends

Move 1: Acknowledge

Don't argue with the idea. Don't immediately reach for the SOW. The client needs to feel heard before they can hear you.

"That's a good catch — I can see why that would be useful once users are actually in the dashboard."

That's it. One sentence. You haven't agreed to build it. You've agreed it's a reasonable thing to want.

Move 2: Classify out loud

This is the move most teams skip, and it's the one that sets up everything else. You name the category of the request in front of the client, so the conversation has a shared frame.

"Let me think about where this fits. We scoped the dashboard to show order history and basic filters. What you're describing — the saved filter views with email alerts — that's a new capability, not a tweak to an existing one. So in our world that's a change request rather than something already in the budget."

Three things just happened:

• You distinguished "tweak" from "new capability" using their language
• You named it a change request without making it sound punitive
• You implied a process exists, which makes the next step feel normal

Move 3: Estimate in ranges

Never quote a precise number on a call. You will either lowball it (and eat the difference) or sandbag it (and look greedy). Use ranges, and tie them to the things that drive the range.

"Rough order of magnitude, something like that is usually two to five days of work depending on how the alerts are triggered — whether it's real-time or a daily digest changes the cost meaningfully. I'll send a proper estimate by Thursday."

The range does two jobs. It gives the client a sense of whether to keep talking (a 2–5 day item is a different conversation from a 4–6 week item). And it educates them on what makes it expensive, so the eventual number doesn't feel arbitrary.

Move 4: Offer a decision, not a quote

This is the inversion that changes everything. Instead of "here's the price, what do you think," you frame three options and let them pick.

"You've got three reasonable paths here. One: we add this as a CR and push the launch by about a week. Two: we swap it in for something already in scope — the CSV export was lower priority, we could trade. Three: we ship v1 without it and add it in the next phase once you've seen real usage. Which feels right?"

Clients who feel cornered by a quote will haggle. Clients who feel like they're choosing between three sensible options will pick one and move on. The trade option (#2) is especially powerful — it reframes scope as a fixed budget of effort rather than an infinite menu.

Move 5: Write it down before the call ends

The single highest-leverage habit in agency work. Before the call ends, you summarise the decision in the chat or send a follow-up within the hour.

"Quick recap so I don't lose it: you're going with option 2 — we'll swap the CSV export for saved filter views, no change to budget or timeline. I'll update the scope doc this afternoon and send it for sign-off."

If you don't do this, the client will remember a different version of the conversation in three weeks. Not because they're dishonest — because human memory is bad and software projects have a lot of conversations.

Where the script fails

The script assumes a few things that aren't always true. Worth being honest about.

It assumes you have a scope document. If your SOW is two paragraphs in an email, you have no baseline to classify against. Everything is in-scope or out-of-scope by vibe. Before you worry about CRs, fix the scope process.

It assumes the client can make decisions. If the person on the call has to check with three other stakeholders, ranges and options just stall. In that case, you need to send the three options in writing and let the stakeholder group argue among themselves.

It assumes a reasonable client. Some clients will use every CR conversation as a negotiation. For those, the script still works — but you also need a CR log that gets reviewed at every weekly status meeting, so the cumulative cost of "small things" is visible.

A note on the small ones

Not every request needs the full five moves. If a client asks to change a button colour, just change it. The rule of thumb we use: if it's under 30 minutes and doesn't change behaviour, absorb it cheerfully. If it's over 30 minutes or changes how the system works, run the script.

This isn't generosity — it's economics. The overhead of formally tracking a 15-minute CR costs more than the CR itself, and clients remember the small free things more than they remember the big invoiced ones.

What this looks like in your tooling

The script lives in conversations, but it needs supporting infrastructure. The minimum:

• A scope document that's specific enough to argue with (user stories, not bullet points)
• A CR log visible to the client, with status (proposed / estimated / approved / rejected / done)
• A weekly status email or meeting where the CR log is reviewed
• A budget tracker the client can see, even if it's a simple spreadsheet

Notice that none of these require fancy software. We've shipped this on Linear, on Notion, on a shared Google Sheet, and once memorably on a printed-out kanban board taped to a wall. The tool doesn't matter. The visibility does.

Where we'd start

If you've never run this script, don't try to roll it out across every project on Monday. Pick the next change request conversation you have to run and try just two moves: classify out loud and offer a decision, not a quote. Those two alone will shift the dynamic more than any contract clause you could write.

Then, after the call, send the written recap. Do that three times in a row with the same client and you'll notice something quiet but important: they start framing their own requests the same way. "I know this is probably a CR, but…" That's the moment you've won. The script stops being something you run on clients and becomes the shared language of the project.