A client asks for an extra deliverable during a meeting. You make a note, start working and discuss the consequences later. By then, it may be difficult to reconstruct what was requested, whether it was agreed and which version of the project plan applied.
A scope-change tracker makes the proposed change visible before it becomes execution work.
1. Define what counts as a change record
Create a record when a request may alter the agreed deliverables, assumptions, timing or responsibilities. You do not need a scope-change record for every typo correction. You need one when a request requires a decision about changing the work.
Use a concrete title: “Add a second landing page for the partner campaign.” Avoid vague titles such as “Extra work” or “Client changes.” If the request is still unclear, capture it as a proposal and record the clarification needed. Do not describe it as approved.
2. Create a Scope Changes database
| Property | Type | Purpose |
|---|---|---|
| Change | Title | Describe the proposed change |
| Project | Relation | Connect to the existing project |
| Requested On | Date | Record when the request arrived |
| Requested By | Text | Identify the requester |
| State | Select | Track the decision stage |
| Owner | Person | Assign the next action |
| Next Action | Text | Explain what happens next |
| Decision Date | Date | Record when a decision was made |
| Evidence | URL or Text | Reference the recorded decision |
Suggested State options: Proposed, Assessing, Awaiting decision, Approved, Declined, Implemented. These labels deliberately separate approval from implementation.
Connect the tracker to your existing project database using the database connection guide.
3. Assess the change inside its page
Requested change
Record what the requester wants and identify the source.
Current agreement
Describe the relevant deliverable or assumption in the current agreed work. Reference its version or location.
Expected impact
Explain the effect on deliverables, workload, dependencies, schedule and price where relevant. If an impact is not known, say what must be checked. Do not turn an estimate into a confirmed commitment.
Decision needed
State the question that must be resolved before work begins. For example: “Should the additional landing page be added to this project under the proposed revised delivery plan?”
For the commercial workflow around a request, use the client change request guide.
4. Work through one complete example
Suppose the agreed project includes one landing page. The client requests a second page for a different audience. Create a record in Proposed.
During Assessing, identify:
- Whether the second page needs separate copy.
- Which design components can be reused.
- Who supplies the assets.
- Which delivery dates could be affected.
- What additional agreement is required.
Move it to Awaiting decision once the proposal is clear enough to decide.
If approved, record the decision date and evidence, update the affected project plan and create the execution tasks. Keep those tasks connected to the project and reference the change record.
After the approved addition is delivered through the agreed process, move the change to Implemented. If declined, keep the record as Declined. It preserves the outcome without placing the proposed work in the delivery queue.
5. Create three views
Decisions needed
Filter State to Awaiting decision. Show Change, Project, Owner and Next Action. This view should explain what decision is outstanding and who is following it up.
Approved — not implemented
Filter State to Approved. Review whether the project plan and execution tasks have been updated. Approval alone does not establish that the work has been scheduled or completed.
Change history
Keep an unfiltered view. Include proposed, declined and implemented records so the project’s evolution can be reconstructed.
A filtered view is a working display, not an access boundary. Keep internal pricing or notes within your established sharing arrangements.
6. Record the decision precisely
A useful decision note identifies:
- The change being decided.
- The proposal version.
- The person making the decision.
- The decision and its date.
- The source of the confirmation.
- Any conditions that remain unresolved.
“Client said yes” is weak context. “Client confirmed proposal version 2 in the referenced email” is easier to trace. Use the client decision log guide when a project has several related decisions.
For unresolved requests, build a pending decision review that shows the missing answer, owner and next check.
Common mistakes
- Starting execution while the record still says Awaiting decision. Keep proposal work and approved delivery work distinguishable.
- Updating price but overlooking timing. Record the relevant impacts together.
- Replacing the original agreement without retaining its context. Identify the agreement and change versions.
- Marking Approved as Implemented. Keep the decision and delivery stages separate.
Frequently asked questions
Is every revision a scope change?
No. Compare the request with the agreed deliverables and revision process. Use a change record when the request may alter that agreement.
Can I keep scope changes in my task database?
You can, but tasks and change decisions have different jobs. A dedicated register is useful when you need to preserve proposals, assessments and outcomes before creating delivery tasks.
What should I do if the impact is unknown?
Keep the change in Assessing. Record the unanswered question, assign an owner and define the next action needed to prepare a decision.
Should declined changes be deleted?
Usually, retaining the record provides useful project history. Keep the outcome clear so declined proposals do not enter the execution queue.
Does an Approved status prove that the client agreed?
The status is your tracking label. Record the actual decision source, proposal version and decision-maker so the outcome can be traced.
Want this already built?
This guide shows you how to build this workflow yourself. For the wider client and project workflow, take a look at Freelancer CRM and compare its structure with how you work before adapting this process.