A living scope register
Approved deliverables, revision allowances, dependencies, and accepted changes with their supporting records.
Client delivery / Agency scope-change tracking
The request changed. Make the trade-off visible.
Compare incoming creative or delivery requests with an approved project scope and prepare a change discussion before extra work becomes an unnoticed commitment.
Discuss your project Start with an outline, not a perfect brief.
Where it gets stuckAgency scope-change tracking,
Agency scope-change tracking,
with the context attached.
A new deliverable can arrive as a casual comment on a proof. The account team needs to distinguish feedback within scope from a proposed expansion. Unlike proposal writing or contract review, this workflow tracks delivery-stage requests against the actual approved baseline.
A good first scope
Pick one active project type and its scope format. Agree what counts as a revision, a new deliverable, and a change requiring client approval.
The workflow
- 01 / The starting point
A client requests a second language version during review of an approved campaign deliverable.
- 02 / The right context
Compare the request with the approved deliverable register, included revision rounds, accepted changes, and the current production plan.
- 03 / Prepared for review
Prepare a change note with the original request, scope references, affected deliverables, and questions for estimating effort and timing. Do not fabricate hours or fees.
- 04 / A person decides
The delivery lead checks feasibility and the account owner agrees any commercial change with the client. Only approved changes become the new scope baseline.
Tangible work
A useful working handoff
A request-to-scope comparison
Show why a request may be covered, unclear, or additional, without framing the client as at fault.
A change-discussion pack
Prepare impacts for owner estimation and a client-facing draft, with approval status and baseline history.
A focused engagementDefine the job.
Define the job.
Test the handoff.
- 01
Define the first boundary
Pick one active project type and its scope format. Agree what counts as a revision, a new deliverable, and a change requiring client approval.
- 02
Build the inspectable handoff
Show why a request may be covered, unclear, or additional, without framing the client as at fault.
- 03
Test before connecting actions
Test contradictory approvals, a request withdrawn later in the thread, an included revision mistaken for new work, and a changed baseline not yet accepted by the client.
How we would startMap it. Test it.
Map it. Test it.
Then decide.
Agree the trigger, source systems, reviewer, and acceptance criteria. Build the bounded preparation path, then test it with the person who will own it.
Include the awkward cases
Test contradictory approvals, a request withdrawn later in the thread, an included revision mistaken for new work, and a changed baseline not yet accepted by the client.
Keep this boundary explicit
No automatic fee, project delay, contract interpretation, client message, or refusal of work. The account owner confirms the commercial response and protects the relationship.
See how acceptance evidence works ↗A few useful answers
Before we begin.
Will it automatically charge for changes?
No. It prepares the evidence for a conversation. Authorized people agree price, timing, and acceptance.
Does every new comment become out of scope?
No. The comparison must respect included revisions and accepted changes. Ambiguous requests should remain questions, not accusations.