The Change Order Email: Write It for the Person Who Approves the Money
The reply you are about to write is addressed to the wrong person.
The client who asked for the change is very often not the client who approves the spend. The marketing manager asks for a second product group on the home page; the person who can say yes to $1,400 is their director, who never saw the thread, does not remember what was in the original scope, and is deciding in the ninety seconds before another meeting.
So a change order email is not a conversation. It is a short document that has to survive being forwarded without you in it. Almost every approval that sits untouched for a week was written for the reader in front of you rather than the one who signs.
That is a different job from the two things either side of it. The reply script handles the moment the request lands, before anything has a number on it. The change order itself is the document that gets signed and kept. The email in between has one task: carry a decision to somebody who was not in the room.
Put the decision in the first two lines
The most common structural mistake is burying the ask. A paragraph of thanks, a paragraph of context, a paragraph about the work — and the actual request for approval in the last sentence, where a skimming reader will not reach it.
Open with the decision and the reason it exists:
Thanks for the extra checkout fields — happy to build them. They fall outside the approved scope, so here is a change order to approve before we start.
Two sentences, and a forwarded reader already knows what they are being asked and why. Everything after that is supporting material for a decision they have already been told they need to make.
Note what this opening does not do. It does not apologise, and it does not argue. A scope boundary stated as a fact reads as process; the same boundary defended reads as a grievance, and a grievance is much harder to forward to a director.
The four facts an approver needs
An approver who was not in the conversation needs exactly four things, and a fifth fact only you can supply.
What changed, described by its result. Not the method. "Add custom field logic and validation to the checkout" is what you will build; "customers can choose a delivery window at checkout" is what the approver is buying. Lead with the second.
Why it is outside the approved scope. A pointer, not a case. "The approved scope covers standard checkout setup" is neutral and checkable. It also lets the approver verify you without asking you.
What it costs. A number, a range, or the method — but something. An email that raises a cost and does not name it guarantees a reply asking for the number, which is a round trip you paid for with a day.
What it does to the date. State this even when the answer is none, because "no change to the launch date" is itself the fact that unlocks a fast yes. A change can add no fee and still move a milestone, or hold the date and cost more precisely because it has to be built in parallel.
The fifth is the assumptions. If the price depends on something you have not seen yet, say so in the same breath rather than in a footnote: this assumes the existing payment provider supports it; we can confirm after a two-hour review. An estimate with its condition attached survives being wrong. One without it becomes a number you quoted.
Getting from the request to a defensible figure is its own problem, and it is the one most freelancers guess at — how to price a scope creep request covers the arithmetic this email is reporting.
Give the approval more than one door
A change order email with a single yes/no is an ultimatum wearing a polite voice. It also loses deals it did not need to lose, because an approver who cannot authorise the full amount today has nowhere to go except no.
Name the alternatives you would actually accept:
- approve it now as scoped
- approve a smaller version — the field logic without the confirmation-email rework
- move it to a later phase and keep the current date
- swap it for something already in scope that matters less
- leave the scope as it is
Five doors, and four of them keep the project moving. This is not softening the ask; it is the difference between a decision and a refusal. An approver who picks the reduced version has still approved a change order.
The template
Subject lines that survive a forward name the project and the action:
- Change order approval needed — [project name]
- Approval requested: [one-line change summary]
- [Project name] — new scope item, approval by [date]
The body:
Hi [Client Name],
Thanks for the request to [one line, in their words]. Happy to build it.
It falls outside the approved scope for [project name], so here is a
change order to approve before we schedule the work.
WHAT CHANGES
[One plain sentence describing the result the client will see.]
WHY IT NEEDS A CHANGE ORDER
The approved scope covers [X]. This adds [Y], which is not in
Section [N] of the agreement.
COST
$[amount], [fixed fee / estimate at $X per hour, capped at $Y].
Assumes [condition, if any].
TIMELINE
Adds [N] business days. New delivery date: [date].
(Or: no change to the current delivery date.)
TO APPROVE
Reply "approved" or sign the attached change order by [date] and we
will schedule it. If the budget is the constraint, I can also do
[smaller version] for $[amount], or hold this for [later phase] —
either keeps the current date.
Best,
[Your Name]Attach the document. The email carries the decision; the change order carries the signature, and conflating the two is why some approvals are agreed in a thread and then cannot be found six months later. If you want the signature sequenced properly, the e-signature change order workflow covers which party signs first and why the order matters.
After the yes: the confirmation email
The email most people skip is the one that costs the least and does the most.
Confirming approval of the change order for the checkout delivery windows. We are adding it to the plan, the new delivery date is 14 October, and work starts once the countersigned copy is back.
One minute, and it is the only artifact proving both sides agreed on the same thing. An approval that exists as the word "yes" in the middle of a reply chain is a record nobody will find when it matters. A confirmation email is a record either side can forward, which is exactly the property you want the day somebody asks why the launch moved.
Where this stalls anyway
Worth being honest about the limit: a well-structured email does not fix a client who has no budget, and it does not rescue a project whose original scope was too vague to point at. If you cannot name the clause the request falls outside, the problem is upstream of the email and no template closes it.
The other failure is not the writing at all. It is the moment on a Thursday when three projects are live and producing this email properly costs more attention than the change appears to be worth — so it becomes a "sure, no problem" and never gets written. That is the step worth removing, and it is the narrow thing Stria does: you forward the client's message, it checks the request against the scope you locked, and it quotes the clause the request falls outside so the email is written from the record rather than from memory, with the priced change order drafted alongside it. It does not connect to your inbox and it does not send anything on its own — you choose what to forward and you approve what goes out.
Detection is on the free plan. You can see the mechanics on a pasted excerpt with no account at getstria.com/scope-check, or start free for the full loop.
Frequently asked questions
What should a change order email include?
The decision you need in the first two lines, the requested change described by its result rather than its method, a pointer to the clause it falls outside, the fee, the effect on the delivery date, and one named way to approve it. Attach or link the change order document itself — the email carries the decision, the document carries the signature.
Why do change order emails go unanswered?
Usually because they were written for the person who asked rather than the person who pays. The requester forwards it to whoever holds the budget, and that reader has no context, no memory of the original scope, and no patience for a thread. An email that only makes sense if you were in the conversation stalls at the forward.
Should a change order email include the timeline as well as the price?
Yes, and state it even when the answer is none. A change can add no fee and still move a launch date, or hold the date and cost more because it has to be done in parallel. Naming both closes the two questions an approver would otherwise have to come back and ask, which is a round trip that costs more than the change.
What should you send after the client approves?
A short confirmation that restates what was approved, the new date, and what happens next. It takes a minute and it is the only artifact that proves the two sides agreed on the same thing. Approval buried in a reply chain is a record nobody can find later; a confirmation email is one both sides can forward.
How does Stria help with the change order email?
You forward the client's message and Stria checks it against the scope you locked, quoting the clause it falls outside so the email is written from the record instead of from memory, and drafting the priced change order alongside it. Detection is on the free plan. Stria does not connect to your inbox and does not send anything on its own.