E-Mail- und Push-Fallbacks: Klare nächste Schritte

Eine Fallback-E-Mail sollte Kundinnen und Kunden dabei unterstützen, eine noch offene Aufgabe abzuschließen. Erstellen Sie dieses Mailing in Migma mit denselben freigegebenen Fakten und demselben Ziel-Link wie bei der ursprünglichen Push-Benachrichtigung. Die Entscheidung, wann der Versand tatsächlich ausgelöst wird, liegt beim Journey Owner.

Die entscheidende Frage ist nicht, wie sich eine Push-Nachricht in ein längeres Format übertragen lässt. Es geht darum, ob die Information noch relevant ist und ob E-Mail an dieser Stelle der passende Kanal ist. Ignoriert ein Fallback bereits abgeschlossene Aktionen, erinnert er Nutzer an Aufgaben, die sie längst erledigt haben.

Dieser Leitfaden von Migma beschreibt einen Content- und Freigabe-Workflow für Teams, die Multi-Channel-Plattformen wie Customer.io nutzen. Er setzt nicht voraus, dass Migma fehlgeschlagene Push-Zustellungen automatisch erkennt oder die Fallback-Logik einer externen Plattform steuert.

Definieren, was „Fallback“ in dieser Journey bedeutet

Der Begriff „Fallback“ kann ganz unterschiedliche Szenarien meinen: Eine Push-Benachrichtigung lässt sich nicht zustellen, weil die Berechtigung im Betriebssystem fehlt. Der Versanddienstleister meldet einen technischen Zustellfehler. Oder die Nachricht wurde zugestellt, die eigentliche Aufgabe ist jedoch weiterhin offen. Diese Zustände sind keineswegs identisch.

Dokumentieren Sie die exakte Bedingung, auf der Ihr Workflow aufbaut. Wenn das Kriterium „Aufgabe nach definiertem Intervall unvollständig“ lautet, benennen Sie es genau so. Sprechen Sie nicht von einem „Push-Fehlschlag“, wenn keine Belege für einen Zustellungsfehler vorliegen. Dieser Unterschied beeinflusst sowohl das Routing als auch das Wording der E-Mail.

Der Leitfaden zur Kanalstrategie von Customer.io erläutert, wie sich Kanäle auf den Kontext der Zielgruppe abstimmen und orchestrieren lassen. Er bietet eine gute Grundlage für inhaltliche Entscheidungen. Technisch muss die für die Implementierung zuständige Person prüfen, welche Signale und Steuerungsoptionen in der Live-Journey tatsächlich zur Verfügung stehen.

Die Aufgabe anhand von drei Entscheidungen prüfen

Klären Sie zuerst, ob die Aufgabe überhaupt noch relevant ist. Hat der Kunde das Setup abgeschlossen, muss die Erinnerung stoppen. Wurde ein Termin storniert, verliert die Terminerinnerung ihren ursprünglichen Zweck. Eine zuvor versendete Benachrichtigung reicht als Begründung für ein weiteres Mailing nicht aus.

Prüfen Sie zweitens, ob E-Mail für die Person und den Anlass der richtige Kanal ist. Gleichen Sie Kanalberechtigungen und den Zweck der Nachricht mit den internen Richtlinien Ihres Teams ab. Ein Opt-in für einen Kanal bedeutet nicht automatisch die Berechtigung, denselben Inhalt über jeden anderen Kanal auszuspielen.

Legen Sie drittens fest, welchen Mehrwert die E-Mail bietet. Sie kann zusätzlichen Kontext liefern, Schritte ausführlicher erklären oder als dauerhafter Nachweis im Postfach dienen – Inhalte, für die ein kurzer Push-Text keinen Raum bietet. Schafft die E-Mail keinen echten Nutzen, sollten Sie auf den Fallback verzichten.

Dokumentieren Sie diese Entscheidungen direkt an der Journey. So verstehen alle Beteiligten die inhaltliche Begründung für das Mailing, statt blind jeden verfügbaren Kanal zu bespielen.

Eine E-Mail erstellen, die nützliche Details ergänzt

Beginnen Sie das Template in Migma mit der definierten Aufgabe, dem aktuellen Status, der Zielseite und den Support-Optionen. Prüfen Sie dabei den Markenkontext, damit die E-Mail visuell und tonal nahtlos an die Push-Benachrichtigung anknüpft.

Bei einem unvollständigen Setup kann der Push beispielsweise dazu einladen, in die App zurückzukehren. Die E-Mail wiederum erklärt, welche Schritte noch fehlen, warum sie wichtig sind und wo man direkt wieder einsteigt. Vermeiden Sie Formulierungen, die suggerieren, eine Nachricht sei ignoriert worden, oder die dem Empfänger ein Versäumnis unterstellen.

Ein knappes Briefing für die E-Mail könnte so lauten:

Unterstützen Sie Nutzer beim Abschluss des verbleibenden Setup-Schritts. Beschreiben Sie die freigegebene nächste Aktion, verlinken Sie auf das richtige Ziel und bieten Sie Support an. Behaupten Sie keine Zustellprobleme und setzen Sie keine Fristen, sofern diese nicht explizit vorgegeben sind.

Halten Sie die primäre Handlungsaufforderung kanalübergreifend konsistent. Führt der Push direkt zur Konfiguration, während die E-Mail für ein unpassendes Upgrade wirbt, wechselt die Journey unbemerkt das Ziel – zum Nachteil der User Experience.

Aussagen auch bei Statusänderungen konsistent halten

Der Textentwurf muss einen Zustand beschreiben, den der finale Workflow beim Versandzeitpunkt verlässlich abgleichen kann. Ein Aufruf wie „Erstellen Sie Ihren ersten Eintrag“ setzt voraus, dass dieser Eintrag beim Absenden der E-Mail tatsächlich noch nicht existiert.

Unterscheiden Sie zwischen stabilen Daten und Werten, die vor dem Versand neu abgefragt werden müssen. Der Produktname bleibt unverändert; Aufgabenstatus, Verfügbarkeiten oder Fristen können sich schnell ändern. Klären Sie mit den Data-Verantwortlichen, wie diese Parameter an die Zielplattform übergeben werden.

Formulieren Sie Varianten für alle definierten Pfade, statt zu hoffen, dass ein einziger Satz für jede Situation passt. Ist ein Schritt erledigt, besteht die richtige Reaktion oft darin, gar keine Nachricht zu senden. Ist eine Zielseite vorübergehend nicht erreichbar, erfordert dies einen Ausnahmeprozess im Workflow – keine Fallback-E-Mail mit einem toten Link.

Dabei handelt es sich um eine konzeptionelle Festlegung, die dokumentiert werden muss – nicht um die Behauptung, eine E-Mail könne sich nach dem Eintreffen im Posteingang nachträglich selbst anpassen.

Mailing und Routing getrennt voneinander testen

Nutzen Sie Migma Email Preflight, um Texte, Links, Darstellung im Posteingang und typische Versandrisiken zu prüfen. Testen Sie das Mailing wie gewohnt in Desktop- und mobilen E-Mail-Clients.

Verwenden Sie bei Bedarf den HTML-Export für das Zielsystem. Ein Entwickler oder Lifecycle-Verantwortlicher muss das Template an die Personalisierungsvariablen und Routing-Regeln der jeweiligen Plattform anpassen. Ein PNG-Vorschaubild ist kein versandfertiges Template.

Testen Sie anschließend die zentralen Szenarien der Journey mit Test-Accounts: Push nicht aktiviert, relevanter Fehlerstatus, Aufgabe vor dem Fallback erledigt, Aufgabe weiterhin offen sowie fehlende optionale Daten. Prüfen Sie dabei nur Zustände, die Ihre tatsächliche Implementierung auch abbildet.

Beurteilen Sie den gesamten Ablauf, nicht nur die E-Mail-Vorschau. Dokumentieren Sie, warum ein Fallback ausgelöst oder unterdrückt wurde, welche finale Textvariante zum Einsatz kam und wohin verlinkt wurde. Wenn ein Provider die Nachricht erfolgreich annimmt, bedeutet das noch lange nicht, dass der Nutzer die Aktion auch ausgeführt hat.

Eine klare Zuständigkeit für den Fallback festlegen

Bestimmen Sie, wer die Routing- und Berechtigungsregeln verantwortet und wer das Creative freigibt. Beide Seiten sollten denselben Versionsstand und dieselbe Aufgabendefinition abstimmen. Ein geänderter Produktstatus kann Anpassungen im Routing erfordern, selbst wenn das Design der E-Mail unverändert bleibt.

Dokumentieren Sie gewählte Zeitintervalle als fundierte Teamentscheidung und nicht als vermeintlichen Best-Practice-Standard. Überprüfen Sie diese Abstände anhand tatsächlicher Abschlussraten und Nutzerfeedback, und berücksichtigen Sie dabei auch externe Faktoren.

Migma sorgt für klare, prüfbare E-Mail-Inhalte. Die Multi-Channel-Plattform und ihr Journey Owner entscheiden, ob der Versand in diesem Moment sinnvoll ist. Ein gelungener Fallback ist ein stimmiger nächster Schritt – basierend auf dem aktuellen Nutzerstatus und echtem Mehrwert, nicht die bloße Wiederholung einer vorherigen Unterbrechung.

Häufig gestellte Fragen