Most campaign launch reviews are a list of questions answered from memory. Copy approved? Yes. Landing page live? Yes. Tracking in place? Yes. The campaign ships, and three days later a quarter of the traffic is arriving as direct with nobody able to say which of four possible causes did it.
A campaign go/no-go checklist is supposed to prevent that, and most of them don’t, because they inherit the wrong shape. They’re task lists. They ask whether work was done. They never ask what evidence exists that the work functions.
That distinction sounds academic until you price it. “The tracking is in place” is a claim about configuration. “Twelve test submissions reached the CRM with campaign data intact” is a claim about behavior. Only one of them can be checked by somebody who wasn’t in the room.
Direct answer — what is a campaign go/no-go checklist?
A campaign go/no-go checklist is a pre-launch decision gate that records, for every readiness check, whether the check is verified by transaction-level evidence, merely configured, or unknown. It returns one of three verdicts: go, go with named exceptions, or no-go. Unlike a campaign launch task list it asks what proof exists rather than whether work was done, and unlike an RFP go/no-go it decides execution readiness rather than whether to pursue an opportunity.
Key Takeaways
- A launch gate is not a score. Weighted scorecards let one silent-loss failure be averaged away by a column of green, which is why the go/no-go models borrowed from bid desks and software releases fail on campaigns.
- Every check returns one of three verdicts, not two: verified, configured, or unknown. “Configured” is the false green, and it is not a pass.
- IVRIS tested this directly. An automated read-only scan of live B2B forms detected 8 of 17 payload-confirmed campaign-data captures and missed 9, so a page-level reading of “tracking is installed” was right less than half the time.
- Five classes decide what blocks: silent loss, irreversible, and compliance block a launch. Recoverable and deferred findings don’t, provided each one carries a named owner and a watch window.
- The only honest number the gate produces is verification coverage: blocking checks backed by transaction-level evidence, divided by total blocking checks. A pass rate that counts configured checks as passes is a number that lies.
What is a campaign go/no-go checklist?
A campaign go/no-go checklist is a structured pre-launch review that produces a documented launch decision rather than a list of completed tasks. Each item names the evidence that would satisfy it, and the decision is blocked by unproven items rather than averaged across all of them.
The phrase is borrowed, and the borrowing causes most of the confusion. Search it and you’ll get bid desks and IT release management, because those two disciplines formalized go/no-go decades earlier. Both models are useful. Neither one transfers cleanly, because they answer different questions at different points in a project.
| Decision | The question it answers | Decided by | Failure it prevents |
|---|---|---|---|
| Campaign go/no-go | Is this campaign proven ready to execute? | Marketing ops, with channel and legal owners | Spend and demand lost to defects nobody detected |
| RFP or bid go/no-go | Should we pursue this opportunity at all? | Proposal or sales leadership | Effort spent on bids you were never going to win |
| Project go-live readiness | Is this system safe to put into production? | Delivery and QA leads | Users blocked by an unstable release |
The campaign version is the youngest of the three and the least formalized, which is odd given that it governs the largest number of individually irreversible decisions. A bid desk makes a handful of pursue-or-decline calls a quarter. A mid-market demand gen team launches something almost weekly, and each send, each published ad, each activated workflow starts writing records the moment it goes live. The strategic layer above all of it, the sequencing and channel mix that B2B campaign strategy covers, assumes the execution layer works. This gate is what makes that assumption checkable.
Why a launch gate is not a weighted score
A weighted scorecard is the wrong instrument for a launch decision, because it converts independent failures into a single average. The go/no-go templates that currently rank for this topic are built on exactly that: adjustable weights, yes-or-no responses, and a computed total.
Weighting works when you’re comparing opportunities. A bid with a weak incumbent relationship but excellent margin genuinely is more attractive than one with the reverse, and a score captures the trade. Launch readiness has no trade to capture. If the form isn’t writing to the CRM, it does not matter that the creative is outstanding, the segment is precise, and the budget is confirmed. Nine greens and one silent failure is not a ninety percent campaign. It’s a campaign that collects nothing.
A weighted score can average away the one failure that empties your pipeline. A veto cannot.
So the gate has a different structure. Some checks hold a veto and some don’t, and which is which is decided before anybody looks at the results. That ordering matters more than it sounds, because a defect found at five o’clock on the Friday before a Monday launch is remarkably easy to reclassify as minor. Deciding the blocking list while the campaign is still comfortable is the only time you’ll decide it honestly.
Verified, configured, unknown: the three verdicts a check can return
Every check on the gate returns one of three states, and collapsing them into pass or fail is where launch reviews lose their meaning. The middle state is the one that does the damage, because it reads like a pass to everyone in the room.
- Verified. Transaction-level evidence exists. Something moved through the system and you can point at the record that proves it: a timestamp, a payload, an owner field, a received message.
- Configured. The setting exists and looks correct. Nothing has proved it fires. This is a statement about a screen, not about behavior.
- Unknown. No evidence either way, usually because the environment can’t produce it yet.
How often “configured” turns out to be wrong
The gap between configured and verified is measurable, and IVRIS measured it. In a June 2026 study of live B2B forms, an automated read-only scan was compared against manual submissions where the actual request payload was inspected. The scan detected 8 of 17 payload-confirmed campaign-data captures and missed 9, giving it 47 percent sensitivity across 20 definitive test cases. Reading the page told you the truth slightly less than half the time.
That result generalizes past forms, because the mechanism is the same everywhere. Configuration is visible on a screen and behavior only shows up in a payload, a log, or a record. Google’s own tag documentation is built on the distinction: preview and debug mode exists to “test a container configuration before it is published,” and its interface lets you check whether a tag fired successfully and what triggered, or did not trigger, its firing status. The vendor is telling you plainly that the existence of the tag is not the evidence. The firing is.
IMPORTANT
A configured check recorded as a pass is worse than an unknown one, because an unknown gets followed up and a false pass never does. If nobody watched something happen, the honest entry is “configured,” and the launch decision has to account for it.
Hidden fields are the canonical example of how confidently this fails. A field can be present in the form builder, mapped to the right CRM property, and still arrive empty on every submission because of where it sits in the page lifecycle. The seven ways hidden fields lose campaign data are all invisible from the configuration screen and all obvious in the payload.
What actually blocks a launch: five classes of finding
Classify each check before the review, not after. A finding blocks or it doesn’t based on what kind of failure it represents, and there are five kinds worth separating.
| Class | Blocks launch | Why | Example |
|---|---|---|---|
| Silent loss | Yes | Produces no complaint and no alert, so it can run for a full quarter undetected | Form submitting without writing to the CRM; a tag that never fires |
| Irreversible | Yes | Cannot be pulled back once it executes, so there is no in-flight fix | A send to the full list; a published ad pointing at the wrong offer |
| Compliance | Yes | Creates legal or contractual exposure that grows with volume | Missing unsubscribe path; a suppression list not wired to the sending platform |
| Recoverable | No | Degrades results but is fixable while live, with no loss of record integrity | Bid caps, pacing, an underperforming creative variant |
| Deferred | No | Cannot be exercised before launch at all, so failing it pre-launch is not possible | Real deliverability at volume; real rep capacity on a Monday morning |
Deferred is the class most teams get wrong, in both directions. Some treat it as a fail and hold a launch for something the environment physically cannot test. Others quietly record it as a pass, which converts a known gap into an assumption within about a week. Neither is right: a deferred item is a real obligation that moves to the first hour after launch, with a name attached to it.
A recoverable finding that ships is an accepted risk. A configured check that ships recorded as a pass is an unverified risk, and the two behave completely differently in a post-mortem. That distinction is worth its own vocabulary, which is where accepted risk and unverified risk in launch decisions goes deeper than this gate needs to.
The nine-domain campaign go/no-go checklist
Nine domains cover a campaign launch end to end. Each row states the question the gate asks, the evidence that would make it verified, and the class it falls into if it stays unproven.
| # | Domain | The question the gate asks | Evidence that counts as verified | Class if unproven |
|---|---|---|---|---|
| 1 | Offer and audience | Is the audience the intended one, with suppressions applied? | Built segment count matches the spec, and a record that should be suppressed is shown absent from it | Irreversible |
| 2 | Creative and claims | Has every claim, price and date been approved as written? | The approved version identifier matches the asset currently loaded in the platform | Compliance |
| 3 | Destination integrity | Does every destination load and accept a submission? | A submission from each destination, on mobile and desktop, produced a stored record | Silent loss |
| 4 | Tracking and attribution | Does each tag fire, on the pages that matter, in each consent state? | Debug output showing the tag fired, per page and per consent state | Silent loss |
| 5 | Capture to CRM | Does campaign data survive the write into the CRM? | The submission payload carries the campaign fields, and the resulting CRM record shows the same values | Silent loss |
| 6 | Routing and follow-up | Does a new record reach a named owner inside the response SLA? | One test record per rule reached the expected owner, with timestamps | Silent loss |
| 7 | Platform handoff | Do the record and its campaign membership survive the sync? | The same record inspected on both platforms, campaign membership intact | Silent loss |
| 8 | Consent and unsubscribe | Can a recipient opt out, and is the opt-out honored downstream? | One-click headers present in a received test message, and the suppression list wired to the sending platform | Compliance |
| 9 | Rollback and watch | Who is watching, what triggers a pull, and can it be pulled? | A named owner, a written trigger, and a rehearsed pull for each reversible channel | Irreversible |
Offer, audience and suppression
Audience is the first domain because it’s the least reversible. Once a message reaches a record, it has reached that record. Verify the segment by its count against the spec, then prove one exclusion actually excluded: pick a record that should be suppressed and show it absent from the built list. A suppression rule that exists and doesn’t apply is the same failure as no rule.
Creative, claims and destination integrity
Approval drift is the failure here, and it’s a version problem rather than a judgment problem. The asset legal approved and the asset loaded in the platform are two different objects, and the gate’s job is to confirm they carry the same version identifier. Destinations get the same treatment: load every URL in the set, submit each form, and confirm a record was stored. Testing the primary landing page and assuming the other four match is how a campaign ends up with one working destination out of five.
Tracking, capture and the CRM write
These three rows are the heart of the gate and the source of most silent loss, so they get the most specific evidence standard. Tracking is verified by observing tags fire, per page and per consent state, not by confirming the container is published. Capture is verified at the payload, because the page can carry a field the submission doesn’t send. And the CRM write is verified on the record, because a payload that contains campaign data can still land in a property nothing reads.
Link hygiene sits underneath all three, and it’s worth running as its own pass rather than a single row. The fourteen-rule UTM gate covers presence, casing, encoding, naming drift and channel-pair consistency, and it catches the class of defect that produces a clean-looking report full of duplicate channels.
Routing, follow-up and platform handoff
A captured record that nobody owns is a slower version of a lost one. Verify routing with one test record per rule, reaching the expected owner, timestamped, so the SLA claim is measured rather than asserted. Deriving that test set properly is its own job, and pre-launch routing testing covers how many cases the rules actually require. What the gate needs from it is a coverage figure and a pass.
Handoff is where campaign membership tends to disappear. Inspect the same record on both platforms and confirm the campaign association survived, because a synced contact with no campaign attached will produce clean-looking reporting that attributes nothing. The platform-side checks inside a marketing automation build, the smart lists, tokens and program membership, belong to the marketing automation QA checklist; this row only asks whether the handoff produced the right record on the far side.
Consent, compliance and the rollback plan
Compliance rows are the ones with external deadlines attached, which makes them unusually easy to verify and unusually expensive to skip. Under CAN-SPAM it becomes unlawful to keep sending to a recipient more than 10 business days after receipt of an opt-out request, and the opt-out mechanism must remain capable of receiving requests for no less than 30 days after the original message. Both are checkable before launch: send yourself a test, click the link, confirm the suppression lands where the sending platform reads it.
Gmail adds requirements that are equally checkable. Bulk senders must support one-click unsubscribe with the appropriate list headers, and Google’s guidance is to keep spam rates reported in Postmaster Tools below 0.30 percent, ideally below 0.10 percent. The headers are verifiable pre-launch by inspecting a received test message. The spam rate is not, because it doesn’t exist until you send at volume. One is a blocking compliance row and the other is a deferred row, and that split is exactly the discipline the three-verdict model is for.
Rollback closes the gate. For every channel, write down what can be pulled and what can’t, then confirm the reversible ones have actually been rehearsed. Email is the honest example: HubSpot’s documentation states that “once an email is finished processing and has been sent, it can no longer be canceled.” A scheduled send can be canceled and a delivered one cannot, which is why the audience row and the creative row hold vetoes and the bid-cap row does not.
Run the gate
With the domains fixed and the classes assigned, the run is mechanical. Work through it in order, because each step consumes the artifact the previous one produced.
Workflow · 2 hours
How to run a campaign go/no-go gate
A recorded pre-launch review that returns a verification coverage figure and a documented go, go-with-exceptions or no-go decision for a campaign that has not yet reached an audience.
Freeze the launch spec
Write down the audience definition, the destination list, the approved asset versions and the response SLA. Save it dated, so the expectation cannot move once results start arriving.
Assign a class to every check
Mark each of the nine domains silent-loss, irreversible, compliance, recoverable or deferred before you look at any result. Record the blocking list and get the launch owner to agree to it.
Collect evidence, not confirmations
Submit test records through every destination, inspect the request payloads, open the resulting CRM records, and send yourself one test message. Capture the timestamp or record ID for each.
Mark each check verified, configured or unknown
Enter the evidence reference beside anything you mark verified. If the cell is empty, the check is configured at best, whatever the screen showed.
Compute verification coverage
Divide the blocking checks that carry transaction-level evidence by the total blocking checks. Publish the figure alongside the verdict rather than inside it.
Record the verdict and its exceptions
State go, go with named exceptions, or no-go. For every exception name the owner, the watch window and the trigger that reverses the launch.
The verdict, the named exception, and the first hour
The gate ends in one of three verdicts, and the middle one carries the most weight because it’s the one most launches actually earn. Stating it as a verdict rather than a score keeps the open items visible after the campaign is live.
Verification coverage, not a pass rate
Coverage is the one number worth publishing, and it counts evidence rather than confirmations.
Verification coverage % = blocking checks with transaction-level evidence ÷ total blocking checks × 100A pass rate that counts configured checks as passes will read close to 100 percent on almost every campaign, which is precisely why launch reviews feel reassuring and stop nothing. Coverage will read lower and it will move, which makes it useful. Six of nine blocking checks verified is 67 percent, and that’s a sentence somebody can argue with, budget against, or accept on the record.
The named-exception record
Use no-go when any blocking check is not verified. Use go with named exceptions when every blocking check is verified and each recoverable or deferred item carries an owner, a watch window and a reversal trigger. Use plain go only when nothing is open. Avoid a fourth verdict, and specifically avoid conditional approval with no named owner, which is how a deferred item becomes an assumption.
Whoever signs the verdict should be whoever carries the consequence. In most teams that’s the marketing ops owner rather than the campaign manager who built it, for the same reason you don’t ask an author to copy-edit. The record itself is short: verdict, coverage figure, blocking checks and their evidence references, open exceptions with owners, and the reversal trigger.
PRO TIP
Write the reversal trigger as a number and a time, not an intention. “Pause paid social if cost per lead exceeds $180 in the first 48 hours” is a trigger. “Monitor performance closely” is a sentence that has never stopped a campaign.
The first hour after launch
Every deferred row comes due in the first hour, and the checks are a subset you’ve already built. Send one record through each critical path against real reps, real capacity and real deliverability, then read the owner fields and the timestamps. Delay costs real money at this point in a way it doesn’t in a test environment, which is the argument for keeping the first-hour set small and rehearsed. The evidence on what that delay is worth sits in the speed-to-lead research.
From there the campaign stops being a change and becomes a system, and the assurance question moves from prevention to detection. The same defects, found three months later against records that already went cold, are the subject of a routing audit. Catching them at the gate is the cheap version of that work.
Download the campaign launch go/no-go record
The table above is the whole gate, so nothing here is withheld. The download exists because a launch decision needs to be an artifact somebody else can read: the workbook holds the nine domains with a verdict dropdown per check, computes verification coverage, and returns the verdict, while the one-page record is the signed version with the exceptions, owners and reversal trigger on it.
It’s deliberately not a task list, and it’s deliberately not weighted. There’s no total to maximize, because a launch gate that can be optimized is a launch gate that can be gamed.
Cite it as: IVRIS Tech, Campaign Launch Go/No-Go Record (2026).
Frequently Asked Questions
Nine domains: offer and audience with suppressions, creative and claims, destination integrity, tracking and attribution, capture into the CRM, routing and follow-up, platform handoff, consent and unsubscribe, and the rollback plan. Each item names the evidence that satisfies it and whether it blocks the launch.
Yes. The full nine-domain gate is published in the table above at no cost and needs no download. A spreadsheet version with a verdict dropdown and an automatic coverage calculation, plus a one-page PDF launch record, are linked in the download section.
A launch checklist tracks whether work was completed. A go/no-go checklist records what evidence proves the work functions, and blocks the launch on unproven items. The first can be fully ticked while the campaign is broken; the second cannot return a clean go in that state.
Whoever carries the consequence of a bad launch, which in most teams is the marketing ops owner rather than the campaign manager who built it. Channel owners and legal supply evidence for their own rows, but one named person signs the verdict and the exception list.
An RFP go/no-go decides whether to pursue an opportunity, so weighted scoring fits: a strong margin genuinely offsets a weak incumbent relationship. A campaign go/no-go decides whether execution is proven, and nothing offsets a silent failure that collects no leads. One compares options; the other applies vetoes.
Methodology and sources
Platform and regulatory claims here were verified against primary sources in July 2026. The 10-business-day opt-out deadline and the 30-day minimum lifespan for an opt-out mechanism come from the CAN-SPAM statute at 15 U.S.C. 7704. Spam-rate guidance and the one-click unsubscribe requirement come from Google’s email sender guidelines. The statement that a delivered marketing email cannot be canceled comes from HubSpot’s own knowledge base, and the description of what preview and debug mode verifies comes from Google Tag Manager’s documentation. Vendor behavior changes; re-check the linked pages before relying on a specific threshold.
The form-capture figures are IVRIS’s own primary research, tested on 17 June 2026 against a subsample of 20 forms with definitive payload results, drawn from a wider audit of 150 public B2B forms. The reported 47 percent sensitivity carries a 95 percent Wilson interval of 26 to 69 percent, so treat it as evidence that page-level scanning is unreliable rather than as a precise industry rate.
The nine domains, the five classes and the verification coverage formula are IVRIS constructions, not published standards. Coverage is stated as a floor rather than a sufficiency claim: full coverage of the blocking checks is the point below which a launch decision is not interpretable, not a guarantee that the campaign will perform. We looked for a published defect rate for marketing campaign launches and found only vendor self-reports with no stated error criteria or sample methodology, so no such figure is quoted here.
