Agency Change Order Template (Copy/Paste) + Rules That Stop Scope Creep

Change orders exist because everyone wants the project to move fast, until the work changes.

The problem is not that change is bad. The problem is that agencies often treat change like a conversation, not a documented decision.

This template gives you a simple change order you can use in Google Docs, and the upstream scoping rules that reduce how often you need one.

Top results for “change order template” are often:

• generic forms (Jotform)
• project management guidance (Asana)
• document template sites

They are usually written for construction or procurement. Agency change orders need the same basics (description, cost, time impact, approvals), but also:

• an explicit link back to the scope of work
• clarity on whether the change is a correction (defect) or new scope
• a fast approval path that does not stall delivery

A change order is appropriate when the request changes any of the following:

• deliverables
• timeline or milestones
• budget or fees
• responsibilities (for example, client wants you to write copy)
• acceptance criteria or quality standard

Do not raise a change order when:

• the work is already included in the signed scope
• you are fixing defects that prevent acceptance
• you are correcting your own omissions

If you blur these, you will either annoy the client, or you will quietly absorb new scope.

If your change orders feel adversarial, it is usually because the original scope did not set expectations.

Your scope of work should include:

• clear exclusions
• acceptance criteria
• limits on feedback rounds
• change triggers written in plain language

Examples of high-signal triggers:

• additional pages/templates beyond the list
• new integrations or expanded integration requirements
• new markets/languages
• new approval stakeholders added late
• content migration volume increases
• timeline changes caused by delayed inputs

The change order then becomes mechanical: “this trigger occurred, here is the impact”.

Aim for a process that is easy to follow and easy to audit.

1. Request captured in writing (email, ticket, or a change order doc)
2. Classification: in scope, defect, or new scope
3. Impact: cost, timeline, and assumptions
4. Approval: named approver signs off
5. Implementation: work scheduled, scope updated

Two rules that prevent drama:

• No work starts until approval.
• Approval requires an explicit acknowledgement of cost and time impact.

Do not rewrite the scope every time. Keep one scope of work as the baseline, then use numbered change orders.

Example:

• SOW v1.0 (approved)
• Change Order #1 (adds new integration)
• Change Order #2 (adds additional templates)

Then update a simple summary line inside the scope:

• “This scope is amended by Change Orders #1 to #2 dated [dates].”

This keeps the contract readable and makes future disputes easier to resolve.

Field	Value
Client	[Client name]
Project	[Project name]
Baseline SOW	[Link or reference to SOW v1.0]
Change Order #	[1]
Date raised	[DD Month YYYY]
Raised by	[Name]
Client approver	[Name, role]
Agency approver	[Name, role]
Status	[Draft / Approved / Rejected / Superseded]

[Describe the change in plain language. Avoid implementation detail where possible.]

• [Business reason]
• [User/customer reason]
• [Technical constraint discovered]

Select one:

• In-scope clarification (no fee change)
• Defect/bug fix required for acceptance (no fee change)
• New scope (requires fee and/or timeline change)

Notes: [Explain the classification and reference the baseline SOW section.]

• New deliverables added:
  • [Deliverable]
• Deliverables changed:
  • [Deliverable]
• Deliverables removed (if any):
  • [Deliverable]

• Additional time required: [X days / weeks]
• Milestones affected:
  • [Milestone] moves from [date] to [date]

Select one:

• No fee change
• Fixed fee addition: £[amount]
• Time and materials: £[rate] x [estimated hours] (cap: £[amount])

Payment terms for this change:

• [Example: 100% payable on approval]
• [Example: added to next invoice]

• [Example: client provides API credentials by DD Month]
• [Example: third-party vendor support available]

Define what “done” means for this change:

• [Acceptance check 1]
• [Acceptance check 2]

By approving, the client confirms they understand the impact on scope, timeline, and fees.

Client approval:

• Name:
• Title:
• Signature/approval:
• Date:

Agency approval:

• Name:
• Title:
• Signature/approval:
• Date:

• Planned start date: [date]
• Planned completion date: [date]
• Notes: [dependencies, staging, release plan]

Most agencies use the terms interchangeably. “Change request” is the process, “change order” is the documented approval that amends the scope.

No, but you need a clear threshold. The simplest approach is to write change triggers in your scope and raise a change order when a trigger occurs (new deliverable, more pages, new integration, more feedback rounds).

Do not. You can acknowledge the request and begin the impact assessment, but work should only start after written approval. Otherwise the change order becomes a retrospective argument.

Keep the baseline scope stable and amend it with numbered change orders. Add a short note in the scope referencing which change orders apply.

Yes. If your change order text and triggers are standardised, RuleDox can assemble consistent change request sections in Google Docs and keep the language aligned with your scopes.

Change orders are a symptom. Tight scoping reduces how often you need them. Pair this with /content/ai/how-to-write-a-scope-of-work, /content/ai/scope-of-work-template-google-docs, and /content/ai/automate-scope-of-work-google-docs.