Die Kanal-Orchestrierung liefert eine logische Nachricht über mehrere Kanäle durch Kaskadieren: Capability prüfen, den bevorzugten reichhaltigen Kanal (RCS oder WhatsApp) versuchen und bei Nicht-Fähigkeit, Fehlschlag oder Timeout auf SMS zurückfallen. Das Routing wägt Least-Cost gegen Best-Experience ab, Retry- und Timeout-Regeln begrenzen jeden Sprung, und eine einheitliche DLR gleicht den Status über die Kanäle ab.
- Nutzer fordert einen Code anLogin, Zahlung oder Registrierung
- Ihre App ruft die Verifizierungs-API aufEin Request pro Code
- BroadNet liefert den CodeÜber den besten verfügbaren KanalFallback bei NichtzustellungSMSWhatsAppVoice
- Nutzer gibt den Code einAbgleich mit dem ausgegebenen Code
- VerifiziertZugriff gewährt
Warum es Orchestrierung gibt
Kein einzelner Kanal erreicht alle, und jeder hat andere Kosten-, Reichhaltigkeits- und Zustelleigenschaften — daher muss ein Unternehmen, das sowohl Reichweite als auch Erlebnis will, für dieselbe logische Nachricht mehrere Kanäle nutzen. Omnichannel-Orchestrierung ist die Logik, die eine Absicht ("diesem Kunden mitteilen, dass seine Bestellung versandt wurde") in die richtige Abfolge von Kanalversuchen für genau diesen Empfänger übersetzt: den reichhaltigsten, am stärksten gebrandeten Kanal versuchen, den das Endgerät empfangen kann, und über progressiv einfachere Kanäle zurückfallen, bis einer zustellt. Der Orchestrator verbirgt diese Komplexität hinter einem einzelnen Versand, sodass der Sender Absicht und Policy ausdrückt, während die Plattform Capability, Routing, Retries und Abgleich übernimmt.
Die Kaskade: erst Capability-Prüfung, dann Fallback
Eine Kaskade ist eine geordnete Liste von Kanälen mit einer Regel zum Weiterschalten zum nächsten. Sie beginnt mit einer Capability-Prüfung — ist dieses Endgerät über RCS erreichbar, hat dieser Nutzer WhatsApp per Opt-in freigegeben —, denn an einen nicht erreichbaren Kanal zu senden, verschwendet nur einen Sprung. Der Orchestrator versucht den ersten geeigneten Kanal und schaltet bei einem definierten Auslöser zum nächsten weiter: Der Kanal ist nicht fähig, der Versand wird abgelehnt, oder die Zustellung wird nicht innerhalb eines Timeouts bestätigt. Übliche Kaskaden sind RCS→SMS (zuerst reichhaltig und gebrandet, universeller Text als Untergrenze), WhatsApp→SMS (zuerst der App-Kanal mit Opt-in, sonst SMS) und RCS→WhatsApp→SMS. SMS steht fast immer ganz unten, weil es die universelle, stets erreichbare Untergrenze ist.
deliver(order_shipped, +15551234567):
if rcsCapable(msisdn):
send RCS rich card; await DLR up to T_rcs
if delivered: DONE
if whatsappOptedIn(msisdn):
send WhatsApp template; await status up to T_wa
if delivered/read: DONE
send SMS (universal fallback); await DLR up to T_sms
record final status on the unified message idRouting: Least-Cost vs. Best-Experience
Die Entscheidung über die Reihenfolge der Kaskade ist eine Routing-Entscheidung, bei der zwei Ziele gegeneinander wirken. Das Least-Cost-Routing bevorzugt den günstigsten Kanal und Weg, der eine Zustellung garantiert – nützlich für hochvolumigen, weniger dringenden Datenverkehr, bei dem eine RCS-Gebühr pro Konversation, eine WhatsApp-Gebühr pro Nachricht oder ein günstigerer SMS-Weg gewinnt. Das Best-Experience-Routing bevorzugt den reichhaltigsten, markenorientiertesten und vertrauenswürdigsten Kanal, den der Empfänger erhalten kann – nützlich, wenn Engagement, Branding oder Interaktivität wichtiger sind als die Stückkosten. Die meisten Richtlinien mischen beides pro Nachrichtentyp: Transaktionsbelege könnten auf Erfahrung und Branding optimiert werden, Massenbenachrichtigungen auf Kosten. Der Orchestrator wendet die Richtlinie zusammen mit den Kapazitäten und Marktregeln (Registrierung der Sender-ID, WhatsApp-Kategorien, RCS-Verfügbarkeit) an, um den tatsächlichen ersten Schritt (First Hop) zu wählen.
| Zielsetzung | Bevorzugt | Ideal für |
|---|---|---|
| Kostengünstigste | Günstigster geeigneter Kanal/Route | Benachrichtigungen mit hohem Volumen und geringer Dringlichkeit |
| Bestmögliche User Experience | Reichhaltigster verifizierter geeigneter Kanal | Markenbezogene, interaktive, auf Engagement ausgerichtete Nachrichten |
| Fokus auf Zuverlässigkeit | Kanal mit der höchsten garantierten Zustellung | OTPs, kritische / zeitkritische Warnmeldungen |
| Compliance-basiert | Nur auf dem Markt zugelassene Kanäle | Regulierte Zielländer, Absender-ID-Regeln |
Retry, Timeout und Deduplizierung
Jeder Sprung in einer Kaskade braucht ein begrenztes Verhalten, damit die gesamte Zustellung deterministisch ist und den Empfänger nie doppelt belastet. Ein Timeout je Kanal definiert, wie lange auf eine Bestätigung gewartet wird, bevor weitergeschaltet wird — lang genug für eine legitime Zustellung, kurz genug, dass das Fallback noch nützlich ankommt (ein OTP, das eine Stunde zu spät kommt, ist wertlos). Retries innerhalb eines Kanals fangen transiente Fehler ab, müssen aber eine dauerhafte Ablehnung (sofort weiterschalten) von einer transienten (erneut versuchen, dann weiterschalten) unterscheiden. Und da eine Nachricht auf einem reichhaltigen Kanal gesendet worden sein kann, während ein Fallback auslöst, dedupliziert der Orchestrator gegen eine einzelne logische Message-ID, sodass der Kunde dieselbe Benachrichtigung nicht zweimal erhält. Idempotenz-Schlüssel beim Versand machen Retries sicher.
Einheitliche Zustellberichte über Kanäle hinweg
Jeder Kanal meldet die Zustellung anders — SMS liefert einen SS7-/SMPP-Zustellbericht, WhatsApp postet sent/delivered/read/failed-Webhooks, RCS emittiert Zustell- und Leseereignisse —, sodass ein orchestrierter Versand eine einheitliche DLR braucht, die sie alle auf ein Statusmodell gegen die logische Message-ID abbildet. Das erlaubt einem Sender, eine einzige Frage zu stellen — "hat dies den Kunden erreicht, und wie" — und eine Antwort zu erhalten, die den Kanal benennt, der letztlich zugestellt hat, die versuchten und übersprungenen Kanäle und das Lese-/Engagement-Signal, wo der Kanal es bereitstellt. Die einheitliche Sicht speist auch die Routing-Analytik — welche Kaskaden zustellen, zu welchen Kosten, in welchen Märkten — und schließt den Kreis von der Policy zum Ergebnis.
| Kanal | Nativer Status | Einheitlicher Status |
|---|---|---|
| SMS | SMPP-/SS7-Zustellbericht | gesendet / zugestellt / fehlgeschlagen |
| RCS | Zustellung + Leseereignisse | gesendet / zugestellt / gelesen / fehlgeschlagen |
| gesendet / zugestellt / gelesen / fehlgeschlagener Webhook | gesendet / zugestellt / gelesen / fehlgeschlagen | |
| Kaskadenergebnis | (kombiniert) | delivered-via-<channel> / exhausted |
Häufig gestellte Fragen
Was ist Kanal-Fallback?
Kanal-Fallback liefert eine logische Nachricht, indem es Kanäle der Reihe nach versucht und weiterschaltet, wenn einer nicht verfügbar ist oder die Zustellung nicht bestätigt. Eine typische Kaskade ist RCS→SMS oder WhatsApp→SMS: zuerst den reichhaltigen, gebrandeten Kanal versuchen und bei Nicht-Fähigkeit, Ablehnung oder Timeout auf SMS — die universelle Untergrenze — zurückfallen.
Wie entscheidet der Orchestrator, welchen Kanal zuerst versucht wird?
Er kombiniert eine Capability-Prüfung (ist das Endgerät über RCS erreichbar, hat der Nutzer WhatsApp per Opt-in freigegeben) mit einer Routing-Policy. Least-Cost-Routing bevorzugt den günstigsten fähigen Kanal; Best-Experience-Routing bevorzugt den reichhaltigsten verifizierten; Reliability-First bevorzugt die garantierte Zustellung. Marktspezifische Regeln wie Sender-ID-Registrierung und WhatsApp-Kategorien schränken die geeigneten Kanäle weiter ein.
Was ist Least-Cost- vs. Best-Experience-Routing?
Least-Cost-Routing wählt den günstigsten Kanal und die günstigste Route, die zustellen wird, geeignet für Traffic mit hohem Volumen und geringer Dringlichkeit. Best-Experience-Routing wählt den reichhaltigsten, am stärksten gebrandeten, vertrauenswürdigsten Kanal, den der Empfänger empfangen kann, geeignet für engagementgetriebene Nachrichten. Die meisten Policies mischen beides je Nachrichtenklasse — Bestätigungen für Erlebnis, Massen-Alerts für Kosten.
Wie vermeidet das Fallback, dieselbe Nachricht zweimal zu senden?
Indem jeder Sprung an eine logische Message-ID gebunden und gegen sie dedupliziert wird, mit Timeouts je Kanal und Idempotenz-Schlüsseln, sodass Retries sicher sind. Eine dauerhafte Ablehnung schaltet sofort zum nächsten Kanal weiter; ein transienter Fehler wird vor dem Weiterschalten erneut versucht. Der Empfänger sieht die Benachrichtigung einmal, auf dem Kanal, der letztlich zugestellt hat.
Welches Timeout sollte jeder Kanalsprung nutzen?
Lang genug, um eine legitime Zustellbestätigung zuzulassen, kurz genug, dass das Fallback noch nützlich ankommt. Ein Einmalpasscode, der eine Stunde zu spät kommt, ist wertlos, daher sind seine Timeouts je Sprung kurz; eine nicht dringende Benachrichtigung kann länger auf einem reichhaltigen Kanal warten, bevor sie auf SMS zurückfällt.
Was ist eine einheitliche DLR?
Ein einheitlicher Zustellbericht bildet den kanalspezifischen Status — SMS-Zustellberichte, WhatsApp-sent/delivered/read/failed-Webhooks, RCS-Zustell- und Leseereignisse — auf ein Statusmodell gegen die logische Message-ID ab. Er erlaubt einem Sender, eine einzige Frage zu stellen, ob und wie eine Nachricht den Kunden erreicht hat, und speist die Routing-Analytik.
Quellenspezifikationen
Diese Seite basiert auf den veröffentlichten Standards. (Wird in einem neuen Tab geöffnet.)