A change order is a written amendment to an agreed scope that records what is being added, what it costs, and how it moves the timeline - approved before the work starts. The process is four steps: the client asks for something outside scope, you write up the change with a price and a date impact, the client approves in writing, then the work proceeds. Agencies avoid raising change orders because they fear the relationship cost, but the opposite is true: a client who approved a number in advance is far less damaged than one who is surprised by an invoice.
Every agency has a version of this conversation. The client asks for something small. It is genuinely small. Raising a change order over it feels petty, and the relationship matters more than two hours, so you absorb it.
Then it happens eleven more times.
The problem was never any individual request. It was that the first "yes, of course" established that requests outside scope are free, and every subsequent one is now measured against that precedent. This guide covers what a change order actually is, the four-step process, how to raise one without damaging the relationship, and the specific mistakes that make change orders feel adversarial when they should be routine.
What a change order is
A change order is a mini-contract that amends the original statement of work to add, remove, or modify deliverables, timelines, or costs. Holdings' agency glossary puts the mechanics simply: the client requests something new, the account manager writes up what is being added along with the additional cost and the timeline impact, the client approves in writing, and the work proceeds.
It is worth being precise about what separates it from the two documents around it:
- The contract governs the legal relationship - liability, IP, payment terms, termination.
- The SOW defines this project: deliverables, milestones, price, and what is excluded.
- The change order amends the SOW. It does not touch the contract.
That last point is what makes change orders routine rather than dramatic. Nobody is renegotiating the relationship. You are updating one line of a document both sides already agreed to.
Why agencies avoid them, and why that reasoning is backwards
The stated reason is always relationship risk: raising a change order feels like nickel-and-diming, and the client might resent it.
The unstated reason is usually that raising one is work - someone has to price it, write it, send it, and chase the approval - and absorbing two hours is faster than an hour of admin.
Both collapse under examination.
On the relationship: the damage is not done by the change order. It is done by the invoice a client did not expect, or by the delivery date that slipped without anyone saying why. A client who approved £800 and three extra days in week two is a client who made a decision. A client who discovers both at the end is a client who was managed badly, and they are right to feel that way.
On the admin: the two hours you absorb this time set the price of every future request at zero. Absorbing is not the cheap option; it is the option whose cost arrives later and larger.
There is also a straightforward legal dimension. Legal GPS's guide to client scope changes makes the point that written approval is what makes a revised scope and fee enforceable - the same way a signature does on the original contract. A verbally agreed change is, in a dispute, an unagreed change.
The four-step process
Step 1: Recognise it
The hardest step, because out-of-scope work rarely announces itself. It arrives as "quick", "small", or "while you're in there".
The practical test is not size, it is whether the request appears in the SOW. If a reasonable person reading the scope document would not expect this work to be included, it is a change - regardless of how long it takes. A ten-minute request that is outside scope is still outside scope; you may well choose not to charge for it, but that should be a decision, not an accident.
This is where a scope document with explicit exclusions earns its keep. A scope that lists only what is included leaves everything unlisted ambiguous, and ambiguity always resolves in favour of the person asking. Smartsheet's guide to writing a statement of work covers the structure; the exclusions section is the one most often skipped and the one that does most of the work here.
Step 2: Write it up
A change order needs five things and nothing else:
- What is being added or changed, described concretely enough that both sides would recognise it later.
- Why - usually a one-line reference to the request.
- The cost, priced the same way the original scope was priced.
- The timeline impact, stated as a new date rather than "adds a few days".
- What happens if it is not approved - normally that the original scope proceeds unchanged.
Keep it to one page. A change order that reads like a contract invites a contract-length review, and the review is where momentum dies.
Step 3: Give a real choice
This is the step that determines whether change orders feel collaborative or extractive, and most agencies skip it.
Do not present a change order as a bill. Present it as three options:
- Approve it - here is the cost and the new date.
- Defer it - it goes into a phase two, and the current scope ships on time.
- Trade it - swap it for something of similar size already in scope.
The trade option is the one clients remember. It says the constraint is real capacity rather than an opportunity to charge more, and it very often produces a better outcome, because the thing they want now is frequently more valuable than something scoped three months ago.
Step 4: Get it in writing, then start
Written approval before work begins. Not after, and not "we'll paper it later" - later is after the work is done, when the client's incentive to approve has evaporated and yours to chase has too.
Email approval is usually sufficient for a change order amending an existing signed SOW. What matters is that it is unambiguous and retrievable, not that it is notarised.
Pricing a change order
Three rules, in order of how often they are broken.
Price it the way you priced the original scope. If the project was fixed-fee, price the change fixed-fee. Switching to hourly for changes reads as a hedge, and it invites the client to audit your hours on something they cannot verify.
Do not discount it to soften it. A change order at 50% "because we value the relationship" tells the client your prices are negotiable, which is a lesson they will apply to the next proposal. If you want to give something away, give the whole thing away as an explicit goodwill gesture with the full value shown and zeroed - the number stays visible, and it does not reset your rate.
Include the coordination cost. A two-hour change is rarely two hours. It is a conversation, a re-plan, a re-test, and a re-review. Pricing only the visible work is how agencies end up losing money on change orders they did raise.
The mistakes that make change orders adversarial
Raising the first one in month three. If a project runs for two months with everything absorbed and then the fourth request produces a change order, the client experiences it as a policy change. Raise the first small one early, so the process is established while the stakes are low.
Batching them. Five changes presented together at the end of a month reads as a bill for things the client thought were free. Individually, at the time, each is a decision. Together, retrospectively, it is a dispute.
Writing them defensively. A change order full of contractual language telegraphs that you expect an argument, and clients respond in kind. Plain language, one page, three options.
Having no scope to change. A change order is an amendment. If the original scope was vague, there is nothing to amend and nothing to point at - which is why change control is downstream of writing a proper SOW and why the two problems are really one problem.
Not tracking the cumulative picture. Six approved change orders on a project that was scoped for eight weeks means the project is not the project any more. Someone should be looking at the total, because at some point the right answer is not another change order - it is a conversation about re-scoping the engagement.
Making the process light enough to actually use
The reason most change orders never get raised is not principle. It is friction. If raising one takes forty minutes and an awkward conversation, absorbing two hours of work is genuinely the rational choice in the moment - and that calculation is what quietly destroys margin over a year.
So the design goal is not rigour. It is making the change order faster than absorbing the work.
A one-page template, pre-written. Five fields, filled in five minutes. Anything longer will lose to the path of least resistance.
A standing rate for small changes. Agreeing a hourly or half-day rate for out-of-scope work at kickoff removes the need to price each one from scratch. The change order then just says what and how long.
A threshold below which you do not bother. Genuinely useful. Anything under, say, thirty minutes gets absorbed without ceremony and without precedent-setting, because the administrative cost exceeds the value. Naming the threshold publicly - "anything under half an hour we just do" - is generous, cheap, and it makes the boundary above it much easier to hold.
Delegated authority to raise one. If only the founder can issue a change order, they will not get raised. The delivery lead should be able to issue anything below an agreed value without checking.
Email approval accepted. Requiring a signature for an amendment to an already-signed SOW adds days and deters use.
What to do about the ones you already absorbed
Most agencies read this while carrying a project that has taken on eleven unbilled requests. The retrospective conversation is different from the preventive one and it is very doable.
Assemble the list before saying anything. Date, request, who asked, hours taken. Feeling is a position the client can dispute; a list is not.
Own the delay explicitly. "I should have raised this at the third or fourth one" removes the accusatory edge and is also true. Clients respond to this far better than agencies expect, because they are usually unaware any of it was out of scope.
Propose a settlement, not an invoice. Offer to treat the accumulated work as a single change order, and consider discounting it explicitly as goodwill while showing the full value. Showing the number and zeroing part of it protects your rate; quietly absorbing it teaches the client that out-of-scope work is free.
Change the process going forward in the same conversation. This is what stops it recurring, and it is much easier to agree in the moment when the client has just seen the scale of what accumulated.
Our guide to difficult client conversations has the full wording for this.
The change order and the estimate
One subtlety worth naming, because it catches people out.
A change order should carry its own estimate, and that estimate should include the coordination cost, not just the visible work. A two-hour change is rarely two hours: it is a conversation, a re-plan, a rebuild of something adjacent, a re-test, and a second review round.
Agencies that price only the obvious work end up losing money on the change orders they did raise, which is a particularly demoralising outcome - the discipline was applied and the margin still went.
A practical rule: price the change at the same effective rate as the original scope, and apply the same buffer. If your project estimates carry a 20% contingency, so should your change orders. There is no reason a mid-project change would be more predictable than the original work; if anything it is less, because it lands in an environment that is already built.
The four sentences that do the work
Most of the difficulty in change control is not process design. It is the moment in a call or a message when a request arrives and you have three seconds to respond.
Four sentences, worth having ready:
For a request in a meeting: "That is a good idea and it is outside what we scoped - let me put a quick estimate together so you can decide whether it is worth it." This does three things at once: it validates the idea, names the boundary neutrally, and hands the decision to them rather than making it a refusal.
For a request in writing: "Happy to do that. It is about four hours, which puts it outside the current scope - shall I raise it as a change so it is covered?" The question at the end converts a potential confrontation into an administrative step.
For a request you will absorb: "That one is small enough that we will just do it - but flagging it so you know it was not in the original scope." This is the sentence agencies most often skip, and it is the one that prevents precedent. Absorbing work silently teaches the client that the boundary is notional; absorbing it visibly builds goodwill and keeps the boundary intact.
For a request that changes the date: "We can do that, and it moves delivery to the 28th. Which matters more to you - the extra feature or the original date?" Almost every scope conversation is really a prioritisation conversation, and asking the question directly usually resolves it faster than pricing it.
The common property: none of them says no, and all of them make the trade-off visible. That is the entire skill.
Who should raise them
A process nobody has authority to use is not a process.
The person closest to the work should be able to raise a change order below an agreed value - often a few hours or a few hundred pounds. If every change needs founder approval, they will not get raised, because the friction of asking exceeds the friction of absorbing.
Above that threshold, whoever owns the commercial relationship raises it. This is one of the practical arguments for separating account management from project management, covered in agency structure and roles: the person defending the scope should not be the same person whose primary relationship goal is keeping the client happy in the moment.
Everyone client-facing should be trained on the four sentences above. The most common leak is a junior team member saying "sure, no problem" to something out of scope, entirely reasonably, because nobody ever told them the project was fixed-fee or what the boundary was. That is a briefing failure rather than a judgement failure, and it is covered in onboarding a new hire.
What a change order looks like in practice
A worked example, so the format is concrete.
Change order 03 - Northwind website rebuild Date: 14 October
Requested: Add a second language (French) across the six page templates, including a language switcher and translated navigation.
Not included in the original scope, which covered English only (see SOW section 6, exclusions).
Effort: 22 hours - 6 template adjustments, switcher build, integration of supplied translations, testing across both languages.
Cost: £2,090
Timeline impact: Delivery moves from 14 November to 21 November.
Alternatives: We could defer this to a phase two after launch, keeping the 14 November date. Or we could swap it against the blog templates currently in scope, which would hold both the date and the cost.
If not approved: The project continues as originally scoped, delivering 14 November.
Please reply to confirm which option you would like by 17 October so we can plan the sprint.
One page. Five facts, three options, one deadline. It takes ten minutes to write once the template exists, and it is very hard to argue with because every element is a statement rather than a request.
Tracking them
Two things worth recording across projects, both cheap.
Change orders raised per project, and their total value. If a project type consistently generates 30% in change orders, that is not scope creep - that is a scoping problem in how you sell that work, and the fix is at proposal stage rather than in delivery.
Change orders raised versus work absorbed. The gap is your unbilled scope. It is one of the more uncomfortable numbers an agency can calculate and one of the more useful, because it converts a vague sense of over-servicing into a figure. It also feeds directly into realisation, covered in agency financial metrics.
Review both at the retrospective, where the pattern across projects is visible in a way it never is from any single engagement.
Where this sits in the wider system
Change control is one of three connected disciplines, and it does not work alone.
It depends on a scope with explicit exclusions, or there is no baseline to change from. It depends on capacity planning, because approving a change without knowing whether you have the hours just moves the problem to your delivery team. And it is the mechanism that converts scope creep from a margin problem into a revenue line - which is the whole point.
Agencies that run change control well are not stricter than everyone else. They have simply made the process small enough that using it is easier than absorbing the work, and that is a design decision rather than a matter of discipline.
The one-page version
If you take nothing else:
- Anything a reasonable reader of your scope would not expect is a change, however small.
- Write it up in one page: what, why, cost, new date, what happens if declined.
- Offer three options - approve, defer, or trade against existing scope.
- Written approval before the work starts, every time.
- Raise the first one early, while it is small, so the process is normal by the time it matters.
The agencies that find change orders uncomfortable are almost always the ones who raise them rarely. Raise them routinely and they stop being an event.