A revision is not automatically a scope change. The log separates a clarification from new work and gives both people a shared record of what was agreed.
Log every request once
Record the date, the request and who asked. A single log prevents the same feedback from arriving in three channels with different wording.
Mark the scope status
Label each request as included, clarification or new work. The label is the conversation starter, not a way to avoid the request.
Record the decision
Write what was accepted, deferred or declined and why. A decision without a reason is likely to be reopened.
Close the round
At the end of the review, summarize the agreed changes and the next review date. This is the boundary that protects the next block of work.
Revision log
| Item | Example |
|---|---|
| Date | Request |
| Oct 21 | Clarify heading |
| Oct 22 | New section |
| Decision | Clarification; new section deferred |
What to watch for
- Tracking revisions only in chat.
- Treating every request as included.
- Reopening a decision without a new reason.
A useful next step
Use the log at the next review. If the client wants more than the agreed round, show the log and discuss a separate scope. If feedback arrives in three places, copy each request into the log once and close the other threads with a link. The log is the source of truth, not a fourth opinion. If a revision is accepted, note the new delivery date beside it so the change does not silently move the whole project. Show the running total of included revisions at each review. Put the revision number in the file name and in the log. Use the same revision number in the next invoice.