Run Campaign Launch QA Across the Whole Asset Chain
Check the approved creative, destination, audience, and response path together. A campaign can contain individually correct assets and still send people to the wrong next step.
TL;DR
- QA the journey from promise to destination to response, not just each file in isolation.
- Attach approval to the exact version, audience, and launch configuration being reviewed.
- Give every failed or untested check an owner and a release consequence.
- Use Mio to assemble the evidence and exceptions in Slack; platform changes and launch authority stay with the team.
Run campaign launch QA by following the exact customer journey from the approved asset to its destination and next step. Check that the promise, audience, timing, and response path agree, then record who can authorize launch. A set of approved files is not enough if their connection has never been tested.
This playbook is for agencies and growth teams preparing a specific campaign. It does not recommend increasing spend, replacing legal review, or letting an AI alter advertising accounts. It proposes a review artifact that works with the tools and approval process you already have.
Freeze what is being reviewed
Record the campaign name, asset versions, destination URLs, audience description, timing and timezone, and accountable launch owner. Link the approved brief. If a link points to a file that can change in place, also record the reviewed version or timestamp. Otherwise a green checklist can silently refer to yesterday's campaign.
Adobe's pre-launch QA guidance recommends a defined builder/reviewer process and adapting acceptance criteria to the program. The original method here adds a cross-asset test: verify that each next step still fulfills the promise of the previous one.
Trace one complete journey
| Transition | Question to answer | Evidence |
|---|---|---|
| Brief to creative | Does this exact asset communicate the approved offer to the intended audience? | Versioned asset and the relevant requirement in the brief. |
| Creative to destination | Does the actual link land on a page that matches the offer and audience? | Resolved URL and a reviewed desktop/mobile view. |
| Destination to action | Can the visitor complete the intended next step? | An authorized test of the form, booking flow, or other action. |
| Action to response | Does the right team receive enough information to follow through? | Test result in the receiving system and named owner. |
| Approval to launch | Is the scheduled configuration still the one that was reviewed? | Final human check of version, audience, timing, and authority. |
Use test records and a permitted preview or test mode wherever available. Do not submit real customer information, trigger a purchase, or send external messages merely to complete a checklist. When a step cannot safely be tested, mark it untested and ask the owner what evidence is acceptable.
Watch for failures between correct pieces
Consider an illustrative webinar campaign. The creative has the correct date. The landing page has the correct registration form. But the destination uses a previous event's confirmation page, so a registrant receives the wrong calendar link. Each asset can look reasonable when reviewed alone; the joined journey is still wrong.
Another example is a region-specific offer linked to a global page that omits the restriction. The problem is not necessarily a typo. It is a mismatch between the promise and the destination. Keep the original requirement and the observed behavior side by side so the owner can decide whether to fix the page, narrow the asset, or delay launch.
Use three outcomes, not a vague percentage complete
- Pass: the exact acceptance criterion was checked against the reviewed version.
- Block: the observed result violates a launch-critical requirement.
- Untested or exception: evidence is missing, or an authorized owner must explicitly accept a stated limit.
Do not turn 'not applicable' into a hiding place for an uncomfortable check. Explain why it does not apply. A missing tracking join, for example, may limit measurement without proving that the visitor journey is broken. Describe the limit accurately instead of demanding a large analytics rebuild before a small campaign can run.
Ask Mio for an exception brief
Mio can help prepare work from the company sources you connect. Its public company-knowledge example includes retrieving written typography guidance from Notion. That supports checking an approved source while preparing a brief. It is not proof of automated browser QA, campaign configuration, or advertising-account control.
Try: 'Using this approved brief, asset manifest, and tester notes, prepare a launch QA exception brief. For each requirement, link the current evidence and label pass, block, or untested. Flag mismatched versions, unresolved approval, and missing destination tests. Do not infer test results from screenshots alone. Do not change settings, spend money, publish, or launch anything.'
The human testers still perform checks that require interacting with the live or preview journey. The launch owner confirms the final configuration. AI helps keep their evidence coherent; it does not become the authority that declares its own draft safe.
Keep creative decisions and product readiness in their own records
If reviewers disagree about the message, resolve that through the creative revision brief before treating it as a QA defect. If the campaign announces a feature, use the separate product launch readiness brief to establish that the feature is available to the promised audience. Neither decision should be silently made by a campaign checklist.
Close the check on the version that ships
After a fix, retest the affected transition and any dependent step. Preserve the failed observation and the new result. A changed URL may invalidate a prior mobile check; a new form may change the receiving workflow. The reviewer should know exactly which evidence was renewed and which was left unchanged.
Measure escaped defects, reopened checks, and preparation plus review time across comparable campaigns. Do not infer better commercial performance from a faster checklist. Try preparing the next campaign's exception brief with Mio, with launch authority remaining with the accountable team.
Keep exploring
Related articles
Playbook
Run a Campaign Retrospective That Changes the Next Campaign
A useful campaign retrospective ends with a decision about what to keep, change or test next, backed by comparable results and explicit unknowns. Assemble the original hypothesis, delivery changes, outcome evidence and team observations before writing the story.
Playbook
Build a Product Launch Readiness Brief From Slack
Separate what is built, what is available and what the team is ready to promise before calling a launch ready.
Playbook
Run a Post-Launch Adoption Review Before Calling a Feature Successful
A post-launch adoption review checks whether the intended customers reached a useful outcome and returned when the job came up again. Define the eligible audience, first-value behavior and observation window before interpreting usage. A successful release or a busy launch announcement is not evidence of adoption.
Mio is the Slack-native AI employee that already knows your company, connects to 3,000+ tools, and turns shared context into work. Just @mio, it's handled.
Add to Slack - free