How to Write a Change Order That Protects You and Keeps Clients Happy

A change order is where scope creep gets formalized. A client asks for something outside the original agreement. You need to capture it, document the cost or timeline impact, and get them to agree.

Most agencies avoid change orders because they feel combative. You don't want to seem nickel-and-diming your client.

But a change order isn't combative - it's professional clarity. It says "Here's what you're asking for, here's what it costs or how long it takes, and here's my confirmation that you want it."

A good change order protects you from scope overages, ensures clients understand the cost of changes, and keeps everyone aligned.

When You Need a Change Order

Not every modification requires a change order. Distinguish between feedback and scope change.

Feedback is normal iteration. "Can you make the headline bigger?" That's a revision round.

A scope change is something new, bigger, or different from what was agreed. "Can you build an entire new feature we didn't discuss?" That's a scope change.

In your contract or brief, define your revision policy. "Two rounds of revisions are included in the agreed price.

Additional revisions are $X per round. Scope changes require a change order."

Once you've defined the policy, you can reference it when scope changes come up. "That's a great request - it's outside our original scope. Here's what that would cost/take in terms of timeline."

Some scope changes are small enough to just absorb. A client asks for a minor thing, you do it, no big deal. But if it's meaningful work, document it.

Create a Change Order Template

Having a template makes this faster and more consistent.

Here's a minimal template:

CHANGE ORDER

Project: [Project name] Date: [Date] Change order #: [Number]

WHAT'S CHANGING [Description of the change. Be specific about what you're adding, removing, or modifying]

REASON FOR CHANGE [Why is the client requesting this? Keep it brief - this is what they told you]

IMPACT ON TIMELINE Original timeline: [Date] New timeline: [New date] Days added: [Number]

IMPACT ON INVESTMENT Original investment: $[Amount] Additional investment: $[Amount] New total: $[Amount]

APPROVAL Client signature: ___________________ Date: _________

Agency signature: ___________________ Date: _________

Keep it simple. You're not trying to create a legal document - you're documenting agreement.

How to Present a Change Order

Most change orders fail not because of the request, but because of how you present them.

First, acknowledge the request. "I got your request to add [X feature]. I think that's a smart addition."

Then explain the impact. "Adding that feature will take about [X hours/days] of development work.

Given our current timeline, that pushes our launch date from [Date] to [New date]. Or we could keep the launch date and reduce [other deliverable]."

Give them options. Don't just tell them the change will delay the project. Offer choices.

Option 1: Accept the timeline change. "We can add this, and launch moves to [new date]."

Option 2: Accept the budget change. "We can keep the timeline and add this for an additional $[amount]."

Option 3: Defer the change. "We can do this in a Phase 2 after launch so we keep the timeline intact."

Option 4: Remove something. "We can add this and remove [lower-priority deliverable] to keep the timeline and budget."

Then ask: "Which works best for you?"

This frames it as a collaborative decision, not you presenting a bill.

Sample Change Order Communication

Here's what it might look like in an email:

"Hey [Client], thanks for sending over the request to add [feature]. We love the idea and I think it'll enhance the final product. Let me give you the impact:

Adding [feature] requires about 20 hours of development work. Our current launch timeline is [Date]. Adding this feature would push us to [New date] - about two weeks later.

Here are your options:

Add the feature, launch on [New date]
Add the feature for $3,000 additional investment, keep the [Original date] launch (we'd need to cut some lower-priority items)
Defer this feature to Phase 2 after launch
Skip this feature and launch on [Original date]

Let me know which direction you'd prefer, and I'll get a formal change order over for you to sign off on."

This is collaborative, clear, and it gives them control over the decision.

Document Everything

When they approve a change order, keep it organized.

File it with the project documentation. Reference it when you discuss the project later. If they claim they didn't approve the change, you have the signed change order.

Use change orders to manage stakeholder expectations too. If a team member approved a change without the decision-maker's buy-in, the change order catches that.

"Wait, did we actually approve this? I see the signature here but I didn't know about it."

Keep a running tally of changes. "We've approved three change orders so far, adding X days to the timeline." This helps everyone understand the cumulative impact.

Handling Pushback

Sometimes they push back on the change order. "I thought this was included" or "Can't you just do it?"

Be empathetic but firm. "I understand you expected it to be included. Looking back at the brief, [original scope] is what we scoped.

[This request] is new. I'm happy to do it - I just want to make sure we align on the impact."

If they really push, you have a few options:

Option 1: Absorb it. If it's not a huge ask and the relationship is valuable, you can say "You know what, I'll absorb this one." Don't make a habit of it.

Option 2: Offer a compromise. "I'll do half of this now, and the other half is a Phase 2."

Option 3: Stand firm. "I've quoted the impact.

If you want to move forward, here's what it costs/takes. If not, we keep the original scope."

When Clients Request Changes Constantly

If you're writing change orders weekly, there's a process problem.

Have a conversation. "I'm noticing we're requesting scope changes frequently.

That suggests either the original scope wasn't clear, or the project direction is evolving. Let's talk about how to prevent scope creep going forward."

Consider a "change order allowance." "Each month you're allowed one small change for free. Additional changes are documented and billed separately."

Or implement a freeze. "We're in execution phase.

I'm not accepting new change requests until we hit [milestone]. After that, we can assess what to add for Phase 2."

FAQ

What if the change is tiny - do I really need a change order? For truly tiny things (five minutes of work), you can skip it. But if it's anything more than that, document it. It adds up.

Should I charge for change orders, or is the documentation free? The documentation is free. You charge for the work involved in the change. The change order just communicates that.

What if they refuse to pay for a change order? Then they don't get the change. "I'm happy to do this, but it's outside scope. It either costs $X or we need to extend the timeline. Which works for you?"

Can I charge a fee just for the change order itself? Not unless it's a really complex change. You're not charging them for paperwork - you're charging them for work.

What if they approve a change order but then want to cancel it? Depends on how far you've gone. If you haven't started, you can cancel. If you've done work, they've paid for it.

Should every change be a formal change order or can some be informal? Formal change orders are better - they create documentation. But small changes can be informal if you note them. Keep a running list so you remember what changed.

What if they claim they didn't approve a change? This is why you get signed approval. "Here's the change order you signed on [date]. This is the version we implemented based on your approval."