The kickoff conversation that makes change orders feel normal.
Scope disputes aren't lost mid-project — they're lost at kickoff, when nobody set the rule. Here's the two-minute conversation, script included, that makes every future change order feel routine.
Every scope dispute has an origin story, and it's almost never the moment you'd expect. It isn't the Slack message where the client asked for "one quick thing." It isn't the invoice that landed six weeks later. It's a moment months earlier, at kickoff, when the agency had a clean opening to say "here's how we handle changes" — and said nothing.
That silence is understandable. Kickoff is the honeymoon. The contract just got signed, everyone's excited, and the last thing anyone wants to do is stand up in the first meeting and talk about billing disputes that haven't happened yet. It feels like starting a marriage by explaining the prenup. So agencies skip it, tell themselves they'll handle changes "as they come up," and walk straight into the trap: the first out-of-scope request arrives with no rule to point to, which means the rule has to be invented mid-project, under pressure, in the exact moment it looks most self-serving.
This piece is about that skipped conversation — why it matters more than the contract language it's supposed to duplicate, what to actually say, and what changes downstream when you say it.
The rule you invent mid-project always sounds like an excuse
Here's the mechanism worth understanding. When a client asks for something out of scope and you respond with "we'll need to price that as a change" — and it's the first time they're hearing that changes get priced — you're not stating a policy. You're improvising one. And from the client's side of the table, a policy announced at the moment it costs them money is indistinguishable from an excuse.
It doesn't matter that the statement of work technically covers it. Nobody remembers the SOW. Contracts are signed, filed, and forgotten; what people remember is what was said out loud. If the first spoken mention of change pricing arrives attached to a bill, the client's honest experience is that the rules changed mid-game. Their skepticism isn't bad faith — it's a reasonable reading of the sequence of events.
Now run the same moment with one difference: at kickoff, you spent two minutes explaining how change requests work. When the "quick favor" arrives and you respond with the process, you're not inventing anything. You're doing exactly what you said you'd do. The same sentence that sounded defensive now sounds reliable. Nothing about the process changed — only when the client first heard about it.
A change process introduced at kickoff is a professional standard. The same process introduced at the first invoice is an excuse.
That timing gap is the whole game. Scope disputes are won by whoever has the clearer record, but the record only stays friendly if the client knew, from day one, that a record was being kept.
Why the conversation works better than the contract
Agencies over-invest in contract language and under-invest in the spoken version of the same idea. The SOW gets a change-order clause drafted by a lawyer, dense enough that no client reads it, and the agency considers the topic handled. It isn't. A clause the client never absorbed provides legal cover but zero relational cover — and most scope disputes are settled relationally, long before anyone would dream of involving the contract.
The kickoff conversation does what the clause can't: it sets the client's expectations, not just your legal position. It tells them three things a contract never will:
- Changes are normal and welcome. You expect the project to evolve, and there's a path for that.
- The path is easy. They don't have to feel awkward about asking.
- Nothing gets built until they've seen the cost and said yes — which, framed correctly, is protection for them.
That third point is the one agencies consistently miss. A change process isn't a defensive wall you build against your client. It's the thing that guarantees they'll never open an invoice and find work they don't remember approving. The client who's been burned by a surprise bill — and most have — hears "nothing gets built until you approve the cost" as a feature, not a threat. You're not telling them the meter is running. You're telling them the meter is visible.
What to actually say: the two-minute script
Here's the version that works, roughly verbatim. It takes two minutes, and it belongs in the kickoff meeting, out loud, from whoever owns the relationship:
"One more thing before we wrap. During this project you'll almost certainly think of things you want that aren't in the scope we agreed. That's normal — it happens on every project, and honestly some of the best ideas show up mid-build. So here's how we handle it: when you want something new, you send it through a request link we'll give you. We'll come back within a day or two with what it costs and what it does to the timeline, in plain English. If you like the trade, you approve it and we build it. If you don't, you decline and nothing changes. Nothing gets built until you've seen the price and said yes — so you'll never get an invoice with a surprise on it."
Notice what the script does. It predicts the change request before it exists ("you'll almost certainly think of things"), which makes the eventual request feel anticipated rather than transgressive. It frames evolution as good ("some of the best ideas show up mid-build") so the client never feels punished for asking. It describes the process in one breath — request, price, approve, build — which is short enough to actually be remembered. And it ends on the client's protection, not yours.
Then it goes two more places. Put a one-line version in the proposal, above the pricing table, where it reads as transparency. Put it again in the kickoff follow-up email, with the actual request link, so the path exists before anyone needs it. Three light touches — spoken, written, linked — and the process is part of the project's furniture before the first "can you just" ever arrives.
What changes downstream
The payoff comes four to eight weeks later, at the moment nobody owns — when the client drops a "quick" request into a thread. On a project without the kickoff conversation, that moment is a fork between two bad options: absorb the work silently, or improvise a pricing conversation that lands as an ambush. Both options are how agencies end up donating thousands of dollars a month in unbilled work.
On a project with the conversation, the moment is boring. "Great idea — send it through the request link and we'll price it this week." No tension, no improvisation, no relationship tax. The client does it, because they were told at kickoff this is how it works, and because the path is genuinely easier than negotiating in a thread. The first change request sets the pattern, the pattern becomes the culture of the project, and by the third request nobody thinks about it at all. Routine is the goal. Scope changes should be the least dramatic thing that happens on a project.
There's a compounding effect across clients, too. The agencies that handle this well don't have tougher contracts or braver project managers. They have a script, said at every kickoff, so consistently that no individual team member ever has to decide whether this client, this time, is worth the awkwardness. The conversation stops being a judgment call and becomes an SOP — which is the only way anything survives contact with a busy studio.
Frequently asked questions
Doesn't this risk souring the kickoff mood?
Only if it's framed as policy. Framed as "here's how we make sure you never get a surprise invoice," it lands as competence. Clients don't resent process — they resent process they learn about retroactively.
What if the client ignores the process and asks in Slack anyway?
They will, and it's fine. The kickoff conversation isn't there to stop informal asks — it's there so that redirecting one ("love it — drop it in the request link so we can price it") reads as consistency instead of deflection. The redirect only works if the destination was established first.
We're mid-project and never had this conversation. Too late?
No, but don't retrofit it silently. Name it: "We're tightening up how we handle change requests so nothing surprises you on an invoice — from here on, here's the flow." A process introduced openly mid-project beats one introduced implicitly on a bill.