Capture the change as a new request
Reference the accepted brief or specification and describe the proposed difference. “Replace the offer wording on site R04” is more useful than sending another attachment called final-final. Record the reason, requester and needed date. Keep the previous approved version available so everyone can distinguish the original agreement from the new request.
Trace the dependent decisions
Identify the affected proof, print quantity, packing list, delivery and budget. Decide which approvals must be repeated. A corrected telephone number may require content and artwork approval without changing the mounting system; a larger panel can also alter production, transport and fixing requirements. The responsible people should review the actual impact rather than relying on a generic change label.
Agree the response before proceeding
Ask the selected provider to state what work has already happened and whether the new requirement changes external cost or delivery. Record their actual answer. No response is not acceptance. Once the buyer approves the variation, issue an updated handover that names the superseded files and new version. The original commitment and the variation remain part of the project history.
Worked example — fictional
A fictional branch changes its offer after proof version 3 has been approved. The requested change affects one bilingual poster variant at two sites. The coordinator creates change C02 against the accepted specification, asks the content owner to supply approved wording and tells the provider which production stage has already been reached. The designer issues proof version 4 with a recorded difference. Visual and content decisions are repeated for that version; the existing frame specification can remain accepted if its requirements are unaffected. The provider reports whether the changed files alter delivery or external cost, and the buyer records an explicit decision. The final manifest names version 4 and identifies version 3 as superseded for those sites. Other branches retain their own accepted version references without being silently overwritten.
Decision checkpoints
- Baseline: identify the exact accepted brief, proof, quote and supplier scope before proposing a change.
- Affected records: include site quantities, labels and dispatch plans where their information will differ.
- Decision scope: reopen the gates affected by the actual change, with a responsible owner.
- Release manifest: show which files replace earlier files and which accepted variants remain current.
Common pitfalls
- Sending a replacement attachment without explaining its scope can leave two versions in production.
- A provider’s acknowledgement of a request is not necessarily acceptance of a new delivery promise.
- Changing a shared template can unintentionally alter sites that were supposed to retain the previous version.
Use it on your next job
Download the change register and complete one proposed row before altering the release pack. Collect the provider response and responsible approvals. Export the revised manifest only after the relevant decisions are complete. Keep a readable comparison of the accepted baseline and variation so a future colleague can understand why both versions exist.
Take this to the next job
- Name the accepted baseline
- Describe the proposed difference
- Find dependent records
- Obtain the provider’s response
- Issue a revised version manifest
