Guía práctica de entrega de SMS A2P
Lo que realmente se rompe en SMS A2P a escala: DLRs, throughput, sender IDs, registros y los hábitos operativos que mantienen sana la entrega.
Por qué "enviar el SMS" es la parte fácil
La mayoría de plataformas de mensajería hacen que la llamada a la API parezca trivial: un POST, un mensaje, un acuse de entrega. En producción, la distancia entre "aceptado por el carrier" y "leído por el usuario" es donde realmente viven los ingresos, los OTP y la reputación.
Esta guía cubre las realidades operativas del SMS Application-to-Person (A2P) a escala: las cosas que los vendors no ponen en sus landings.
Los DLR no son entrega
Un acuse de entrega (DLR) te dice que el carrier reconoció el mensaje. No te dice que el terminal lo renderizó. Un estado "DELIVRD" desde una ruta de mal comportamiento puede convivir con un 30 % de fallos silenciosos causados por:
- Filtrado de spam en el operador
- Throttling a nivel de aggregator que descarta silenciosamente el tráfico que excede cuota
- Listas de bloqueo a nivel de terminal sobre sender IDs no registrados
- Desajustes de portabilidad numérica que enrutan a un rango muerto
La única señal honesta de entrega es la conversión: si el usuario hizo clic en el enlace, introdujo el OTP o respondió. Todo lo demás es un proxy. Construye dashboards que correlacionen el estado de DLR con la conversión aguas abajo por ruta, no en agregado.
El throughput es un contrato, no un número
Cuando un vendor anuncia "200 mensajes/segundo", lee la letra pequeña. Esa cifra suele ser:
- Por conexión, no por cuenta
- Sujeta a throttling por uso justo
- Negociada por separado para short codes vs long codes vs sender alfanumérico
- Diferente además para la primera hora de una campaña vs estado estable
Para tráfico de OTP, la capacidad pico por segundo importa más que el volumen diario. Un pico de login de 5.000 OTP en 30 segundos chocará con techos que un batch de 500.000/día nunca toca. Prueba siempre con patrones de ráfaga realistas, no con medias en estado estable.
Sender ID, registro y el "impuesto" 10DLC
En EE. UU., el tráfico A2P en long codes ahora requiere registro 10DLC en The Campaign Registry. El tráfico no registrado se filtra, throttlea o se le aplican recargos. En el Reino Unido y la mayor parte de Europa, los sender IDs alfanuméricos requieren pre-registro con cada MNO, y las listas difieren.
Operativamente esto significa:
- Un cambio de sender ID es un proyecto de 2 a 6 semanas, no un cambio de configuración
- Cada mercado necesita su propio calendario de registros
- Onboardear un nuevo vendor para failover requiere duplicar registros de extremo a extremo
Planifica los registros con antelación a las campañas. Mantén un pool "caliente" de sender IDs pre-registrados a los que puedas rotar durante incidentes.
Decisiones de enrutamiento que importan de verdad
Cuando el tráfico supera unos pocos millones de mensajes al mes, el enrutamiento se convierte en la palanca de mayor impacto. Las decisiones que mueven la aguja:
- Directo vs aggregator por destino: las conexiones directas dan mejor fidelidad de DLR pero exigen overhead operativo por mercado.
- Primario + backup caliente por ruta: no solo un fallback, sino un vendor al que de verdad envías tráfico en vivo para que se mantenga caliente.
- Enrutamiento por clase de tráfico: transaccional (OTP) y marketing nunca deben compartir ruta. Los picos de marketing dañan la latencia de OTP.
- Coste por mensaje convertido, no coste por mensaje: la ruta más barata es aquella cuyos usuarios realmente reciben el mensaje.
Cómo es realmente un "incidente"
Los incidentes de mensajería en producción rara vez parecen caídas. Parecen:
- DLRs al 99 % pero conversión al 60 % en un operador específico
- Un aumento de 200 ms en el tiempo de entrega de OTP en un país, rompiendo la ventana TOTP de 60 segundos
- Un vendor reenrutando silenciosamente tu tráfico a través de un tercero a final de mes
- Reglas de filtrado del carrier que cambian sin aviso tras una circular regulatoria
La detección requiere observabilidad por ruta, por operador y por clase de tráfico. La resolución requiere una relación con el vendor en la que puedas escalar en minutos, no en días.
Qué poner en tu runbook
Si operas mensajería in-house, tu runbook debería responder a:
- ¿Qué vendor cubre cada mercado hoy y cuál es el failover?
- ¿Cuál es el umbral para cambiar el enrutamiento? ¿Quién lo autoriza?
- ¿Quién en cada vendor atiende una llamada a las 3 de la mañana?
- ¿Cuál es la caída máxima aceptable de conversión por mercado antes de escalar?
- ¿Cuánto tarda una rotación de sender ID si el actual queda filtrado de repente?
La mayoría de equipos descubren que no tienen las respuestas cuando las necesitan.
La decisión construir vs operar
Construir conectividad de mensajería es sencillo. Operarla —con los registros, el enrutamiento, los escalados a vendors, la detección de anomalías por operador— es una disciplina a tiempo completo que escala con el número de mercados y clases de tráfico.
Esa es la brecha que cubre Flowstates. Operamos el gateway, las relaciones con vendors y las operaciones para que tu equipo se centre en el producto al que esos mensajes sirven.
Si tu tráfico A2P ha crecido más allá del punto en que alguien de tu equipo puede mantenerlo todo en la cabeza, reserva una revisión de mensajería de 30 minutos: repasaremos tu setup actual y dónde está el riesgo operativo.