Scope drift usually does not start with a dramatic contract dispute. It starts with one “small” request that enters delivery without a clear decision.

A change request workflow protects both the relationship and the system. It gives you a calm way to assess new asks without pretending every request is automatically included.

This is a narrow control page for live scope changes. It is not the right first page if the broader client workflow or the original project scoping is still weak.

When this workflow matters most

Use it when:

  • clients regularly ask for additions mid-project,
  • “quick changes” are affecting delivery dates,
  • billing is slipping because extra work is being absorbed informally,
  • approvals are unclear when a scope change appears.

If the real problem is that the original scope was never clear, fix Proposal-to-Contract Handoff Workflow Setup first. If the work is still pre-signature and the proposal is under review, use Proposal Revision and Approval Workflow for Freelancers and Solo Service Businesses instead.

If too many unofficial changes, delays, and workarounds have already broken the old plan, reset the operating baseline first with Scope Reset and Recovery Worksheet for Solo Operators before treating the situation like an ordinary new request.

If the reset is already decided and the next issue is explaining the revised baseline clearly, send it with Recovery Update and Revised Plan Notice Template for Solo Operators.

Do not use this page for ordinary delivery feedback that still fits the agreed milestone. Use it only when the request may change the actual operating agreement.

What a good change request workflow should accomplish

It should let you answer five questions quickly:

  • what exactly is being requested,
  • does it change scope, timing, or cost,
  • who can approve the decision,
  • what happens if the change is accepted,
  • how the outcome is recorded in delivery and billing.

If you cannot answer those questions without a long back-and-forth, the workflow is too loose.

Basic decision path

  1. capture the request in writing,
  2. compare it against current scope and exclusions,
  3. assess impact on timeline, workload, and fee,
  4. send one explicit decision: included, repriced, deferred, or declined,
  5. update the project record and billing path if the change is approved.

What counts as a real change request

Usually yes:

  • a new deliverable,
  • a revision that changes effort materially,
  • a timing change that affects the existing sequence,
  • a request that alters pricing assumptions.

Usually no:

  • minor clarification inside agreed scope,
  • ordinary review comments already expected in the current milestone,
  • wording or formatting adjustments already covered by the project terms.

Step 1: Capture the request outside chat ambiguity

Do not rely on memory or scattered message threads.

The request record should include:

  • what is being asked for,
  • why it is needed,
  • when the client wants it,
  • which deliverable or milestone it affects.

Use Client Change Request Template to standardize this step.

Step 2: Compare the request to the agreed scope

Check the request against:

  • in-scope deliverables,
  • explicit exclusions,
  • current milestone timing,
  • required dependencies,
  • pricing assumptions.

If you did not document those clearly during proposal handoff, this step will feel harder than it should.

Step 3: Assess impact before replying

Every meaningful change request affects at least one of these:

  • delivery time,
  • workload,
  • fee,
  • sequence of existing work,
  • approval timing.

Even if you decide not to charge more, you should still assess the operational effect. “Included” does not mean “impact-free.”

Step 4: Name the approval owner

One person must be able to say yes, no, or not now.

If feedback comes from several stakeholders, but no one holds final approval authority, the request can stall the workflow. Use Approval Owner if that role is fuzzy.

Step 5: Send a clear decision

Use one of these outcomes:

  • Included: the request fits current scope and timing.
  • Repriced: the request is valid but changes effort or fee.
  • Deferred: the idea is useful, but it should move to a later phase.
  • Declined: the request does not fit the engagement or current operating constraints.

Avoid soft replies that sound agreeable but do not actually decide anything.

If the request is not ready for a decision because the ask is vague, the next move is clarification, not silent inclusion.

Step 6: Update delivery and billing

If the change is approved:

  • update the milestone or deliverable record,
  • adjust dates where needed,
  • document the fee impact if applicable,
  • align the next invoice trigger if the approved change affects billing.

If that update never makes it into the system of record, the workflow will drift again.

A practical rule for small changes

You can choose to absorb a minor request occasionally, but do it intentionally.

Ask:

  • Is it truly minor?
  • Does it avoid more friction than it creates?
  • Would accepting it create a new precedent that harms future projects?

The risk is not one small change. The risk is silently teaching the client that scope boundaries are optional.

Common failure modes

  • treating every request like a relationship test instead of an operating decision,
  • agreeing verbally before checking impact,
  • failing to update timeline or invoice logic after approval,
  • letting multiple stakeholders suggest changes without a named approver,
  • burying scope changes inside status updates.

Where this workflow stops

This page helps you control live change decisions. It does not replace:

  • better proposal scoping,
  • a pricing policy,
  • a contract,
  • the template you use to document the request.

Edge cases

  • If the request exposes an ambiguity in your original scope, clarify that first before discussing price.
  • If the change is urgent because of a missed client dependency, note whether the urgency is external or self-created.
  • If the project is already near final delivery, even a small request may justify deferral instead of inclusion because sequence risk is higher.

Use this with

What to do next

When this workflow is complete

This workflow is working when:

  • new asks get captured and decided without drama,
  • scope changes no longer enter delivery informally,
  • timeline and billing changes are documented when requests are approved,
  • clients understand that useful collaboration can still have boundaries.