Change Request Addendum Pack

When to use this

• The client asks for 'just one more thing'.
• You need a clean paper trail for expanded scope.

How to use this pack (so scope changes stop being awkward)

Scope changes are normal. What breaks projects is not that scope changes, it's that changes happen informally: a quick DM, a verbal "sure," and then the plan quietly expands while the timeline and budget stay the same.

This tool gives you short addenda you can attach when reality changes. The goal is not legal theater. The goal is a clean paper trail: what changed, what it costs (money or time), what assumptions the change depends on, and what you and the client approved in writing.

If you do not already have an SOW to anchor what was originally agreed, use the Statement of Work (SOW) template first. Change requests are easiest when everyone can point to a clear "in scope vs out of scope" boundary.

Quick start (10 minutes)

If you only do one thing, do this: convert the moment into a documented decision. Change control works when it is boring.

1. Clarify the request in writing. One sentence: what is being added or changed.
2. State the impact. Additional fee and/or timeline shift, plus assumptions.
3. Ask for approval. Email counts. The key is "approved" before you are "in progress."

Then stop. Do not start delivering the change until you have written approval. That is not stubbornness. That is how you avoid financing the project with your own time.

Subject: Change request approval - [Project name]

Hi [Name] - confirming the requested change:
- Change: [one sentence]
- Impact: [fee change] and/or [timeline shift]
- Assumptions: [any assumptions]

If you approve, reply "approved" and I will proceed.

Thanks,
[Your name]

The change request operating loop (calm, repeatable)

The best change request process is not a debate. It is a loop you run every time. That loop protects the relationship because it removes improvisation and emotion from the moment.

Use this loop whether you are doing small adjustments or major scope shifts. The only thing that changes is how big the impact is.

Step 1: Classify the request

First, decide whether the request is in scope or out of scope. If you have an SOW, the classification should be straightforward.

• In scope: you can accept it without changing the plan, budget, or timeline.
• Change request: it changes deliverables, deadlines, assumptions, or how much work will be required.

If you do not have an SOW, your first change request might be to create one. That is not bureaucracy; it is how you make the project legible.

Step 2: Clarify the request in concrete terms

Most "small tweaks" are vague. Vagueness is what turns a request into a moving target. Your job is to turn the request into something observable.

Good clarification questions (pick the minimum needed):

• What is the exact deliverable that changes?
• What will be different when this is done?
• What is the deadline, and what drives it?
• What is the priority relative to the existing deliverables?

Step 3: Estimate impact and present options

A change request is not only "yes" or "no." Most of the time, you are choosing between three options:

1. Add: increase fee and/or move the timeline.
2. Swap: replace an existing deliverable with the new request (same fee, same timeline).
3. Park: defer the change to a later phase.

This keeps the conversation grounded: scope is a budget, even when nobody calls it that.

If you want a practical framework for pricing and for explaining why changes have impact, read set freelance rates. The math is less important than the concept: your time and attention are capacity-constrained.

Step 4: Document and get approval before you start

This is where the addendum comes in. Write the change request using the template, attach it, and request approval. The goal is to eliminate the "I thought you meant..." failure mode.

Step 5: Update the plan and keep delivery boring

After approval, treat the addendum as part of the plan. Update dates. Update milestones. Update who is responsible for what. If the change introduces new dependencies (access, approvals, stakeholders), capture them immediately so the project stays predictable.

If you want a system for turning approvals and dependencies into a repeatable workflow, pair this tool with onboarding, delivery, and retention. The addendum is the paper trail; onboarding and delivery is the operational rhythm.

Step-by-step: fill the change request addendum

The addendum template in the preview is designed to be short. Resist the urge to add ten paragraphs. Clarity comes from specificity, not length.

Header: project name and dates

Fill in the project name, original SOW date, and the change request date. Dates matter because they anchor the timeline and make it clear which agreement version applies.

Change requested

Write what is being added or changed in plain language. Keep it observable: "Add X deliverable" or "Replace Y with Z." Avoid vague language like "improve" or "make it better" unless you define what "better" means.

If you are unsure how detailed to be, use this rule:

If you need more structure for definitions of done, exclusions, and acceptance criteria, the SOW template is the right companion tool.

Impact: additional fee, timeline shift, assumptions

The impact section is the heart of the addendum. It prevents the most common freelancer mistake: accepting a change as if the original plan still holds.

Your goal is not to convince the client that you deserve more money. Your goal is to update the plan so the project remains executable.

Approval block

The template includes signature lines. In practice, email approval can also work. Use the approval method that matches how your agreement is executed. The key is not the format; the key is that it is written and unambiguous.

Writing impact that holds up (fee, timeline, assumptions)

When you write impact, you are doing three things: you are describing what changes, you are making the tradeoff visible, and you are setting up a decision.

Additional fee: state the number, not the justification

If the change requires additional fee, write the amount and currency. Keep it clean. You do not need to argue for the fee in the addendum. The addendum is the decision record.

If you need a script for the conversation, use a simple framing: "I can do that. Here is the impact on fee and timeline. If you approve, I will proceed."

Timeline shift: name what moves

Timelines break when changes are absorbed silently. If the change moves a milestone, name the new milestone dates. If dates are uncertain, anchor to what you can control: "after access is provided" or "after review is completed." Then capture the dependency in assumptions.

Assumptions: the quiet lever

Assumptions are what make the change safe. Examples of assumptions (use only what is true for your project): access is granted by a certain date, feedback arrives within a timebox, or one person consolidates stakeholder input.

Assumptions are not threats. They are how you keep the plan honest. If an assumption fails, the plan changes again, and you run the same loop.

Impact:
- Additional fee: [amount] [currency]
- Timeline shift: [new milestone dates]
- Assumptions: [access/inputs by date], [review window], [single decision-maker]

If these assumptions change, we will update the plan via a new change request.

Notice what this does: it keeps your tone neutral, and it makes the decision about tradeoffs explicit. That is what keeps change requests calm.

Approval: what to get in writing (and how)

You want approval that is clear enough that nobody can later claim they thought the change was included. Written approval is the simplest way to do that.

Practical approval rules:

• One thread per change. Keep the decision in one place (email thread, signed doc, or the client's process).
• Approval before work starts. If you start first, you lose leverage and create ambiguity.
• Approval includes the impact. If the client approves only the idea but not the fee/timeline shift, you do not have a real approval.

If the client replies with "go ahead" but does not acknowledge the fee or timeline shift, reply once with a confirmation question. Do not proceed until the impact is explicitly accepted.

Work pause notice: when to use it (and when not to)

The pack includes optional addendum language for work pause: if invoices are overdue, you may pause work until the account is current, and timeline commitments shift accordingly.

Work pause is an operational boundary. It is only useful if you intend to enforce it consistently. If you do not plan to pause work when an invoice is overdue, do not include the language.

If you want a practical invoicing and follow-up system that stays procedural, use the invoice template and late payment sequence tool and the maintained Codex page on getting paid on time.

If you are working with procurement-heavy clients or local rules matter (for example, late fees or collections paths), keep the boundary aligned with your agreement and your jurisdiction. This page does not attempt to define those rules.

Common pitfalls (and how to recover)

Most change request failures are not dramatic. They are quiet. Watch for these patterns.

• Agreeing verbally, then trying to document later. Recovery: write the addendum immediately while the request is fresh.
• Describing impact vaguely ("it'll take a bit longer"). Recovery: name the moved milestone and a specific fee or a specific schedule change.
• Shipping the change before approval. Recovery: stop new change work, send the addendum, and reset the boundary: "I can proceed after approval."
• Turning the addendum into a renegotiation of everything. Recovery: keep it narrow. One change, one impact, one approval.
• Absorbing changes to preserve the relationship. Recovery: treat scope as a budget. Offer add/swap/park. If they want it "for free," the trade has to come from somewhere.

The underlying rule is simple: do not confuse being easy to work with (professional, responsive, clear) with being free to work with.

FAQ

Is this pack the same as a contract?

No. This pack is a set of short addenda used when scope changes. Many freelancers pair addenda with a main agreement and an SOW. If you want the clause-level context, read freelance contracts: the clauses that matter.

When should I use a change request?

Use a change request whenever the request changes deliverables, timeline, assumptions, or the amount of work required. If it changes the plan, it deserves a written decision.

What if the client says it is "in scope"?

Treat it as a classification conversation. Point to the SOW scope and exclusions, clarify the request in concrete terms, then propose the cleanest path forward. If the request truly is in scope, you can accept it without changing impact. If it changes the plan, it is a change request by definition.

What if the client wants it done urgently?

Urgency is a constraint, not a reason to skip process. If urgency is real, it usually increases impact: you might need to move other deliverables, add fee, or adjust assumptions (for example, faster approvals). Document the impact, then ask for approval.

What if they want it for free?

Offer a trade. Replace or defer an existing deliverable, or move the timeline. Scope is a budget even when the client does not say the word "budget." The addendum makes the tradeoff explicit and keeps it professional.

How detailed should the addendum be?

Detailed enough to prevent ambiguity, short enough to be approved. One page is usually enough: change requested, impact, assumptions, approval. If you need deeper structure, use an updated SOW or attach a revised scope section.

Does an email reply count as approval?

Often, yes, but it depends on your agreement and the client's process. The safest approach is: use whatever approval method your agreement expects, and keep the approval written and unambiguous.

How does this relate to pricing?

Change control and pricing are connected: pricing only holds when scope is controlled. If you want a system for setting a sustainable floor and handling pushback without drama, read set freelance rates.

What should I do after the change is approved?

Update the plan (milestones, dates, dependencies), then execute with a consistent onboarding and delivery rhythm. If you want that system, use onboarding, delivery, and retention.

What is the simplest next step if I do not have any of this set up?

Start with the SOW. Then keep change requests boring: clarify, impact, approval, update plan. Tools that pair well together:

• Statement of Work (SOW) template
• Set freelance rates
• Onboarding, delivery, retention

How to customize

1. Pick the minimum addendum needed for the change.
2. Tie every change to a cost or timeline impact.

Related Codex pages