AI Email Sequences

Most SaaS apps send three emails. A welcome email, a password reset, and maybe a payment receipt. That covers about 10% of the lifecycle.

The other 90% is silence. A user signs up, pokes around for a day, and never comes back. Nobody follows up. Nobody explains what the product actually does. Nobody sends a nudge when the trial is about to expire. The user churns before they ever reach the part of the app that would make them stay.

Here is the gap: automated email flows make up about 2% of total email volume but drive 37% of email revenue. The emails most founders skip are the ones that generate most of the money.

This post walks through a system that builds all of those emails at once. One command. Six AI agents working in parallel. Output: 17 email templates, 6 background job functions, wired trigger events, and type-checked code ready to run locally.

The 6 sequences most SaaS apps are missing

A lifecycle email system covers six stages. Each one targets a different moment in the user's journey.

Welcome is the highest-value sequence. First welcome emails average 55-70% open rates. The top 10% of SaaS companies hit 75%+. That is the best attention you will ever get from a user. Four emails over the first seven days, each one guiding them closer to the moment your product clicks.

Activation Nudge catches the biggest drop-off. Someone finishes onboarding, sees the dashboard, and leaves. One email 48 hours later with a specific action to try brings a chunk of them back.

Feature Education prevents a different kind of churn. The user is active but only uses one feature. Three emails over two weeks, each highlighting a feature they haven't touched. Segmented campaigns like this drive up to 760% more revenue than broadcast blasts.

Upgrade Prompt fires when the user hits a real limit, not on a timer. They tried to do something the free plan doesn't allow. That's the moment they understand the value. Three emails over five days: what happened, what the paid plan includes, and an offer.

Churn Prevention runs on a daily background job. Every morning at 9 AM, it queries the database for users who haven't logged in for 7 days. Three emails spread across the next 30 days. Each one uses a different angle: "here's what you're missing," "your data is still here," and "tell us what went wrong."

Win-Back starts when Stripe sends a cancellation webhook. Three emails over 30 days. The first acknowledges the cancellation. The second highlights what improved since they left. The third makes an offer. Loss-framed messaging (what you're giving up) converts 21-32% better than positive framing (what you'll gain).

A study of 38 SaaS companies found that only 2 covered all lifecycle stages. Most stop at welcome and billing. That gap is where this system fits.

Why most email tools don't help

The standard approach: open your email platform, pick a template, write the copy, set a 3-day delay, repeat.

Three problems.

Batch timers, not behavior. Most tools schedule emails on fixed delays. "Send email 2 three days after email 1." That ignores what the user actually did. A user who activated on day 1 shouldn't get the same nudge as someone who never logged in. Triggered emails (sent based on what a user does) get 76% higher open rates and 152% higher click-through rates than timed sends.

HTML templates that kill clicks. Rich HTML emails with heavy formatting, images, and layout grids look professional but underperform. Plain text emails get 42% more clicks. The email clients that matter (Gmail, Apple Mail) handle plain text well. Heavy HTML triggers spam filters and renders poorly on half the devices your users carry.

No connection to your app. External email platforms don't know your database. They can't check if a user already activated before sending the activation nudge. They can't skip the upgrade email for someone who upgraded yesterday. The email system and the product live in separate worlds.

The system: one command, two phases

The pipeline is one Claude Code slash command: /emails. It reads your product, designs the sequences, and builds everything.

.claude/
  commands/
    emails.md              # The command definition
  skills/
    email-sequence/        # Sequence design frameworks
    react-email/           # Template building rules
webapp/
  emails/                  # React Email templates (output)
  lib/inngest/functions/   # Background job functions (output)
  lib/emails/send.ts       # Sending utility (output)

Phase 1 (Design): One agent reads your product docs, user journeys, brand voice, and pricing. It designs all 6 sequences with specific subject lines, timing, and goals for each email. Then it stops and presents the plan. Nothing gets built until you approve.

Phase 2 (Build): Six agents build in parallel. One per sequence type. Each agent writes React Email templates (email layouts built with React components) and Inngest functions (background jobs that handle timing, retries, and state checks). One base agent runs first to create the shared layout and sending utility. Then five agents build their sequences at the same time.

Phase 1: read product, design sequences, wait for approval

The design agent reads everything it needs to write emails that sound like your product, not like a template.

Product context it reads:

• Product overview (what the app does, pricing tiers)
• User journeys (who signs up, what they care about)
• Brand guidelines (voice, tone, product name)
• Feature map (what to highlight in education emails)
• Auth flow (how signup works, so the welcome sequence matches)
• Billing setup (pricing tiers, upgrade triggers)
• Brand colors (so email templates match the app)

From that, it builds an Email Brief: the product name, the "aha moment" (the specific action where the product clicks for a user), pricing model, top features to educate about, and upgrade triggers.

Then it designs all 17 emails. For each one: subject line, goal, timing, and the copy angle.

Subject lines follow research. Short subject lines (2-4 words) hit 46% average open rates across a study of 5.5 million emails. The system keeps every subject under 50 characters for mobile inbox cutoff.

The full plan goes to you before a single template gets written. You can cut sequences, change timing, rewrite subject lines, or remove emails entirely. The build phase uses your approved plan as its spec.

Phase 2: six agents build in parallel

After approval, six subagents start at the same time. Each one gets the Email Brief, the approved plan, brand colors, and the skills it needs.

Agent 0: base layout and sending utility

Runs first. Creates two shared files that every other agent uses.

The base layout is a React Email component (a reusable email template built with React). It includes the brand logo, container, footer with unsubscribe link, and the brand colors converted from the app's CSS.

The sending utility wraps Resend (the email delivery service). It takes a React Email component, converts it to both HTML and plain text, and sends it. Every sequence uses this same function.

Agents 1 through 5: one per sequence

Each agent writes two things: the email templates and the background job function that orchestrates the sequence.

Templates are React components. Each email is one .tsx file. Typed props so the subject line, user name, and any dynamic data are all validated before the email sends.

Background job functions use Inngest (a background job engine that handles scheduling, retries, and event-driven workflows). Each function defines when the sequence starts, how long to wait between emails, and what checks to run before sending the next one.

The file structure after all six agents finish:

webapp/emails/
  _components/
    base-layout.tsx                  # Shared branded layout
  welcome/
    welcome-1-getting-started.tsx    # 4 templates
    welcome-2-activation-nudge.tsx
    welcome-3-feature-education.tsx
    welcome-4-check-in.tsx
  activation/
    activation-nudge.tsx             # 1 template
  education/
    education-1-feature-a.tsx        # 3 templates
    education-2-feature-b.tsx
    education-3-feature-c.tsx
  upgrade/
    upgrade-1-limit-hit.tsx          # 3 templates
    upgrade-2-value.tsx
    upgrade-3-offer.tsx
  churn/
    churn-1-miss-you.tsx             # 3 templates
    churn-2-data-waiting.tsx
    churn-3-feedback.tsx
  winback/
    winback-1-sorry.tsx              # 3 templates
    winback-2-improvements.tsx
    winback-3-offer.tsx

webapp/lib/inngest/functions/emails/
  welcome-sequence.ts
  activation-nudge.ts
  feature-education.ts
  upgrade-prompt.ts
  churn-prevention.ts
  winback-sequence.ts

17 templates. 6 functions. One shared layout. One sending utility.

Behavioral branching: react to what users do, not when they signed up

This is the part that separates the system from a timer-based drip.

Inngest supports a feature called step.waitForEvent. In plain terms, it pauses the sequence and waits for a specific thing to happen before continuing. If that thing doesn't happen within a time limit, the sequence takes a different path.

Here is what that looks like in practice.

A user signs up. The welcome sequence starts. Email 1 sends immediately. Then the function calls step.waitForEvent and waits up to 48 hours for a user.activated event (meaning the user completed the product's core action).

If the event arrives, the sequence skips the activation nudge and jumps to feature education. The user already found the value. Nudging them would be noise.

If the event does not arrive in 48 hours, the activation nudge fires. One email focused on the specific action the user hasn't taken yet.

That branching happens inside every sequence. The upgrade prompt checks if the user upgraded between emails. The churn prevention sequence checks if the user logged back in. The win-back sequence checks if the user re-subscribed.

Between every step.sleep() call (the pause between emails), the function creates a fresh database connection and checks the user's current state. If the user already converted, the sequence stops. No one gets an upgrade email the day after they upgraded.

This is what triggered emails look like in code. Not a visual flow builder. A function that sleeps, checks state, branches, and sends.

The trigger wiring

Sequences don't start on their own. Something in the app has to fire the event.

The system finds these locations in your codebase and wires the inngest.send() calls. Signup already has an auth callback. Stripe already has a webhook route. The limit check already returns a response when a user hits their cap. Each location gets one line that fires an event with the user's ID, email, and relevant data.

Churn prevention is different. It runs on a daily cron job, not an event. Every morning, the Inngest function queries the database for users who haven't been active in 7+ days and sends individual events for each one. The per-user sequence handles the rest.

What the data says

The numbers that shape this system come from how email actually performs, not from theory.

A 7-email onboarding sequence (tested on a real SaaS product) moved trial-to-paid conversion from 12% to 22% and cut monthly churn from 8% to 4.8%. Those are the two metrics that compound. A 10-point conversion lift plus a 3-point churn reduction changes the math on every marketing dollar you spend.

Plain text wins in click-through rates because it feels like a message from a person, not a promotion. The system renders both an HTML version and a plain text version of every email via React Email's render() function. Recipients whose email clients prefer plain text get the plain version automatically.

Short subject lines work because mobile inboxes truncate. A 2-4 word subject line is fully visible on every device. The system keeps every subject under 50 characters.

Behavioral triggers outperform fixed timers because relevance matters more than timing. Sending the right email after the right action beats sending any email on day 3 regardless of what happened.

Quality gates

After all six agents finish, the system runs TypeScript's type checker across the entire project:

cd webapp && npx tsc --noEmit

Zero type errors. Every template has typed props. Every Inngest function has typed event payloads. Every inngest.send() call matches the expected event shape.

Then it provides local test instructions:

# Terminal 1: start the dev server
npm run dev

# Terminal 2: start the Inngest dev server
npm run dev:inngest

# Open http://localhost:8288
# Send a test event: app/user.signed-up
# Watch the welcome sequence execute step by step

The Inngest dev server shows every function execution in real time. You can see each step run, each sleep countdown, each email that would send. Nothing goes to real inboxes in local dev.

Rules for building this yourself

The pattern works with any email provider, any background job engine, any framework. Here is what makes it work.

Read your product before designing emails. The most common mistake is writing emails that sound generic because the person writing them didn't understand the product deeply. Feed the system your product docs, user journeys, and brand voice before it touches a template.

Design all sequences before building any of them. Present the full plan. Get approval. Then build. Changing a subject line in a plan is free. Changing it in a built template means re-rendering, re-testing, and re-deploying.

Check user state between every email. Never assume the user is still in the same state they were in when the sequence started. A step.sleep("3d") (wait 3 days) means three days of potential changes. Query the database before sending.

One action per email. Not two buttons. Not three links. One clear next step. Emails with a single call to action get higher click-through rates because there is no decision to make.

Build plain text alongside HTML. Do not treat plain text as an afterthought. Render both versions from the same template. Plain text emails get 42% more clicks in head-to-head tests.

Wire triggers to existing events, not new ones. Signup already happens. Cancellation already happens. Limit hits already happen. The email system hooks into events your app already fires. That's zero new infrastructure.

Beyond email

The parallel-agents pattern (one base agent builds shared infrastructure, then specialized agents build on top of it at the same time) works for more than email.

Notification systems. Same structure: design all notification types, build templates, wire triggers. Push notifications, in-app alerts, and SMS all follow the same lifecycle stages.

Onboarding flows. One agent reads product context and designs the flow. Separate agents build each step (welcome modal, feature tour, checklist, empty states). Behavioral branching decides which steps to show based on what the user already did.

Documentation. One agent builds the structure and shared components. Specialized agents write individual sections in parallel. Same shape. Same coordination pattern.

Same core idea every time. Read the product context first. Design before building. Build in parallel with shared infrastructure. Check state before acting. Type-check everything at the end.