The email campaign QA checklist for regulated CRM teams

An email campaign QA checklist for a regulated team has to cover seven surfaces: audience and counts, suppression and consent, timing and journey logic, personalisation, content and claims, links and tracking, and the evidence that the checks actually happened. Subject lines and rendering matter, but they are the least dangerous part of a regulated send. The failures that reach customers, and sometimes regulators, live in the audience SQL, the suppression export date and the journey configuration.

This guide sets out the full pre-send checklist, the regulatory context behind each check, and the failure patterns I have seen in real regulated CRM programmes. It is written for CRM leads and lifecycle managers in financial services, insurance, utilities and any other sector where a wrong send is more than an embarrassment. Nothing here is compliance advice or a substitute for your own sign-off process. It is the working checklist I wish someone had handed me earlier.

The email campaign QA checklist at a glance

Here is the condensed checklist. Every item is expanded below with the regulatory context, the business risk and the practical steps in tools like Salesforce Marketing Cloud, Braze and HubSpot. Run it against the campaign brief, not against memory. The brief is the contract for what the send is allowed to be; QA is the act of holding the built campaign to it.

Why most QA checklists test the email, not the send

Most published QA checklists concentrate on the email itself: subject line length, preview text, image weight, dark-mode rendering, spelling. Those checks are worth doing, and they are also the checks least likely to hurt anyone. A broken hero image embarrasses the team. A stale suppression file contacts someone who told you to stop, or someone recently bereaved. In a regulated firm those are different categories of failure, and the second kind is the one your compliance function will be asked about. The FCA’s Consumer Duty expects firms to avoid foreseeable harm to retail customers, and a mis-targeted send is about as foreseeable as harm gets. Yet the harm-bearing surfaces, audience logic, suppression currency and journey configuration, are exactly what generic checklists skip, because they cannot be checked from inside the email. They can only be checked against evidence: the brief, the SQL, the counts, the export dates.

That is the organising principle of this checklist. Check the send first. Then check the email.

Audience and counts: does the export match the brief?

The audience check answers one question: is the set of people in the export the set of people the brief describes, and no one else? Start with the number. If the brief approves 5,000 recipients and the export holds 7,200, stop until the gap has a written explanation. Then check the source. The SQL or segment should reference the production table or data extension named in the brief, not a copy and not a test object. Finally, read the exclusion logic line by line and check the polarity of every flag. This takes minutes, and it is the highest-value block on the whole checklist, because audience failures put the wrong message in front of the wrong customers at scale. Under the Consumer Duty, sending to people the brief never authorised is not a technicality. It is the definition of a foreseeable, preventable harm.

Three audience patterns recur in real programmes. The first is the test artefact: an audience query that quietly references a test data extension left over from a UAT cycle, still holding synthetic records mixed with real addresses. It survives review because the object name looks plausible. The second is inverted exclusion logic. A single operator, = ‘Y’ where the brief means everyone except ‘Y’, selects precisely the opted-out customers the campaign was supposed to protect, and it passes any check that only looks for the opt-out field being present. The third is the count mismatch that gets explained away. A join fanning out on a household identifier will inflate an export, and the difference gets waved through as deduplication because nobody asks to see the join.

In Salesforce Marketing Cloud, open the query activity and confirm the source and target data extensions by name against the brief; the activity label is not evidence. In Braze or HubSpot, open the segment or list definition, re-read every filter, then compare the live membership count with the brief before the send is scheduled. Record both numbers in your QA note.

Suppression and consent: the checks that protect people

Suppression is where pre-send QA earns its keep, because suppression failures contact people who have a legal or a moral right not to hear from you. The check has two halves. Coverage: are all the standard exclusion lists applied to this campaign, including the ones this campaign type makes tempting to skip? Currency: how old is each suppression file, measured from its export or refresh date to the planned send date? UK GDPR and PECR make opt-out and consent handling a legal requirement rather than a courtesy; the ICO’s direct marketing guidance is the primary reference. The business risk scales badly too. A suppression failure is rarely one contact; it is every contact added to the list since the stale file was cut, and that group skews towards the people most likely to complain again.

The stale export is the pattern I have seen most often. A campaign is ready, the current suppression list is “still being built”, and last month’s file gets attached so the send can go out. The gap between those two files is exactly the set of people who complained or opted out most recently. A subtler version is the sync-lag window: the suppression export runs weekly on one day, a central register updates on another, and a midweek send falls between them, which is how a deceased flag set on Tuesday misses a Wednesday campaign. Preference-centre changes have the same failure mode. If the campaign suppression table is built from a snapshot, a customer’s opt-out can exist in the master data model and still be absent from the send.

In Marketing Cloud, check the completion timestamp of the automation that builds each suppression data extension and compare it with the send date. In Braze, confirm the campaign respects the global unsubscribe state and any custom suppression segments. In HubSpot, check the exclusion lists attached to this send, not just the ones that exist in the account. For win-back and re-engagement campaigns, confirm the complaint-list join is present: lapsed customers can and do have open complaints, and briefs almost always say “all standard suppressions apply”.

Timing and journey logic: when the send fires

Timing checks confirm that the send fires when the brief says it should, for every recipient, and that automated journeys still mean what the team thinks they mean. Verify three things. First, the schedule honours any quiet-hours rule in the recipient’s local time; a journey configured in UTC will breach a “not before 9am” brief for part of the audience while looking correct in the console. Second, re-entry and exit criteria: a customer who completes the goal elsewhere, by renewing online for example, must actually leave the journey rather than receive a reminder for something already done. Third, decision splits survive data model changes; a split whose field has been removed can default silently down one branch and fire an offer at everyone who passes through it. None of these appear in an email proof. All of them appear in the journey configuration, if someone reads it.

The regulatory frame is the same foreseeable-harm test, alongside the CAP Code’s requirement that marketing be prepared with a sense of responsibility to consumers. The commercial cost is quieter but real: double sends and mistimed reminders teach customers to ignore you, and remediating a mistimed regulated notice can mean re-sending the whole programme at your own expense. In Journey Builder, open the re-entry settings and exit criteria and check them against every event that should remove someone; reaching the goal does not automatically exit people. In Braze, compare the quiet hours and local-timezone delivery settings against the brief’s exact wording. After any data model change, list every journey that references the changed field and re-validate its splits before the next send.

Personalisation and rendering: what each customer actually sees

Personalisation checks confirm the message renders correctly for the records at the edges, not just the neat ones in the seed list. Every token needs a fallback, every conditional needs a branch for every live value, and every language or regional variant needs a default that matches the requirement rather than whatever the platform falls back to. “Dear ,” at the top of a regulated notice reads as carelessness to the customer and to everyone the customer forwards it to. Under the Consumer Duty’s consumer understanding outcome, communications should equip customers to make decisions, and a template that renders an empty block for a whole product tier fails that test in a visible way. The QA step is mechanical and cheap: preview against deliberately imperfect records, and enumerate the values your conditionals must handle before anyone asks whether they do.

The recurring patterns here: a first-name token shipped without a default, so every null attribute renders “Dear ,” in production. A new product tier added to the data model with no matching branch in the template conditional, so those customers receive an empty section where their benefits should be. A language fallback that quietly defaults to English for records with a null language attribute, against a requirement that a specific segment default the other way. Each of these lived in the template or the schema, not in the copy deck, which is why copy review never catches them.

In Marketing Cloud, give every AMPscript personalisation string an explicit default and check the delimiter balance before the template is signed off. In Braze, put Liquid’s default filter on every attribute token. Everywhere, preview against a record with null attributes, and treat a clean render for that record as the pass condition.

Content, claims and links: what the email promises

Content QA in a regulated team is a scope check before it is a style check. Every factual claim in the copy must trace to something the brief authorised: a price promise, a rate figure, a product feature, a deadline. Copy that promises premiums will not rise, when the brief authorised only a renewal reminder, is not a tone problem. In a financial promotion it is the kind of statement the FCA’s fair, clear and not misleading standard exists for, and the CAP Code applies the same discipline to marketing communications generally. Links carry equal weight. A preference-centre link that returns a 404 because the template hardcoded a previous brand domain means the customer cannot complete an unsubscribe, which turns a housekeeping error into a PECR problem. And if the brief requires trackable links, stripped UTM parameters mean the send cannot be measured or evidenced afterwards.

The steps are unglamorous. Read the copy next to the brief and flag any claim without an authorised source. Click every link in the final rendered proof, in the sending environment rather than the design file. Complete an unsubscribe end to end, all the way to the confirmation state. Diff the tracking parameters on the final links against what the brief requires, because undocumented removal is still removal.

Evidence and sign-off: proving the QA happened

The last item on the checklist is the one that protects the team: a record that the checks happened, made at the time, kept somewhere retrievable. Screenshots in a chat thread are where QA evidence goes to die; the thread scrolls away, and six months later nobody can show what was verified against which files. A useful QA record is small. Campaign name. What was checked. Which evidence files, with their dates. What was found, what was fixed, what was accepted as a risk and by whom. Who signed. The ICO’s accountability principle and the FCA’s record-keeping expectations both reward being able to show your working. One framing discipline matters more than any tooling choice: a passed checklist is a decision-support record, not an approval certificate. No pre-send review, human or automated, guarantees a compliant send. The record shows that the team looked, what it saw, and who made the call.

One structural rule follows from everything above: the person who built the audience should not be its only checker. A second reader who comes to the SQL cold spots the inverted flag and the fanned-out join, because the builder is the worst-placed person to catch their own assumptions.

Final tip: turn every incident into a checklist line

The strongest pre-send checklist is not downloaded; it is accumulated. Every near-miss and every incident in your programme should end as a permanent line on the checklist, together with the evidence that would have caught it. The checklist above is exactly that: the sediment of real failures. Yours should grow the same way. When a fix is made under pressure, the pressure passes and the lesson evaporates unless someone writes the check down in the same week.