The campaign QA checklist we run before every send

Nearly every campaign disaster we have been asked to help with was caused by something small and checkable. A segment saved with the wrong operator. A personalisation token that rendered as raw syntax for every record with a blank name field. A link to a staging domain that nobody clicked because everyone was reading the copy.

None of them were creative failures, and none were caught by an approval process that consisted of forwarding a preview to three people and waiting for replies saying "looks good".

What follows is the checklist we run before every send. It is deliberately boring, it takes about forty minutes on a standard campaign, and it is the same list whether the send is twelve thousand people or two million. The value is in running it the same way every time, so the step that gets skipped is visible.

Count the audience twice, from two directions

Start with the audience, because it is the only error you cannot correct after the fact. Everything else can be followed by a fix; the wrong recipients cannot be un-received.

1. Pull the count in the sending platform and, separately, from the warehouse or a second query. If the two disagree by more than a rounding difference, stop and find out why before anything else happens.
2. Read the segment definition out loud, in words, to another person. Ambiguity between "and" and "or" survives every visual builder ever made but rarely survives being spoken.
3. Compare the count with the last comparable send. A change of more than a quarter in either direction needs an explanation, and "we grew" is not one unless someone can point to the growth.
4. Confirm the suppressions are attached: global unsubscribes, complaints, hard bounces, deceased and data-request suppressions, plus any campaign-specific exclusions.
5. Check the overlap with anything else going out in the same window, so that a customer is not receiving three messages within an hour from three different owners.
6. Export twenty real records from the audience and read them. Not a preview — the actual rows, with the fields the template will use.

That last step catches more than the other five combined. It is also where you notice that a segment you inherited quietly includes test accounts, internal staff or a cohort that should have aged out. Definitions drift, and the cohort work we described in cohorts that change the roadmap is only trustworthy if the underlying segments are re-read occasionally rather than reused on faith.

Render it where people actually read it

Preview panes lie. They render a simplified version of a message in a browser, and browsers are not mail clients.

Send to a seed list that covers the clients your audience genuinely uses, which you should confirm from your own data rather than from an industry summary. For most programmes that means the two dominant webmail providers, the desktop client your corporate recipients use, and iOS and Android mail apps on real devices.

Then check, on each:

• Subject line and preheader as they truncate on a phone, not as they appear in the platform field.
• Dark mode. Logos with white backgrounds and text set in near-black are the usual casualties.
• Images off. The message must still make sense and still have a clickable route through.
• Alt text present on every image that carries meaning, and absent on decorative ones.
• Plain-text version, which is still generated in many stacks by a converter that produces unreadable output nobody has looked at in two years.

For anything with dynamic content, the seed test is not enough. Build a proof list containing one real record per variant, plus the edge cases. The empty field, the very long product name, the customer in a different currency, the person whose only qualifying purchase was returned. Send to that list and read every version.

Set a default for every token and check the default renders sensibly. "Hi there" is a perfectly good fallback; the token name in curly braces is not.

Click every link with tracking switched on

Read the message as a recipient would and click everything, in the seed version rather than in the preview, so tracking parameters are present.

What this catches: staging and localhost URLs, expired campaign pages, redirects that drop the tracking parameters. Also links to a category that sold out this morning, and footer links copied from a template built for another market.

Confirm the tracking parameters match the convention your reporting expects, exactly, including case. A campaign tagged inconsistently is not merely untidy. It lands in a different bucket in every downstream model, and the channel inputs feeding work like marketing mix modelling for CRM teams are only as good as the tagging behind them.

Check the unsubscribe path last, and check it properly. Click the footer link and confirm the page loads, is legible on a phone and does not require a login. Separately, use the mailbox provider's own control to confirm one-click unsubscribe works from the headers and that the suppression reaches your platform.

The technical checks nobody enjoys

These are quick, and they are the ones that protect the programme rather than the campaign.

• From-name and from-address correct for this stream, and the reply address monitored by a human or routed to the service desk.
• Sending domain and stream correct, so a promotional campaign is not going out over the transactional path.
• Authentication passing on the seed messages, checked in the received headers rather than assumed from last month's configuration.
• Message size within the limit at which the dominant webmail provider clips the content, since a clipped message hides the footer and the unsubscribe link.
• Rate and throttling settings appropriate to the volume, particularly for a send larger than your usual pattern, because deliverability problems often start as queueing problems.
• Any test sends and internal addresses removed from the audience before scheduling.

Sign-off, timing and who is holding the switch

Sign-off should name a person per area rather than collecting general approval. In practice that is one owner for audience, one for content and offer accuracy, and one for the technical checks. Three names, recorded against the campaign, with the time they signed.

Check the schedule in the recipient's time zone, and check the day. The most common scheduling error we see is a send set for the correct clock time in the wrong zone, and the second is a campaign scheduled on a date that a public holiday has moved.

Before the send goes into the queue, confirm two things out loud: who can stop it once it starts, and whether they have the permissions to do so. Test that assumption on a quiet day rather than discovering it during a live incident.

The first half hour after you press send

The checklist does not end at the send. Someone stays with it for thirty minutes and watches the delivery rate, the bounce rate, the early complaint signals and the destination page's server response.

A landing page that falls over under the opening burst is the failure most often missed, because everyone is watching the email platform. Have the page owner watching their own dashboard at the same time, and agree in advance what the two of you do if either number looks wrong.

The hard part of all this is not writing the list. It is keeping it in use when the campaign is late and the deadline was yesterday, which is precisely when the errors happen. Put it in the workflow tool as a real gate with the three names attached, not in a document that people intend to open.