When a client changes a project, the request is only the beginning of the record.
Months later, the useful questions are different: What changed? Was it included? What did it cost? Did the deadline move? Who approved it? What happened next?
If those answers live across chat messages, meeting notes, tasks and memory, even a small change can become difficult to reconstruct.
The solution is not to document everything. It is to preserve the few facts that explain the decision.
Start with the request itself
Record what the client actually asked for before translating it into internal tasks.
- short request title;
- request date;
- requester;
- project or deliverable affected;
- a specific description of the requested change.
Avoid labels such as “extra changes” or “client edits”. They describe activity, not the change.
Preserve the original scope reference
A change only makes sense in relation to the baseline it changes.
Keep enough of the original agreement visible to answer whether the request was already included. That might be a deliverable, quantity, revision limit, milestone, responsibility or explicit exclusion.
You do not need to copy the entire contract into the record. Link or quote the relevant scope boundary.
Record the scope decision
Before thinking about execution, classify the request.
- Included — already part of the agreed work.
- Revision — a permitted refinement inside the agreed deliverable.
- New scope — additional or materially changed work.
- Unclear — more information is needed before deciding.
This is the point where an incoming message becomes an operational decision.
Capture the impact before approval
If the request changes the scope, document the consequences the client needs to understand.
- estimated additional work or hours;
- additional fee when relevant;
- timeline impact;
- dependencies or milestones affected;
- anything that will be removed or exchanged if the scope is being swapped rather than expanded.
Not every change affects every field. Record the impacts that are real rather than filling boxes for the sake of completeness.
Keep the approval with the change
If approval is required, the record should show more than a generic Approved status.
- approval status;
- approver;
- approval date;
- the relevant evidence or confirmation.
The goal is simple: someone reviewing the project later should not need to search an inbox to discover whether the client accepted the change.
Record what the decision creates
An approved change normally creates consequences elsewhere in the project.
Connect the next action, updated milestone, billing step or other work created by the decision.
This prevents the change log from becoming a passive archive. Its job is to explain the decision and hand the project cleanly back into execution.
A minimal change record
For many service businesses, the core record can stay surprisingly small:
- Project
- Request
- Requested by
- Requested date
- Original scope reference
- Scope decision
- Estimated hours
- Fee impact
- Timeline impact
- Approval status
- Approver
- Approval date
- Next action
That is enough to answer most of the questions that matter without creating another giant project-management system.
Do not mix requests together
Three unrelated client changes should not become one record called “September updates”.
Separate changes when they have different impacts or could receive different decisions. One may be included, another declined and another approved for an additional fee.
One record per meaningful decision keeps the history understandable.
The rule worth keeping
Document the change before documenting the task.
Preserve the request, the original boundary, the impact, the decision and the approval. Then connect the work that follows.
If the record can explain what changed without reopening old messages, it is doing its job.
If you are still deciding whether a request belongs inside the original agreement, use the revision vs new scope test first. Once it is a genuine change, the change request workflow controls the process; this log preserves the history.