A change order template gives your agency a fast, repeatable way to capture work that falls outside the original scope, price it, and get written approval before you start. It is the mechanism that turns "can you also do this?" from a quiet margin leak into a clean, billed decision. If your team does extra work first and hopes to sort out the billing later, this is the document that fixes it.
A change order is short by design. It names what changed, what it costs, what it does to the timeline, and where the client signs. The hard part is not the format; it is the habit of writing one every time scope shifts, and writing it well enough that the client says yes without friction. This guide covers both: the template to copy, and how to use it so approvals are quick instead of awkward.
When a change order is required
A change order is not for every passing request. It is for any request that adds work, time, or cost beyond what the statement of work already covers. The cleanest way to know is to define the triggers in your SOW up front, so the change order is simply the agreed-upon next step rather than a surprise.
The standard triggers are:
- A deliverable changes after sign-off. Once the client has approved something, any request to revisit it is new work, full stop.
- Work is requested that is not in the SOW or is explicitly excluded. New pages, screens, assets, or features beyond the listed deliverables.
- Included revision rounds are used up. A request for an additional round beyond the number in the SOW.
- Client delays break a documented assumption. Late inputs that push the timeline past the thresholds you wrote down.
The single most important trigger is the post sign-off change. If you only enforce one, enforce that one. It is where the most expensive rework hides, and it is the easiest to justify because the client already said the work was done.
The change order template
Here is the full structure. Keep it to a single page. Each field exists to remove a question the client might otherwise raise.
1. Header and reference
Project name, change order number (CO-001, CO-002, so they are easy to track), the date, and a reference to the original SOW it amends. This ties the change to the agreement it modifies.
2. Description of the change
Plainly state what is being added or modified, and why. One or two sentences. "Add a careers page (one template, desktop and mobile) to the site build, requested after the SOW was signed." Be specific enough that there is no ambiguity about what the client is approving.
3. Reason and origin
Note where the change came from: a new client request, a broken assumption, a revision beyond the included rounds. This is not about blame. It keeps the record clean and helps both sides understand the pattern over the life of the project.
4. Impact on deliverables, timeline, and cost
The core of the document. Spell out exactly what changes:
- Scope impact: the new or modified deliverables, defined with the same specificity as the original SOW.
- Timeline impact: how many days or weeks this adds, and any shift to dependent milestones.
- Cost: the price, broken out by hours and rate or as a fixed fee, so the number is transparent.
5. Approval and signatures
A clear statement that work on the change begins only after written approval, with space for both parties to sign and date. An email reply that explicitly approves the change can count, as long as your SOW says so.
A worked example
To make the template concrete, here is what a filled-in change order looks like for a common situation: a client asking for an extra page mid-build.
| Field | Example entry |
|---|---|
| Reference | CO-002, amends SOW dated Mar 3, 2026 |
| Change | Add one careers page template, desktop and mobile, with a 5-role job listing layout |
| Origin | New client request, made after design sign-off |
| Scope impact | 1 new page design, 2 revision rounds, build and QA |
| Timeline impact | Adds 5 business days; launch moves from May 12 to May 19 |
| Cost | 14 hours at your standard rate, billed on approval |
| Approval | Work begins on written sign-off below |
Notice how little room this leaves for disagreement. The client is not approving a vague "extra page." They are approving a specific deliverable, a specific date change, and a specific number, all in one place.
How to get a change order approved without friction
The format is easy. Getting a fast yes is a skill. The agencies that bill change orders smoothly do a few things consistently:
- Set the expectation early. When change order triggers are written into the SOW, the first change order is not a surprise; it is the process working as agreed.
- Send it the moment scope shifts, not at the end. A change order presented in the moment reads as professional. The same charge surfaced at final invoice reads as a bill for work the client thought was included.
- Lead with the value, not the cost. Frame the change around what the client gets ("this adds the careers page you asked for") before the number. The price is easier to accept when the benefit is clear.
- Make approval one step. A single signature line or a "reply YES to approve" lowers the effort to say yes. Friction in the approval process is where change orders go to die.
- Keep it short. One page. A change order that reads like a contract invites scrutiny; one that reads like a clear summary invites a quick decision.
Change orders work best as one piece of a larger system. The tighter your original scope, the easier the change order conversation, because the boundary is already clear. Our guide on preventing scope creep in agencies covers how the SOW and the change order work together, and the scope of work guide shows how to write the triggers that make change orders feel expected rather than confrontational.
The best agencies do not write change orders from scratch under pressure. They have a standard template, standard pricing logic, and a defined moment when one gets sent, so capturing a change takes minutes and never gets skipped. That is the kind of process we build at ScopeStack. We audit where your projects lose unbilled work, then wire the change order step (template, triggers, and approval) directly into the tools your team already uses, so added scope gets captured every time instead of absorbed.
Frequently asked questions
What is the difference between a change order and a new statement of work?
A change order amends an existing SOW for a specific, bounded change to the current project: an added page, an extra revision round, a timeline shift. A new SOW is for a distinct new project or a major expansion that effectively starts a new engagement. If the change is small and tied to the active project, use a change order. If it is large enough to stand on its own, write a new SOW.
Should I charge for every change order?
Charge whenever the change adds real work, time, or cost. Tiny courtesy adjustments can be absorbed and noted, but anything that consumes meaningful hours should be priced. The point of a change order is not to nickel-and-dime; it is to make sure that work which expands the project is a deliberate, paid decision rather than a quiet hit to your margin.
How do I bring up a change order without seeming difficult?
Reference what was already agreed. When the SOW defines the triggers, a change order is not you being difficult; it is the process both parties signed up for. Present it promptly, frame it around the value the client gets, and make approval a single step. Handled that way, clients read it as competence, not conflict.
Make the change order a reflex, not an afterthought
The agencies that protect their margin are not the ones with the toughest negotiators. They are the ones for whom writing a change order is automatic: scope shifts, a one-page document goes out, the client approves, work begins. No drama, no end-of-project reckoning, no unbilled hours.
Copy the template above, define your triggers in the SOW so change orders feel expected, and commit to sending one every single time scope moves. To see what scope changes are already costing you when they go uncaptured, run the numbers with our scope creep calculator. The discipline of the change order is small. The margin it protects is not.