Change Requests Without Tears: A Playbook for Scope Drift With Non-Technical Clients

Every agency project has a moment where a client says "just one small thing" and a senior engineer's Slack goes quiet. That small thing is almost never small, and how you handle the next 48 hours decides whether the project ends profitably or in a passive-aggressive Notion doc. This is the playbook we use at 72Technologies when scope moves — especially with non-technical clients who genuinely don't know they're asking for a rewrite.

Why Scope Drift Isn't a Client Problem

It's tempting to frame scope creep as clients behaving badly. In our experience, it almost never is. Non-technical clients don't have a mental model of what "add a filter" costs. To them, it's a checkbox on a screen. To you, it's a new index, a migration, a query rewrite, and probably a conversation about pagination.

The drift is a communication failure, not a moral failure. Which means it's fixable with process — not with harder contracts or angrier project managers.

The Three Kinds of Change Requests

Before you can price a change, you have to classify it. We use three buckets internally:

• Clarification: The spec was ambiguous and the client is telling you what they meant. This is on you. Absorb it.
• Refinement: The spec was clear, the build matches it, but seeing the working thing revealed a better version. Negotiable.
• Expansion: New functionality that wasn't discussed. Always billable, always a change order.

Half the arguments about scope happen because both sides think they're talking about a different bucket. Naming the bucket out loud, in the meeting, defuses about 70% of the tension.

Build the Change Request Muscle Early

The worst time to introduce a change request process is when you desperately need one. If change orders show up for the first time in week six, they read as punishment. If they show up in week one for something trivial — even something you absorb for free — they read as normal.

On kickoff, we do a fake change request in front of the client. Something like: "Hey, we noticed the mockup shows a CSV export we didn't scope. We're going to log that as CR-001 and come back to you with an estimate. It might be small, it might not." Then we log it, price it, send it, and often waive it.

The client learns three things at once:

1. Changes are expected and welcome.
2. Every change has a cost, even if you don't charge it.
3. There's a paper trail.

By the time a real, expensive change comes up in week five, the ritual is boring. Boring is what you want.

The Anatomy of a Change Order That Gets Signed

A change order that reads like a legal threat gets stalled. A change order that reads like a helpful summary gets signed same-day. The difference is mostly tone and structure.

Here's the template we use:

# CR-014: Multi-currency support on checkout

**Requested by:** Sarah (client) on 12 Mar
**Type:** Expansion
**Status:** Awaiting approval

## What you asked for
Show prices in the customer's local currency at checkout,
with USD as the settlement currency.

## What this actually involves
- Currency detection from IP + user preference override
- Live FX rates (we recommend Open Exchange Rates)
- Rounding rules per currency (JPY has no decimals, etc.)
- Updated invoice PDF template
- QA across 6 currencies

## What it does NOT include
- Charging in local currency (that's a payments integration)
- Historical price display for existing orders

## Effort & timing
- 5–7 engineering days
- Pushes launch from 4 Apr to 11 Apr
- Cost: $X,XXX at agreed T&M rate

## Decision needed by
15 Mar, to avoid launch slip beyond 11 Apr

Notice what's doing the work: the "what it does NOT include" section, and the explicit decision deadline. Non-technical clients don't stall because they're indecisive — they stall because they're afraid of missing something. Tell them what you're not building and they can decide in an hour.

Price the Change, Not the Task

One mistake juniors make: pricing a change order by the hours of coding it takes. A change order includes discovery, QA, deployment risk, context switching, and — the big one — the schedule impact on everything else. A five-day feature dropped into week six of an eight-week build is not a five-day feature. It's a five-day feature plus rework of anything that assumed it wasn't there.

We usually price expansion CRs at 1.3–1.6x the raw estimate to reflect this. We tell clients that ratio exists and why. They respect it more than a suspiciously round number.

The Conversation Nobody Wants to Have

Sometimes a client keeps asking for "small tweaks" that individually are absorbable but collectively have eaten your margin. The temptation is to keep quiet and hope. Don't.

Schedule a 20-minute call. Not an email. Not Slack. A call. Say something like:

"I want to flag something before it becomes a problem. Since kickoff, we've absorbed about 14 small changes without billing them because each one felt minor. Added up, that's roughly two weeks of engineering. I'm not asking for that back — I'm telling you so we can agree on how we handle the next batch."

This works because you're not asking for money. You're establishing a fact. Nine times out of ten the client is embarrassed and immediately more disciplined. The tenth time, you've surfaced a mismatch that was going to blow up anyway — better in week four than week ten.

When to Absorb, When to Bill

Our internal rule of thumb:

• Absorb if it's under half a day, it's a clarification, or the relationship is strategic and early.
• Bill if it's over a day, it's genuinely new scope, or you're already trending over on budget.
• Trade if the client is anxious about cost. Offer to swap the new thing for something already-scoped they care less about. This preserves the budget and makes them feel in control.

The trade move is underrated. It reframes the conversation from "more money" to "same money, different priorities," which is a much easier yes.

Fixed-Price Projects Need a Different Muscle

On T&M, change orders are a mild administrative overhead. On fixed-price, they're existential. A fixed-price project without a working change control process is not a project — it's a slow-motion loss.

If you're running fixed-price, your contract needs three things, minimum:

1. A named change control process with a defined turnaround (we use 48 hours to respond, 5 business days for client decision).
2. A minimum billable unit for changes (we use half a day) so clients don't nickel-and-dime.
3. An explicit statement that undecided CRs pause the timeline, not the budget.

That third one is what saves you. If a client sits on CR-014 for two weeks, your delivery date moves two weeks. Otherwise you're eating the schedule risk of their indecision, which is insane. If you're wrestling with which model to use in the first place, our take on pricing models for agency work covers the tradeoffs in more depth.

The Retro Question That Prevents Next Time

At the end of every project, we ask one question in the internal retro: which change requests should have been in the original scope? Not which ones were annoying — which ones were predictable.

Usually two or three CRs per project were things a more experienced discovery would have caught. Multi-currency, admin roles, email deliverability, timezone handling, soft deletes, audit logs. These come up on almost every serious build. If they're not in your discovery checklist, they will become change orders — and change orders are worse than scope because they cost trust as well as money.

Over a year, this retro question is what upgrades your discovery process from "we asked good questions" to "we have a written list of things every build of this type needs to answer." That list is the actual asset. If discovery is the weak link for you, we've written more on how we run scoping and delivery for exactly this reason.

Where we'd start

If you're an agency reading this and feeling seen: don't rewrite your contracts this week. Do one thing. Take your current active project and log every change that's happened since kickoff, whether you billed for it or not. Classify each one as clarification, refinement, or expansion. Then look at the ratio and the total absorbed hours.

That spreadsheet, shown to the client in a friendly Friday call, will do more for your margin and your relationship than any contract clause. Start there. The process comes after the honesty.