FS
Email für SaaS
E-Mail Automation Datenmodell und Lifecycle

E-Mail-Automation für SaaS nach Datenmodell auswählen

Für ein SaaS-Team ist die entscheidende Frage bei einer E-Mail-Automation nicht zuerst, wie viele Nachrichten ein Editor gestalten kann. Entscheidend ist, ob die Plattform den Zustand eures Produkts richtig abbildet. Eine einzelne Person kann einen Account vertreten, mehrere Personen können zu einem B2B-Unternehmen gehören, und der Vertrag kann unabhängig vom Verhalten einer einzelnen Person aktiv, im Trial oder überfällig sein. Wenn diese Ebenen vermischt werden, bekommt ein aktiver Kunde womöglich eine Trial-Erinnerung oder ein einzelner Nutzer eine Nachricht, die nur für den Vertragsinhaber gedacht war.

Vergleiche deshalb Datenmodell, Identitäten und Übertragungsweg vor dem Funktionsumfang. Prüfe, ob Kontakteigenschaften, Account-Eigenschaften und Produkt-Events eigenständige Felder oder Objekte sind. Für Billing braucht es außerdem einen nachvollziehbaren Status aus Stripe oder Paddle: Ein Webhook kann eine Zahlung melden, doch eure Anwendung muss daraus einen eindeutigen, aktuellen Zustand machen. Marketing sollte mit verständlichen Namen und Regeln arbeiten können; Engineering muss IDs, Schema und Fehlerbehandlung kontrollieren.

Die Tabelle ordnet die Plattformen nach dem Einsatz, den du vorab prüfen solltest. Preise sind Einstiegswerte mit dem jeweiligen Tarif und Umfang, soweit ein passender Preis vorliegt. Sie ersetzen keinen Vergleich mit deiner tatsächlichen Kontaktzahl, Versandmenge oder benötigten Nutzer- und Accountstruktur.

Kurz gesagt

Wähle eine Plattform zuerst nach ihrem Datenmodell: Kann sie einzelne Kontakte, zugehörige Accounts, Produktaktivität und den aktuellen Billing-Status sauber auseinanderhalten? Die Antwort bestimmt, ob Willkommens-, Aktivierungs-, Trial-, Zahlungsfehler-, Upgrade- und Reaktivierungs-Flows belastbar arbeiten. Kläre vor dem Tarifvergleich, wie eure Daten hineingelangen, wer sie pflegt und wie ihr Änderungen in einer Testumgebung prüft.

PlattformPassender PrüfpunktDatenmodell im AuswahlgesprächEinstiegspreis
Customer.ioViele ProduktzuständeWie kommen Events und Profile aus eurem Produkt an?Essentials ab 100 $ monatlich
UserlistB2B mit mehreren PersonenWie werden Nutzer einem Unternehmen zugeordnet?Basic 149 $ monatlich bis 10.000 Nutzer
LoopsKleiner VersandstartWelche Kontakte und Ereignisse sind im Startumfang enthalten?Early Stage kostenlos; Growing Audience 99 $ monatlich bei 9.998 Abonnenten
SequenzySaaS-Billing-SignaleWie wird der Vertragsstatus an Kontakte gebunden?Kostenlos für 2.500 E-Mails monatlich; 15.000 E-Mails für 19 $ monatlich
EnchargeLifecycle-KommunikationWelche Events und Profile steuern einen Flow?Growth 99 $ monatlich oder 79 $ pro Monat bei jährlicher Abrechnung, bis 2.000 Abonnenten
DripKontaktbasierte AbläufeWie werden Nutzerstatus und Ereignisse übertragen?39 $ monatlich für 1–2.500 Personen
BrevoVersandbudget und KontaktbestandWelche Daten fließen laufend, welche nur als Liste?Free mit 300 E-Mails täglich; Starter 9 $ monatlich ab 5.000 E-Mails
ActiveCampaignMarketing und CRM zusammenWelche Felder bleiben Kontakt-, welche CRM-Daten?Starter 15 $ pro Monat bei jährlicher Abrechnung für 1.000 Kontakte
IntercomSupport und ProduktkontaktWie wird eine Person mit Account und Nachricht verknüpft?Essential 29 $ pro Platz und Monat bei jährlicher Abrechnung
KlaviyoProfile und SegmentierungWelche Ereignisse und Profilfelder sind für SaaS relevant?Free bis 250 aktive Profile; 20 $ monatlich für 500 Profile

1. Customer.io: Produktzustände in Segmente übersetzen

Customer.io passt in eine Evaluation, wenn euer Produkt viele eigenständige Verhaltenssignale erzeugt und Marketing diese in mehrstufige Kommunikation überführen möchte. Im Gespräch sollte nicht ein abstrakter Workflow-Editor im Mittelpunkt stehen, sondern die Frage, welche Identität eine Nachricht adressiert: die Person, die sich gerade angemeldet hat, oder das Unternehmen, dessen Team sie nutzt? Legt ein Beispielschema mit einer Person-ID, einer Account-ID und wenigen klar definierten Events vor und bittet das Team, daran den Weg von der Registrierung bis zum Upgrade nachzuzeichnen.

Customer.io Essentials kostet ab 100 $ pro Monat. Prüfe bei eurer Zielgröße, welche Profile und Versandmengen der konkrete Tarif abdeckt, und welche zusätzlichen Kosten bei Wachstum entstehen. Die Preisangabe ist ein Einstieg; für eine konkrete Kalkulation braucht ihr die aktuelle Menge und euren Abrechnungszeitraum. Auf der Datenzufuhrseite sollte Engineering klären, ob Ereignisse aus dem Backend oder aus clientseitigem Tracking kommen, wer doppelte Events verhindert und wie verspätete Ereignisse behandelt werden. Marketing sollte mit einem Beispieldatensatz nachvollziehen, ob Segmente die beabsichtigten Personen enthalten. Erst wenn beide Seiten dieselbe Interpretation teilen, werden Regeln für Aktivierung oder Trial-Ende wartbar.

Besonders wichtig ist die Semantik: Ein Event namens „Projekt erstellt“ sagt noch nicht, ob eine Person oder ein Account aktiviert ist. Definiert deshalb einen Zeitpunkt oder eine Bedingung, die das Produktteam verantwortet. Wenn die Plattform nur den Kontakt kennt, kann sie accountweite Reife nicht selbst herleiten. Wenn sie Account-Bezüge unterstützt, muss die Zuordnung trotzdem lückenlos aus eurem System stammen. Diese Vorarbeit ist für jede Plattform nötig, bei umfangreichen Eventlandschaften aber besonders sichtbar.

2. Userlist: Personen und Unternehmen getrennt betrachten

Bei B2B-SaaS besteht ein Kunde oft aus mehreren Nutzern, die gemeinsam einen Vertrag verwenden. Userlist ist deshalb ein sinnvoller Kandidat, wenn ihr gezielt prüfen wollt, wie ein Anbieter User- und Company-Ebene in der täglichen Arbeit abbildet. Bringt zur Demo eine konkrete Situation mit: Eine Person nimmt eine Einladung an, zwei Kolleginnen sind bereits aktiv, und der Account hat noch keine zentrale Integration eingerichtet. Welche Nachricht erhält jede Person, und welche Information sieht das Team auf Unternehmensebene? Damit wird klar, ob eure Segmentlogik Einzelpersonen und den gemeinsamen Account wirklich trennt.

Der Basic-Tarif kostet 149 $ pro Monat bis 10.000 Nutzer. Die Preisbasis ist hier eine Nutzerzahl; fragt nach, wie weitere Nutzer berechnet werden und wie inaktive oder doppelte Profile zählen. Testet auch die Zuordnung bei Rollenwechseln, Einladungen und gelöschten Mitgliedern. Eine E-Mail-Adresse ist kein stabiler Unternehmensschlüssel, weil Mitarbeitende wechseln und eine Domain mehrere Kundengruppen enthalten kann. Gebt daher eine dauerhafte Account-ID aus eurem Anwendungssystem vor und haltet fest, welches System die Zuordnung ändern darf.

Eine Account-Ansicht löst Billing nicht automatisch. Für Zahlungsausfälle oder einen Planwechsel muss die Plattform den Status des zahlenden Kontos erhalten, nicht bloß den letzten Klick eines Nutzers. Prüft, ob diese Information über eure Integration, einen API-Aufruf oder einen normalisierten Webhook ankommt und ob Marketing sie als lesbares Feld verwenden kann. Der beste Probelauf ist ein Account mit mehreren Testpersonen, bei dem eine Person kündigt, eine andere aktiv bleibt und der Vertrag seinen Status ändert. So entdeckt ihr früh, ob eure Automationen die richtige Ebene adressieren.

3. Loops: Einen schlanken Datenumfang bewusst begrenzen

Loops eignet sich als Prüfpunkt für Teams, die mit einem überschaubaren Kontaktbestand und klar abgegrenzten Lifecycle-Nachrichten starten wollen. Lege vor der Auswahl fest, welche wenigen Datenfelder tatsächlich eine E-Mail verändern: zum Beispiel Anmeldedatum, Aktivierungsstatus, Trial-Ende und Plan. Ein kleines, stabiles Schema ist oft hilfreicher als ein vollständiger Export aller Nutzungsdaten. Die Kernfrage lautet, ob die Plattform den gewünschten Zustand laufend erhält oder ob das Team regelmäßig Listen exportieren und erneut importieren müsste.

Der Early Stage Plan ist kostenlos und umfasst bis zu 4.000 Sendungen in einem rollierenden Zeitraum von 30 Tagen an die 1.000 neuesten Kontakte. Growing Audience kostet 99 $ pro Monat bei 9.998 Abonnenten. Prüfe, welche Kontakte im konkreten Tarif als Abonnenten zählen und wie Transaktionsnachrichten berücksichtigt werden. Der Preis richtet sich nach dem gewählten Umfang; vergleiche daher nicht nur eine Tarifzeile, sondern deinen erwarteten Bestand und Versand. Wenn Nutzer sowohl Marketing-E-Mails als auch wichtige Produktmeldungen erhalten, müssen Einwilligung und Nachrichtentyp getrennt bleiben.

Für die technische Seite sollte das Team einen kleinen Datenvertrag erstellen: eindeutige Nutzer-ID, zulässige Profilfelder, Eventnamen und Zeitstempel. Danach lässt sich prüfen, wie der Anbieter diese Informationen annimmt und welche Felder Marketing selbst ändern kann. CSV eignet sich für einen einmaligen Startbestand, ist aber kein Ersatz für Statusänderungen in Echtzeit. Eine spätere Migration wird einfacher, wenn die Ereignisse nicht an eine bestimmte Kampagne gekoppelt sind. Dokumentiere deshalb schon beim Start, was ein Event bedeutet und welche Automation davon abhängt.

4. Sequenzy: Billing-Status in den Auswahlvergleich aufnehmen

Sequenzy bietet native Stripe-Integration und MCP-Unterstützung.

Bei einem SaaS-Produkt sollte ein Abrechnungsereignis nicht als lose Notiz am Kontakt enden. Kläre, ob eure Anwendung daraus einen aktuellen Vertragsstatus macht, ob ein Account mehrere Kontakte enthält und welcher Status bei widersprüchlichen oder verspäteten Webhooks gilt. Zeichne dazu den Weg vom Ereignis des Zahlungsdienstleisters bis zum Segment auf, das eine Nachricht auslöst. Für Paddle und andere Zahlungsdienste ist derselbe Ablauf einzeln zu prüfen; die Existenz einer Integration für einen Anbieter belegt keine Unterstützung für einen anderen.

Der kostenlose Tarif umfasst 2.500 E-Mails pro Monat; der Tarif für 15.000 E-Mails kostet 19 $ pro Monat. Die Preisbasis sind gesendete E-Mails, nicht die Zahl der gespeicherten Kontakte. Vergleiche sie deshalb mit eurer tatsächlichen Versandplanung und berücksichtige alle Lifecycle-Nachrichten, die ihr parallel verschicken möchtet. Unabhängig vom Tarif sollte Engineering den Empfang und die Auswertung von Billing-Events verantworten. Marketing legt fest, welche Nachricht auf einen verifizierten Status folgt, wie häufig sie gesendet wird und wann ein Kontakt ausgeschlossen wird. Ein sauberer Zuständigkeitsvertrag ist hier ebenso wichtig wie die technische Verbindung.

5. Encharge: Flows anhand einer Eventliste bewerten

Bei Encharge ist ein guter Auswahltest, ob eine geplante Lifecycle-Automation verständlich aus einer Eventliste aufgebaut werden kann. Nimm dazu keine zehn Kampagnen, sondern einen einzigen Ablauf wie Aktivierung: Registrierung, erste erfolgreiche Kernaktion, Wartefenster und Abbruchbedingung. Lass Marketing erklären, welche Inhalte und Ausschlüsse dazugehören, und Engineering erläutern, wie diese Events zuverlässig eintreffen. Wenn die Regeln nur funktionieren, solange eine Person in einer Tabellenansicht manuell korrigiert, ist das zugrunde liegende Modell noch nicht bereit.

Growth kostet 99 $ monatlich oder 79 $ pro Monat bei jährlicher Abrechnung und gilt bis 2.000 Abonnenten. Zusätzlich sind Versand- und Eventgrenzen relevant, daher solltet ihr den Umfang neben der Kontaktzahl prüfen. Vermeide den Vergleich von Monats- und Jahreswerten ohne den Abrechnungszeitraum mitzunennen. Eine belastbare Planung zählt außerdem Testprofile, interne Mitarbeitende und Kontakte, die zwar gespeichert, aber von allen Nachrichten ausgeschlossen sind.

Für die Datenzufuhr kann es unterschiedliche Pfade geben: Backend-API, ein SDK im Produkt, eine vorhandene Integration oder ein gelegentlicher Dateiimport. Lass den Anbieter für euren Anwendungsfall genau benennen, welcher Pfad unterstützt wird, wie Fehler sichtbar werden und ob ein erneut gesendetes Event Duplikate erzeugt. Für Billing sollte ein vertrauenswürdiger Serverprozess den bestätigten Status übertragen; eine Browseraktion wie der Klick auf eine Checkout-Schaltfläche belegt keine erfolgreiche Zahlung. Wenn Marketing eine Trial-Nachricht bearbeitet, darf das keine technischen Statusfelder überschreiben. So bleibt die Grenze zwischen Inhaltspflege und Datenverantwortung klar.

6. Drip: Kontaktstatus und Versandumfang auseinanderhalten

Drip kann in die Prüfung aufgenommen werden, wenn euer Team ein kontaktbezogenes Modell mit nachvollziehbaren Eigenschaften und wiederkehrenden Abläufen abbilden möchte. Für SaaS ist dabei nicht entscheidend, ob ein Anbieter allgemein automatisierte Nachrichten ermöglicht, sondern ob euer Nutzungsstatus und euer Vertrag als getrennte Tatsachen ankommen. Erstellt einen Testkontakt mit einem abgeschlossenen Trial und einem aktiven Vertrag. Ein Flow darf diesen Kontakt nicht als unkonvertiert behandeln, nur weil das Feld „Trial-Ende“ unverändert geblieben ist.

Der Tarif für 1 bis 2.500 Personen kostet 39 $ monatlich. Die Personenanzahl und die enthaltenen Funktionen bilden den Startpunkt; bei einem größeren Bestand solltet ihr die nächste Preisstufe anhand eurer realen Daten prüfen. Eine Liste gespeicherter Kontakte ist nicht identisch mit der Anzahl der tatsächlich erreichbaren Empfänger. Legt fest, wie abgemeldete Kontakte, interne Testpersonen und gelöschte Nutzer gezählt oder synchronisiert werden. So vermeidet ihr, dass ein Import eine größere Zielgruppe erzeugt als das Produkt tatsächlich hat.

Fragt bei der Evaluierung außerdem, ob neue Aktivitätsdaten per API, SDK, Integration oder Dateiübergabe eingehen und wie ein fehlgeschlagener Transfer auffällt. Für einen einmaligen Kontaktimport genügt oft eine CSV. Bei Upgrade, Kündigung oder fehlgeschlagener Zahlung braucht ihr eine laufende und überprüfbare Übermittlung. Eine einfache Kontrolle vergleicht täglich die Anzahl übertragener Billing-Änderungen mit den Änderungen im Quellsystem. Engineering sollte diese Kontrolle einrichten; Marketing benötigt eine verständliche Anzeige des resultierenden Status, damit eine Automation keine Zahlungsdetails interpretieren muss.

7. Brevo: Versandgrenzen und Automationsdaten getrennt planen

Brevo ist ein Kandidat, wenn Versandvolumen und Kontaktbestand für eure Entscheidung eine größere Rolle spielen als ein besonders detailliertes Accountmodell. Für SaaS sollte das Team gezielt prüfen, welche Automationsdaten verfügbar sind und ob die Grenze des kostenlosen Plans zu den vorgesehenen Flows passt. Der Free-Tarif erlaubt 300 E-Mails pro Tag und bis zu 100.000 gespeicherte Kontakte; für Marketing-Automation sind darin bis zu 2.000 Kontakte relevant. Starter beginnt bei 9 $ pro Monat für 5.000 E-Mails monatlich und enthält im ersten Preisbereich Platz für bis zu 500 Kontakte.

Diese Einheiten sind nicht austauschbar: Eine hohe Kontaktgrenze sagt nichts darüber aus, wie viele Kontakte an einer Automation teilnehmen können, und ein tägliches Sendelimit sagt nichts über den Datenumfang aus. Berechnet daher zuerst, wie viele Einladungen, Willkommensnachrichten und Lifecycle-Mails bei eurer aktiven Nutzerzahl anfallen. Für Trial-Ende oder Zahlungsfehler sind außerdem aktuelle Statusdaten nötig, nicht nur ein monatlicher Listenimport.

Beim Datenmodell solltet ihr einen kleinen Beispieldatensatz einspielen und kontrollieren, ob Personenfelder und Account-Attribute unterscheidbar bleiben. Falls B2B-Konten aus mehreren Nutzerkontakten bestehen, definiert, welcher Kontakt eine Vertragsnachricht erhält und wer eine Aktivierungsnachricht bekommt. Ein API- oder Webhook-Prozess sollte serverseitig nachvollziehbar sein; ein CSV-Import kann sich für Migration und initiale Bereinigung eignen. Marketing sollte nur jene Segmente bearbeiten, deren Kriterien dokumentiert sind. Wenn die Plattform keinen stabilen Accountbezug bietet, muss dieser möglicherweise vor dem Export in eurem eigenen Backend aufgelöst werden.

8. ActiveCampaign: CRM-Felder gegen Produktstatus abgrenzen

Wenn Marketing und Vertrieb bereits mit einem CRM arbeiten, prüfe ActiveCampaign anhand eines gemeinsamen Datenwörterbuchs. CRM-Felder wie Lead-Quelle oder Vertriebsphase beschreiben nicht automatisch, ob ein Produktnutzer aktiviert ist oder ob ein Konto bezahlt. Lege fest, welches System jede Information besitzt, wer Änderungen vornehmen kann und wie Konflikte gelöst werden. Ein Flow für Produktaktivierung sollte nicht an ein Feld gebunden sein, das ein Vertriebsteam aus einem anderen Grund manuell pflegt.

Starter kostet 15 $ pro Monat bei jährlicher Abrechnung für 1.000 Kontakte. Im Tarif ist ein Nutzer enthalten, und eine Automation kann bis zu fünf Aktionen umfassen. Diese Grenze ist beim Entwurf konkreter Flows zu berücksichtigen: Zeichne die Schritte für eine Willkommenssequenz oder Upgrade-Nachricht auf und prüfe, ob Bedingungen und Aktionen innerhalb des Tarifs abbildbar sind. Der Einstiegspreis ist kein Beleg dafür, dass alle CRM- und Lifecycle-Anforderungen im selben Umfang enthalten sind.

Beim Übertragungsweg sollte das Team unterscheiden, ob ein Ereignis aus dem Produkt, dem CRM oder einem Abrechnungsdienst stammt. Ein Zahlungsausfall kann nicht aus einem Lead-Status abgeleitet werden. Wenn ihr einen Integrationsdienst oder einen eigenen Webhook nutzt, protokolliert die Umwandlung in ein internes Feld und verhindert, dass ein älteres Ereignis einen neueren Status zurücksetzt. Marketing kann anschließend eine verständliche Regel wie „Vertrag überfällig“ verwenden, ohne sich mit Rohdaten oder Zahlungsantworten auseinanderzusetzen. Diese Arbeitsteilung hält Kampagnen bedienbar und senkt das Risiko fehlerhafter Nachrichten.

9. Intercom: Produktkommunikation mit Supportkontext bewerten

Intercom sollte in den Vergleich, wenn ihr neben E-Mail auch Support- und Produktkontakte koordinieren möchtet. Bevor ihr einen Ablauf entwerft, trennt die Supportbeziehung von der kommerziellen Identität: Eine Person kann eine Frage stellen, während Vertrag und Zahlung dem gesamten Unternehmen zugeordnet sind. Prüft, ob die Plattform diese Zuordnung in eurer gewünschten Weise darstellt und ob eine Supportinteraktion eine Marketingautomation versehentlich starten oder unterbrechen kann.

Essential kostet 29 $ pro Platz und Monat bei jährlicher Abrechnung. Bei monatlicher Zahlung sind es 39 $ pro Platz und Monat. Fin ist separat mit 0,99 $ je Lösung bepreist. Diese Werte gehören zu unterschiedlichen Einheiten und sollten deshalb nicht zu einem Gesamtbetrag addiert werden, bevor ihr wisst, wie viele Plätze und Lösungen tatsächlich anfallen. Für die Entscheidung über SaaS-Lifecycle-E-Mails ist außerdem zu klären, welche Automationsmöglichkeiten in dem benötigten Tarif liegen und welche primär für Supportprozesse gedacht sind.

Teste einen konkreten Ablauf von Aktivierung bis Zahlungsfrage: Welche Information kann das Supportteam sehen, welche darf Marketing für Segmente nutzen, und wer korrigiert einen falschen Vertragsstatus? Daten aus einem Zahlungswebhook sollten in einem kontrollierten Prozess validiert werden. Eine Supportnachricht ist kein Beweis für einen Planwechsel. Marketing definiert Ton und Versandregeln; Support pflegt Gesprächskontext; Engineering verantwortet Identitäten und die Übertragung zwischen Produkt, Billing und Kommunikationsplattform. So werden Antworten nicht mit Kampagnen verwechselt und Accountstatus bleiben nachvollziehbar.

10. Klaviyo: Profilbestand auf SaaS-Signale prüfen

Klaviyo ist vor allem als Plattform mit Profilen, Segmenten und ereignisbezogener Kommunikation in der Auswahl, aber für ein SaaS-Team lohnt ein konkreter Abgleich mit den eigenen Produktdaten. Fragt, welche Ereignisse im benötigten Umfang verarbeitet werden, wie Eigenschaften aktualisiert werden und ob ein Account mit mehreren Nutzern ein eigenes Objekt sein kann. Wo die Plattform nur Kontaktprofile nutzt, braucht ihr eine klare Strategie, um accountweite Kriterien in ein Kontaktsegment zu übersetzen.

Der Free-Tarif umfasst bis zu 250 aktive Profile und 500 E-Mail-Sendungen pro Monat. Für 500 Profile kostet der E-Mail-Tarif 20 $ monatlich und enthält 5.000 Sendungen. Vergleicht diese Einheiten mit eurer aktiven Nutzerzahl und euren erwarteten Nachrichten, nicht mit der Gesamtzahl aller registrierten Konten. Ein kostenpflichtiger Tarif kann bei einer großen, aber wenig aktiven Datenbank trotzdem anders passen als bei einer kleineren Gruppe mit vielen Lifecycle-Nachrichten.

Bevor ihr Daten übertragt, trennt Produkt-Events von abgeleiteten Segmenten. Das Backend kann beispielsweise eine Aktivierung als eindeutig festgestellten Status senden, während Marketing entscheidet, welche Nachricht folgt. Für Abrechnungsdaten sollte der Vertrag nach erfolgreicher Verarbeitung als eigener Zustand übertragen werden. Prüft bei einem Import, ob bestehende Profile zusammengeführt werden oder doppelt entstehen, wenn eine Person zunächst mit einer privaten und später mit einer Firmenadresse registriert wird. Eine stabile interne ID erleichtert die Bereinigung und verhindert, dass ein Nutzer nach einem Adresswechsel erneut in eine Willkommenssequenz gelangt.

Nächste Schritte: Schema, Pilot und Zuständigkeit festhalten

Schreibe vor einem Vertragsschluss eine Seite mit den benötigten Identitäten, Feldern und Events. Markiere für jedes Feld das Quellsystem, den Verantwortlichen, die erlaubten Werte und den Zeitpunkt, an dem es aktualisiert wird. Wähle dann eine Plattform, die dieses Modell ohne dauernde manuelle Korrekturen verarbeiten kann. Mit einem einzelnen Pilotflow lässt sich schneller lernen als mit einer vollständigen Lifecycle-Landkarte.

Für den Pilot reichen ein Testkontakt, ein Testaccount und ein überschaubarer Ablauf. Lege fest, welche Ereignisse den Einstieg auslösen, welche Statusänderung den Kontakt entfernt und wer eine Nachricht freigibt. Prüfe auch, was bei fehlenden oder doppelt eingehenden Events geschieht. Erst wenn Zuständigkeiten und Datenweg dokumentiert sind, lohnt sich die Übertragung auf echte Nutzergruppen.

Weitere Themen findest du unter Drip-Kampagnen, SaaS-Onboarding, Marketing-Automation, Trial-Conversion und E-Mail-Analysen.

Häufige Fragen

Soll ich Kontakte oder Accounts als Ausgangspunkt wählen?

Wenn Kauf, Vertrag und Aktivierung für das ganze Unternehmen gelten, brauchst du ein Accountmodell mit verknüpften Personen. Bei einem Produkt, das einzelne Nutzer unabhängig abrechnen und aktivieren kann, genügt oft ein Kontaktmodell.

Welche Ereignisse sollte ich zuerst übertragen?

Beginne mit Registrierung, erstem wichtigen Produktmoment, Trial-Ende, erfolgreicher oder fehlgeschlagener Zahlung, Planwechsel und Kündigung. Übertrage nur Ereignisse, deren Bedeutung und Zeitpunkt im Produkt eindeutig sind.

Reicht eine CSV-Datei für Automationen?

Eine CSV kann vorhandene Kontakte und statische Eigenschaften importieren. Sie ersetzt keinen fortlaufenden Ereignisstrom für Anmeldung, Nutzung und Zahlung. Prüfe, ob API, SDK oder eine vorhandene Integration die laufenden Änderungen zuverlässig überträgt.

Wie ordne ich Personen einem B2B-Account zu?

Verwende eine stabile Account-ID, die auch in Produktdaten und Billing vorkommt. So können einzelne Nutzeraktivität und der gemeinsame Vertragsstatus getrennt ausgewertet werden, ohne sie anhand von Namen oder E-Mail-Domains zu erraten.

Wer sollte Ereignisse und Segmente pflegen?

Engineering verantwortet Schema, IDs, Übertragung und Fehlerbehandlung. Marketing definiert Zielgruppen, Inhalte, Ausschlüsse und Versandregeln. Beide Teams stimmen die Bedeutung der Ereignisse und die Freigabe von Änderungen ab.

Wie teste ich einen Trial-Ende-Flow?

Nutze eine Staging-Umgebung mit Testkonten und simulierten Zeitpunkten. Prüfe Eintritt, Wartezeit, Statusänderung, Ausschluss bei Upgrade und den tatsächlichen Nachrichteninhalt, bevor du den Flow für echte Konten aktivierst.

Wie gelangen Stripe- oder Paddle-Zahlungsdaten in die Plattform?

Das hängt vom Anbieter und der Integration ab. Prüfe konkret, ob ein Ereignis direkt übernommen wird oder ob dein Backend einen Webhook validieren und normalisieren muss. Speichere keine Kartendaten im Marketingprofil.

Was sollte ich vor einem Anbieterwechsel exportieren?

Sichere Kontakte, Account-Zuordnungen, Einwilligungen, relevante Ereignisse, Segmentdefinitionen und aktive Automationslogik. Plane außerdem einen Abgleich der IDs und Statuswerte, damit bestehende Empfänger nicht versehentlich erneut in eine Sequenz eintreten.