Zwei unterschiedliche Aufgaben werden „Orchestrierung" genannt, und ihre Vermischung ist der Grund, warum Multi-Channel-Projekte stecken bleiben. Journey-Orchestrierung entscheidet, ob, wann, warum und über welchen Kanal jemand kontaktiert wird – das ist Geschäftslogik. Zustelloperationen setzen eine bereits getroffene Entscheidung um: Absender- und Routenwahl, Provider-Adapter, Durchsatz, Retries, Statusmapping und Failover innerhalb eines Kanals. Beide brauchen unterschiedliche Owner, Tests und Fehlerbehandlung.
Kundenzustand modellieren, nicht den Kanal-Workflow
Die wichtigste Entscheidung ist, ob das System einen kanonischen Zustand für den Vorgang hält – diese Rechnung ist unbezahlt, dieser Termin unbestätigt – oder separate Workflows je Kanal, die nichts voneinander wissen. Mit kanonischem Zustand wirkt jeder Versuch auf jedem Kanal auf denselben Datensatz, und dieser Datensatz entscheidet über den nächsten Schritt.
Trigger-Ereignisse und ihre Aktualität
Ereignisse veralten: die Rechnung wurde gerade bezahlt, der Termin bereits bestätigt. Der Zustand muss unmittelbar vor dem Versand erneut gelesen werden, nicht nur bei der Planung, und die Anfrage sollte einen Aktualitätsstempel tragen, damit veraltete Entscheidungen abgelehnt werden.
Eignungsregeln, zum Versandzeitpunkt geprüft
Einwilligung mit nachvollziehbarem Nachweis, kanalübergreifend propagierte Sperrlisten, tatsächliche Erreichbarkeit des Kanals, verifizierte Identität, Sprache und lokale Zeitzone, in Ortszeit ausgewertete Ruhezeiten, Frequenzgrenzen und die Traffic-Klasse – all das gehört zum Versandzeitpunkt geprüft, nicht zum Anmeldezeitpunkt.
Entscheidungslogik: welcher Kanal, und warum
Bevorzugter Kanal, Dringlichkeit und Frist, Inhaltssensibilität – gewöhnliches SMS gilt als unverschlüsselt und auf dem Sperrbildschirm sichtbar, gehört also nicht mit Zugangsdaten oder sensiblen Daten befüllt –, Risiko, Kosten als ein Eingabewert unter mehreren, und Kanalfähigkeit sollten als Tabelle je Anwendungsfall dokumentiert werden.
Idempotenz, Versuchszustand und Fallback
Deduplizierung muss auf Zustandsebene erfolgen, mit einer eigenen, vor dem Versand gespeicherten Referenz. Jeder Versuch braucht einen expliziten Zustand – erstellt, übermittelt, finaler Providerstatus, timeout, abgelöst –, wobei ein endgültiger Fehlschlag klar von einem bloß fehlenden Zustellnachweis unterschieden werden muss. Fallback sollte durch Fristen des Geschäftsprozesses und durch vertrauenswürdige Signale ausgelöst werden (klare Ablehnung, ungültiges Ziel), während das bloße Fehlen eines Zustellnachweises vorsichtig behandelt wird. Es braucht ein Limit an Kanälen und Versuchen sowie einen definierten Weg, wenn die Kette erschöpft ist.
Stoppbedingungen, Antworten und Zuordnung
Jede Journey braucht explizite Stoppbedingungen – Ergebnis erreicht, Zustandsänderung, Abmeldung oder Beschwerde, Frist abgelaufen, Frequenzlimit erreicht, manueller Kill-Switch –, die zum Versandzeitpunkt geprüft werden. Eingehende Antworten und Abmeldungen müssen die State Machine erreichen und kanalübergreifend propagiert werden. Eine einzige Journey-ID über alle Versuche, Klicks und Ergebnisse hinweg zeigt, was tatsächlich gewirkt hat, statt dass sich jeder Kanal das Verdienst zuschreibt.
Wo welche Ebene lebt
Zustelloperationen – Adapter, Routing, Absenderidentität, Retries, Reconciliation und Eskalation – sind der Teil, den kaum ein Team zweimal bauen sollte. Flowstates liefert und betreibt Kanäle und Routen, unterstützt eigene Anbieter über BYOV und unterstützt Hybrid-Deployments als diese betriebene Schicht. Orchestrierung ist variabler und lebt meist dort, wo der kanonische Geschäftszustand ohnehin schon liegt – in der eigenen Anwendung, in einem CRM oder in einem von Flowstates unterstützten Workflow.