Jede Onboarding-E-Mail beginnt in Migma mit einer klaren Handlungsaufforderung an den Nutzer. Genauso wichtig ist eine eindeutige Regel für das Workflow-Team: Wann verliert diese Aufforderung ihren Sinn? Selbst das am besten gestaltete Setup-Reminder wirkt unprofessionell, wenn der Nutzer die Einrichtung bereits gestern abgeschlossen hat.
Dieser Leitfaden von Migma konzentriert sich auf Exit Rules für Teams, die Loops einsetzen. Statt starre Versandpläne nach Tagen vorzugeben, liefert er ein praxiserprobtes Review-Worksheet und konkrete Testszenarien. Der Stand der offiziellen Dokumentation wurde am 15. Oktober 2026 geprüft. Migma deckt dabei den kreativen Review-Prozess ab – die Implementierung und Verifikation von Kontaktstatus und Workflow-Logik liegen bei den zuständigen Produkt- und E-Mail-Teams.
Abschlüsse so definieren, dass das Produkt sie verifizieren kann
Definieren Sie die gewünschte Aktion hinter jedem Reminder in einem einzigen präzisen Satz. Bei einer Projektmanagement-App könnte der entscheidende Meilenstein beispielsweise lauten: „Der Nutzer veröffentlicht sein erstes Projekt mit mindestens einer Aufgabe.“ Ein reines Login oder das Öffnen der Willkommens-E-Mail reicht dafür nicht aus.
Legen Sie anschließend die Datenquelle für dieses Ereignis fest. Ein Product Event, ein gespeichertes Kontaktattribut (Contact Property) und ein E-Mail-Open sind grundlegend unterschiedliche Signale. Das Produktteam muss klären, wie der Zielstatus an die Versandplattform übermittelt wird und wie dessen Eingang kontrolliert werden kann. Ein Entwurf mit der Aufforderung „Projekt jetzt fertigstellen“ darf nicht darauf beruhen, ob der Nutzer möglicherweise schon eines angelegt hat.
Der Leitfaden für Onboarding-Beispiele von Loops empfiehlt, den Abschlussstatus in einer Kontakt-Property zu spiegeln und diesen Wert vor jedem weiteren Setup-Reminder abzufragen. Übernehmen Sie Beispiel-Properties jedoch nicht unbesehen, sondern definieren Sie eigene, produktspezifische Meilensteine.
Creative Briefings um eine Exit-Spalte erweitern
Erfassen Sie in Migma das freigegebene Copywriting, den Markenkontext und die Kernaktion jeder Nachricht. Ergänzen Sie das Briefing um ein kompaktes Worksheet für das Workflow-Team direkt neben der Designversion. So sehen alle Beteiligten im Review sofort, an welche Bedingung ein Textbaustein geknüpft ist.
| Zweck der Nachricht | Relevanter Nutzerstatus | Nachricht stoppen oder anpassen, wenn |
|---|---|---|
| Erstes Projekt anlegen | Nutzer hat den Meilenstein noch nicht erreicht | Abschluss im System registriert wird |
| Unvollständige Integration erklären | Schnittstelle fehlt noch, Nutzer hat die nötigen Rechte | Verbindung steht oder Nutzer fehlen die Berechtigungen |
| Setup-Hilfe anbieten | Nutzer ist qualifiziert, kommt aber nicht weiter | Setup beendet ist, Rechte sich ändern oder Sequenz ausläuft |
| Nächsten Arbeitsschritt vorstellen | Erster Meilenstein ist erfolgreich abgeschlossen | Anschlussaufgabe bereits erledigt oder nicht relevant ist |
Diese Regeln dienen als Modell für die Beispiel-App – sie stellen weder gemessene Richtwerte noch eine schlüsselfertige Loops-Konfiguration dar. Stimmen Sie die Kriterien vor dem Livegang immer mit den Verantwortlichen für Ihre Produktdaten ab.
Gültigkeitsbereich der Zielgruppenfilter prüfen
Die aktuelle Branching-Dokumentation von Loops unterscheidet zwischen „All following nodes“ und „Next node only“. Bei der ersten Option scheidet ein Kontakt aus dem gesamten Workflow aus, sobald er die Bedingung zu einem späteren Zeitpunkt nicht mehr erfüllt. Bei „Next node only“ gilt die Bedingung ausschließlich beim Erreichen des unmittelbar nächsten Knotens – spätere Statuswechsel führen nicht zum Abbruch.
Dieser Unterschied ist entscheidend, wenn Nutzer den Setup-Schritt während einer Wartezeit (Wait-Node) abschließen. Ein einzelner Filter zu Beginn der Sequenz garantiert nicht, dass spätere Reminder noch relevant sind. Lassen Sie sich vom Workflow-Owner genau zeigen, an welchen Stellen die Abbruchbedingung greift und was mit Kontakten passiert, die bereits in nachgelagerten Schritten warten.
Prüfen Sie zudem die Versionslogik der Verzweigungen: Loops dokumentiert eine Umstellung von früheren parallelen Auswertungen hin zu First-Match-Verhalten für neue Branches. Bestehende Verzweigungen behalten ihre alte Logik bei, solange sie nicht manuell aktualisiert werden. Verlassen Sie sich bei bestehenden Workflows daher nie auf Screenshots aktueller Dokumentationen.
Nutzerrollen und Fortschritt strikt trennen
Ein eingeladener Teamkollege kann im Produkt aktiv sein, ohne die Berechtigung zu besitzen, unternehmensweite Datenquellen anzubinden. Umgekehrt kann der Workspace-Admin die Integration bereits eingerichtet haben, während ein Teammitglied noch auf ein Reminder wartet. Im Briefing muss daher klar festgehalten werden, ob ein Meilenstein auf Nutzer-, Account- oder Workspace-Ebene gemessen wird.
Diese Unterscheidung gehört auch in das Copywriting: Die Aufforderung „Verbinden Sie die Datenquelle Ihres Teams“ ist für Administratoren sinnvoll, für reine Bearbeiter jedoch irreführend. Fehlen verlässliche Rollendaten, formulieren Sie den Text neutral und definieren Sie gemeinsam mit der Implementierung, wie unklare Zustände gehandhabt werden.
Aktuelle Loops-Branches werten Filter von links nach rechts aus und folgen dem ersten Treffer. Ein ganz rechts platzierter Filter ohne Bedingungen kann als Default-Pfad dienen. Behandeln Sie diesen Pfad als inhaltliche Entscheidung: Fehlende Daten dürfen nicht dazu führen, dass Nutzern fälschlicherweise ein unvollständiges Setup unterstellt wird.
Statuswechsel während der Wartezeit gezielt testen
Erstellen Sie einen übersichtlichen Testplan mit synthetischen Datensätzen, den das zuständige Team in einer geeigneten Testumgebung durchspielt. Verändern Sie keine Kontakt-Properties realer Kunden, nur um Screenshots zu erstellen.
Testen Sie mindestens fünf Szenarien:
- Ein Kontakt schließt das Setup gar nicht ab.
- Ein Kontakt erreicht den Meilenstein vor dem ersten Reminder.
- Ein Kontakt schließt das Setup während der Wartezeit zwischen zwei Remindern ab.
- Ein Datensatz weist unvollständige Statusdaten auf.
- Ein Kontakt vertritt eine Nutzerrolle ohne Berechtigung für die geforderte Aktion.
Dokumentieren Sie für jedes Szenario die erwartete Nachricht bzw. den Exit, das tatsächliche Workflow-Verhalten und die verwendete Designversion. Wird ein Reminder trotz erfolgreichem Abschluss verschickt, prüfen Sie zuerst die Event-Synchronisierung und die Filterreichweite, bevor Sie an der Headline feilen. Eine treffendere Formulierung rettet keine fehlerhafte Zielgruppenlogik.
Finale E-Mails mit dem freigegebenen Design abgleichen
Prüfen Sie den Entwurf in Migma auf eine eindeutige Handlungsaufforderung und verständliche Hilfestellungen für den nächsten Schritt. Nutzen Sie Email Preflight, um das Creative technisch und visuell zu testen. Halten Sie die E-Mail kurz, damit Call-to-Action und Support-Kanäle sofort ins Auge fallen.
Für die Übergabe an Entwickler eignen sich die Exportoptionen von Migma, um Templates in Loops passgenau aufzubauen (dies impliziert keinen nativen Direkt-Export von Migma zu Loops). Testen Sie Ziel-Links immer mit verschiedenen Nutzerrollen und Statusvarianten: Ein Link kann technisch funktionieren, führt einen Nutzer ohne Rechte aber möglicherweise auf eine Fehlerseite.
Trennen Sie das Freigeben des Creatives strikt vom Acceptance-Testing des Workflows: Der Migma-Entwurf zeigt das freigegebene Design. Die empfangene Testnachricht und der dokumentierte Workflow-Pfad belegen, wie die Automation in der Praxis reagiert.
Reminder beenden und sinnvoll anknüpfen
Erreicht ein Nutzer das Ziel, muss die bestehende Setup-Aufforderung stoppen. Das bedeutet nicht, dass sofort die nächste E-Mail folgen muss. Prüfen Sie, ob der Nutzer eine Bestätigung, eine weiterführende Anleitung oder schlicht Zeit zum Arbeiten mit dem Produkt benötigt.
In unserer Beispiel-App könnte ein erstelltes Projekt später Tipps zur Team-Kollaboration auslösen, während unvollständige Accounts ein kurzes Hilfsangebot erhalten. Beide Nachrichten bedienen völlig unterschiedliche Kontexte und erfordern eigene Briefings. Vermeiden Sie es, ein generisches Setup-Reminder unter neuem Betreff endlos weiterzuschicken.
Erstellen Sie Ihre Entwürfe in Migma und machen Sie Exit Rules schon im Review-Prozess sichtbar. Lassen Sie sich anschließend vom Workflow-Owner nachweisen, dass Reminder aus den richtigen Gründen stoppen. Ein durchdachtes Onboarding honoriert den Fortschritt der Nutzer ebenso aufmerksam, wie es sie dazu auffordert.
Häufig gestellte Fragen
Reicht das Öffnen einer E-Mail als Abschlusskriterium für das Onboarding?
Nein. Ein E-Mail-Open belegt keinen Fortschritt im Produkt. Definieren Sie konkrete Produktaktionen und stellen Sie sicher, dass dieser Status verlässlich an die Versandplattform übertragen wird.
Was geschieht, wenn ein Nutzer während einer Wartezeit aktiv wird?
Im Idealfall stoppen überflüssige Setup-Reminder sofort. Der Workflow-Owner muss prüfen, wie der Kontaktstatus aktualisiert wird und ob der Zielgruppenfilter für Kontakte in Warteknoten greift.
Nutzen alle gespeicherten Branches in Loops dieselbe Auswertungslogik?
Nein. Die offizielle Dokumentation unterscheidet zwischen neueren First-Match-Verzweigungen und älteren Branches, die bis zu einem manuellen Upgrade parallele Bedingungen nutzen. Prüfen Sie bestehende Workflows daher direkt im System.
Wird für diesen Prozess eine native Schnittstelle zwischen Migma und Loops benötigt?
Nein. Creatives werden in Migma gestaltet und geprüft und anschließend über die passenden Exportoptionen im Zielsystem umgesetzt. Die finale Funktionsprüfung von Template und Workflow erfolgt im jeweiligen Versandtool.