Email Lifecycle

End-to-end lifecycle email — pick the right provider for the job, build the audience, draft the sequence, launch, and measure. Cross-provider patterns at the top; provider-specific tool calls below.

Out of scope — defer to other skills

Requirements

• Hyper MCP installed and connected. https://app.hyperfx.ai/mcp
• At least one of these providers connected at https://app.hyperfx.ai/apps:
  • Klaviyo — ecommerce, Shopify-heavy lists, behavioral triggers off purchase / browse data
  • Resend — product-led / SaaS / dev tools, transactional + lifecycle on the same domain
  • Beehiiv — newsletters, paid-tier subscriptions, content-driven lists
  • Gmail — small / personal lists, founder-mode broadcasts, ops emails

If none of those tool prefixes (klaviyo_*, resend_*, beehiiv_*, gmail_*) appear in the agent's tool list, stop and tell the user to enable the Hyper MCP and connect the provider they intend to use.

Provider selection

The wrong provider is the most common reason a lifecycle program fails. Pick first.

You can run more than one. The pattern is: Klaviyo for marketing, Resend for transactional + product onboarding (when the brand also runs ecom). Or Beehiiv for the newsletter and Resend for the product. Decide once per program, not per email.

Tool surface

Full per-provider mechanics, gotchas, and concrete tool-call examples in references/provider-mechanics.md.

Critical rules

1. Pick the provider before writing copy. The mechanics of how a flow gets triggered, how a segment gets defined, and what data you can personalize against differ enough that "we'll figure out the provider later" wastes a day.
2. Always start with the audience, not the email. A welcome flow with no opt-in source is unsendable. A win-back with no inactivity definition is unsendable. Define the audience first; the copy is downstream.
3. One purpose per sequence. A "welcome + onboarding + product education + first purchase nudge" mega-flow is brittle and impossible to measure. Split into separate flows wired together.
4. Honor unsubscribes globally, not per-list. When a profile unsubscribes, suppress them across every flow in the workspace — not just the one they unsubscribed from. All four providers expose this; it's not optional.
5. Test sends with a real seed inbox before going live. Every provider supports a test send. Do not launch a 10-email sequence to a 50,000-person list without seeing every email render in Gmail / Outlook / Apple Mail / mobile.
6. Stay under provider rate limits. Especially for resend_send_broadcast (large blast → throttled), gmail_messages_send (~500/day soft cap), and klaviyo_send_campaign (account-tier dependent).
7. Track conversion metric, not opens. Apple Mail Privacy Protection makes open rates ~useless on iOS. Configure conversion events at the provider level (Klaviyo metrics, Resend automation completion, Beehiiv segment transitions) and report on those.

Workflow

Phase 1 — Define the lifecycle program

Get the user to commit to:

1. Trigger — The event that puts a profile into this flow. Examples: "signed up for the newsletter", "made first purchase", "abandoned cart with > $50 value", "no order in 90 days".
2. Audience filter — Beyond the trigger, who qualifies. ("Newsletter signup, but only US-based". "Abandoned cart, but only first-time visitors.")
3. Goal — One concrete outcome the flow drives toward. Not "engage them more". Concrete: "first purchase within 14 days", "activate the integration within 7 days", "upgrade to paid within 30 days".
4. Success metric — Conversion rate to goal. Open and click are diagnostic, not goal metrics.
5. Suppression rules — Who should never get this flow even if they hit the trigger. (Existing customers shouldn't get the new-customer welcome. Recent purchasers shouldn't get the win-back.)

If the user can't answer the trigger or the goal, the flow isn't ready to build.

Phase 2 — Pick the sequence pattern

Five patterns cover ~95% of lifecycle work. See references/sequence-patterns.md for full templates with copy, timing, and provider-specific notes.

Phase 3 — Build the audience

Audience setup is provider-specific. Examples for the most common case (welcome flow):

Klaviyo — create the list, then a flow trigger on "Subscribed to List":

klaviyo_create_list(list_name="newsletter-2026")
# triggers + flows are configured in Klaviyo UI; the API surface here is
# for adding profiles, building segments, and sending one-off campaigns.

Resend — create an audience, then an automation triggered by contact.created:

resend_create_audience(name="newsletter-2026")
resend_create_automation(
  name="welcome-2026",
  trigger="contact.created",
  audience_id="aud_...",
  ...
)

Beehiiv — subscriptions trigger automations directly when added to a segment / publication:

beehiiv_create_subscription(
  publication_id="pub_...",
  email="user@example.com",
  utm_source="signup-form",
)
beehiiv_add_to_automation(
  automation_id="aut_...",
  subscription_id="sub_...",
)

Gmail — labels are the segment. Start with a label per program:

gmail_labels_create(name="lifecycle/welcome-2026")
# manual contact list maintained outside Gmail (Sheets, CSV) — Gmail
# is best for ≤500 contacts, founder-led sends.

Provider-specific gotchas (e.g., Klaviyo's profile-merging behavior, Resend's audience-vs-segment distinction) are in references/provider-mechanics.md.

Phase 4 — Draft the sequence

For each email in the sequence:

1. Subject + preview text — Lifecycle subject lines should look like 1:1 mail when possible (lowercase, short). Different rules than cold email — a welcome from a brand the user just opted into can be slightly more branded.
2. Body — One job per email. Welcome touch 1 = "thanks, here's what to expect"; touch 2 = "here's the one thing to do first"; touch 3 = "here's the proof / case study".
3. CTA — One per email. Same rules as cold email — interest-based or single-action.
4. Personalization tokens — Use whatever the provider exposes ({{first_name}}, {{event.product_name}}, {{custom_field.plan_tier}}). Never use a token without a fallback ({{first_name|"there"}}).

Drafts-first by default — for any new sequence, build the first email and test send it to yourself before moving on. Provider previews look correct in the editor and broken in production more often than not.

Phase 5 — Launch

1. Test send to a seed inbox. Every provider supports it. Use it for every email before activation.
2. Activate the flow. Klaviyo: set status to Live. Resend: enable the automation. Beehiiv: publish the post / set automation to active. Gmail: just send.
3. Set a 7-day check-in. Most lifecycle issues (broken token, wrong audience filter, send-time-pacing surprise) show up in the first week. Pull metrics on day 7 and again on day 30.

Phase 6 — Measure & iterate

Pull the conversion to goal metric, not opens or clicks. Open rate post-MPP is noise.

Iteration rule: don't tune copy until the audience is right. If the welcome flow has a 1.2% conversion and the same product organic conversion is 4%, the audience is misaligned (too broad, wrong source, suppression rules missing) — fix that first. Copy comes second.

Quality check (before launch)

Read the whole sequence end-to-end as if you're a single person receiving it over the planned timing. Reject any sequence that fails:

• The 5-email arc tells one coherent story.
• Each email could stand alone if the previous ones bounced.
• Every CTA leads somewhere that still works (no broken links, no canceled offers).
• The unsubscribe link is visible (provider auto-adds, but verify in test send).
• Tokens have fallbacks. No Hi , after a missing first-name.
• Subject lines are different across the sequence — same subject 5x reads as a system glitch.
• The send time isn't 3am in the recipient's time zone.

Reference workflows

---

Supporting file: references/provider-mechanics.md

Provider Mechanics

Concrete tool-call patterns and gotchas per provider. Read the section that matches the provider you picked in Phase 1 of SKILL.md. Cross-provider sequence design lives in sequence-patterns.md.

Klaviyo

The richest surface for ecommerce. Klaviyo's mental model is profiles → lists → segments → flows. The Hyper MCP exposes ~50 Klaviyo tools; the ones you'll touch most:

Concrete: build a one-off welcome campaign

# 1. Create the audience list
klaviyo_create_list(list_name="welcome-test-2026")

# 2. Add some test profiles
klaviyo_create_profile(
  profile={
    "email": "seed@yourdomain.com",
    "first_name": "Seed",
    "properties": {"signup_source": "test"},
  },
)
klaviyo_add_member_to_list(
  list_id="<list_id>",
  profile_ids=["<profile_id>"],
)

# 3. Build the campaign
klaviyo_create_campaign(
  name="welcome-2026-touch-1",
  included_audiences=["<list_id>"],
  send_strategy_method="immediate",
)

# 4. Update the message body / subject
klaviyo_update_campaign_message(
  campaign_message_id="<msg_id>",
  subject="you're in",
  preview_text="here's what to expect",
  body_html="<p>...</p>",
  ...
)

# 5. Send
klaviyo_send_campaign(campaign_id="<campaign_id>")

# 6. Poll the send job until it's complete
klaviyo_get_campaign_send_job(send_job_id="<send_job_id>")

For a multi-touch automated welcome flow (vs a one-off campaign), the flow itself is configured in Klaviyo's UI — the API surface here is for building audiences, sending one-off broadcasts, and querying metrics. The flow template + trigger + delays are set in Klaviyo and the API is for everything around them.

Klaviyo gotchas

• Profile merging. Klaviyo merges profiles by email and by phone if both exist. A profile created with email a@x.com and a profile created with phone +1-555-... and later both updated with the other field will collapse into one profile. Don't depend on stable profile IDs across creation events.
• Segment vs list. Lists are static memberships — a profile is on a list because it was added. Segments are dynamic queries — membership recomputes whenever underlying properties change. Use lists for opt-in audiences; use segments for behavior-driven audiences ("opened at least one email in 30d", "purchased in last 90d").
• Custom metrics for non-standard conversions. If your conversion event isn't Placed Order or Started Checkout, custom metrics are created automatically from Klaviyo events — you can't create them via API. Use klaviyo_get_custom_metrics to list available custom metrics and klaviyo_get_metrics_for_custom_metric to pull attribution data from them.
• Account tier limits. Send rate is capped per Klaviyo plan — large blasts to large lists chunk over hours, not seconds. Check klaviyo_get_campaign_send_job instead of assuming "send_campaign returned, so it's done."
• Tagging is the cheapest way to organize. Use klaviyo_create_tag + klaviyo_tag_campaigns to group every email in a program (e.g., tag everything in the welcome program with program:welcome-2026) — makes pulling metrics across the program trivial.

Resend

Newer surface. Resend's mental model is contacts → audiences → automations + broadcasts, with the same API serving transactional sends. Best fit for SaaS / dev tools where you want one mailing infrastructure for product mail and lifecycle.

Concrete: build an automated welcome sequence

# 1. Create the audience
resend_create_audience(name="newsletter-2026")

# 2. Create the automation
resend_create_automation(
  name="welcome-2026",
  audience_id="<audience_id>",
  trigger="contact.created",
  steps=[
    {"type": "email", "wait": "0", "subject": "you're in", "html": "..."},
    {"type": "wait", "duration": "2d"},
    {"type": "email", "subject": "start with this", "html": "..."},
    {"type": "wait", "duration": "3d"},
    {"type": "email", "subject": "here's how Notion did it", "html": "..."},
  ],
)

# 3. Add a contact (this triggers the automation)
resend_create_contact(
  audience_id="<audience_id>",
  email="user@example.com",
  first_name="User",
)

# 4. Inspect runs after a few days
resend_list_automation_runs(automation_id="<automation_id>")

Resend gotchas

• Audience vs segment. Resend audiences are static membership lists, like Klaviyo lists. There's no native dynamic-segment concept — if you need a segment, maintain it externally (e.g., daily Cloud Run / cron pulling from your DB) and sync via resend_update_contact or resend_create_contact (idempotent on email).
• Broadcasts are throttled. A 100k-recipient broadcast does not send all in one minute — Resend paces it. Don't chain a resend_send_broadcast call into a "wait 60s and check inbox" workflow.
• Domain verification. Cold transactional + lifecycle on a fresh Resend account requires SPF + DKIM + DMARC on the sending domain (same as Gmail — see cold-email-outreach/references/deliverability.md). Verify in the Resend dashboard before launching.
• Single API for transactional + marketing. Powerful, but means a bug in your lifecycle flow can poison your transactional reputation. Use separate sub-domains for transactional (mail.yourdomain.com) and lifecycle (updates.yourdomain.com) — Resend supports both on one account.

Beehiiv

Newsletter-first. Mental model: publication → subscriptions → posts → automations. Best when the product is the newsletter (paid tiers, referral, post stats are all first-class).

Concrete: add a new subscriber and put them in the welcome automation

# 1. Create the subscription (this is the opt-in signal)
beehiiv_create_subscription(
  publication_id="<pub_id>",
  email="user@example.com",
  utm_source="signup-form",
  utm_medium="organic",
  custom_fields={"signup_intent": "founder-mode"},
)

# 2. Put them into the welcome automation
beehiiv_add_to_automation(
  automation_id="<aut_id>",
  subscription_id="<sub_id>",
)

# 3. Tag them so you can segment later
beehiiv_add_tags(
  subscription_id="<sub_id>",
  tags=["welcome-2026", "founder-mode"],
)

# 4. Watch the automation journey
beehiiv_list_automation_journeys(automation_id="<aut_id>")

Beehiiv gotchas

• Posts are content, not flows. A "post" is a newsletter issue. Multi-touch sequences are automations, not chained posts. Don't try to model a welcome flow as 5 sequential posts.
• Segments need explicit recalculation. Unlike Klaviyo's auto-recomputing segments, Beehiiv segments need beehiiv_recalculate_segment to refresh after underlying data changes. Build it into your weekly cadence.
• Custom fields drive personalization. If you want to personalize beyond {{first_name}}, define custom fields with beehiiv_create_custom_field before signing people up — backfilling is painful.
• Paid tiers + referral = the value loop. If you're running a paid newsletter, the referral program is doing more lifecycle work than your email sequences. Pull beehiiv_get_referral_program data into the conversion analysis.

Gmail (small-list / founder-mode)

Best for under-500 lists where the value of every email is high enough to justify hand-curation. Once you cross 500 contacts, move to Klaviyo / Resend / Beehiiv — see cold-email-outreach/references/deliverability.md for why.

Concrete: send a 50-person founder broadcast

# 1. Make sure all recipients are tagged
gmail_labels_create(name="lifecycle/q3-investor-update")

# 2. Loop over recipients (maintained externally — Sheets, CSV, DB)
for email in recipient_list:
    result = gmail_messages_send(
      to=email,
      subject="Q3 update",
      body=render_personalized_body(email),
    )
    # Label each sent message (gmail_messages_send has no label_ids arg)
    gmail_labels_add(
      message_id=result["message_id"],
      label_ids=["<label_id_for_lifecycle/q3-investor-update>"],
    )

# 3. Pull replies a week later
gmail_messages_list(query="label:lifecycle/q3-investor-update is:unread newer_than:7d")

Gmail gotchas

• No native segmentation, no native flows. All the lifecycle logic lives outside Gmail (in your code / agent). Gmail is purely the send + label + reply layer.
• Personalization happens at send time. No template engine — you build the body string per recipient before calling gmail_messages_send.
• Same deliverability rules as cold email. Even though these are warm contacts, going from 5 sends/day to 500 sends/day overnight will trip Gmail's heuristics. Pace it.
• Labels are your only segment. Use a hierarchical label scheme: lifecycle/<program> and lifecycle/<program>/converted, etc. Then gmail_messages_list(query="label:lifecycle/<program> -label:lifecycle/<program>/converted") gives you "still in the program."

---

Supporting file: references/sequence-patterns.md

Sequence Patterns

Five lifecycle patterns cover ~95% of programs. Each one has a distinct trigger, audience, length, timing, and goal — pick the pattern first, then map it to your provider in provider-mechanics.md.

The copy below is a skeleton, not a template. Fill in the brand voice, swap the proof point, but keep the sentence shape — these patterns work because they're concise, single-purpose, and matched to where the recipient is in their lifecycle.

Pattern 1 — Welcome / onboarding

Highest-engagement window in the entire lifecycle. People who just signed up want to hear from you. Don't waste it.

Audience

• Trigger: opt-in event (newsletter signup, free trial start, account creation, first download).
• Filter: opted in within the last 24h. Not already a paying / converted customer.
• Suppress: anyone who has already hit the conversion goal of this flow (e.g., already purchased).

Cadence (3–5 emails over 7–10 days)

Skeleton

Subject (1): you're in

Hi {{first_name|"there"}},

Welcome — glad you're here. {{Promised_value_delivery}}.

A couple things to expect:
  - {{Cadence promise}}
  - {{Value promise}}

If you ever want to reach me directly, just reply.

— {{Sender name}}

Subject (2): start with this

Hi {{first_name|"there"}},

The single most useful thing to do first is {{The_One_Thing}}.

{{Why_it_matters_in_one_sentence}}.

{{CTA — link to the action}}

— {{Sender name}}

What kills welcome flows

• Sending the welcome 6 hours after signup. Send within 5 minutes. Engagement falls off a cliff after the first hour.
• Skipping email 1 because the signup form already showed a confirmation. A confirmation page is not a welcome email. People don't keep the page open.
• Branded marketing template on email 1. The welcome should look like a 1:1 message from a person, not a launch announcement.

Benchmarks (rough — varies hugely by industry)

• Open rate: 40–60% (highest of any lifecycle program)
• Click rate: 8–15%
• Conversion to goal: 3–10% (if the goal is well-aligned with the trigger)

If your welcome converts under 1%, the trigger or audience is wrong, not the copy.

Pattern 2 — Nurture

Lower-intent than welcome. The recipient signed up for content, not your product. Goal is to bridge from content interest to product interest over weeks.

Audience

• Trigger: lead magnet download, content opt-in, gated resource access.
• Filter: opted in via content channel (not a product signup). Hasn't taken a product action.
• Suppress: product signups, paying customers, anyone in another active sequence.

Cadence (4–7 emails over 3–6 weeks)

What kills nurture flows

• Pitching the product on email 1. They opted in for content. Selling immediately violates the implicit deal and tanks engagement.
• Long gaps with no value. "Just checking in" between content emails reads as filler.
• Forgetting to suppress when they convert. A nurture flow continuing to send after the recipient becomes a customer is the most common embarrassing lifecycle bug.

Pattern 3 — Abandoned cart (ecom only)

Highest-ROI lifecycle program for ecommerce. Often runs through Klaviyo with native Shopify event listeners.

Audience

• Trigger: Started Checkout event with cart value > threshold (often $30–50).
• Filter: No Placed Order event in the next 24h.
• Suppress: anyone who completed the purchase between trigger and send.

Cadence (2–3 emails over 24–72 hours)

What kills abandoned-cart flows

• Discounting on email 1. Trains repeat behavior — people start abandoning intentionally to wait for the email.
• Showing the wrong cart. Klaviyo's cart-content variables can stale-cache. Test thoroughly.
• Suppression bug — sending the cart email after the order completes. Embarrassing and damages trust. Suppression is non-negotiable.

Benchmarks

• Open rate: 30–45%
• Click rate: 6–10%
• Recovery rate: 8–15% of abandoned carts

Pattern 4 — Re-engagement

Audience: people who used to engage and stopped. The goal is re-open, not conversion. If they re-open, the regular lifecycle programs take over.

Audience

• Trigger: lapsed engagement signal — no opens in 60 days, no site visits in 90 days, no app sessions in 30 days. Set the threshold per product.
• Filter: still subscribed (haven't unsubscribed). Not a paying customer (they get win-back instead).
• Suppress: anyone who opened or engaged in the last 7 days.

Cadence (2–3 emails over 7–14 days)

After the cadence: anyone who didn't engage gets suppressed (not unsubscribed — kept on the list, just not sent to). Re-evaluate in 90 days.

What kills re-engagement flows

• Marketing-templated emails. A lapsed subscriber's eye filters them out. Use plain-text or near-plain-text.
• Asking them to update preferences. They won't. The decision is binary: re-engage or pause.
• Not pausing after the sequence. Sending to people who explicitly didn't engage with the re-engagement flow tanks deliverability for everyone else on the list.

Pattern 5 — Win-back (for lapsed customers)

Different from re-engagement: this is for paying customers who stopped purchasing or canceled.

Audience

• Trigger: no purchase in 180+ days (ecom), canceled subscription / no login in 60+ days (SaaS).
• Filter: customer has historical revenue / engagement.
• Suppress: active customers, anyone in cancellation / churn-prevention flow.

Cadence (2–3 emails over 14–21 days)

What kills win-back flows

• Generic "We miss you!" with a 10% off coupon. Treats them like a stranger. Win-back has to acknowledge they were a customer.
• No personalization. A win-back without "since you bought X" personalization is indistinguishable from re-engagement.
• Discount-only thinking. A discount is the last lever. Better is "here's the new thing in the category you cared about."

Cross-pattern measurement

For all five patterns, the only real metric is conversion to goal — defined per program.

Open rate is diagnostic. Click rate is diagnostic. Conversion is the only number that matters for whether the program ships value.