Start with an allocation, not a total
Multi-site marketing teams need a campaign master and a site allocation that can disagree visibly. Define the purpose, controlled brand elements and intended service first. Then give every site a stable ID and a separate variant requirement. A programme quantity is useful for planning, but it does not say which branch needs which size, language or fixing. Keep missing local measurements empty and appoint an owner to obtain them before production scope is accepted.
Make local differences reviewable
Design the site matrix around actual differences: format, dimensions, local wording, quantities, delivery constraints and responsible reviewers. Separate locked master content from fields a branch may propose to change. The local editor should raise a change when its requirement crosses that boundary. Keep rejected import rows outside production totals and resolve duplicate site IDs before committing the matrix. If a centrally held buffer is later allocated locally, update the allocation rather than counting the spare stock again.
Release one exact site version
A site review needs its own artwork version, content owner and relevant technical gate. Approval at one location cannot approve another location's address or language. Prepare a package for the chosen provider that binds the site allocation, specification and exact file identities. Compare a proposed campaign change with accepted provider promises before revising the plan. An internal date change should highlight affected delivery and installation packages, with commercial confirmation sought from the responsible parties.
Keep receipt and completion separate
Plan how branches will report what they received and what was installed. A carrier receipt does not establish correct local installation, customer acceptance or absence of defects. Use package IDs and record shortages, damage and wrong variants as exceptions with owners. Avoid letting a programme-wide green status hide one incomplete location. Returns and retained fixtures should enter the next campaign from their actual inspected state, with outdated graphics and unresolved repairs kept visible.
Fictional working example
In a fictional rollout, three branches each need two panels and one central spare panel is held for the programme. The base allocation is six panels and the total planned quantity is seven. When one branch requests a different width, the team changes that site's specification and proof only. The central spare is not assumed to fit both widths. The observed planning result is a separated exception and a new review task, not proof that the campaign has been produced or delivered.
Control access and repeat work deliberately
Local staff usually need their site's records rather than competing provider quotes or other branches' private information. Use the commissioned identity system for real grants; a CSV cannot enforce those boundaries. Keep private financial fields limited in exports and remove personal details from public stories. Reuse the site structure next time, but check dates, measurements, artwork, contact roles and provider commitments again. Successful repetition comes from a controlled difference review, not from silently inheriting all historical approvals.
Take it to the next job
- Dry-run site imports and resolve duplicate identities before allocation.
- Bind each site release to its exact variant and review.
- Keep receipt, installation, defects and returns as distinct outcomes.
- Limit branch exports and revisit changing requirements before reordering.
