Template
Marketing Automation Planning Template
Updated · By Amir Mousavi
A marketing automation planning template is a one-page plan, completed before any journey is built, that fixes the objective, the audience rules, the trigger and cadence, the channels and their consent, every exit, and the measurement method for one automated program. This version has six sections. Each section lists the fields to fill, shows them completed for a real program type, and names the mistake that section exists to prevent.
Quick answer
Fill the six sections in order — objective, audience, trigger and timing, channels and content, exits and handoff, measurement and ownership — one program per copy. A field may hold a value or an explicit “not applicable, because…”; it may not be blank. The plan is finished when the program owner has signed it, a review date is on it, and the measurement section names a holdout group rather than a last-touch report.
It is written for the person who has to make an automation tool — HubSpot, Marketo, Braze, Adobe Campaign, Salesforce Marketing Cloud, Klaviyo, or any of their peers — do something specific, and for the stakeholders who have to agree on what that something is. It is tool-agnostic on purpose: every field maps onto a setting in every platform I have configured, and the ones that do not map are the ones that cause incidents.
How to use this template
The template is a contract between the people who want the program and the people who build it. Treat it that way:
- Copy the plain-text version at the end of this page into the document or ticket where the program will be approved. One program per copy; a “welcome series” and a “win-back” are two plans, not one.
- Fill the sections in order. Objective before audience, audience before trigger. A trigger chosen first tends to define the audience by accident.
- Write field names and system names, not concepts. “Active customer” is a phrase; “status = active in the billing system, as of the nightly sync” is a rule someone can test.
- Where a field genuinely does not apply, write “N/A” and the reason. An empty field is indistinguishable from a forgotten one.
- Run the pre-launch review below against the finished plan, then have the named owner sign it. The signature is what turns a document into a decision.
- Store the plan where the program lives — most tools have a description field on the journey — and treat edits to entry rules or cadence as changes that reopen it.
The third column of every table shows the fields completed for one program so the level of detail is clear: an abandoned-checkout recovery sequence for an online retailer selling in Canada and the United States, running email first and SMS second. The numbers are illustrative; the shape of the entries is the point.
1. Objective and success metric
State the one business outcome the program exists to move, the metric that will prove it moved, the baseline that metric is measured against, and the date on which someone will decide whether to keep, change, or kill the program.
| Field | What to write | Completed example |
|---|---|---|
| Business outcome | One outcome, in the language the business already reports on. Not three. | Recover revenue from abandoned checkouts. |
| Primary metric and method | The number that proves the outcome moved, and how it will be isolated from everything else happening at the same time. | Incremental completed orders within 72 hours of the trigger, measured against a 10% randomized holdout that enters the program but receives no messages. |
| Baseline | The metric’s value before launch, with the period it was measured over. If none exists, say so and treat the first cycle as the baseline. | 9.8% of abandoned checkouts complete on their own within 72 hours (trailing eight weeks, no recovery program running). |
| Target and decision date | The change you are aiming for and the date the keep/change/kill decision will be taken. | +3 points absolute recovery rate versus the holdout within 90 days of launch; decision on 30 November. |
| Constraints | Budget, brand, legal, or commercial limits the program must respect even if they cost performance. | No discount in the first two messages. A code may appear in message 3 only for carts over $80 and only once per customer per quarter. |
What goes wrong here
- Three objectives in one program. A program asked to recover revenue, educate the market, and re-engage dormant accounts at once will be judged against whichever goal it happens to miss. Split it.
- A baseline recorded after launch. Once the program is running there is nothing honest left to compare against. Pull the baseline the week before, and write the period next to it.
- A metric the tool reports but nobody can defend. “Attributed revenue” in an automation platform usually means last-touch within a window the vendor chose. The holdout in the measurement section is what makes the primary metric real.
2. Audience: entry, exclusion, and suppression
Define who may enter the program as a testable rule against named fields in named systems, then write the exclusions that keep the wrong people out, the global suppressions that apply regardless, and the single system that decides membership.
| Field | What to write | Completed example |
|---|---|---|
| Entry rule | The condition a person must meet, written as field, value, and source system. | checkout_started event on the CDP profile with no order_completed in the following 60 minutes; email address or mobile number present; consent flag for that channel = true in the consent service. |
| Exclusions | People who meet the entry rule but must not enter this program. | Order completed in the last 24 hours; open service ticket (status not closed); payment declined at checkout (handled by a separate program); employee and test accounts; anyone who entered this program in the last 14 days. |
| Global suppressions | Lists that override every program: unsubscribes, bounces, complaints, legal holds, frequency-cap hits. | Global unsubscribe list, hard bounces, spam complainants, accounts under a legal or fraud hold, and anyone at the cross-program frequency cap for the channel. |
| Source of truth | Which system decides membership, which system owns consent, and the direction data flows between them. | CDP profile decides membership; the consent service owns consent and the CDP only reads it; the commerce platform owns order status. Nothing in the automation tool writes back to any of the three. |
| Re-entry rule | Whether a person can enter twice, how soon, and what happens to a sequence already in progress. | Once per 14 days. A new abandonment inside the window updates the cart contents shown in the remaining messages; it does not restart the sequence. |
What goes wrong here
- A concept instead of a definition. “Active customers” cannot be tested. A field, a value, a system, and the time the value was last synced can. If the field does not exist yet, the plan has just discovered a data requirement — write it down as one.
- Exclusions written after the incident. Existing customers in an acquisition flow, people with an open complaint, and recent purchasers are the three exclusions that every program needs and most programs add only after one of them replies.
- Two systems that can both change membership. They will disagree, and the disagreement will surface as a customer who received a message they should not have. Decide which system is authoritative and make the other read from it; the CDP, CRM, and marketing automation comparison shows how to write that ownership down field by field.
3. Trigger, timing, and frequency
Name the discrete event that starts the journey, the wait between steps, the frequency cap that applies across every program, and the hours in the recipient’s own time zone during which a message may be sent.
| Field | What to write | Completed example |
|---|---|---|
| Trigger | The event that starts the journey, named as the system names it. Prefer an event to a scheduled scan of a state. | Event checkout_started followed by a 60-minute wait with no order_completed — not a daily query of carts in an “abandoned” state. |
| Sequence and wait steps | Each step, its offset from the trigger, and its channel. | T+1 h: email 1, cart reminder. T+24 h: email 2, the two most common objections (shipping cost, return policy). T+48 h: SMS if SMS consent exists, otherwise email 3; incentive only if the constraints in section 1 allow it. |
| Frequency cap | The maximum number of marketing messages a person may receive per channel per period, counted across all programs and calendar sends. | Global: at most one marketing SMS per day and three marketing emails per week across every program. Promotional calendar sends count toward the cap. Transactional messages do not. |
| Quiet hours and time zone | The local-time window during which each channel may send, and where the recipient’s time zone comes from. | SMS only between 9 a.m. and 8 p.m. in the recipient’s local time, derived from the shipping-address region. If no region is known, no SMS. Email is not time-restricted. |
| Blackouts and priority | Dates the program pauses, and which programs it yields to or overrides when two want to message the same person. | SMS pauses on statutory holidays in the recipient’s province or state. For 72 hours after entry this program takes priority over the weekly newsletter and yields to transactional and service messages. |
What goes wrong here
- A segment where an event should be. An event fires once. A segment evaluated on a schedule re-qualifies the same person every time the scan runs, which is how one abandonment turns into a message a day for a week. If the platform only offers segment entry, the re-entry rule in section 2 has to do the work the trigger cannot.
- Caps set per program. Five well-behaved journeys with a cap of one message a day each still produce five messages in a day. The cap is a property of the person, not the program, and it has to include the calendar sends the marketing team schedules by hand.
- Quiet hours in the sender’s time zone. The U.S. telemarketing rules restrict solicitations to 8 a.m.–9 p.m. at the called party’s location, and SMS programs in the United States are run to the same window. A server in Toronto sending at 9 a.m. Eastern reaches Vancouver at 6 a.m. If the time zone is unknown, the safe default is not to send the SMS at all.
4. Channels, consent, and content
For each step, record the channel, the consent you hold for that channel and where it is recorded, the content the message needs, every personalization token with its fallback, and the path the journey takes when a channel is unavailable for a given person.
| Field | What to write | Completed example |
|---|---|---|
| Channel and consent per step | The channel each step uses and the specific consent that permits it, with the system that stores the consent record. | Email: express consent, or implied consent inside the CASL window (two years after a purchase, six months after an inquiry), as recorded in the consent service. SMS: express written consent captured at checkout, with the opt-in timestamp and source stored. No consent, no step. |
| Content per message | What each message has to say and do, in a line. The copy comes later; the job comes now. | Email 1: the cart, one call to action, no selling. Email 2: shipping cost and return policy answered plainly, same call to action. Message 3: the incentive if eligible, otherwise a final reminder with a clear end. |
| Personalization tokens and fallbacks | Every dynamic field, the profile attribute it reads, and what renders when the attribute is empty. | first_name → greeting without a name. cart_items (first three) → a generic “your items” line. cart_total → omit the sentence. language = fr-CA → the French variant of every message, not the English one with a French greeting. |
| Required elements | The elements every message must carry for the channel: identification, address, unsubscribe mechanism, headers. | Sender name and physical mailing address in every email; a working unsubscribe link; List-Unsubscribe and List-Unsubscribe-Post headers for one-click unsubscribe; “STOP” handling on SMS with a confirmation reply. |
| Fallback paths | What the journey does when a channel cannot be used for this person: skip the step, substitute a channel, or exit. | No SMS consent → email 3 replaces the SMS. Email hard-bounces → exit and flag the profile. Opted out of email but not SMS → skip emails, keep the SMS step. Language unknown → English, flagged for review. |
What goes wrong here
- Consent treated as transferable. Permission to email is not permission to text. Consent is per channel and, under the Québec and EU rules, per purpose; a checkbox that granted “updates” does not cover a promotional sequence. Confirm the consent for every channel in the sequence before designing it, not after the messages are written.
- A token without a fallback. “Hi
{{first_name}},” rendering literally is the most common automation failure and the most avoidable. Test every message against a profile with every attribute empty. - Unsubscribe treated as a legal formality. Google and Yahoo require one-click unsubscribe headers from anyone sending 5,000 or more messages a day to their users, and Google asks senders to keep the spam-complaint rate below 0.3% — ideally under 0.1%. An unsubscribe that takes effort produces complaints instead, and complaints cost deliverability for every program, not just this one.
5. Exits, follow-up, and handoff
Define an end state for every path through the program — conversion, no response, opt-out, and error — what happens to the person after each one, and exactly how and when a lead or a problem is handed to sales or service.
| Field | What to write | Completed example |
|---|---|---|
| Exit conditions | Every event that removes a person from the journey, and how quickly the removal takes effect. | order_completed on any channel, including in-store and phone orders → exit within 15 minutes. Unsubscribe → exit and add to the global suppression. Cart emptied → exit. 72 hours after the last message with no order → exit as “no response”. |
| After the exit | What each end state makes the person eligible or ineligible for next. | No response → eligible for re-entry after 14 days, not before. Converted → excluded from this program for 30 days, eligible for post-purchase onboarding. Opted out → no further marketing on that channel anywhere. |
| Handoff to sales or service | The trigger, the destination record, the fields passed, and the response time the receiving team has agreed to — with a name. | Payment error detected at checkout → a case in the service system carrying the cart ID and error code, routed to the payments queue; four-business-hour response agreed with the service lead (named on the plan). No handoff to sales in this program. |
| Conflicts with other programs | Programs this one pre-empts, programs that pre-empt it, and programs it is mutually exclusive with. | Excluded from the win-back and browse-abandonment programs while active. Yields to transactional, service, and fraud messages. Overrides the newsletter for 72 hours after entry. |
What goes wrong here
- Nurturing someone who already bought. Conversion should exit the journey immediately, and “conversion” has to include the channels the automation tool cannot see — the store, the call centre, a sales rep. A program that keeps recovering a cart that was paid for yesterday is the clearest sign nobody mapped the exits.
- A handoff nobody accepted. A lead routed to a queue that no one agreed to watch is not a handoff; it is a lead sitting in a queue. Agree the trigger, the destination, and the response time with the receiving team before launch and write the person’s name on the plan.
- Doing nothing left undefined. Silence is a path. A person who never opens, never clicks, and never buys has to end somewhere deliberate — re-entry eligible, suppressed for a period, or moved to a lower-frequency program — or they accumulate in the journey forever.
6. Measurement, ownership, and review
List the events tracked at each step, the method that isolates the program’s effect, the guardrail metrics that will stop it, the attribution window, and the named owner, review date, and kill criteria.
| Field | What to write | Completed example |
|---|---|---|
| Step-level events | The events captured for each message, so drop-off can be located to a step and a variant. | Sent, delivered, bounced, opened (indicative only), clicked, converted, unsubscribed, complained — per message and per variant, with the journey and step identifiers on every event. |
| Primary KPI and method | The metric from section 1 and the mechanism that isolates the program’s contribution. | Incremental recovered orders and revenue versus a 10% randomized holdout assigned at entry, measured over a 72-hour window and reported weekly with confidence intervals. |
| Guardrails | Thresholds that pause the program automatically or trigger a review, whatever the primary metric says. | Unsubscribe rate above 0.3% of delivered on any send; spam-complaint rate above 0.1%; SMS opt-out rate above 1%; delivery rate below 97%. Any breach pauses the step and notifies the owner. |
| Attribution window and rule | How long after a message a conversion counts, and which touch gets it when several could — decided before results arrive. | 72 hours from the trigger. Last click within the program for diagnostics; the holdout comparison is the number reported upward. |
| Owner, review date, kill criteria | A business owner and a technical owner by name, the first review date, the recurring cadence, and the condition under which the program is switched off. | Business owner: lifecycle marketing manager. Technical owner: marketing operations lead. Review 30 days after launch, then quarterly. Kill if lift versus the holdout is not statistically distinguishable from zero after 90 days. |
| Documentation and change control | Where the signed plan lives and which kinds of edit reopen it. | Plan stored in the journey’s description field and the team wiki, with the program ID. Any change to entry rules, exclusions, cadence, or the incentive reopens the plan for sign-off and is logged. |
What goes wrong here
- Opens as a trigger or a KPI. Apple’s Mail Privacy Protection loads message content through a proxy and stops senders from seeing whether a message was opened, so open rates have been inflated and unreliable since 2021. Do not branch a journey on an open, and do not report one as a result.
- No holdout. Without a group that qualified and was not messaged, the program’s “lift” is the retailer’s organic recovery rate wearing the program’s name. The holdout is cheap; the argument about attribution it prevents is not. The analytics implementation checklist covers getting the step events themselves captured cleanly.
- A launch date but no review date. Automation programs do not fail loudly. They keep running against assumptions that stopped being true — a renamed field, a changed return policy, a price increase — which is why the review date matters more than the launch date and why a program without kill criteria runs until someone is embarrassed by it.
Pre-launch review
Run this against the finished plan and the configured journey together. Each line is a test with a pass or fail, not a reminder.
- Every field holds a value or an explicit “N/A, because…”. No blanks.
- The entry rule, run against the live data, returns a count within 10% of what the plan predicted. A large gap means the rule or the data is not what the plan assumed.
- Seed records for each exclusion — a recent purchaser, an open ticket, an employee account — were enrolled and correctly kept out.
- Every message rendered against a profile with every attribute empty, and every fallback appeared.
- The unsubscribe link works, suppresses across every program, and takes effect immediately in the tool — the legal limit under CASL and CAN-SPAM is ten business days, and nobody should need it.
- One-click unsubscribe headers are present on a test send and resolve correctly.
- A seed enrolled in this program and one other hit the cross-program frequency cap and received the capped number of messages, not the sum.
- A seed with a time zone three hours from the sender’s received the SMS inside its own quiet-hours window.
- A seed that completed an order after message 1 received nothing further, including when the order was placed through a channel the automation tool does not see.
- The holdout was assigned at entry, before the first send, and appears in reporting as a population with zero messages.
- The step-level dashboard exists before launch and shows zeroes, so the first week’s data lands somewhere that was already agreed.
- The owner, the review date, and the kill criteria are written at the top of the plan, and the owner has signed it.
Why marketing automation programs fail
The template is organized around the ways programs actually break. From implementation work across campaign platforms, these are the recurring ones, and the section that prevents each:
- Strategy improvised inside the tool. The journey canvas becomes the place where audience, cadence, and exits are decided, one drag at a time, by whoever is configuring it. Sections 1 and 2 move those decisions into a document that stakeholders can read.
- Re-entry loops from segment-based triggers. A scheduled segment re-qualifies the same people every run. Section 3 asks for an event, and section 2 asks for a re-entry rule when an event is not available.
- Caps that only count one program. Each journey is polite; the customer still hears from five of them on the same day. Section 3 puts the cap on the person, across programs and calendar sends.
- Consent assumed to travel across channels. Email permission applied to SMS is the fastest route to a complaint with a regulator’s letterhead on it. Section 4 records the consent per channel, with its source.
- Exits nobody mapped. People who bought keep being sold to; people who went silent stay in the journey indefinitely. Section 5 requires an end state for every path, including the quiet one.
- A handoff without a receiver. Leads land in a queue no one agreed to watch. Section 5 requires the receiving team’s name and response time on the plan before launch.
- Lift that is really the baseline. Without a holdout, the program is credited with conversions that would have happened anyway. Section 6 makes the holdout the primary measurement method, and section 1 makes the baseline explicit.
- Programs that outlive their assumptions. No review date, no kill criteria, and the program runs for years against a field that was renamed in the second quarter. Section 6 puts a date and a condition on it.
Which system should run the program
The template does not care which platform executes the journey, but the plan will expose whether the stack can. Section 2 needs a system that can evaluate the entry rule against current data; section 4 needs a consent record per channel that the automation tool reads rather than owns; section 6 needs step events landing somewhere a holdout can be compared. When a field has no system to point at, that is a stack finding, not a planning failure.
If the question is whether the CRM, the automation platform, or a customer data platform should own the audience and the consent, the CDP, CRM, and marketing automation comparison separates the three by the job each owns and gives a field-level ownership table to copy. For the wider question of whether the stack is ready for programs like this at all, the stack readiness assessment scores nine areas in a few minutes, and the MarTech planning guide covers how to write use cases like this one as operating contracts before any tool is chosen. Terms used here — suppression list, frequency cap, holdout, system of record — are defined in the MarTech glossary.
Frequently asked questions
What is a marketing automation planning template?
It is a short, structured document completed before an automated program is configured. It fixes the program’s objective and success metric, the rules for who enters and who is excluded, the trigger and cadence, the channels and the consent held for each, every exit and handoff, and the measurement method and owner. Its purpose is to make those decisions explicit and testable before they are encoded, one drag at a time, inside an automation tool.
What should a marketing automation plan include?
At minimum: one business outcome with a baseline and a decision date; an entry rule written against named fields and systems, with exclusions, global suppressions, and a re-entry rule; an event trigger, the wait between steps, a cross-program frequency cap, and quiet hours in the recipient’s time zone; the channel and consent for each step, with token fallbacks and required elements; an exit for every path, including no response, and any handoff with the receiving team’s agreed response time; and step-level events, a holdout-based measurement method, guardrails, an attribution window, and a named owner with a review date and kill criteria.
Should a journey start from a segment or from an event?
From an event wherever the platform allows it. An event fires once when something happens; a segment is re-evaluated on a schedule and re-qualifies the same people each run, which produces repeat entries and repeated messages. If only segment entry is available, write an explicit re-entry rule — for example, once per 14 days — and test it with seed records before launch.
How do you measure whether an automated program actually works?
With a holdout: a randomly assigned share of people who qualify for the program and are enrolled but receive none of its messages. The difference in the outcome between the messaged group and the holdout is the program’s incremental effect. Platform attribution reports, which usually credit the last message before a conversion inside a vendor-chosen window, measure activity, not effect; keep them for diagnosing which step loses people.
How often should marketing automation programs be reviewed?
A first review about 30 days after launch, when enough data exists to see step-level drop-off, then quarterly. Any change to the entry rule, exclusions, cadence, or incentive should reopen the plan rather than wait for the next review. Programs should also carry kill criteria — a condition under which they are switched off — because automation fails silently by continuing to run against assumptions that are no longer true.
Do you need a customer data platform to run a program like this?
No. The example in the template uses a CDP profile to evaluate the entry rule, but the same rule can be evaluated in a CRM, a data warehouse with reverse ETL, or the automation platform itself, provided one system is authoritative for membership and another is authoritative for consent. A CDP becomes worth discussing when several programs need the same real-time identity resolution across channels, not because one program needs a clean audience.
How long does it take to complete the template?
For a single-channel program with an existing audience definition, a first draft takes about an hour and a half. For a multi-channel program that crosses teams — marketing, service, data, legal — expect two or three working sessions, most of them spent on sections 2, 4, and 5, where ownership and consent have to be agreed rather than written. That time is the point: it is the same conversation that otherwise happens after the first incident.
The template as plain text
Copy this into the document, ticket, or wiki page where the program will be approved. It is also the form to hand to an assistant or agent that is helping draft the plan — each line is a field to fill, and the headings match the sections above.
MARKETING AUTOMATION PROGRAM PLAN
Program name / ID:
Business owner: Technical owner:
Plan version / date: Signed off by / date:
1. OBJECTIVE AND SUCCESS METRIC
- Business outcome (one):
- Primary metric and method (how the effect is isolated):
- Baseline (value, period measured):
- Target and decision date:
- Constraints (budget, brand, legal, commercial):
2. AUDIENCE
- Entry rule (field, value, source system, sync time):
- Exclusions:
- Global suppressions:
- Source of truth (membership / consent / status) and data direction:
- Re-entry rule:
3. TRIGGER, TIMING, AND FREQUENCY
- Trigger (event name, system):
- Sequence and wait steps (offset, channel, purpose):
- Frequency cap (per channel, per period, across all programs):
- Quiet hours and time-zone source:
- Blackouts and priority versus other programs:
4. CHANNELS, CONSENT, AND CONTENT
- Channel and consent per step (type, where recorded):
- Content per message (the job, one line each):
- Personalization tokens and fallbacks:
- Required elements (identification, address, unsubscribe, headers, STOP):
- Fallback paths (no consent / bounce / partial opt-out / unknown language):
5. EXITS, FOLLOW-UP, AND HANDOFF
- Exit conditions and time to take effect:
- After each exit (eligible / ineligible for):
- Handoff (trigger, destination record, fields, agreed response time, name):
- Conflicts with other programs (pre-empts / yields to / exclusive with):
6. MEASUREMENT, OWNERSHIP, AND REVIEW
- Step-level events:
- Primary KPI and method (holdout share, window, cadence):
- Guardrails (thresholds and action):
- Attribution window and rule:
- Review date, cadence, and kill criteria:
- Documentation location and change control:Sources and method
The structure and the judgments are the author’s, drawn from planning and configuring campaign programs on Unica, SAS, Redpoint, Adobe Campaign, and Adobe Experience Platform for financial services, telecommunications, and e-commerce clients. External facts rest on the following sources, verified on August 21, 2026:
- CRTC — Canada’s Anti-Spam Legislation: frequently asked questions — supports the two-year (purchase) and six-month (inquiry) implied-consent windows, the three requirements for a commercial electronic message, and the ten-business-day limit on unsubscribe requests.
- Justice Laws Website — Canada’s Anti-Spam Legislation (S.C. 2010, c. 23) — supports the statutory text behind the CRTC guidance.
- Federal Trade Commission — CAN-SPAM Act: A Compliance Guide for Business — supports the requirement to honour an opt-out within ten business days.
- 47 CFR § 64.1200 (Cornell Legal Information Institute) — supports the restriction on telephone solicitations before 8 a.m. or after 9 p.m. local time at the called party’s location.
- Google — Email sender guidelines — supports SPF, DKIM, and DMARC requirements, one-click unsubscribe headers for senders of 5,000 or more daily messages, and the 0.3% spam-rate ceiling with a 0.1% target.
- RFC 8058 — Signaling One-Click Functionality for List Email Headers — supports the List-Unsubscribe-Post header and its required List-Unsubscribe=One-Click value.
- Apple — Use Mail Privacy Protection on iPhone — supports that Mail Privacy Protection prevents senders from seeing whether a message was opened.
- GDPR Article 7 — Conditions for consent — supports consent that is demonstrable, specific, and as easy to withdraw as to give.
- Québec — Act respecting the protection of personal information in the private sector (P-39.1, as amended by Law 25) — supports consent that is clear, free, informed, and given for specific purposes (s. 14), and the notice required before using technology that identifies, locates, or profiles a person (s. 8.1).
The abandoned-checkout example is a composite of the program type, not a client’s figures. Thresholds given as examples — the 10% holdout, the 72-hour window, the guardrail rates — are sensible starting points, not standards; the plan should record the ones your program uses and why.