Building a Useful CRM Campaign Decision Record
A practical structure for recording CRM campaign evidence, findings, approvals and accepted risk without creating administrative theatre.
Max Rozmetov
CRM Systems & Automation Specialist
A CRM campaign decision record should explain why a send was approved. It is not a folder of screenshots and it is not a completed checklist with no context. It connects the campaign intent, evidence, findings and accountable decision.
The record needs to be quick enough for routine use and complete enough for another person to reconstruct the decision later. That balance is what turns campaign QA into governance.
Record the campaign version under review
Begin with a stable identifier, campaign owner, channel, planned release time and the exact content, audience and configuration versions reviewed. If any of those change after approval, the record must show whether re-review is required.
Links to live assets are useful for navigation but weak as evidence. Store immutable exports, hashes or version references for the material elements of the send.
Capture evidence, not activity
Evidence should demonstrate that a control worked. For audience logic, retain the rule and reconciliation. For suppression, retain source timestamps and removed counts. For personalisation, retain representative outputs and edge cases.
A screenshot showing that somebody opened a settings page proves activity, not correctness. Add the expected state, observed state and conclusion so the evidence can be interpreted without relying on memory.
Write findings as testable statements
A useful finding identifies the condition, evidence, consequence and required action. 'Counts look wrong' is not enough.
'Final audience is 18% above the approved range because the closed-account exclusion did not refresh' gives the team something it can resolve and retest.
Classify severity by customer, regulatory and commercial impact. Do not use severity as a proxy for effort. A one-line configuration error can create a large incident.
Distinguish fixing from accepting risk
Every material finding needs a recorded disposition: fixed and retested, accepted for a stated reason, or release blocked.
Accepted risk needs an accountable owner and a clear expiry. Otherwise a temporary exception becomes an undocumented standard.
The reviewer should have authority to stop release. Approval without the ability to challenge is a notification step, not a control.
Design the record for learning
Use consistent finding categories so recurring defects can be measured. Repeated suppression freshness issues point to an upstream reliability problem. Repeated personalisation failures point to missing test data or weak template contracts.
The ICO's accountability guidance emphasises keeping decision records and demonstrating how information is used.
A well-designed campaign record also gives CRM teams the operational history needed to improve their controls.
The standard for release
A useful decision record answers four questions: what was reviewed, what evidence supported it, what problems were found and who decided to release. Everything else should earn its place by making those answers clearer.
Keep the structure stable, automate evidence collection where possible and use the findings history to remove recurring failure modes.
CRM pre-send QA questions
What belongs in a CRM campaign approval record?
Include the campaign version, approved brief, audience and suppression evidence, test outputs, findings, fixes, accepted risks, reviewer, approver and decision timestamp.
How long should campaign evidence be retained?
Retention should follow the organisation's legal, regulatory and records-management requirements. Define the period centrally rather than leaving individual campaign owners to decide.
Does every campaign need the same level of evidence?
No. The evidence should be proportionate to risk, but the decision structure should stay consistent. Higher-risk sends need deeper testing and more explicit approval gates.
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 →