A marketing automation planning template with a rule card and a metric specification

This marketing automation planning template is designed for one proposed rule or journey. Copy the fields into the team's controlled workspace and replace every bracketed prompt. An unanswered gate is a reason to pause, not permission to assume.

What to take away

An unanswered gate is a reason to pause the plan, not permission to assume.
Keep observations and assumptions in separate rows so the causal route stays visible.
Record whether a missing input excludes, queues for review or uses an approved default.
Complete a separate metric card for every outcome, guardrail and diagnostic.
The release gate passes only when owners can reproduce the rule, metrics and rollback.

Decision record

Field / Entry

Decision to make: [What will this plan allow the owner to approve or reject?]
Process owner: [Named role]
Analyst: [Named role]
Proposed audience: [Eligibility and geography]
Excluded population: [Who must not enter and why?]
Current problem: [Observable condition, baseline period and source]
Chosen intervention: [One bounded change]
Options deferred: [Alternatives and reason]
Review date: [Date]

Keep observations and assumptions in different rows. The 2026 Magenta Book recommends exposing the causal route, evidence strength and alternative explanations when planning evaluation.

Rule card

Record the trigger event, source system, required fields, eligibility test, channel, action, timing and frequency cap. Add suppression sources, conflict priority, manual-review point, exception owner, failed-record route, version number, pause switch and rollback step.

Rule Card Logic Flow

Trigger event and source system
Required fields and eligibility test
Channel, action and timing
Frequency cap and suppression sources
Conflict priority and manual review
Failed-record route and rollback

For each input, state whether absence means exclude, queue for review or use an approved default. Never let a blank value silently select a marketing action.

Where the rule card sits in the stack

The trigger and action rows map onto features that already exist in the main platforms. HubSpot workflows enrol records on criteria and branch on contact properties; Klaviyo flows start from a trigger and split on profile data; Braze Canvas and Salesforce Marketing Cloud Journey Builder both start from an entry event; Mailchimp customer journeys start from a starting point; Marketo smart campaigns fire from a trigger. Record next to the trigger which of these runs the rule, which connector or integration supplies the source fields, and whether that sync runs in real time or on a schedule.

Two platform behaviours belong on the card. A contact can sit in more than one workflow or journey at the same time, so the conflict-priority row must name the order and the owner who decides it. Suppression is also split: a platform-wide unsubscribe list, a channel-level block and an ad audience exclusion are three separate switches, and the card should say which one is checked before each send.

Metric specification

Complete a separate card for every outcome, guardrail and diagnostic:

Metric card field	Entry
Metric name and decision it informs	[Name of the metric; the decision it changes]
Numerator	[What is counted, and in which platform report or warehouse view]
Denominator	[The eligible population the numerator is divided by]
Eligible population and exclusions	[Who is in scope; who is out and why]
Event source, time zone and attribution window	[Source system or platform report; time zone; window]
Reporting period and comparison period	[Dates for both periods]
Data owner and quality check	[Named role, reconciliation step and who signs it off]
Review trigger and action when triggered	[Threshold, who is alerted, what they do]

Rebuild the numerator and denominator from the same event source before anyone reads the rate. Platform dashboards define events differently from one another, so the definition on the card, not the default report label, is what the team reports against.

The GOV.UK Service Manual's performance guidance says the method should match what the team is trying to learn and that metrics may need to be combined with user research. Its public-service context does not supply a private marketing benchmark.

Permissions and data sheet

Keep the permissions and data fields in the same row-per-field format, with personal-data fields and the lawful basis in separate rows:

Field / Entry

Purpose: [Why this rule processes personal data]
Personal-data fields: [Each field, its category and its sensitivity]
Source: [Where each field comes from]
Retention: [How long it is kept and what deletes it]
Recipients: [Who receives the data, including any processor]
Processor: [Named processor and the contract in place]
International-transfer review: [Transfer, safeguard and the decision taken]
UK GDPR lawful basis: [Basis, why it applies, who approved it]
PECR rule for the chosen channel: [Soft opt-in, consent or exception, and the wording used]
Consent or exception evidence: [Where the record sits]
Objection handling: [How an objection is captured and applied]
Suppression tests: [Test, result and date]

The ICO says organisations must determine and document the basis before processing in its current lawful-basis guide. Do not use a generic "consent" field to cover lawful basis, electronic-mail permission and research participation at once.

Journey quality sheet

The sheet is one row per journey step, with a tester and an evidence location named against each:

Journey step	Tester	Evidence location
Message	[Named role]	[File or link]
Landing page	[Named role]	[File or link]
Form	[Named role]	[File or link]
Validation error	[Named role]	[File or link]
Confirmation	[Named role]	[File or link]
Alternative route	[Named role]	[File or link]

Use the W3C WCAG 2.2 recommendation as a technical reference for web content, while asking a qualified reviewer which legal and contractual requirements apply.

Include keyboard, focus, label, error, reflow and status-message checks where relevant. An automated report alone cannot establish that a complete journey is usable.

Approval and change log

Create a row for legal, data protection, advertising, accessibility, security, AI and commercial review as required. Each row needs a named reviewer, evidence examined, decision, conditions, date and expiry. Then log every change to data, audience, rule, message, model, supplier or integration.

The release gate passes only when owners can reproduce the rule, metrics and rollback. If a reviewer declines, a suppression test fails or the denominator cannot be rebuilt, record the stop and return the plan to its owner.

Dry-run the document

Give the completed template to a colleague who did not design the journey. Ask them to identify one eligible record, explain why an excluded record stays out, calculate the main measure from sample events and locate the pause control. They should also be able to name the person who decides each unresolved exception.

Record every point that required an oral explanation. That gap belongs in the template or operating procedure before approval. Schedule a fresh dry run after a material change rather than treating the first exercise as permanent assurance.

Before you act

Copy the fields into the team's controlled workspace.
Replace every bracketed prompt before approval.
Document the lawful basis before processing personal data.
Assign a tester and evidence location to each journey step.
Dry-run the completed template with a colleague who did not design the journey.
Log every change to data, audience, rule, message, model, supplier or integration.

Common questions

What should happen when a gate in the template is left unanswered?

An unanswered gate is a reason to pause, not permission to assume. The template tells you to replace every bracketed prompt and to keep observations and assumptions in different rows, so a blank field cannot quietly become a decision.

How should a missing input be handled in the rule card?

For each input, state whether absence means exclude, queue for review or use an approved default. The article warns that a blank value must never silently select a marketing action, so the route for missing data is written down in advance.

What does the dry run test, and what happens to gaps it exposes?

A colleague who did not design the journey must identify an eligible record, explain an exclusion, calculate the main measure and locate the pause control. Record every point that needed an oral explanation, because that gap belongs in the template before approval.