La orquestación de canales entrega un mensaje lógico a través de varios canales haciendo cascada: comprobar capacidad, intentar el canal enriquecido preferido (RCS o WhatsApp) y hacer fallback a SMS ante falta de capacidad, fallo o timeout. El encaminamiento equilibra mínimo coste frente a mejor experiencia, las reglas de reintento y timeout acotan cada salto, y un DLR unificado concilia el estado entre canales.
- El usuario solicita un códigoInicio de sesión, pago o registro
- Su app llama a la API de verificaciónUna solicitud por código
- BroadNet entrega el códigoA través del mejor canal disponibleRuta de respaldo si no se entregaSMSWhatsAppVoz
- El usuario introduce el códigoSe coteja con el código emitido
- VerificadoAcceso concedido
Por qué existe la orquestación
Ningún canal llega a todo el mundo, y cada uno tiene características distintas de coste, riqueza y entrega, así que una empresa que quiere tanto alcance como experiencia tiene que usar varios canales para el mismo mensaje lógico. La orquestación omnicanal es la lógica que convierte una intención ("decir a este cliente que su pedido se ha enviado") en la secuencia correcta de intentos de canal para ese destinatario concreto: intentar el canal más rico y con más marca que el dispositivo pueda recibir, y hacer fallback por canales progresivamente más simples hasta que uno entregue. El orquestador oculta esa complejidad tras un único envío, de modo que el remitente expresa intención y política mientras la plataforma gestiona capacidad, encaminamiento, reintentos y conciliación.
La cascada: comprobación de capacidad y luego fallback
Una cascada es una lista ordenada de canales con una regla para avanzar al siguiente. Empieza con una comprobación de capacidad —¿es este dispositivo alcanzable por RCS, tiene este usuario opt-in de WhatsApp— porque enviar a un canal inalcanzable solo desperdicia un salto. El orquestador intenta el primer canal elegible y avanza al siguiente ante un disparador definido: el canal no tiene capacidad, el envío se rechaza, o la entrega no se confirma dentro de un timeout. Las cascadas comunes son RCS→SMS (rico y con marca primero, texto universal como suelo), WhatsApp→SMS (canal de app con opt-in primero, SMS en su defecto) y RCS→WhatsApp→SMS. El SMS casi siempre queda al fondo porque es el suelo universal, siempre alcanzable.
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 idEncaminamiento: mínimo coste frente a mejor experiencia
Elegir el orden de la cascada es una decisión de enrutamiento, y dos objetivos entran en conflicto. El enrutamiento de menor coste prefiere el canal y la ruta más económicos que garanticen la entrega; es útil para tráfico de alto volumen y baja urgencia donde gana un cargo de RCS por conversación, un cargo de WhatsApp por mensaje o una ruta de SMS más barata. El enrutamiento de mejor experiencia prefiere el canal más rico, con mayor presencia de marca y más confiable que el destinatario pueda recibir; es útil cuando el compromiso, la marca o la interactividad importan más que el coste unitario. La mayoría de las políticas combinan ambos según la clase de mensaje: los recibos transaccionales podrían optimizarse para la experiencia y la marca, mientras que las notificaciones masivas para el coste. El orquestador aplica la política junto con la capacidad y las reglas por mercado (registro de ID de remitente, categorías de WhatsApp, disponibilidad de RCS) para elegir el primer salto real.
| Objetivo | Prefiere | Ideal para |
|---|---|---|
| Menor costo | Canal/ruta compatible más económico | Notificaciones de alto volumen y baja urgencia |
| Mejor experiencia | Canal compatible verificado más rico | Mensajes de marca, interactivos y orientados a la participación |
| Prioridad en confiabilidad | Canal con la mayor garantía de entrega | OTP, alertas críticas/urgentes |
| Sujeto a cumplimiento | Solo canales permitidos en el mercado | Destinos regulados, reglas de identificación del remitente |
Reintento, timeout y de-duplicación
Cada salto de una cascada necesita un comportamiento acotado para que toda la entrega sea determinista y nunca cobre dos veces al destinatario. Un timeout por canal define cuánto esperar la confirmación antes de avanzar: lo bastante largo para una entrega legítima, lo bastante corto para que el fallback aún llegue de forma útil (un OTP que llega una hora tarde no vale nada). Los reintentos dentro de un canal manejan fallos transitorios, pero deben distinguir un rechazo permanente (avanzar de inmediato) de uno transitorio (reintentar, luego avanzar). Y como un mensaje puede haberse enviado por un canal rico mientras se dispara un fallback, el orquestador de-duplica contra un único ID de mensaje lógico para que el cliente no reciba la misma notificación dos veces. Las claves de idempotencia en el envío hacen seguros los reintentos.
Confirmaciones de entrega unificadas entre canales
Cada canal informa de la entrega de forma distinta —el SMS devuelve una confirmación de entrega SS7/SMPP, WhatsApp publica webhooks sent/delivered/read/failed, RCS emite eventos de entrega y lectura— así que un envío orquestado necesita un DLR unificado que los mapee a todos a un único modelo de estado contra el ID de mensaje lógico. Eso permite a un remitente hacer una sola pregunta, "¿llegó esto al cliente, y cómo?", y obtener una sola respuesta que nombra el canal que finalmente entregó, los canales que se intentaron y omitieron, y la señal de lectura/engagement donde el canal la proporciona. La vista unificada es también lo que alimenta la analítica de encaminamiento —qué cascadas entregan, a qué coste, en qué mercados— cerrando el bucle de la política al resultado.
| Canal | Estado nativo | Estado unificado |
|---|---|---|
| SMS | Confirmación de entrega SMPP / SS7 | enviado / entregado / fallido |
| RCS | Eventos de entrega + lectura | enviado / entregado / leído / fallido |
| webhook enviado / entregado / leído / fallido | enviado / entregado / leído / fallido | |
| Resultado en cascada | (compuesto) | delivered-via-<channel> / exhausted |
Preguntas frecuentes
¿Qué es la conmutación de canales?
La conmutación de canales entrega un mensaje lógico intentando canales en orden y avanzando cuando uno no está disponible o no confirma la entrega. Una cascada típica es RCS→SMS o WhatsApp→SMS: intentar primero el canal rico y con marca, y hacer fallback a SMS —el suelo universal— ante falta de capacidad, rechazo o timeout.
¿Cómo decide el orquestador qué canal intentar primero?
Combina una comprobación de capacidad (¿es el dispositivo alcanzable por RCS, tiene el usuario opt-in de WhatsApp) con una política de encaminamiento. El encaminamiento de mínimo coste prefiere el canal capaz más barato; el de mejor experiencia prefiere el más rico y verificado; el de fiabilidad primero prefiere la entrega garantizada. Las reglas por mercado, como el registro de sender-ID y las categorías de WhatsApp, restringen aún más los canales elegibles.
¿Qué es el encaminamiento de mínimo coste frente al de mejor experiencia?
El encaminamiento de mínimo coste elige el canal y la ruta más baratos que entreguen, apto para tráfico de alto volumen y baja urgencia. El de mejor experiencia elige el canal más rico, con más marca y más confianza que el destinatario pueda recibir, apto para mensajes orientados al engagement. La mayoría de las políticas mezclan ambos por clase de mensaje: recibos para experiencia, alertas masivas para coste.
¿Cómo evita el fallback enviar el mismo mensaje dos veces?
Vinculando cada salto a un único ID de mensaje lógico y de-duplicando contra él, con timeouts por canal y claves de idempotencia para que los reintentos sean seguros. Un rechazo permanente avanza de inmediato al siguiente canal; un fallo transitorio se reintenta antes de avanzar. El destinatario ve la notificación una vez, en el canal que finalmente entregó.
¿Qué timeout debería usar cada salto de canal?
Lo bastante largo para permitir una confirmación de entrega legítima, lo bastante corto para que el fallback aún llegue de forma útil. Una contraseña de un solo uso que llega una hora tarde no vale nada, así que sus timeouts por salto son cortos; una notificación no urgente puede esperar más en un canal rico antes de hacer fallback a SMS.
¿Qué es un DLR unificado?
Una confirmación de entrega unificada mapea el estado nativo de cada canal —confirmaciones de entrega de SMS, webhooks sent/delivered/read/failed de WhatsApp, eventos de entrega y lectura de RCS— a un único modelo de estado contra el ID de mensaje lógico. Permite a un remitente hacer una sola pregunta sobre si un mensaje llegó al cliente y cómo, y alimenta la analítica de encaminamiento.
Especificaciones de la fuente
Las normas publicadas en las que se basa esta página. Se abre en una pestaña nueva.