How to run a change order conversation without damaging the relationship

In TWINJAM's 2026 survey of 214 agency project managers, 68% said they avoid change order conversations when they lack objective evidence that a request is out of scope. That number matches what we hear in onboarding calls. PMs are not afraid of clients. They are afraid of being wrong in front of clients, and of turning a good relationship into a debate about contract wording.

The answer is not a script that makes PMs braver. It is a process that makes them certain before they speak, and a structure for the conversation that keeps it about the client's goals rather than the agency's margin.

The single biggest factor in how a change order lands is when it is raised. Before anyone has started, a change order is a menu: the client chooses whether the new thing is worth the money. After the work is delivered, the same document is a bill for something they assumed was free.

• Same day as the request: ideal. Acknowledge it warmly and say you will come back with options.
• Within the sprint: fine, as long as nobody has started building.
• After delivery: possible, but expect to absorb some of it, and change the process so it does not happen again.

This is why monitoring matters more than drafting. A PM can write a perfect change order, but if they learn about the request three weeks later from a pull request, the window has already closed.

1. The evidence: the client's original message, quoted exactly, and the SOW clause it touches, with section number. If you cannot point to the clause, you are not ready.
2. The estimate: hours by role and the price, plus the effect on the timeline. Ranges are fine if you say what would narrow them.
3. The options: at least two. Typically add it with budget, swap it for something already planned, or move it to a later phase.

Having options is what keeps the conversation from becoming a yes-or-no standoff. Clients who are offered a choice almost always pick one. Clients who are told no tend to escalate.

Whether it is a Slack message, an email or a call, the structure is the same: goal, clause, options, next step. Here is how that sounds in a chat reply to a client who asked for a new admin report.

Notice what is not there. No apology, no "unfortunately", no reference to the agency's margin and no implication that the client did something wrong by asking. The clause is mentioned once, as a fact. The rest is about their goal and their choice.

"I assumed that was included."

This is the most common response and usually sincere. Do not argue about what they assumed. Agree that it is a reasonable thing to want, show the clause, and move straight to options. If the SOW really is ambiguous, say so and offer to split the cost. Conceding a genuine ambiguity buys a lot of trust for the next conversation.

"It's only a small change."

Share the breakdown, not just the total. Clients see the build time; they do not see review, QA, regression and deployment. A short line such as "the code is about two hours, testing it across the checkout flow is the rest" usually resolves it. If it truly is small, use your monthly allowance or include it and log it as included.

"Your team already said yes."

This one is the agency's fault, not the client's, and it should be treated that way. Honor anything that was explicitly promised, then agree a rule for the future: "from now on, anything new comes through Priya so we can check the timeline before anyone commits." Then fix the internal process so developers route requests instead of accepting them.

Larger changes, anything that moves a launch date or touches more than a week of effort, deserve a short call rather than a message. Send the evidence and the options in writing beforehand so the client is not hearing numbers for the first time while you watch their face. Keep the call to fifteen minutes and run it in the same order: restate what they want and why it matters, confirm where the SOW stands, walk through the options, and agree who decides and by when.

Two habits help. First, let the client talk first about the goal; you will often learn that a smaller version solves the real problem. Second, write the summary yourself within the hour, with the option they chose and the next step. The written summary, not the call, is what keeps the decision from drifting a week later.

Get a signature before work starts, even for small amounts. An approval in Slack is better than nothing, but a signed change order with the clause reference, hours and price is what finance will need at invoice time and what the next PM will need if the project changes hands.

• Update the project plan and the client-facing timeline the same day.
• Link the change order to the tickets it created, so the hours are tracked against it.
• Add it to the monthly scope summary, alongside items you chose to absorb.

Change orders done this way stop being awkward fairly quickly. After two or three, clients start asking "is this in scope?" before they ask for things, which is the best outcome of all.