Lifecycle Email Sequence Prompt

Build a lifecycle email sequence from the supplied business, audience, messaging, event, and performance evidence.

Inputs
- Lifecycle goal: [Lifecycle goal]
- Audience and lifecycle context: [Audience and lifecycle context]
- Offer and messaging inputs: [Offer and messaging inputs]
- Trigger and channel data: [Trigger and channel data]
- Sending platform and implementation context: [Sending platform and implementation context]
- Constraints and compliance requirements: [Constraints and compliance requirements]
- Performance evidence and success criteria: [Performance evidence and success criteria]

Claude’s operating boundaries
- Analyze only the information supplied in this conversation and any sources Claude can verifiably access. Do not imply that a URL, platform, account, customer record, or analytics system was inspected if its contents were not available.
- Produce strategy, automation specifications, copy, QA criteria, and implementation guidance. Do not claim to configure automations, upload audiences, change consent records, approve copy, launch tests, or send messages.
- Treat benchmarks, prior results, customer research, event definitions, legal requirements, and brand claims as supported only when evidence is supplied. Never invent performance data, testimonials, product capabilities, consent, or legal conclusions.

Input handling
1. Treat the lifecycle objective, intended recipients, lifecycle entry condition, primary offer, and known consent or suppression requirements as blocking prerequisites for final copy and launch logic. If any are absent or materially contradictory, ask up to five targeted clarification questions before drafting a final sequence.
2. If useful but non-blocking details are missing, continue with a bounded draft. Mark each assumption, explain its likely impact, and identify the owner who should resolve it.
3. Separate supplied facts, observed results, assumptions, hypotheses, conflicts, and unknowns. Preserve conflicting evidence rather than silently choosing one version.
4. If jurisdiction, consent basis, suppression policy, or mandatory footer requirements are unknown, provide a provisional design and require review by the organization’s authorized legal or compliance owner before launch.

Sequence design workflow
1. Define the lifecycle transition the sequence should produce, such as new lead to qualified lead, signup to activation, trial to paid, active customer to renewal, or lapsed customer to reactivation. Identify the primary conversion event, supporting micro-conversions, exclusion conditions, and exit conditions.
2. Map meaningful audience states and segments using only available attributes or behaviors. For every segment, state the eligibility rule, evidence source, message need, value proposition, likely objection, and prohibited or unreliable personalization.
3. Specify the automation logic: entry trigger, event and property definitions, eligibility window, delay and send-time rules, timezone handling, branches, re-entry policy, deduplication, frequency caps, suppression checks, conversion exits, and collision rules for other campaigns.
4. Design the minimum sufficient sequence. Justify the purpose and timing of each email, including the trade-off between urgency and fatigue, personalization and data reliability, test isolation and available volume, and sequence length and speed to conversion.
5. Draft each email with a distinct messaging job. Use accurate subject lines, preheaders, body copy, one primary call to action, and only substantiated claims. Include sensible fallback copy for optional personalization fields. Avoid deceptive urgency, misleading sender identity, manipulative consent language, discriminatory targeting, or inferences from sensitive personal data.
6. Address operational failure modes, including duplicate or delayed events, out-of-order events, missing properties, stale segments, broken merge fields, re-entry loops, timezone errors, frequency collisions, suppressed recipients, conversion events that fail to exit recipients, and attribution gaps. Define a safe default or stop condition for each material failure.
7. Define a measurement plan connecting each email and branch to delivery, engagement, conversion, unsubscribe, complaint, and fatigue indicators. Prefer the supplied business success criteria over generic benchmarks. Clearly label any suggested benchmark as external and unverified unless a source is available.
8. Propose tests only when traffic and measurement conditions can support a useful result. For each test, provide the hypothesis, single primary variable, audience unit, primary metric, guardrail metric, minimum decision rule, contamination risk, and action for an inconclusive result. Do not fabricate sample-size calculations when baseline rates or statistical requirements are unavailable.
9. Prepare launch verification and human handoff. Require authorization from the designated marketing owner before implementation, from the appropriate privacy or legal owner where required, and from the platform owner before automation changes or sending.

Required deliverable

A. Evidence and uncertainty register
Provide a table with: item, classification as supplied fact, observation, assumption, hypothesis, conflict, or unknown; source or evidence; confidence; design impact; and resolution owner.

B. Lifecycle strategy brief
State the lifecycle transition, audience state, customer need, business goal, primary conversion, micro-conversions, offer, message promise, exclusions, exit criteria, success thresholds, and unresolved decisions.

C. Audience and journey map
Provide a table with: segment or state, eligibility rule, entry trigger, evidence used, message need, objection, branch condition, exit condition, suppression rule, and data dependency.

D. Sequence specification
Provide a table with one row per email containing: email ID, segment, messaging job, trigger, delay, send window, subject line, preheader, primary CTA, conversion checkpoint, branch or exit behavior, required data fields, fallback behavior, and rationale.

E. Complete email drafts
For every email, provide:
- Email ID and intended segment
- Sender-name recommendation and reply handling
- Two subject-line options with the distinction between them
- Preheader
- Full body copy
- Primary CTA and destination requirement
- Personalization fields and explicit fallback copy
- Required footer, preference, or unsubscribe elements based on supplied requirements
- Plain-text considerations
- Claims or links requiring human substantiation

F. Automation and exception logic
Describe entry, delays, branches, exits, re-entry, deduplication, suppression, frequency caps, campaign collision handling, timezone behavior, and safe handling for missing or malformed events. Include a failure-mode table with: failure, detection signal, recipient risk, safe default, recovery action, and owner.

G. Measurement and experiment plan
Provide an event and KPI table with: email or branch, event name, event definition, source system, attribution window, baseline if supplied, target, guardrail, reporting segment, and unresolved instrumentation need. Then provide any justified experiment cards with hypothesis, variable, metric, decision rule, and inconclusive outcome.

H. Launch verification matrix
Provide concrete checks for audience eligibility, suppression reconciliation, consent handling, event firing, branch logic, conversion exits, re-entry, merge-field fallbacks, links and tracking parameters, rendering, sender identity, reply routing, accessibility, footer content, frequency caps, and analytics capture. For each check include: expected observation, actual observation from supplied evidence or “not executed,” evidence reference, status as passed, failed, blocked, or unverified, and responsible approver. Never mark a check passed without observed evidence.

I. Approval and handoff register
List each decision or action, current state as proposed, approved, implemented, executed, blocked, or unverified; required owner; required evidence; dependencies; and safest next action. End with the smallest action that can be taken without sending messages or changing a live automation.

Completion language
Call the result a proposed sequence or launch candidate unless implementation, testing, approval, and sending evidence was actually supplied. Use “passed,” “approved,” “configured,” “launched,” “sent,” or “measured” only when the corresponding action occurred and its evidence is cited.