CRM Pre-Send QA: A Practical Framework
A practical CRM pre-send QA framework covering audience logic, suppression, personalisation, send setup and evidence-based approval.
Max Rozmetov
CRM Systems & Automation Specialist
CRM pre-send QA should answer one question: is this campaign safe to release? A useful review does more than confirm that somebody completed a checklist. It tests the audience, exclusions, content, configuration and evidence behind the decision.
After seven years working across fintech and insurtech CRM, I have seen how quickly a familiar process can become unreliable. Campaign volume increases. Journeys gain branches. Suppression rules spread across platforms. Personalisation becomes more ambitious. The checklist stays the same while the system around it changes.
This framework turns the final review into a structured release decision. It is platform-neutral, but the examples reflect the realities of Salesforce Marketing Cloud and regulated CRM teams.
Start with the campaign contract
Before checking the build, establish what the campaign is meant to do. The brief is the contract against which every later check should be tested. If the objective, audience and exclusions are unclear, the reviewer cannot distinguish a defect from an undocumented decision.
Record the expected audience, permitted channels, intended send time, commercial objective and owner. Add the source system and the version of the brief being reviewed. A screenshot without context proves that a screen existed. It does not prove that the configuration matched the approved plan.
- Objective and measurable outcome
- Target audience and explicit exclusions
- Channel, sender, timing and frequency limits
- Approved offer, content version and personalisation rules
- Named owner and reviewer
Test audience logic, not just the final count
A plausible audience count can hide incorrect logic. Two errors may cancel each other out and leave a total that looks normal. Review the construction of the audience before accepting the number it produces.
Compare the final count with a reasoned expectation. Break it into included, excluded, suppressed and duplicate records. Sample edge cases, not only typical customers. Check people near date boundaries, customers with multiple products, recently changed preferences and records that satisfy conflicting rules.
Keep the query, filter or segment definition with the review evidence. If the audience changes between approval and send time, the team should be able to identify what changed and decide whether approval still holds.
Treat suppression as a control system
Suppression is not a single checkbox. It is a chain of controls covering consent, objections, product eligibility, complaints, operational exclusions and contact policy. Each source needs a defined owner, refresh schedule and matching key.
The Information Commissioner's Office advises organisations to keep a suppression or do-not-contact list so that people who object to marketing are not contacted again. Salesforce distinguishes auto-suppression, suppression and exclusion lists, which can behave differently depending on the sending method and account configuration.
For every send, verify which controls apply automatically and which require manual selection. Record the extraction time and row count for each source. Test the match key. A current list joined on the wrong identifier is not a functioning control.
- Confirm consent and objection rules for the audience
- Verify suppression freshness and ownership
- Check the join key and treatment of missing values
- Reconcile excluded counts against expectations
- Retain evidence of the controls applied at send time
Exercise personalisation with hostile test data
A successful test using a clean internal record proves very little. Personalisation fails at the edges: missing names, unexpected punctuation, long company names, conflicting product states, empty recommendations and values that were never intended to appear in customer-facing copy.
Create a small test pack that deliberately contains those cases. Confirm fallback behaviour and escaping. Check the subject line, preheader, body, links and plain-text version. Where content changes by segment, capture evidence for every material branch rather than the easiest one to reach.
The standard is not that the template renders. The standard is that no realistic customer record can produce misleading, broken or sensitive output.
Review the send configuration as production code
Campaign content receives most of the attention, but configuration errors can have a larger blast radius. Confirm the sender identity, reply handling, send classification, business unit, target data source, exclusions, time zone, throttling and journey entry settings.
Separate reversible issues from release blockers. A minor spacing defect may be acceptable with a recorded decision. An unexplained count movement, stale suppression source or broken fallback should stop the send. Severity must reflect customer and regulatory impact, not how quickly a defect can be fixed.
- Sender, reply address and send classification
- Target audience and selected exclusions
- Schedule, time zone and frequency controls
- Journey entry, re-entry and exit behaviour
- Tracking, link destinations and analytics parameters
Make the approval defensible
Approval should leave a record that another person can understand later. Store the campaign version, evidence reviewed, material findings, fixes, remaining risks, reviewer and timestamp. If a finding is accepted rather than fixed, record who accepted it and why.
This changes QA from a ceremony into governance. It also makes retrospectives useful. When an incident occurs, the team can see whether the control was missing, the evidence was wrong, the reviewer missed a signal or the campaign changed after approval.
The same record creates a basis for improving the system. Repeated findings should become automated checks. Rare, ambiguous cases should remain with experienced reviewers. Deterministic controls and human judgement are complementary when the boundary between them is explicit.
The standard for release
A reliable CRM pre-send QA process does not depend on a longer checklist. It depends on clear campaign intent, inspectable audience logic, functioning suppression controls, adversarial personalisation tests, verified configuration and a retained decision record.
Start with the highest-consequence sends. Define the evidence required for approval and the conditions that must stop release. Then use recurring findings to improve the controls upstream. That is how QA scales without becoming superficial.
CRM pre-send QA questions
What should a CRM pre-send QA checklist include?
It should cover the approved brief, audience logic, expected and actual counts, suppression controls, personalisation edge cases, sender and scheduling configuration, links, tracking and a named approval record.
Who should approve a CRM campaign?
The reviewer should be independent enough to challenge the build and experienced enough to understand its customer impact. High-risk campaigns may also need legal, compliance or data-owner approval, depending on the organisation's control model.
Can CRM pre-send QA be automated?
Counts, required fields, suppression freshness, link checks and configuration rules are good candidates for deterministic automation. Ambiguous audience intent, content risk and accepted exceptions still require accountable human judgement.
How should teams retain campaign QA evidence?
Keep a versioned record of the brief, audience and suppression evidence, test outputs, findings, fixes, reviewer, decision and timestamp. The record should show what was approved and whether anything changed before release.
Related project
Anveal: pre-send governance for regulated CRM teams
See how I turned this operating problem into a working governance workflow with deterministic checks, model-assisted review and a retained report.
Read the Anveal case study →