Use this template when a client request may change scope, timing, or fee and you need a clear operating response.

This is not just a client-facing message. It is a small decision tool that helps you avoid absorbing extra work by accident.

It works best as the execution asset for Change Request Workflow for Freelancers and Consultants, not as the full policy by itself. If scope-control rules are still unclear, this page is too early.

What this template is for and not for

Use it for:

  • requests that may change scope, timing, fee, or delivery sequence,
  • written decisions that need an approval owner and a recorded outcome,
  • internal or client-facing change records that must feed back into delivery.

Do not use it for:

  • minor clarifications already clearly inside scope,
  • vague brainstorming that is not yet a real request,
  • first-time scope definition before the project starts,
  • pre-signature proposal revisions still being negotiated before approval.

What this asset should help prevent

  • vague agreements to new work,
  • hidden scope drift,
  • delivery delays caused by unassessed requests,
  • billing changes that never get documented.

When to use it

  • when the client asks for a new deliverable,
  • when a revision changes the original scope materially,
  • when the request affects timeline, effort, or invoice timing.

If the issue is really a weak original scope, revisit Proposal-to-Contract Handoff Workflow Setup first. If the project is still in proposal review before signature, use Proposal Revision and Approval Workflow for Freelancers and Solo Service Businesses instead.

Before you use it

Confirm:

  • the original scope or exclusions are available to compare against,
  • the request is specific enough to assess,
  • someone can actually approve the outcome,
  • you know whether delivery or billing would change if it is accepted.

Change request template

Change request: [short title]

Requested by: [name]
Date received: [date]

1. Requested change
- [what is being asked for]

2. Why it is being requested
- [business reason or project context]

3. Impact assessment
- Scope impact: [included / new work / unclear]
- Timeline impact: [none / delayed by X / needs revision]
- Fee impact: [none / additional fee / to be confirmed]

4. Approval owner
- [name]

5. Proposed outcome
- [included / repriced / deferred / declined]

6. Notes to client
- [short explanation]

7. Internal update required
- [milestone change / invoice change / delivery note / none]

Use one short reply structure:

  • acknowledge the request,
  • state the assessed impact,
  • give one clear outcome,
  • name the next step needed for approval or implementation.

Do not let the reply sound like a discussion that is still open if you have already made the decision.

Practical usage notes

  • Fill in the impact assessment before replying, not after.
  • If the outcome is “unclear,” the next step is to clarify the request, not to start the work.
  • If the request is accepted, update the project record immediately so the template becomes an operational input, not just documentation.
  • If the request is declined or deferred, keep the record anyway. It prevents the same ambiguity from resurfacing later.

Common misses or edge cases

  • If the client is suggesting rather than formally requesting, you may still need to log it if it could alter scope.
  • If the request is approved, update delivery and invoice records immediately instead of waiting.
  • If the request is deferred, note when it should be revisited so it does not reappear as unresolved tension later.

What this template does not decide for you

This template helps you record and communicate the decision. It does not replace:

  • scope judgment,
  • pricing judgment,
  • approval ownership,
  • the broader change-control workflow.

If those are still fuzzy, go back to Change Request Workflow for Freelancers and Consultants.

Completion standard

This template has done its job when:

  • the request is captured in writing,
  • the impact is assessed before work changes,
  • the approver is named,
  • the outcome is recorded in the project workflow.

What to do next