KI-E-Mail-Sequenzen

Die meisten SaaS-Apps senden drei E-Mails. Eine Willkommens-E-Mail, ein Passwort-Reset und vielleicht eine Zahlungsquittung. Das deckt ungefähr 10% des Lebenszyklus ab.

Die anderen 90% sind Stille. Ein Nutzer meldet sich an, schaut einen Tag lang herum und kommt nie zurück. Niemand folgt nach. Niemand erklärt, was das Produkt eigentlich macht. Niemand schickt eine Erinnerung, wenn der Trial kurz vor dem Ablauf steht. Der Nutzer churnt, bevor er jemals den Teil der App erreicht, der ihn zum Bleiben bringen würde.

Hier ist die Lücke: Automatisierte E-Mail-Flows machen etwa 2% des gesamten E-Mail-Volumens aus, treiben aber 37% des E-Mail-Umsatzes. Die E-Mails, die die meisten Gründer überspringen, sind die, die den Großteil des Geldes generieren.

Dieser Post geht durch ein System, das all diese E-Mails auf einmal erstellt. Ein Befehl. Sechs KI-Agenten, die parallel arbeiten. Output: 17 E-Mail-Templates, 6 Background-Job-Funktionen, verkabelte Trigger-Events und type-gechecktor Code, der lokal lauffähig ist.

Die 6 Sequenzen, die den meisten SaaS-Apps fehlen

Ein Lifecycle-E-Mail-System deckt sechs Phasen ab. Jede zielt auf einen anderen Moment in der Nutzerreise ab.

Willkommen ist die wertvollste Sequenz. Erste Willkommens-E-Mails haben durchschnittlich 55-70% Öffnungsraten. Die Top 10% der SaaS-Unternehmen erreichen 75%+. Das ist die beste Aufmerksamkeit, die du jemals von einem Nutzer bekommen wirst. Vier E-Mails in den ersten sieben Tagen, jede führt sie näher an den Moment, an dem dein Produkt klickt.

Aktivierungs-Nudge fängt den größten Drop-Off. Jemand schließt das Onboarding ab, sieht das Dashboard und geht. Eine E-Mail 48 Stunden später mit einer konkreten Aktion, die er ausprobieren soll, bringt einen Teil von ihnen zurück.

Feature-Edukation verhindert eine andere Art von Churn. Der Nutzer ist aktiv, nutzt aber nur ein Feature. Drei E-Mails über zwei Wochen, jede hebt ein Feature hervor, das er noch nicht berührt hat. Segmentierte Kampagnen wie diese treiben bis zu 760% mehr Umsatz als Broadcast-Blasts.

Upgrade-Prompt feuert, wenn der Nutzer ein echtes Limit trifft, nicht nach einem Timer. Er hat versucht, etwas zu tun, was der Free-Plan nicht erlaubt. Das ist der Moment, in dem er den Wert versteht. Drei E-Mails über fünf Tage: was passiert ist, was der Bezahlplan enthält, und ein Angebot.

Churn-Prävention läuft auf einem täglichen Background-Job. Jeden Morgen um 9 Uhr fragt er die Datenbank nach Nutzern ab, die sich seit 7 Tagen nicht eingeloggt haben. Drei E-Mails verteilt über die nächsten 30 Tage. Jede nutzt einen anderen Winkel: "Hier ist, was du verpasst", "Deine Daten sind noch hier" und "Sag uns, was schiefgelaufen ist."

Win-Back startet, wenn Stripe einen Cancellation-Webhook sendet. Drei E-Mails über 30 Tage. Die erste bestätigt die Kündigung. Die zweite hebt hervor, was sich seit ihrem Weggang verbessert hat. Die dritte macht ein Angebot. Verlust-geframte Botschaften (was du aufgibst) konvertieren 21-32% besser als positive Framings (was du gewinnen wirst).

Eine Studie von 38 SaaS-Unternehmen fand, dass nur 2 alle Lifecycle-Phasen abdeckten. Die meisten hören bei Willkommen und Billing auf. Diese Lücke ist, wo dieses System passt.

Warum die meisten E-Mail-Tools nicht helfen

Der Standard-Ansatz: öffne deine E-Mail-Plattform, wähle ein Template, schreibe die Copy, setze eine 3-Tage-Verzögerung, wiederhole.

Drei Probleme.

Batch-Timer, kein Verhalten. Die meisten Tools planen E-Mails nach festen Verzögerungen. "Sende E-Mail 2 drei Tage nach E-Mail 1." Das ignoriert, was der Nutzer tatsächlich getan hat. Ein Nutzer, der am Tag 1 aktiviert hat, sollte nicht denselben Nudge bekommen wie jemand, der sich nie eingeloggt hat. Getriggerte E-Mails (gesendet basierend auf dem, was ein Nutzer tut) haben 76% höhere Öffnungsraten und 152% höhere Klickraten als zeitgesteuerte Sends.

HTML-Templates, die Klicks killen. Umfangreiche HTML-E-Mails mit schwerer Formatierung, Bildern und Layout-Grids sehen professionell aus, schneiden aber schlechter ab. Plaintext-E-Mails bekommen 42% mehr Klicks. Die E-Mail-Clients, auf die es ankommt (Gmail, Apple Mail), handhaben Plaintext gut. Schweres HTML löst Spam-Filter aus und rendert auf der Hälfte der Geräte deiner Nutzer schlecht.

Keine Verbindung zu deiner App. Externe E-Mail-Plattformen kennen deine Datenbank nicht. Sie können nicht prüfen, ob ein Nutzer bereits aktiviert hat, bevor sie den Aktivierungs-Nudge senden. Sie können nicht die Upgrade-E-Mail überspringen für jemanden, der gestern upgegraded hat. Das E-Mail-System und das Produkt leben in getrennten Welten.

Das System: ein Befehl, zwei Phasen

Die Pipeline ist ein Claude Code-Slash-Befehl: /emails. Er liest dein Produkt, entwirft die Sequenzen und baut alles.

.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): Ein Agent liest deine Produktdocs, Nutzerreisen, Brand Voice und Pricing. Er entwirft alle 6 Sequenzen mit konkreten Betreffzeilen, Timing und Zielen für jede E-Mail. Dann stoppt er und präsentiert den Plan. Nichts wird gebaut, bis du genehmigst.

Phase 2 (Build): Sechs Agenten bauen parallel. Einer pro Sequenztyp. Jeder Agent schreibt React Email-Templates (E-Mail-Layouts, gebaut mit React-Komponenten) und Inngest-Funktionen (Background-Jobs, die Timing, Retries und State-Checks handhaben). Ein Basis-Agent läuft zuerst, um das gemeinsame Layout und das Sending-Utility zu erstellen. Dann bauen fünf Agenten ihre Sequenzen gleichzeitig.

Phase 1: Produkt lesen, Sequenzen entwerfen, auf Genehmigung warten

Der Design-Agent liest alles, was er braucht, um E-Mails zu schreiben, die wie dein Produkt klingen, nicht wie ein Template.

Produktkontext, den er liest:

• Produkt-Übersicht (was die App macht, Pricing-Tiers)
• Nutzerreisen (wer sich anmeldet, was sie interessiert)
• Brand-Richtlinien (Stimme, Ton, Produktname)
• Feature Map (was in Edukations-E-Mails hervorheben)
• Auth-Flow (wie die Anmeldung funktioniert, damit die Willkommenssequenz passt)
• Billing-Setup (Pricing-Tiers, Upgrade-Trigger)
• Brand-Farben (damit E-Mail-Templates zur App passen)

Daraus erstellt er ein E-Mail-Briefing: den Produktnamen, den "Aha-Moment" (die konkrete Aktion, bei der das Produkt für einen Nutzer klickt), das Pricing-Modell, die Top-Features für Edukation und die Upgrade-Trigger.

Dann entwirft er alle 17 E-Mails. Für jede: Betreffzeile, Ziel, Timing und den Copy-Winkel.

Betreffzeilen folgen der Forschung. Kurze Betreffzeilen (2-4 Wörter) erreichen 46% durchschnittliche Öffnungsraten in einer Studie von 5,5 Millionen E-Mails. Das System hält jede Betreffzeile unter 50 Zeichen für die Abschneidung im mobilen Posteingang.

Der vollständige Plan geht an dich, bevor ein einziges Template geschrieben wird. Du kannst Sequenzen kürzen, Timing ändern, Betreffzeilen umschreiben oder E-Mails komplett entfernen. Die Build-Phase nutzt deinen genehmigten Plan als Spec.

Phase 2: Sechs Agenten bauen parallel

Nach der Genehmigung starten sechs Sub-Agenten gleichzeitig. Jeder bekommt das E-Mail-Briefing, den genehmigten Plan, Brand-Farben und die Skills, die er braucht.

Agent 0: Basis-Layout und Sending-Utility

Läuft zuerst. Erstellt zwei gemeinsame Dateien, die jeder andere Agent nutzt.

Das Basis-Layout ist eine React Email-Komponente (ein wiederverwendbares E-Mail-Template, gebaut mit React). Es enthält das Brand-Logo, Container, Footer mit Abmelde-Link und die Brand-Farben, aus dem CSS der App konvertiert.

Das Sending-Utility umhüllt Resend (den E-Mail-Zustelldienst). Es nimmt eine React Email-Komponente, konvertiert sie in HTML und Plaintext und sendet sie. Jede Sequenz nutzt dieselbe Funktion.

Agenten 1 bis 5: einer pro Sequenz

Jeder Agent schreibt zwei Dinge: die E-Mail-Templates und die Background-Job-Funktion, die die Sequenz orchestriert.

Templates sind React-Komponenten. Jede E-Mail ist eine .tsx-Datei. Typisierte Props, damit Betreffzeile, Nutzername und alle dynamischen Daten validiert werden, bevor die E-Mail gesendet wird.

Background-Job-Funktionen nutzen Inngest (eine Background-Job-Engine, die Scheduling, Retries und eventgesteuerte Workflows handhabt). Jede Funktion definiert, wann die Sequenz startet, wie lange zwischen E-Mails gewartet wird und welche Checks vor dem Senden der nächsten ausgeführt werden.

Die Dateistruktur, nachdem alle sechs Agenten fertig sind:

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 Funktionen. Ein gemeinsames Layout. Ein Sending-Utility.

Verhaltensbasiertes Branching: reagiere auf das, was Nutzer tun, nicht wann sie sich angemeldet haben

Das ist der Teil, der das System von einem timer-basierten Drip unterscheidet.

Inngest unterstützt ein Feature namens step.waitForEvent. Auf einfach gesagt: Es pausiert die Sequenz und wartet auf ein bestimmtes Ereignis, bevor es weitergeht. Wenn dieses Ereignis nicht innerhalb eines Zeitlimits eintrifft, nimmt die Sequenz einen anderen Pfad.

So sieht das in der Praxis aus.

Ein Nutzer meldet sich an. Die Willkommenssequenz startet. E-Mail 1 wird sofort gesendet. Dann ruft die Funktion step.waitForEvent auf und wartet bis zu 48 Stunden auf ein user.activated-Event (was bedeutet, dass der Nutzer die Kernakton des Produkts abgeschlossen hat).

Wenn das Event eintrifft, überspringt die Sequenz den Aktivierungs-Nudge und springt zur Feature-Edukation. Der Nutzer hat den Wert bereits gefunden. Ihn zu nudgen wäre Lärm.

Wenn das Event in 48 Stunden nicht eintrifft, feuert der Aktivierungs-Nudge. Eine E-Mail, die auf die konkrete Aktion fokussiert, die der Nutzer noch nicht ausgeführt hat.

Dieses Branching passiert in jeder Sequenz. Der Upgrade-Prompt prüft, ob der Nutzer zwischen E-Mails upgegraded hat. Die Churn-Prävention-Sequenz prüft, ob der Nutzer sich wieder eingeloggt hat. Die Win-Back-Sequenz prüft, ob der Nutzer sich re-abonniert hat.

Zwischen jedem step.sleep()-Aufruf (die Pause zwischen E-Mails) erstellt die Funktion eine neue Datenbankverbindung und prüft den aktuellen Status des Nutzers. Wenn der Nutzer bereits konvertiert hat, stoppt die Sequenz. Niemand bekommt eine Upgrade-E-Mail am Tag nach dem Upgrade.

Das ist, wie getriggerte E-Mails im Code aussehen. Nicht ein visueller Flow-Builder. Eine Funktion, die schläft, State prüft, verzweigt und sendet.

Die Trigger-Verkabelung

Sequenzen starten nicht von selbst. Irgendetwas in der App muss das Event feuern.

Das System findet diese Stellen in deiner Codebasis und verkabelt die inngest.send()-Aufrufe. Signup hat bereits einen Auth-Callback. Stripe hat bereits eine Webhook-Route. Der Limit-Check gibt bereits eine Antwort zurück, wenn ein Nutzer sein Limit erreicht. Jede Stelle bekommt eine Zeile, die ein Event mit der Nutzer-ID, E-Mail und relevanten Daten feuert.

Churn-Prävention ist anders. Sie läuft auf einem täglichen Cron-Job, nicht auf einem Event. Jeden Morgen fragt die Inngest-Funktion die Datenbank nach Nutzern ab, die seit 7+ Tagen nicht aktiv waren, und sendet individuelle Events für jeden. Die Sequenz pro Nutzer übernimmt den Rest.

Was die Daten sagen

Die Zahlen, die dieses System formen, kommen davon, wie E-Mails tatsächlich performen, nicht aus der Theorie.

Eine 7-E-Mail-Onboarding-Sequenz (getestet bei einem echten SaaS-Produkt) verschob die Trial-zu-Bezahlt-Konversion von 12% auf 22% und senkte den monatlichen Churn von 8% auf 4,8%. Das sind die zwei Metriken, die sich zusammensetzen. Ein 10-Punkte-Konversions-Lift plus eine 3-Punkte-Churn-Reduktion verändert die Mathematik für jeden Marketing-Dollar, den du ausgibst.

Plaintext gewinnt bei Klickraten, weil es wie eine Nachricht von einer Person wirkt, nicht wie eine Werbung. Das System rendert über React Emails render()-Funktion sowohl eine HTML-Version als auch eine Plaintext-Version jeder E-Mail. Empfänger, deren E-Mail-Clients Plaintext bevorzugen, bekommen automatisch die Plaintext-Version.

Kurze Betreffzeilen funktionieren, weil mobile Posteingänge kürzen. Eine 2-4-Wort-Betreffzeile ist auf jedem Gerät vollständig sichtbar. Das System hält jede Betreffzeile unter 50 Zeichen.

Verhaltens-Trigger übertreffen feste Timer, weil Relevanz wichtiger ist als Timing. Die richtige E-Mail nach der richtigen Aktion zu senden, schlägt jede E-Mail an Tag 3, unabhängig davon, was passiert ist.

Qualitätsgates

Nachdem alle sechs Agenten fertig sind, führt das System TypeScripts Type-Checker über das gesamte Projekt aus:

cd webapp && npx tsc --noEmit

Null Type-Fehler. Jedes Template hat typisierte Props. Jede Inngest-Funktion hat typisierte Event-Payloads. Jeder inngest.send()-Aufruf passt zur erwarteten Event-Form.

Dann liefert es lokale Test-Anweisungen:

# 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

Der Inngest-Dev-Server zeigt jede Funktionsausführung in Echtzeit. Du kannst jeden Schritt laufen sehen, jeden Sleep-Countdown, jede E-Mail, die gesendet würde. Nichts geht in der lokalen Entwicklung an echte Posteingänge.

Regeln für das Selbstbauen

Das Muster funktioniert mit jedem E-Mail-Anbieter, jeder Background-Job-Engine, jedem Framework. Das macht es funktionieren.

Lies dein Produkt, bevor du E-Mails entwirfst. Der häufigste Fehler ist das Schreiben von E-Mails, die generisch klingen, weil die Person, die sie schreibt, das Produkt nicht tief verstanden hat. Füttere das System mit deinen Produktdocs, Nutzerreisen und Brand Voice, bevor es ein Template anfasst.

Entwirf alle Sequenzen, bevor du eine davon baust. Präsentiere den vollständigen Plan. Hole Genehmigung ein. Dann baue. Eine Betreffzeile in einem Plan zu ändern, kostet nichts. Sie in einem gebautem Template zu ändern bedeutet Re-Rendering, Re-Testing und Re-Deployment.

Prüfe den Nutzerstatus zwischen jeder E-Mail. Nimm nie an, dass der Nutzer noch im selben Zustand ist wie beim Start der Sequenz. Ein step.sleep("3d") (warte 3 Tage) bedeutet drei Tage möglicher Änderungen. Frage die Datenbank ab, bevor du sendest.

Eine Aktion pro E-Mail. Nicht zwei Buttons. Nicht drei Links. Ein klarer nächster Schritt. E-Mails mit einem einzigen Call-to-Action haben höhere Klickraten, weil keine Entscheidung zu treffen ist.

Baue Plaintext neben HTML. Behandle Plaintext nicht als Nachgedanken. Rendere beide Versionen aus demselben Template. Plaintext-E-Mails bekommen in Direktvergleichen 42% mehr Klicks.

Verkable Trigger an bestehende Events, nicht an neue. Signup passiert bereits. Kündigung passiert bereits. Limit-Hits passieren bereits. Das E-Mail-System hakt sich in Events ein, die deine App bereits feuert. Das ist null neue Infrastruktur.

Über E-Mail hinaus

Das Parallel-Agenten-Muster (ein Basis-Agent baut gemeinsame Infrastruktur, dann bauen spezialisierte Agenten gleichzeitig darauf) funktioniert für mehr als E-Mail.

Benachrichtigungssysteme. Gleiche Struktur: entwirf alle Benachrichtigungstypen, baue Templates, verkable Trigger. Push-Benachrichtigungen, In-App-Alerts und SMS folgen alle denselben Lifecycle-Phasen.

Onboarding-Flows. Ein Agent liest den Produktkontext und entwirft den Flow. Separate Agenten bauen jeden Schritt (Willkommens-Modal, Feature-Tour, Checkliste, leere Zustände). Verhaltensbasiertes Branching entscheidet, welche Schritte basierend auf dem gezeigt werden, was der Nutzer bereits getan hat.

Dokumentation. Ein Agent baut die Struktur und gemeinsame Komponenten. Spezialisierte Agenten schreiben einzelne Abschnitte parallel. Gleiche Form. Gleiches Koordinierungsmuster.

Jedes Mal dieselbe Kernidee. Lies den Produktkontext zuerst. Entwirf vor dem Bauen. Baue parallel mit gemeinsamer Infrastruktur. Prüfe den Status vor dem Handeln. Type-checke alles am Ende.