a mensajería de un solo canal presenta un único punto de fallo. WhatsApp puede sufrir una interrupción, un usuario puede quedar inaccesible en RCS, la ruta del operador puede degradarse o una plantilla puede ser rechazada a mitad de una campaña. Una estrategia de conmutación por error multicanal considera que el objetivo es "entregar este mensaje a esta persona" y el canal como un medio intercambiable. A continuación, se explica cómo diseñar una que funcione correctamente.
Defina la jerarquía de canales por tipo de mensaje.
No existe un orden universal: la secuencia adecuada depende del mensaje. Algunas opciones predeterminadas sensatas: para la autenticación, WhatsApp o RCS primero (contenido enriquecido, personalizado y rápido), luego SMS y, por último, OTP por voz. Para notificaciones transaccionales, RCS o WhatsApp primero para una experiencia personalizada, SMS como alternativa garantizada. Para alertas urgentes, priorice SMS para una mayor cobertura y añada la voz como opción de escalamiento. Defina la secuencia cuidadosamente, para cada tipo de mensaje, y anótela.
La conmutación por error debe ser condicional, no ciega.
- Fallo de capacidad: el usuario no está disponible en el canal (no se ha configurado RCS ni se ha creado una cuenta de WhatsApp). Se debe interrumpir la conexión inmediatamente; no se debe esperar.
- Error de entrega: el canal aceptó el mensaje, pero el DLR indica que no se entregó. Se cancela la entrega por falta de confirmación.
- Fallo por tiempo de espera: no se recibe confirmación de entrega dentro del plazo establecido para cada tipo de mensaje (estricto para OTP, más flexible para notificaciones). El envío se realiza cuando expira el plazo.
- Fallo del proveedor: el canal está caído. Detectar mediante la monitorización de la tasa de errores y redirigir todo el canal para todo el tráfico, no mensaje por mensaje.
Cuidado con las entregas dobles.
El fallo sutil en cualquier sistema de conmutación por error consiste en enviar el mensaje dos veces: una vez por el canal lento, aunque no haya fallado realmente, y otra vez por el canal de reserva. Para OTP, esto es especialmente perjudicial: el usuario recibe dos códigos diferentes y no sabe cuál usar. La solución consiste en una única fuente de información para el estado de entrega de cada mensaje, un registro de cada envío (conserve el ID de mensaje que devuelve la API y compruebe su estado antes de reenviar) para que un reintento nunca genere un segundo envío y, para OTP, generar el código una sola vez y reutilizarlo en todos los canales de la cadena, de modo que cualquier mensaje que llegue contenga un código válido.
El costo y la experiencia se desplazan hacia abajo en la escala.
Cada nivel de la cadena de comunicación tiene una economía y una experiencia de usuario diferentes. La conmutación por error no es gratuita: puede implicar un mensaje con menor personalización o un mayor coste unitario. Esto es comprensible: un SMS ligeramente más caro que llega a su destino es mejor que un mensaje gratuito de WhatsApp que no llega. Sin embargo, esto significa que debes monitorizar tu tasa de conmutación por error. Si el 40 % del tráfico se pierde en el último nivel, el problema reside en la fuente (datos de capacidad incorrectos, un canal principal mal configurado) y debes solucionar la causa en lugar de pagar por el síntoma.
La API omnicanal de BroadNet implementa todo el proceso —verificación de capacidad, conmutación por error condicional, código OTP compartido y análisis por canal— con una sola llamada a la API, y devuelve un ID de mensaje por cada envío para que sus reintentos comprueben el estado en lugar de enviar dos veces (consulte idempotencia y reintentos seguros). Usted describe el mensaje y la prioridad; la plataforma se encarga de la orquestación.
Pruebe las rutas de fallo
La razón más común por la que una estrategia de conmutación por error no funciona en producción es que la ruta de conmutación por error nunca se puso a prueba: se diseñó, se implementó y nunca se activó hasta que se produjo una interrupción real. Cree pruebas sintéticas que fuercen cada modo de fallo (desactive el canal principal, simule un tiempo de espera, inyecte un DLR negativo) y verifique que el mensaje se siga recibiendo. Una ruta de conmutación por error que no se ha probado es una ruta de conmutación por error que no existe.