Campaign handover checklist for complete, usable deliveries
Prepare a campaign handover that gives the recipient the right files, clear instructions, approval context and a way to resolve missing items.
Define delivery from the recipient's point of view
A campaign handover is complete when the receiving team can use the agreed deliverables for their intended purpose. Uploading a folder is only one part of that outcome. The recipient also needs to know which files are approved, where each belongs, what has changed and whether any dependencies remain. Start by asking how the files will be used after they leave the design workflow.
Different recipients need different packages. A social media colleague may need ready-to-upload images and approved captions. A printer may require production files matched to its specification. An internal design team may need editable sources, linked assets and a short explanation of the structure. Do not assume that the same export is suitable for every audience simply because it looks correct in a preview.
Agree the handover requirements early enough to influence production. If editable files or a particular format are part of the scope, the design partner should know before the final day. The handover plan should reflect the agreed work and any applicable asset restrictions. It should not become an opportunity to add substantial new deliverables without discussing their effect on time and effort.
Create a deliverable register
List every expected output with a stable identifier. Include the campaign, asset, language, placement, dimensions or specification, file format and responsible owner. Use this register throughout production so that it becomes a record of actual completion rather than a checklist assembled from memory at the end. A campaign with many variants benefits especially from a visible list.
Separate required outputs from optional working material. The recipient should be able to identify the files they are expected to use without sorting through drafts and experiments. If a preview is included for convenience, label it as a preview. If an editable source is supplied, distinguish it from the flattened output so someone does not accidentally send the wrong file to a production partner.
Record exceptions as they arise. A cancelled format should be marked as removed from scope, while a missing asset should remain visibly incomplete. Do not delete an item from the list simply to make the handover appear finished. A clear record of agreed changes helps both teams understand why the final package differs from the original brief.
- Confirm the final list of assets and variants.
- Identify the approved version of each item.
- Match formats to the recipient's intended use.
- Include agreed source files and supporting material.
- Record any outstanding item with an owner and date.
- Provide a concise package summary.
Check the exported files themselves
Open every final output, rather than relying only on the working document or thumbnail. Confirm that the content is complete, the intended fonts and images appear correctly and the file is readable at its actual use size. An export can succeed technically while still containing an incorrect crop, missing element or outdated line of copy.
Compare the output to the approved proof. Look for changes introduced during resizing, conversion or compression. A transparent background may become opaque in another format, small text may become difficult to read and an image may be cropped differently. The check should reflect the destination's requirements, which should be confirmed with the platform or production partner when they are specific or subject to change.
For a package with repeated variants, use a systematic order. Check one asset family at a time and tick off each language and size. This reduces the chance that several nearly identical filenames conceal a missing version. If a correction is made, regenerate and recheck the affected files before rebuilding the package. Do not leave both the incorrect and corrected output in the delivery area without clear status.
Include the approval context
The recipient needs to know which version is authorised for use. Keep a reference to the approval decision with the deliverable register or package summary. Identify the decision maker, date and scope of approval. This is particularly useful when the handover crosses teams and the person publishing the campaign did not participate in the artwork review.
Make conditional approvals visible. If a file was approved subject to a final factual correction, confirm that the correction was made and checked before presenting the package as complete. A vague note that something was “approved in principle” is not the same as a final decision on the delivered version. Resolve the distinction while the design and review teams are still available.
If the organisation requires specialist review, keep its outcome connected to the relevant asset. The handover checklist does not replace that review or establish legal sufficiency. It simply prevents a delivery process from losing the context that the organisation's own decision makers need to confirm the files are ready.
Explain names and folder structure
Use a structure that the recipient can understand without a guided tour. Group files by a meaningful dimension, such as channel, language or asset family, and keep the same logic throughout. A short readme can explain the naming pattern and identify the authoritative delivery folder. Avoid duplicating the same output in several places unless there is a clear reason.
Include a manifest that lists the package contents and intended uses. For example, distinguish a print poster from a web preview and a portrait social image from a square version. The manifest should match the actual files exactly. Check both that every listed file exists and that every file in the package has a clear purpose. Unexplained extras often indicate old exports or temporary working material.
Keep the package dated or otherwise identifiable. If a replacement is issued later, the recipient should be able to tell which package supersedes the earlier one. A stable link can be useful, but it should not hide a material change to files someone may already have downloaded. Explain the replacement and the affected assets explicitly.
Supply supporting information that enables use
Some deliverables need context beyond the file itself. A campaign may require approved captions, destination links, placement notes, accessibility text or a schedule reference. Identify which of these are part of the agreed handover and include them in an organised form. Do not expect the receiving team to reconstruct the intended message from a design preview.
Check links in the context where they will be used. A link printed on a poster, attached to a social post or embedded in a document can fail for different reasons. Confirm the intended destination with the campaign owner and test the delivered version where practical. Keep test or staging destinations out of the final package unless they are explicitly required and labelled.
Provide asset permissions or restrictions that the recipient needs to respect. A photograph, font or illustration may have conditions affecting reuse or editing. Do not assume that possessing the file gives every recipient unrestricted rights. The responsible owner should supply the relevant information, and the handover should keep that information connected to the asset without inventing an interpretation of the terms.
Make editable-source handover usable
When editable source files are part of the agreement, test that they can be opened in the expected application and version. Identify linked images, fonts, plugins or other dependencies that may be required. A source file that opens with missing assets is not equivalent to a self-contained editable project. Explain any limitations that cannot be resolved within the agreed scope.
Clean the working structure enough that another designer can navigate it. Clear layer or page names, a short note about master elements and an explanation of variant organisation can save substantial time. Avoid changing the approved design during cleanup without checking the result. The purpose is to make the source understandable while preserving the delivered appearance and content.
Do not confuse source handover with a promise of unlimited future compatibility. Applications and dependencies change. Record the relevant environment and keep a usable final export alongside the editable material. The receiving team can then distinguish the source intended for future editing from the output approved for immediate use.
Confirm receipt and handle exceptions
Agree how the recipient will acknowledge the handover. A message that the package arrived is different from confirmation that it is complete and usable. Ask the receiving owner to check access, file presence and any immediate technical requirements within a practical review window. This helps surface problems while the production context is still fresh.
If something is missing or incorrect, record the issue against the relevant deliverable rather than reopening the entire campaign vaguely. Assign an owner and a clear correction. When the replacement is ready, identify what changed and whether any earlier file should be withdrawn from use. Keep the final package and manifest consistent after the correction.
A handover can include an explicitly agreed exception, but it should not conceal it. For example, one optional source file may be scheduled for later delivery while all launch outputs are ready. The campaign owner and recipient should understand that arrangement. Marking every item complete when an exception remains creates confusion for the next person who consults the record.
Example: handing a campaign to two recipients
Imagine a campaign with social graphics and a printed event poster. The communications team receives the approved screen assets, captions and destination links. The printer receives only the production poster and its relevant specification. Both packages refer to the same campaign and approval record, but their contents match the recipients' different jobs.
The design partner supplies a manifest for each package. The communications owner checks that all scheduled placements have files, while the print owner confirms the production proof. If the event location changes, the register identifies every affected output and the team can issue precise replacements. The handover remains understandable because the package structure follows actual use.
Frequently asked questions
Is a shared folder enough for a handover?
A folder can be the delivery location, but the recipient still needs to know what is approved, which files belong to which placement and whether the package is complete. Add a manifest and concise instructions appropriate to the campaign. A well-organised small package is often easier to use than a large folder of unexplained files.
Should drafts be included with final files?
Usually keep drafts separate from the current delivery view. Preserve earlier work in an archive or version history if needed, clearly labelled as superseded. Include working material only when it has an agreed purpose, and make sure the recipient cannot mistake it for an approved output.
How does Campaign Bay fit into handover?
Campaign Bay brings the brief, design partners, artwork reviews and deliveries into one campaign workspace. Use that shared context to identify the agreed outputs and keep decisions near the files. The receiving team should still verify the delivered package against its actual publishing or production requirements.