When a client request may change scope, timing, or fee, record it here before you reply.

The record captures the request, its effect on scope, timing, fee, and delivery, and the person authorized to decide it. If the scope-control rule is still unclear, define it in Change request workflow for freelancers and consultants before adapting the template.

Requests this template covers

  • 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.

It does not cover:

  • 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.

Gaps the record should expose

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

If the original scope is unclear, revisit Proposal-to-contract handoff workflow setup first. If the project is still in proposal review before signature, use Proposal revision and approval workflow instead.

Gather the original agreement and decision owner

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]

8. Recorded decision
- Status: [awaiting decision / approved / deferred / declined]
- Confirmed scope, fee, and timing: [terms accepted, if approved]
- Authorized decision-maker and date: [name / date]
- Decision evidence: [link to the written response or approved change record]

Reply with the decision and its effect

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.

Distinguish your proposed outcome from the client’s authorization. A price or timing proposal remains pending until the required decision-maker accepts it under the agreed change process. Record a decline or deferral clearly when that is the final outcome.

Keep the project record aligned

  • 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, record the authorization and agreed scope, fee, and timing, then update the affected project records before the changed work begins.
  • If the request is declined or deferred, keep the record anyway. It prevents the same ambiguity from resurfacing later.

Handle informal, approved, and deferred requests

  • 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 deferred, note when it should be revisited so it does not reappear as unresolved tension later.

Decisions the template cannot make

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

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

Define those rules in the change request workflow before using the template.

Complete change record

The record is complete when:

  • the request is captured in writing,
  • the impact is assessed before work changes,
  • the approver is named,
  • the outcome and its decision evidence are recorded in the project workflow, with pending requests kept separate from approved work.

Continue from the recorded outcome