Practical reference library
Decision templates for measurable customer activation, retention and lifecycle operations.
Looking for ready-to-send copy instead? The lifecycle email templates cover onboarding, win-back and NPS follow-up sequences.
Guide 01
An activation event contract defines the customer action that represents first value, the eligible population, the event fields and the observation window. Use the same definition in analytics and lifecycle campaigns. Otherwise the team can report an activation lift while the campaign is acting on a different behavior.
Read the guide →Guide 02
To estimate a lifecycle campaign's incremental effect, assign eligible users or accounts to a treatment group and a concurrent holdout before exposure. Keep assignment stable, define the primary outcome and observation window, and compare outcomes for the originally assigned groups. Report uncertainty and implementation failures alongside the result.
Read the guide →Guide 03
A next-best-action log records what the system knew, which actions were eligible, why it selected one and what happened afterward. Preserve decision time separately from outcome time. This makes an automated lifecycle action explainable and helps distinguish a poor decision from stale data, failed delivery or missing measurement.
Read the guide →Guide 04
A cross-channel frequency policy defines who is counted, which messages count, the time window, priority rules and exceptions. Evaluate the policy before an action is dispatched, and record the reason when a message is suppressed. Separate essential service messages from promotional contact using an explicit reviewed policy.
Read the guide →Guide 05
Evaluate an engagement platform using one representative lifecycle workflow, a fixed dataset and explicit acceptance criteria. Ask each vendor to demonstrate identity handling, eligibility, decision control, channel execution and measurement. Record observed behavior and limitations rather than assigning scores from feature checkboxes alone.
Read the guide →Guide 06
Score each candidate 1-5 on eight weighted criteria: data-integration effort against your real stack, journey-building depth, channel coverage you'll actually use, experimentation rigor (real holdouts, not just A/B subject lines), pricing model fit at your volume, time-to-first-campaign, operational headcount required, and exit portability. Weight before demos, score only on evidence you generated, and run every vendor through the same fixed lifecycle brief.
Read the guide →Guide 07
Bring a written script to every platform demo: your fixed lifecycle brief, four build requests you watch performed live, and five failure cases you explicitly ask to see — a journey hitting a missing event, a send exceeding a frequency cap, a segment computed on late data, an experiment stopped early, and a user withdrawing consent mid-journey. How a platform behaves in failure is the product; the happy path is the brochure.
Read the guide →Guide 08
Before crediting any 'predictive' claim, demand six pieces of evidence in writing: what exactly is predicted (event, horizon, population), the model's measured performance on held-out data with the metric named, how performance is monitored after deployment, what happens when the model is wrong, whether predictions are explainable at the user level, and what data the model needs from you before it predicts anything. A vendor who can't produce item two is selling a heuristic with a hat on.
Read the guide →Guide 09
Before any orchestration platform can work, four data layers must be ready: identity (one resolvable user key across channels and devices), events (the journey-triggering actions, named, versioned and actually firing), consent (channel-level permissions queryable in real time), and latency (events arriving fast enough for the journeys you're designing). Audit all four against your real pipelines before signing — the platform inherits your data exactly as broken as it is.
Read the guide →Guide 10
Write one lifecycle brief — a real journey, your event schema, your volume, your channels, your success metric — and make it the only artifact of the evaluation: every demo builds it, every trial implements it, every price quote prices it, every exit answer covers its data. Cross-vendor comparison becomes honest arithmetic instead of adjective-matching, because the denominator is identical everywhere.
Read the guide →Guide 11
Specify the journey in five parts before building anything: the first-value event (one product action that predicts retention, chosen from data or founder conviction — not 'logged in'), the eligibility window (typically days 0-14), the intervention ladder (day-0 welcome with one action, day-2 nudge if the value event hasn't fired, day-5 different-angle attempt, day-9 human-or-highest-card offer), exit conditions (value event fires, or window ends, or user opts down), and the holdout (5-10% receiving nothing, so you measure the campaign rather than the cohort).
Read the guide →Guide 12
Before launching any activation experiment, lock five guardrails in writing: a pre-registered primary metric (one, with its measurement window), fixed assignment (users keep their arm for the full window — no reassignment on upgrade or complaint), a minimum sample and duration you commit to before reading results, a no-mid-flight-edits rule (copy, timing and audience frozen; a needed fix means restart, not patch), and a decision rule written in advance (what result ships the variant, what result kills it). Experiments without guardrails produce vibes with confidence intervals.
Read the guide →Guide 13
A churn-risk cohort needs four written rules before any journey touches it: the risk signal (which behaviors over which window — e.g. core-action frequency down 50% across 14 days vs the prior 28), the exclusions (new accounts still onboarding, accounts in open support escalations, already-cancelled), the cooldown (an account exiting the cohort can't re-enter for 30 days, and can't receive the same play twice in a quarter), and the exit condition (what behavior change removes them). Write these as a table the whole team signs; every retention argument later is one of these four cells, and the spec is what makes a churn play testable instead of vibes.
Read the guide →Guide 14
Retention numbers disagree because four definitions float free: who's in the cohort (signup date vs activation date — activation-based curves run higher and hide onboarding losses), what counts as retained (any login vs core action — the activity bar), how windows work (calendar weeks vs rolling N-day, unbounded vs bounded), and the minimum segment size worth reading (under ~50 accounts, curves are noise). The contract is one page that pins all four, gets signed by product, marketing and CS, and becomes the citation for every retention claim. After that, a 'retention improved' claim either references the contract or it doesn't count.
Read the guide →Guide 15
Keep one dated log with a row per merge rule: the identifiers it joins (e.g. verified email = verified email), the evidence standard (verified vs user-typed vs inferred), retroactivity (does the merge rewrite history or apply forward), the unwind procedure when a merge proves wrong, and who approved it. Default posture for lifecycle messaging: merge only on verified deterministic keys, apply forward, and treat every un-keyed coincidence (same name, same device) as a candidate for review — never an automatic join. The log matters because merge rules silently define who receives what: an over-eager rule sends one person another person's receipts, and nobody can debug it later without knowing what rule fired and why it existed.
Read the guide →Guide 16
Write a freshness policy with one row per campaign type: the triggering event, the maximum age at which acting on it is still sensible (cart abandonment: hours; feature-adoption nudge: days; win-back: weeks), what the campaign should do when data arrives late (skip, not send stale), and the staleness check the send actually performs. The failure this prevents is structural: pipelines batch, retry and backfill, so events routinely arrive hours or days old — and a campaign that fires on arrival time rather than event time congratulates users on the purchase they made last Tuesday. Freshness is a property of the campaign's meaning, not of the pipeline's speed; the policy is where the two are reconciled.
Read the guide →Guide 17
Report four numbers per campaign instead of one: treatment conversion rate, holdout conversion rate, the difference (incremental rate), and the incremental count applied to the eligible population. Attributed conversions answer 'how many converters touched this message', which counts people who would have converted anyway; incremental conversions answer 'how many extra converted because of it', which is the only number that justifies spend. Expect the incremental figure to be a fraction of the attributed one — that gap is not a failure, it is what attribution was hiding, and reporting both side by side is how a lifecycle team keeps its credibility when someone finally runs the holdout.
Read the guide →Guide 18
Choose the window from your observed time-to-conversion rather than from convention: pull the distribution of time between first qualifying touch and conversion, and set the window where the curve flattens — commonly a few days for transactional products and several weeks for considered B2B purchases. Then write down four things: the window per campaign type, whether it is click-based or view-based, what happens when two campaigns both fall inside it, and the date the policy took effect. That last item is what protects you, because changing a window retroactively re-writes historical numbers and makes every previous report unreproducible.
Read the guide →Guide 19
A sample-ratio mismatch means the observed split differs from the intended one by more than chance explains, and it invalidates the experiment rather than merely adding noise — because whatever caused the imbalance probably also affected the outcome. Investigate six causes in order: assignment happening after an action that itself differs by arm, filtering applied to one arm only, duplicate or missing assignment events, bots and internal traffic hitting one arm disproportionately, a redirect or latency difference between arms, and analysis-time joins dropping rows. Do not rebalance the data. Reweighting hides the mechanism and produces a confidently wrong result — find the cause, fix it, and rerun.
Read the guide →Guide 20
Fill in five fields and then test them. The unit (account or user — pick one and be consistent), the signals (three to five behaviours, each observable in your event data today), the thresholds (a number and a window for each), the eligibility filter (who is excluded regardless of score), and the action (what happens when an account qualifies, and who owns it). Then backtest: what share of accounts that converted last quarter would have qualified, and what share of qualifiers never converted. If either number is bad, the definition is wrong, and shipping it will burn the trust of whoever works the list.
Read the guide →Guide 21
Specify five things: the trigger (the exact event and threshold, with the window it is measured over), the debounce (how long the condition must hold before the campaign fires, so a single spike does not trigger it), the cooldown (how long before the same account can trigger again, which is the rule that separates helpful from nagging), the exclusions (who never receives this regardless of usage), and the exit (what stops the journey — upgrade, reply, opt-out, or usage falling back). Write the cooldown and the exit before the copy. Those two decide whether the campaign reads as attentive or as automated pestering.
Read the guide →Guide 22
Build the journey as a timing ladder with suppression checked at every step, not at entry. A typical ladder is a notice far enough out to act on (30 days for annual), a reminder close enough to be urgent (7 days), and a confirmation after the event. At every step, re-check: is there an open support escalation, an active billing dispute, a cancellation already requested, a conversation in progress with a human. Suppression at entry is not enough, because the account's situation changes during the window — and a cheerful renewal reminder sent to someone mid-complaint does more damage than the reminder was ever worth.
Read the guide →Guide 23
Keep eligibility separate from scoring and apply it last, immediately before send. The score answers 'does this account look ready'; eligibility answers 'is it appropriate to ask'. The exclusion list is short and mostly obvious once written: active support escalation, open billing dispute, capacity already included in their contract, recent failed upsell attempt, account flagged at-risk, region or segment you cannot service, and anyone who opted out. Log which rule excluded each account, because an eligibility layer nobody can audit is indistinguishable from one that silently stopped running.
Read the guide →Guide 24
List every action the agent can take and assign each one of four levels: autonomous (it acts and logs), review-required (it prepares, a human approves, it acts), human-only (the agent can recommend but never execute), and forbidden. Then add two columns that make the matrix usable — a blast radius estimate (how many customers a single mistake reaches) and a reversibility note (can this be undone). Anything with a large blast radius and no undo belongs in review-required or human-only regardless of how reliable the agent has been, because reliability is a rate and the matrix is about the tail.
Read the guide →Guide 25
Record nine fields per action: what was done, by which agent and version, on whose authority (autonomous under a named policy, or approved by a named person), to which audience with the resolved count, at what time, with what content reference, which eligibility and suppression rules were evaluated and their outcomes, what the agent's stated reason was, and whether it succeeded. Write it in business language rather than as a trace, because the people who read it are answering 'why did this customer get this message' rather than debugging a run. Retention has to outlast the complaint window, which is usually longer than your logging default.
Read the guide →Guide 26
Make each queue item show four things before anything else: the resolved audience count, a sample of real recipients, the exact rendered message, and the eligibility rules that ran with how many each excluded. Then define the approver's job as three checks rather than a general read — is the audience what was intended, is the content correct and on-brand, and is the timing appropriate. Track approved-without-edit rate and time-in-queue: when the first climbs past roughly four in five while volume rises, the queue has become a rubber stamp, and that is a governance failure whether or not anything has gone wrong yet.
Read the guide →Guide 27
Have one stop control that halts all agent sending immediately, reachable by anyone on call without a deploy — that is the whole first minute. Then work the ladder: contain (stop sending, freeze the agent, do not start fixing), assess (how many received it, what exactly did they receive, is it still going), decide (who is accountable for the customer-facing response, which is a business decision not an engineering one), communicate, and only then diagnose. The most expensive mistake in these incidents is an engineer deciding alone whether to send an apology, because that decision is about the relationship and the liability rather than the bug.
Read the guide →Guide 28
Map field by field rather than event by event, and record five things per field: the source name and type, the destination name and type, the transformation applied, what happens when the value is missing, and who owns the field if it changes. Then add the two checks that catch most of the damage — confirm timestamps carry a timezone and are not being reinterpreted as local, and confirm identifiers are the same identifier on both sides rather than two different keys with similar names. An event that arrives with the right name and a subtly wrong field is worse than one that fails, because nothing alerts and the campaigns built on it look fine.
Read the guide →Guide 29
Name one system as the owner of lifecycle stage and make every other system read-only for that field. If both can write it, they will overwrite each other on every cycle — a record flipping between Lead and Customer indefinitely, generating a stage-change event each time and firing whatever is triggered on it. Then write the transition map: which stages can move to which, whether backwards transitions are allowed, and what happens to a stage the other system does not recognise. Unmapped values are the second-biggest cause of sync problems after dual ownership, because the usual default is to blank the field.
Read the guide →Guide 30
Set a staleness budget per use case rather than one refresh schedule for everything. Three tiers cover most needs: attributes that change slowly (plan, company size, region) can refresh daily; audience membership driving scheduled campaigns needs hourly or better; anything a user expects to be immediate should not come from a sync at all and needs an event path. Then record the actual observed freshness alongside the target, because warehouse jobs slip and a sync configured hourly that has been running every four hours since a schema change is the common failure — and nothing reports it unless you measure it.
Read the guide →Guide 31
Write a policy per message class, not per provider. For each class decide four things: the retry window (how long a message is still worth delivering), whether a fallback channel is permitted, whether the message may be dropped entirely, and who is told when it is. Time-critical security and transactional messages justify aggressive retry and sometimes a fallback channel; marketing messages should usually be dropped rather than delivered late, because a promotion arriving nine hours after the window it referred to is worse than silence. The rule that must not be broken: a fallback to another channel requires consent for that channel — SMS-ing someone because email failed is a consent violation, not a clever mitigation.
Read the guide →Guide 32
Force six collisions in staging rather than discovering them in production: two campaigns qualifying the same person in the same hour, a marketing send landing during an active support escalation, a win-back firing for someone who just converted, a billing-failure notice competing with a feature announcement, the same message arriving on two channels, and a journey re-entry while the contact is still mid-journey. For each, assert what the customer actually receives, in what order, and which rule decided it. The output is not a pass mark — it is a written arbitration policy, because every one of these has a defensible answer and the failure is having no answer rather than the wrong one.
Read the guide →Guide 33
Define a fallback ladder per decision input, ordered from best to worst, ending in an explicit do-nothing: use the live signal; if absent, use the most recent known value with an age limit; if that is stale, use the cohort default; if there is no cohort, send the neutral message; if even that does not apply, send nothing and log why. The rule that matters: never let a missing input silently become a default value, because a default is indistinguishable from real data downstream. And write down the suppression threshold — the confidence level below which the honest action is no action, since a confidently wrong recommendation costs more than an absent one.
Read the guide →Guide 34
Draw the boundary by blast radius and reversibility, not by how clever the action is. Auto-approve reversible, bounded actions: adjusting send time inside an approved window, choosing between approved message variants, pausing an underperforming variant. Require one human for anything that reaches new people or changes what is said: new audience definitions, new copy, channel additions, budget or volume increases. Require two for the irreversible and the regulated: anything touching suppression or consent, anything with a legal or financial claim, and any send above a volume threshold you set in advance. Write the table, name the approver per row as a role rather than a person, and log every automated action with enough context to reconstruct why it happened.
Read the guide →Guide 35
Treat the invited user's first successful action as the activation event, not the invitation being sent. That reframing changes everything downstream: you measure invites accepted and acted on rather than invites sent, you message the inviter when an invite goes unaccepted rather than only the invitee, and you make the invited user's first screen about what they were invited to do rather than a generic welcome. The common failure is an invite flow measured at send: it reports healthy numbers while a large share of invitations expire unopened, and nobody notices because the metric was never about the second user arriving.
Read the guide →Guide 36
Run two separate playbooks with two separate activation definitions — first purchase for demand, first sale for supply — and add a rule most marketplaces skip: check the other side's state before messaging. Encouraging buyers into a category with no available supply produces a bad first experience and a seller who never appears; pushing sellers to list in a category with no demand produces a listing that never sells and a seller who leaves. The liquidity check belongs in the eligibility conditions for both sequences, which means marketplace lifecycle messaging cannot be designed one side at a time even though it almost always is.
Read the guide →Guide 37
Build the risk signal from usage change rather than usage level, and act on it with a ladder that escalates from automated to human rather than jumping to a discount. A low-usage account that has always been low-usage is a pricing fit question, not a churn signal; an account whose usage halved in three weeks is the one worth intervening on. The ladder: notice and understand, offer help, involve a human, and only then discuss commercial terms. Leading with a discount to a wavering customer teaches them that wavering produces discounts, and the ones who learn that lesson are the ones you most want to keep.
Read the guide →Guide 38
Treat the first contribution as a threshold problem rather than a motivation problem. Lower the bar — a reaction, a vote, an answer to a direct question — before asking for a post, and route a specific question to someone with relevant context rather than broadcasting an invitation to contribute. Then protect the first contribution: a first post that receives no response within a day is the strongest predictor of never posting again, which makes response time a programme responsibility rather than a community outcome. Generic prompts to 'introduce yourself' or 'share your thoughts' reliably produce nothing, because they ask for effort with no defined shape and no guaranteed audience.
Read the guide →Guide 39
Write the sentence you want to publish first, then fill one evidence record for it: the activation definition frozen before anyone saw results, the eligible population, the comparison design, counts and rates for each arm, the absolute difference with an interval, how credit was split across email, push, in-app and SMS, what else changed during the window, and the customer's written sign-off. The comparison design decides the verb. A random holdout supports 'increased'; a before-and-after supports 'coincided with'; no comparison supports a story about what was built and no outcome number at all. Channel percentages from attribution describe credit, not effect, unless each channel had its own holdout.
Read the guide →Guide 40
Check the claim in order and stop at the first check it fails: what 'retained' means (event, unit, window), what it was compared with, whether the group was selected for unusually low recent activity, whether the metric and window were fixed before the results, the absolute difference with an interval, which base any percentage refers to, whether the effect lasts to the retention window that matters, and whether the comparison group was reached some other way. At-risk and win-back programs are the most exposed, because their entry rule selects people at a low point, and people selected at a low point tend to drift back toward their usual level whether or not you message them.
Read the guide →Guide 41
Split each campaign into stages with start and stop evidence you can observe (brief approved, audience saved, draft submitted, QA passed, approved, scheduled, report delivered) and record two numbers per stage: touch time, when someone is working, and elapsed time, which includes waiting. Time a baseline of the same campaign types before the change and after it, count rework loops and abandoned campaigns, and report medians with their spread for each campaign type. Because this is a before-and-after comparison, keep a log of what else changed, and keep timing past the first weeks, when people are still learning the new way of working. Don't convert minutes into money without saying where the time went.
Read the guide →Guide 42
Assemble five things: both journey versions as exported definitions, one eligibility rule applied to both periods, a weekly outcome series covering several weeks on each side of the switch, a comparison series the change didn't touch, and a log of everything else that moved in the window. With those you can say whether the outcome changed at the switch by more than it was already moving, and by more than the comparison series moved. You can't say the redesign caused it. If a large decision rides on the answer, run the old and new versions side by side with random assignment instead.
Read the guide →Guide 43
Before putting your numbers next to a lifecycle benchmark, run it through nine tests: who is in the sample and how they got there, whether the metric's numerator, denominator and window match yours, measurement artifacts such as privacy-protected opens, how it was aggregated, whether spread is shown, how many companies sit in the cell you're using, when it was measured, whether the publisher benefits from the result, and how you intend to use it. A definitions failure ends the comparison. A benchmark that passes the rest is still a range for context, not a target, because your audience, channel mix and product differ from everyone in the sample.
Read the guide →Guide 44
Run 45 minutes in five fixed blocks: health first (anything broken or harming customers), then running experiments (status only), last week's launches, decisions, and next week's queue. A pre-read generated the day before carries the numbers, so the meeting spends its time on exceptions. The rule that keeps it honest: an experiment is read only on the readout date set before it launched. Checking significance every week and stopping on a good week makes a false positive more likely than the nominal rate, and Johari and colleagues call p-values 'wholly unreliable' when sample size is chosen by continuous monitoring. Every decision leaves the room as a logged entry with an owner and a date.
Read the guide →Guide 45
For each campaign stage, name exactly one accountable person, the people responsible for doing the work, who must be consulted before, and who is informed after. Check first the stages that sit between roles: audience sign-off, the consent and suppression check, the kill switch while a send is running, the post-send readout, and switching off journeys nobody watches any more. Put a person against each, never a team alias, and give every accountable person a deputy with the same authority. Where a marketing agent does the work, list it as responsible for the steps its permissions allow; the accountable name stays human.
Read the guide →Guide 46
Spend days 1 to 7 on data and consent rather than journeys: the events and identity rules your first journey needs, a reconciled import of every opt-out and consent record with its timestamp and source, and authenticated channels. Days 8 to 14 build one journey and run it in shadow, on live events without sending. Days 15 to 21 send it to a random slice of eligible users with a holdout, with the legacy version suppressed for the same people. Days 22 to 30 expand, hold or roll back against criteria written on day one, and set the date the legacy journey switches off. The month ends with one journey live and measured, not fourteen rebuilt at once.
Read the guide →Guide 47
Before scoring any idea on impact or ease, work out whether it can be read at all. Weekly eligible volume, the baseline rate and the smallest effect worth acting on give a rough sample size per arm (a rule of thumb for comparing two proportions, as presented by van Belle: about 16 × p(1 − p) ÷ difference², for 80% power and a two-sided 5% test), and from that the weeks to a readout. Ideas that can't read out within the quarter are marked 'not testable as designed': pool audiences, pick a more frequent outcome, or ship without a test and say so. Rank the testable ones on what changes if they win, build cost, customer risk and collisions with other tests.
Read the guide →Guide 48
Treat every change to a marketing agent as a release: a new model version, edited instructions, a new tool or permission, a new data source, a changed guardrail, updated brand or product facts. Each gets a change record, a test chosen by change type, a staged rollout and a rollback trigger written in advance. Instruction and model changes are replayed against a frozen set of past cases and compared with the current version's output; permission and tool changes go through the permission matrix before any test; data-source changes need freshness and consent checks. No change goes straight from edit to full autonomy: shadow first, then review-required, then the level the agent had before.
Read the guide →Guide 49
List the capabilities your lifecycle program needs over the next 12 to 24 months, mark each as differentiating or commodity, and cost the build honestly, including the parts a prototype never shows: journey state held across days, frequency caps across channels, consent and suppression enforcement, a preference center, retries when a channel provider fails, audit logs, and the tooling marketers need to change a journey without an engineer. Buy the commodity layer unless a verified hard constraint forces you to build it. Build where the logic is your differentiation, and feed its output into whatever you buy. Decide per capability rather than once for the whole stack; either way, compliance stays your responsibility.
Read the guide →Guide 50
Hand procurement, legal and security a packet, not a recommendation: every requirement with the evidence behind it and its evidence class (tested in your trial, documented by the vendor, or said in a demo), projected volumes per channel for the contract term, the personal data the platform will process and where, the sub-processors, the exit terms you need, and the open risks with owners. Each row names the contract term or document that would make it binding. Anything resting only on a verbal claim gets written confirmation or a contract clause before signature, including which plan tier it belongs to.
Read the guide →Guide 51
Register the risks that harm customers or create legal exposure first, then the ones that only cost time. For an engagement platform migration those are: opt-outs and consent not carried over, the same person messaged by both platforms during the overlap, people partway through a journey dropped or restarted, identity merges that differ between platforms, personalization fields that render empty, event names that silently stop matching, sender reputation on new sending infrastructure, and push registrations that don't transfer. Each row gets an owner, an early signal you can watch, a mitigation completed before cutover, and a rollback trigger agreed in advance. Review the register daily during cutover week.
Read the guide →Guide 52
One page, in this order: the decision or approval you are asking for; the portfolio (tests launched, read out, shipped, stopped for harm, inconclusive, still running); the program-level effect measured against a standing holdout, with its interval; the shipped changes, each with its own interval; and the caveats. Never add up individual test lifts to claim a total. Tests selected because they won tend to overstate their own effects, a selection bias Lee and Shen describe for the aggregated impact of launched experiments, and separate changes to the same journey don't simply add. If there is no standing holdout, say plainly that the program's total effect is unmeasured.
Read the guide →Guide 53
Keep one entry per learning, not per test: a one-sentence claim at the scope actually tested, the evidence behind it (test IDs, dates, absolute effects with intervals), where it holds (segment, channel, lifecycle stage), a strength grade (replicated, single test, observational only, inconclusive, contradicted), the decision it informed, known limits, a revisit date and an owner. At month end, spend an hour: add entries for the month's readouts, inconclusive ones included, re-grade the entries new evidence touches, and retire those past their revisit date without fresh support. New test proposals cite the entries they build on.
Read the guide →
