Diseñar una cadena de fallback multicanal

Los canales no son intercambiables

La mayoría de propuestas multicanal tratan SMS, RCS, WhatsApp y email como opciones paralelas que el usuario puede elegir. En mensajería de producción, ese es el modelo mental incorrecto.

El modelo correcto es una cadena de fallback: prueba el canal más barato que probablemente funcione para este usuario, pasa al siguiente solo si el primero falla o no entrega a tiempo.

Bien hecho, esto reduce costes un 20–40 % y mejora el alcance. Mal hecho, envía el mismo mensaje cuatro veces a la misma persona.

La economía que dirige la cadena

Los costes por mensaje varían en un orden de magnitud:

• Email: fracciones de céntimo
• Plantilla utility de WhatsApp: ~1–2 céntimos (varía por mercado)
• RCS: similar a SMS en la mayoría de mercados, a veces más barato para contenido rico
• SMS: 0,5–10 céntimos según país

Así que el orden óptimo en coste suele ser: email → RCS (si el usuario lo tiene) → WhatsApp → SMS. El óptimo en alcance es el inverso: SMS primero porque cualquier terminal puede recibirlo.

Una cadena de fallback real equilibra esto contra el coste de un mensaje fallido.

Una cadena concreta para tráfico transaccional

Para un mensaje transaccional de alto valor (pedido enviado, confirmación de entrega):

1. Prueba RCS (si el dispositivo es compatible, ~2s timeout para acuse de lectura)
2. Si no hay acuse de lectura → prueba plantilla WhatsApp Business
3. Si no hay acuse de lectura en 60s → fallback a SMS
4. Envía email en paralelo siempre como copia pasiva

Puntos críticos de diseño:

• Acuses de lectura, no de entrega, dirigen la decisión de fallback en canales ricos. RCS y WhatsApp lo exponen; SMS no.
• Topes de tiempo en cada paso. Un fallback que tarda 5 minutos es peor que ningún fallback para mensajes sensibles al tiempo.
• El email es una copia pasiva, no un paso de fallback. Enviar email al final y esperar a que falle no significa nada: no hay señal real de "entrega".

La excepción del OTP

Para OTPs, la cadena de fallback es mucho más corta y rápida:

1. SMS (siempre, inmediato)
2. Llamada de voz con lectura del código (solo si el usuario lo opta o tras 60s sin entrada)

¿Por qué no RCS o WhatsApp? Porque:

• La latencia en canales ricos es menos predecible
• Los acuses de lectura añaden un paso que no te puedes permitir en una ventana TOTP de 60 segundos
• El alcance del SMS es universal; los canales ricos no

Los OTP deben optimizarse por tiempo de entrega, no por coste.

Cuándo paralelo gana a serial

Hay casos en los que enviar por múltiples canales en paralelo es correcto:

• Anuncios de marketing donde el objetivo es notoriedad, no entrega de un solo toque
• Alertas críticas donde el coste de un mensaje fallido excede con mucho el coste de un duplicado (seguridad, compromiso de cuenta)
• Usuarios multi-dispositivo donde el email se lee en escritorio y el SMS en el móvil

Regla de pulgar: paralelo cuando el mensaje es crítico y el usuario no objetará la duplicación; fallback serial en el resto de casos.

Requisitos operativos

Una cadena de fallback requiere tres cosas que la mayoría de stacks de mensajería no traen de serie:

1. Lookup de capacidad de canal por usuario: ¿este número tiene RCS? ¿Hay un número de WhatsApp con opt-in?
2. Tracking de estado entre canales: dentro de un mismo mensaje lógico, qué se envió por qué canal y cuál fue la respuesta
3. Manejo de timeout por paso: la cadena debe avanzar automáticamente cuando un canal no responde

Construir esto in-house no es trivial. Es una de las cosas que un gateway gestionado debería resolverte.

Qué medir

No midas solo entrega por canal. Mide:

• Coste por mensaje convertido: gasto total a lo largo de la cadena dividido entre los usuarios que actuaron
• Atribución de canal: qué paso de la cadena entregó realmente la lectura
• Tasa de fallback: con qué frecuencia se necesitan el segundo y tercer canal (tasas altas sugieren que el primer canal está mal elegido)
• Tiempo total hasta lectura a lo largo de la cadena, no por canal

Estos números te dicen si la cadena funciona o si estás pagando por redundancia que no necesitas.

Errores comunes

Tres patrones que vemos repetidamente:

1. Enviar por todos los canales "por seguridad": quema presupuesto, molesta a usuarios, diluye señales de engagement.
2. Sin timeouts entre pasos: un fallback que tarda 10 minutos hace irrelevante el mensaje.
3. Tratar el email como fallback: no hay señal real de entrega, así que la cadena no puede tomar decisiones sobre él.

---

Si estás diseñando o reconstruyendo tu lógica de fallback entre canales, reserva una revisión de mensajería de 30 minutos. Compartimos patrones que funcionan en producción.