Change requests without the scope fight: a workflow that works

Scope fights rarely begin with a client trying to be difficult. They begin with an unspoken change: a new audience, an extra format, a new approver, a revised launch date, or one more round of “small” edits.

The agency sees the impact. The client sees a reasonable request. The gap grows until someone says “that’s out of scope” and the conversation becomes defensive.

A change-request workflow makes the trade-off visible early. It turns a vague disagreement into a decision about outcome, time, cost, risk, and ownership.

Start with the outcome

Do not begin with the phrase “this is out of scope.” Begin with what the client wants to achieve. “You want the campaign to work for the partner audience as well as the launch audience” is more useful than “you added another audience.”

Then restate the original outcome and the new outcome. Sometimes the new request replaces the old one. Sometimes it adds to it. Those are different decisions.

Show the impact in five lines

For each request, record:

1. What changes: the deliverable, decision, dependency, or owner.
2. Why it matters: the client outcome behind the request.
3. Impact: effort, timing, cost, quality, risk, or other work displaced.
4. Options: what can be added, removed, delayed, or simplified.
5. Decision needed: who approves the new plan and by when.

This is enough detail for most changes. It keeps the conversation about choices rather than blame.

Offer three kinds of option

Add

Keep the original plan and add the new request. This protects the first outcome but usually changes time, budget, or both.

Swap

Do the new thing instead of something that was planned. This keeps the constraint visible and helps the client choose what matters more.

Stage

Deliver the original outcome now and put the change into a named next phase. This is often the best answer when the request is valuable but the launch cannot move.

Avoid offering a fake fourth option where the team absorbs the work silently. That teaches the client that the plan is not real and leaves the agency carrying invisible cost.

Use a decision record, not a long thread

When the client chooses, write the decision in one place: what was approved, what moved, the new timing, the new fee if any, and who owns the next step. Link the request to the affected deliverable or project record.

The record is not bureaucracy. It is protection for both sides. The client can see what they bought and the agency can see what it promised.

Make small changes easy to handle

Not every small edit needs a formal proposal. Set a threshold: changes under a defined amount of time can be logged in the project; changes that affect dates, deliverables, dependencies, or external commitments use the full workflow.

The threshold should be clear to the team and visible to the client. The point is consistent treatment, not making a two-minute correction feel like a procurement event.

Put scope where the work happens

Keep the scope, comments, approvals, versions, and change decisions close to the files. When a request arrives in a separate message, bring the useful part back into the project record before acting on it.

Shared documents, comments, and version history make the decision legible to everyone who joins later. A client does not need to know which tool stores the record; they do need to know which version and decision are current.

The sentence that keeps the relationship healthy

“We can do that. It changes X, so here are the three ways to make it fit.”

That sentence acknowledges the request, names the constraint, and gives the client agency. A good change workflow is not a wall around the scope. It is a clear way to choose what the work becomes next.