# Fallback dei canali e orchestrazione omnicanale

> L'orchestrazione dei canali consegna un messaggio logico su più canali mettendoli in cascata: controlla la capacità, prova il canale ricco preferito (RCS o WhatsApp) e ripiega sull'SMS in caso di non-capacità, fallimento o timeout. Il routing bilancia least-cost e best-experience, le regole di retry e timeout delimitano ciascun salto, e un DLR unificato riconcilia lo stato tra i canali.

- URL canonico: https://www.broadnet.me/it/reference/channel-fallback-and-orchestration
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

Come la consegna omnicanale mette in cascata i canali: controlli di capacità, fallback RCS→SMS e WhatsApp→SMS, routing least-cost rispetto a best-experience, regole di retry e timeout, e una vista unificata dei delivery receipt che riconcilia lo stato su ogni canale.

## Perché esiste l'orchestrazione

Nessun singolo canale raggiunge tutti, e ciascuno ha costo, ricchezza e caratteristiche di consegna diverse — quindi un business che vuole sia raggiungibilità sia esperienza deve usare più canali per lo stesso messaggio logico. L'orchestrazione omnicanale è la logica che trasforma un'intenzione ("dì a questo cliente che il suo ordine è stato spedito") nella giusta sequenza di tentativi di canale per quello specifico destinatario: prova il canale più ricco e brandizzato che il dispositivo può ricevere, e ripiega attraverso canali progressivamente più semplici finché uno consegna. L'orchestratore nasconde quella complessità dietro un singolo invio, così il mittente esprime intenzione e policy mentre la piattaforma gestisce capacità, routing, retry e riconciliazione.

## La cascata: controllo di capacità poi fallback

Una cascata è una lista ordinata di canali con una regola per avanzare al successivo. Inizia con un controllo di capacità — questo dispositivo è raggiungibile via RCS, questo utente ha fatto opt-in su WhatsApp — perché inviare a un canale irraggiungibile spreca solo un salto. L'orchestratore prova il primo canale idoneo e avanza al successivo su un trigger definito: il canale non è capace, l'invio è rifiutato, o la consegna non è confermata entro un timeout. Le cascate comuni sono RCS→SMS (prima il ricco brandizzato, il testo universale come pavimento), WhatsApp→SMS (prima il canale app con opt-in, altrimenti SMS) e RCS→WhatsApp→SMS. L'SMS sta quasi sempre in fondo perché è il pavimento universale, sempre raggiungibile.

*Cascata RCS → WhatsApp → SMS con gate di capacità e timeout*

```text
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 id
```

## Routing: least-cost vs best-experience

Scegliere l'ordine della cascata è una decisione di routing, e due obiettivi entrano in conflitto tra loro. Il routing a costo minimo preferisce il canale e il percorso più economici che garantiscano la consegna — utile per traffico ad alto volume e bassa urgenza dove prevale un addebito RCS per conversazione, un addebito WhatsApp per messaggio o un percorso SMS più economico. Il routing per la migliore esperienza preferisce il canale più ricco, più branded e più affidabile che il destinatario possa ricevere — utile dove l'engagement, il branding o l'interattività contano più del costo unitario. La maggior parte delle policy combina i due per classe di messaggio: le ricevute transazionali potrebbero ottimizzare per esperienza e branding, le notifiche bulk per il costo. L'orchestratore applica la policy insieme alla capacità e alle regole per mercato (registrazione sender-ID, categorie WhatsApp, disponibilità RCS) per scegliere il primo salto effettivo.

*Obiettivi di routing e dove ciascuno si adatta*

| Obiettivo | Preferisce | Ideale per |
|---|---|---|
| Costo minimo | Canale/rotta più economica tra quelle idonee | Notifiche ad alto volume e bassa urgenza |
| Migliore esperienza | Canale più ricco tra quelli verificati e idonei | Messaggi di marca, interattivi e orientati al coinvolgimento |
| Priorità all'affidabilità | Canale con la massima garanzia di consegna | OTP, avvisi critici / urgenti |
| Vincolato alla conformità | Solo i canali autorizzati sul mercato | Destinazioni regolamentate, regole relative all'ID mittente |

## Retry, timeout e deduplicazione

Ogni salto in una cascata ha bisogno di un comportamento delimitato affinché l'intera consegna sia deterministica e non addebiti mai due volte il destinatario. Un timeout per canale definisce quanto attendere la conferma prima di avanzare — abbastanza lungo per una consegna legittima, abbastanza breve perché il fallback arrivi ancora utilmente (un OTP che arriva un'ora dopo è inutile). I retry all'interno di un canale gestiscono i fallimenti transitori, ma devono distinguere un rifiuto permanente (avanza subito) da uno transitorio (riprova, poi avanza). E poiché un messaggio potrebbe essere stato inviato su un canale ricco mentre parte un fallback, l'orchestratore deduplica rispetto a un singolo message ID logico così che il cliente non riceva la stessa notifica due volte. Le chiavi di idempotenza sull'invio rendono i retry sicuri.

## Delivery receipt unificati tra i canali

Ogni canale riporta la consegna in modo diverso — l'SMS restituisce un delivery report SS7/SMPP, WhatsApp invia webhook sent/delivered/read/failed, RCS emette eventi di consegna e lettura — quindi un invio orchestrato ha bisogno di un DLR unificato che li mappi tutti su un unico modello di stato rispetto al message ID logico. Questo permette a un mittente di porre una sola domanda, "il messaggio ha raggiunto il cliente, e come", e ottenere una sola risposta che nomina il canale che ha infine consegnato, i canali provati e saltati, e il segnale di lettura/engagement dove il canale lo fornisce. La vista unificata è anche ciò che alimenta le analytics di routing — quali cascate consegnano, a quale costo, in quali mercati — chiudendo il cerchio dalla policy al risultato.

*Stato per canale mappato su un modello unificato*

| Canale | Stato nativo | Stato unificato |
|---|---|---|
| SMS | Rapporto di consegna SMPP / SS7 | inviato / consegnato / fallito |
| RCS | Consegna + eventi di lettura | inviato / consegnato / letto / fallito |
| WhatsApp | webhook inviato / consegnato / letto / fallito | inviato / consegnato / letto / fallito |
| Risultato a cascata | (composito) | delivered-via-<channel> / exhausted |

## Domande frequenti

### Che cos'è il fallback dei canali?

Il fallback dei canali consegna un messaggio logico provando i canali in ordine e avanzando quando uno non è disponibile o non conferma la consegna. Una cascata tipica è RCS→SMS o WhatsApp→SMS: prova prima il canale ricco e brandizzato, e ripiega sull'SMS — il pavimento universale — in caso di non-capacità, rifiuto o timeout.

### Come decide l'orchestratore quale canale provare per primo?

Combina un controllo di capacità (il dispositivo è raggiungibile via RCS, l'utente ha fatto opt-in su WhatsApp) con una policy di routing. Il routing least-cost preferisce il canale capace più economico; il best-experience preferisce quello verificato più ricco; il reliability-first preferisce la consegna garantita. Regole per mercato come la registrazione del sender-ID e le categorie WhatsApp vincolano ulteriormente i canali idonei.

### Che cos'è il routing least-cost vs best-experience?

Il routing least-cost sceglie il canale e la rotta più economici che consegneranno, adatto a traffico ad alto volume e bassa urgenza. Il routing best-experience sceglie il canale più ricco, brandizzato e affidabile che il destinatario può ricevere, adatto a messaggi orientati all'engagement. La maggior parte delle policy fonde i due per classe di messaggio — ricevute per esperienza, avvisi bulk per costo.

### Come fa il fallback a evitare di inviare due volte lo stesso messaggio?

Legando ogni salto a un unico message ID logico e deduplicando rispetto ad esso, con timeout per canale e chiavi di idempotenza così che i retry siano sicuri. Un rifiuto permanente avanza subito al canale successivo; un fallimento transitorio viene ritentato prima di avanzare. Il destinatario vede la notifica una sola volta, sul canale che ha infine consegnato.

### Quale timeout dovrebbe usare ogni salto di canale?

Abbastanza lungo da permettere una conferma di consegna legittima, abbastanza breve perché il fallback arrivi ancora utilmente. Un codice monouso che arriva un'ora dopo è inutile, quindi i suoi timeout per salto sono brevi; una notifica non urgente può attendere più a lungo su un canale ricco prima di ripiegare sull'SMS.

### Che cos'è un DLR unificato?

Un delivery receipt unificato mappa lo stato nativo di ciascun canale — delivery report SMS, webhook WhatsApp sent/delivered/read/failed, eventi di consegna e lettura RCS — su un unico modello di stato rispetto al message ID logico. Permette a un mittente di porre una sola domanda su se e come un messaggio ha raggiunto il cliente, e alimenta le analytics di routing.

## Fonti

- [GSMA — RCS Business Messaging and capability discovery](https://www.gsma.com/solutions-and-impact/technologies/networks/rcs/)
- [WhatsApp Business Platform — message status webhooks](https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks)
- [3GPP TS 23.040 — SMS status reports](https://www.3gpp.org/dynareport/23040.htm)

## Correlati

- [Omnicanale](https://www.broadnet.me/it/products/omnichannel)
- [RCS vs SMS vs WhatsApp](https://www.broadnet.me/it/reference/rcs-vs-sms-vs-whatsapp-channels)
- [RCS Business Messaging e la piattaforma MaaP](https://www.broadnet.me/it/reference/rcs-business-messaging-maap)
- [WhatsApp Business Cloud API](https://www.broadnet.me/it/reference/whatsapp-business-cloud-api)
- [SMS API](https://www.broadnet.me/it/products/sms-api)
- [Piattaforma CPaaS](https://www.broadnet.me/it/platforms/cpaas)