Er is geen universele kanaalvolgorde
De meeste fallbackontwerpen beginnen met een kanaalladder en ontdekken daarna dat die voor de helft van de journeys verkeerd is. De volgorde is een uitkomst, geen invoer. De invoer is het bedrijfsdoel en de bruikbare deadline.
Wat het beleid werkelijk beoordeelt
Voor elke poging: doel en succescriterium; bruikbare deadline waarna bezorging niet meer helpt; consent en geuite voorkeur; geverifieerde bestemming; kanaalbeschikbaarheid in die markt en goedkeuring van je afzender; urgentie en gevoeligheid van de inhoud; kosten per behaalde uitkomst; en betrouwbaarheid van het signaal.
Betrouwbare en ambigue signalen
Een afwijzing bij verzending rechtvaardigt het volgende kanaal. Een bezorgbevestiging zegt dat het kanaal het toestel bereikte, niet dat iemand het zag. Een leesindicatie bewijst geen aandacht en kan uitgezet zijn. Geen status is ambiguïteit, geen storing: stilte als storing behandelen levert duplicaten op.
Één journey, één identiteit
Een journey-ID, gemaakt bij het besluit te communiceren, aanwezig in elke poging, callback en uitkomst. Daarmee geldt: geschiktheid wordt vóór elke poging opnieuw beoordeeld; idempotentie en deduplicatie op journeyniveau; pogingstoestand en journeytoestand zijn gescheiden; stopcondities gaan voor als het doel is behaald of de bedrijfsstatus wijzigt; late callbacks worden vastgelegd zonder een afgeronde journey te heropenen.
Serieel of parallel
Serieel is de standaard. Parallel wanneer de gevolgen van een gemist bericht duidelijk zwaarder wegen dan duplicatie — veiligheid, fraude, storing — of wanneer de deadline geen seriële keten toelaat. Bij een verwachte code is de deadline de beperking, niet een regel over toegestane kanalen; wat je voorkomt is een tweede code voor dezelfde sessie.
Beslistabel
| Journey | Doel en deadline | Ordeningslogica | Stopcondities |
|---|---|---|---|
| Authenticatiecode | Code binnen de live sessie | Snelste kanaal met betrouwbaar signaal en geverifieerde bestemming | Verificatie, einde sessie, deadline |
| Bezorg- of afspraakmelding | Ontvanger vóór het moment informeren | Voorkeurskanaal, dan het volgende geschikte | Bevestiging, gebeurtenis of annulering |
| Betaalverzoek | Betaling voor de vervaldatum | Kanaal met consent en identiteitsvertrouwen, escalatie naar antwoordkanaal | Betaling, afspraak, statuswijziging |
| Supportopvolging | Antwoord ontvangen | Het kanaal van het gesprek | Antwoord, ticket gesloten |
| Promotie | Interactie met consent | Goedkoopste toegestane kanaal, geen herhaling van de aanbieding | Opt-out, frequentielimiet, einde campagne |
| Urgent operationeel | Bevestiging | Parallel over geschikte kanalen, dan menselijke escalatie | Bevestiging of afgeronde escalatie |
Toestandsmachine
journey: GEPLAND -> POGING -> AFGEROND | GESTOPT | UITGEPUT
per poging: deadline en stopcondities checken, geschiktheid herbeoordelen,
poging aanmaken met sleutel opgeslagen vóór verzending
uitkomsten: afwijzing of eindfout -> volgende kandidaat
bezorgd zonder doel -> deadline van deze poging afwachten
geen status bij deadline -> AMBIGU (doorgaan is duplicatie accepteren)
actie van ontvanger -> AFGEROND, openstaande pogingen annuleren
late callback: vastleggen, nooit een afgeronde journey heropenen
De ambigue tak is waar de meeste ontwerpen stil misgaan. Waar duplicatie schaadt — een tweede code, een tweede betaalverzoek — is wachten of stoppen meestal juist.
Attributie en kosten
Uitkomsten per journeytype en ketenpositie; kosten per behaalde uitkomst over de hele keten; duplicatiegraad; ambiguïteitsgraad; effectiviteit van stopcondities. Komen de meeste uitkomsten op positie twee of drie, dan is positie één verkeerd voor die groep.
Het leveringsmodel
Flowstates verkoopt en beheert messagingroutes over meerdere kanalen, ondersteunt eigen providercontracten (BYOV) en hybride opzetten. De ketenlogica is in elk model hetzelfde werk en hoort naast de bedrijfsstatus die het doel bepaalt.