A reliable campaign approval workflow gives every asset a clear identity, version, reviewer and release state. Separate feedback from approval, record which formats and languages were checked, and reopen approval when a material change is made. “Final” should describe a controlled decision, not the emotional state of the designer naming the file.

Most campaign chaos begins innocently: a message in one chat, a corrected price in another, and a folder called final-final-really-final. By launch day, several perfectly reasonable people are looking at different versions. This guide shows how to create a simple approval matrix that makes the correct release easier to identify.

Define the campaign and the release

Begin with a campaign reference, objective, audience and intended launch window. Then list the actual deliverables: sizes, placements, languages and file types. “Social artwork” is too broad if the team needs a square post, a vertical story and several localised versions. A release is the agreed set of deliverables that may be used together.

Identify which details must remain consistent across that set, such as the offer, dates, destination link and brand treatment. Assign an owner for the source information. Designers should not have to decide which of three conflicting price messages is authoritative. Resolve the content first, then make it visible to everyone creating or reviewing assets.

Create an asset matrix before design expands

A matrix is simply a list of the combinations that must exist. Give each row an asset identifier and record its format, language, owner, version and status. Start with the real deliverables rather than a template containing every possible channel. Unneeded rows create noise and make missing required work harder to notice.

Illustrative campaign asset matrix
AssetFormatLanguageVersionState
Launch offer ASquare postEnglish03Approved
Launch offer BVertical storyEnglish02Changes requested
Launch offer CSquare postArabic02Language review
Launch offer DVertical storyArabic01Design review

The table prevents approval of one attractive image being mistaken for approval of the whole campaign. It also reveals where a change must be carried across. If the offer date changes, the team can identify every affected row instead of hoping somebody remembers all the adaptations.

Separate comments from decisions

A comment describes feedback. An approval authorises a defined version for a defined use. Those should not be interchangeable. “Looks good” in a long conversation may refer to the colour, layout or general direction. Ask reviewers to use an explicit decision when the asset is ready, and preserve the version that decision concerns.

Use a small number of meaningful states: draft, in review, changes requested, approved and released. Add a language or specialist review stage only when it represents a real responsibility. Too many statuses can become administrative decoration. The important question is whether a person can tell what happens next and who owns that step.

Give reviewers a bounded task

Tell each reviewer what they are checking. A campaign owner may confirm the offer, a language reviewer may check meaning and a designer may assess layout consistency. If everyone reviews everything without clear responsibility, obvious mistakes can survive because each person assumes someone else checked them.

Set a review window and explain what happens if feedback is late. Silence should not quietly become approval unless an explicit, appropriate process has been agreed. A deadline can guide planning, but it cannot make an unchecked claim accurate. Escalate missing decisions to the campaign owner rather than asking the designer to interpret absence as consent.

Ask for actionable feedback

Useful feedback identifies the asset, the issue, the reason and the desired outcome. “The price is hard to read at phone size; increase its prominence” gives the designer a problem to solve. “Make it pop” gives everyone an opportunity to develop a headache. Encourage reviewers to distinguish required corrections from optional preferences.

Consolidate conflicting feedback before sending it back for revision. If one reviewer wants a shorter headline and another wants additional detail, the campaign owner should resolve the priority. Designers can propose solutions, but they should not have to arbitrate business decisions hidden inside contradictory comments. Keep the agreed feedback attached to the relevant version.

  • Identify the exact asset and version.
  • Describe the specific issue rather than a general reaction.
  • Explain whether it affects accuracy, readability, brand or preference.
  • State the required outcome without prescribing unnecessary detail.
  • Resolve contradictions before requesting another revision.

Treat localisation as a design check

A translated version is not automatically approved because the original was approved. Text length, reading direction, line breaks and cultural context can affect the design. Give the language reviewer the actual rendered asset, not only a separate text document. The words may be correct while the final layout still makes them difficult to read.

Check numbers, dates, currency, contact information and destination links for each version. Record which elements are shared and which are localised. If a source line changes after translation, mark the affected versions for review again. Otherwise, a campaign can release several internally consistent images that quietly communicate different offers.

Set a rule for changes after approval

Decide which changes require renewed approval. A correction to an offer, date, claim, destination or important visual should normally return to the appropriate reviewer. A technical export adjustment may require a production check rather than full content review. The team should understand the distinction before a rushed launch makes every change seem “only tiny”.

Keep the previous approved file and record the replacement. Do not overwrite the only copy and leave the approval attached to an asset nobody can reconstruct. A clear version history helps if a scheduled item must be corrected or a partner asks which file was authorised. It also reduces the temptation to search old messages for evidence.

Worked example: a late offer-date change

Imagine a fictional retail campaign with two formats and two languages. Three assets are approved when the campaign owner changes the end date. The owner updates the source brief and identifies all four rows in the matrix as affected. The designer creates new versions rather than replacing the approved files silently.

The English reviewer checks the revised date and context. The Arabic reviewer checks the corresponding localised versions in their final layouts. The release owner then verifies that the download set contains only the newly approved files. Any already scheduled placements are checked separately so an old file is not left waiting in another tool.

The process takes a little discipline, but it answers the important question: which assets are safe to use now? Without it, the team may celebrate approval in one place while an outdated image remains scheduled elsewhere. The matrix connects the content change to the actual release.

Make the release package easy to recognise

Use a dedicated release location containing the approved files and a concise manifest. The manifest should identify the campaign, release date, asset versions and intended uses. Keep working drafts elsewhere. A partner downloading artwork should not need to interpret a folder full of historical experiments to find the correct square image.

Check exports at their intended size and format. Open the files, verify dimensions, inspect text and test links where applicable. A filename is not a quality check. If delivery includes editable sources, distinguish those from publication-ready exports. Record who receives the package and how replacements will be communicated.

Improve the workflow using a short retrospective

After launch, review where work waited and why revisions occurred. Separate missing source information from design changes, late feedback and technical export issues. Each cause suggests a different improvement. A longer approval chain will not fix an unclear brief, and a better naming convention will not resolve contradictory business instructions.

Choose one change for the next campaign: a clearer brief, a named language reviewer, a shorter feedback window or a release checklist. Keep the matrix small enough that people maintain it. The best workflow is one the team uses when busy, not a magnificent diagram that lives untouched beside the final-final folder.

Review the workflow after the first release

After one campaign, compare the planned review time with the actual time spent waiting. Identify one bottleneck rather than changing every rule at once. If feedback arrived late because the approver was away, add a named backup. If comments were contradictory, clarify who makes the final decision. If an approved asset was edited afterwards, tighten the change record. Keep a short note of what improved and review it again after the next release. A useful process becomes easier to follow with practice; it should not grow another form every time somebody spots a typo.

Frequently asked questions

Does approval of the main design cover every adaptation?

No. Adaptations can introduce cropped content, unreadable text or localisation errors. Use the approved main design as a reference, then check each required format and language before release.

Who should make the final decision?

Name a release owner with authority to confirm that the necessary reviews are complete. Specialist reviewers remain responsible for their areas. The release owner coordinates the decision rather than replacing all expertise.

Should a minor change create a new version?

Preserve a clear record whenever an approved asset changes. The review required depends on the change, but the released file should always be identifiable. Avoid silently replacing the evidence behind an earlier approval.

How does Campaign Bay fit this process?

Use Campaign Bay to organise campaign design work and collaboration, with the matrix guiding your team's responsibilities. See the version-control guide and artwork approval guide for related practices. This method does not assume automatic publishing to every channel.