inkanalige Messaging-Systeme bergen einen Single Point of Failure. WhatsApp kann ausfallen, ein Nutzer ist über RCS nicht erreichbar, die Übertragungswege der Mobilfunkanbieter können sich verschlechtern, und eine Vorlage kann mitten in einer Kampagne abgelehnt werden. Eine Multi-Channel-Failover-Strategie hingegen definiert das Ziel „Diese Nachricht an diese Person zustellen“ und betrachtet den Kanal als austauschbares Mittel. Hier erfahren Sie, wie Sie eine solche Strategie entwickeln, die tatsächlich zuverlässig funktioniert.
Definiere die Kanalstruktur pro Nachrichtentyp
Es gibt keine allgemeingültige Reihenfolge – die optimale Vorgehensweise hängt von der jeweiligen Nachricht ab. Einige sinnvolle Standardeinstellungen: Für die Authentifizierung zuerst WhatsApp oder RCS (umfangreich, markenspezifisch, schnell), dann SMS, dann Sprach-OTP. Bei Transaktionsbenachrichtigungen zuerst RCS oder WhatsApp für ein optimales Nutzererlebnis, SMS als sichere Alternative. Bei zeitkritischen Benachrichtigungen SMS als erste Option für maximale Reichweite, Sprach-OTP als Eskalationsmöglichkeit. Legen Sie die Reihenfolge bewusst für jeden Nachrichtentyp fest und dokumentieren Sie sie.
Einlaufprozesse müssen bedingt, nicht blind erfolgen.
- Fehlerhafte Verbindung – der Nutzer ist über den Kanal nicht erreichbar (keine RCS-Bereitstellung, kein WhatsApp-Konto). Sofortige Abbruchreaktion; nicht warten.
- Zustellungsfehler – der Kanal hat die Nachricht zwar angenommen, aber die Zustellungsliste zeigt „nicht zugestellt“ an. Der Fehler tritt bei der negativen Empfangsbestätigung auf.
- Zeitüberschreitung – keine positive Zustellbestätigung innerhalb einer nachrichtentypspezifischen Frist (streng bei OTP, weniger streng bei Benachrichtigungen). Die Zustellung wird nach Ablauf der Frist abgebrochen.
- Providerausfall – der Kanal selbst ist ausgefallen. Erkennung durch Fehlerratenüberwachung und Umleitung des gesamten Kanals für den gesamten Datenverkehr, nicht für jede Nachricht einzeln.
Vorsicht vor Doppellieferungen!
Der heimtückische Fehler in jedem Failover-System besteht darin, die Nachricht zweimal zu senden – einmal über den Kanal, der zwar langsam, aber nicht ausgefallen war, und dann erneut über den Ausweichkanal. Bei OTP ist dies besonders problematisch: Der Benutzer erhält zwei unterschiedliche Codes und weiß nicht, welchen er verwenden soll. Die Lösung besteht in einer einzigen, verlässlichen Quelle für den Zustellungsstatus jeder Nachricht, einer Aufzeichnung jedes Versands (die von der API zurückgegebene Nachrichten-ID speichern und vor jedem erneuten Senden den Status prüfen), damit ein erneuter Versuch niemals eine zweite Sendung auslöst, und – speziell für OTP – darin, den Code nur einmal zu generieren und ihn in allen Kanälen der Übertragungskette wiederzuverwenden, sodass jede ankommende Nachricht einen gültigen Code enthält.
Sowohl Kosten als auch Erfahrung verschieben sich auf der Leiter nach unten.
Jede Stufe der Leiter hat unterschiedliche wirtschaftliche Gegebenheiten und ein anderes Nutzererlebnis. Failover ist nicht kostenlos – es kann zu einer weniger markengerechten Nachricht oder höheren Stückkosten führen. Das ist durchaus verständlich: Eine etwas teurere SMS, die ankommt, ist besser als eine kostenlose WhatsApp-Nachricht, die nicht ankommt. Das bedeutet aber auch, dass Sie Ihre Failover-Rate überwachen sollten. Wenn 40 % des Datenverkehrs bis zur letzten Stufe durchfallen, liegt das Problem weiter oben – fehlerhafte Kapazitätsdaten, ein falsch konfigurierter primärer Kanal – und Sie sollten die Ursache beheben, anstatt nur die Symptome zu behandeln.
BroadNets Omnichannel-API implementiert die gesamte Sicherheitskette – von der Funktionsprüfung über bedingtes Failover und gemeinsam genutzten OTP-Code bis hin zu kanalspezifischer Analyse – mit nur einem API-Aufruf und gibt für jeden Versand eine Nachrichten-ID zurück, damit Ihre Wiederholungsversuche den Status prüfen, statt doppelt zu senden (siehe Idempotenz und sichere Wiederholungen). Sie beschreiben die Nachricht und die Priorität; die Plattform übernimmt die Orchestrierung.
Testen Sie die Fehlerpfade
Der häufigste Grund, warum eine Failover-Strategie im Produktivbetrieb nicht funktioniert, ist, dass der Failover-Pfad nie getestet wurde – er wurde zwar geschrieben und bereitgestellt, aber erst bei einem tatsächlichen Ausfall aktiviert. Erstellen Sie synthetische Tests, die jeden Fehlerszenario erzwingen (primären Kanal deaktivieren, Timeout simulieren, negatives DLR einfügen) und überprüfen Sie, ob die Nachricht weiterhin ankommt. Ein ungetesteter Failover-Pfad ist ein nicht existierender Failover-Pfad.