Política de enrutamiento A2P SMS por destino: un marco auditable para decidir rutas
Una política de enrutamiento A2P SMS sólida convierte requisitos de cumplimiento, perfil de tráfico, evidencia de calidad, capacidad y coste en reglas revisables por destino. Este marco ayuda a seleccionar, supervisar y cambiar rutas sin confundir una DLR con una garantía universal de recepción en terminal.
Qué es una política de enrutamiento por destino y por qué una tabla de precios no basta
Una política de enrutamiento A2P SMS por destino es un conjunto documentado de reglas para decidir qué rutas pueden transportar un mensaje concreto, en qué condiciones y bajo qué controles. Su objetivo no es simplemente encontrar el menor precio, sino tomar decisiones reproducibles que respeten la elegibilidad del tráfico, los requisitos de cumplimiento, la capacidad disponible y la evidencia técnica observada.
Una tabla de precios puede ser un dato de entrada, pero no debe ser el mecanismo de decisión completo. Una ruta económicamente atractiva puede no ser apta para un sender ID determinado, para un perfil OTP o para una campaña promocional. Del mismo modo, una ruta con resultados históricos aceptables puede no disponer de capacidad suficiente en una ventana operativa crítica.
La numeración E.164 permite estructurar el destino internacional por país o código de país, pero un prefijo no resume por sí solo el contexto operativo. La decisión puede requerir, además, red efectiva cuando esté confirmada, perfil de tráfico, comportamiento del remitente, requisitos del mercado y reglas vigentes de la relación contractual.
- Use el precio como criterio de ordenación entre rutas elegibles, no como sustituto de la elegibilidad.
- Trate país, red, perfil de tráfico y sender ID como atributos separados.
- Documente tanto las rutas aprobadas como las excluidas y el motivo de cada exclusión.
Las unidades de decisión: país, rango o red, tipo de tráfico, remitente y ventana operativa
La unidad mínima de una política rara vez debería ser solo un país. Una regla útil puede aplicarse a un país, a un rango E.164, a una red confirmada o a una combinación de estos atributos. La granularidad debe reflejar la evidencia disponible: no conviene afirmar una red efectiva si únicamente se conoce el país o el rango de numeración.
A cada destino deben asociarse atributos del mensaje. Entre ellos están el perfil de tráfico, el tipo de sender ID permitido o esperado, el historial de comportamiento del remitente, la ventana de validez y la prioridad operativa. Esto evita aplicar una ruta diseñada para notificaciones de bajo riesgo a un flujo OTP sensible al tiempo.
La ventana operativa importa especialmente cuando el valor del mensaje caduca. Un OTP que alcance un estado final cuando el código ya no es útil puede tener una señal técnica positiva, pero no satisfacer el objetivo de negocio. La política debe definir el punto a partir del cual la latencia deja de ser aceptable para cada perfil.
- Destino: país, rango E.164 y red solo cuando exista confirmación suficiente.
- Mensaje: OTP, alerta transaccional, notificación operativa o marketing consentido.
- Remitente: tipo de sender ID, registro aplicable y comportamiento esperado.
- Tiempo: periodo de validez, prioridad y límite interno de utilidad.
- Contexto: capacidad prevista, horario operativo y reglas de cumplimiento aplicables.
Separar precio, calidad, capacidad y cumplimiento como dimensiones independientes
Una matriz robusta trata el cumplimiento, la aptitud del perfil de tráfico, la calidad observada, la capacidad y el coste como dimensiones independientes. Mezclarlas en una única puntuación sin restricciones previas puede permitir que un precio bajo compense indebidamente una exclusión regulatoria, contractual u operativa.
El cumplimiento y la elegibilidad deben funcionar como filtros. Si una ruta no admite el tipo de tráfico, el sender ID o las condiciones de uso aplicables, no debe entrar en la comparación económica. Después de filtrar, la organización puede ordenar las alternativas elegibles mediante criterios técnicos y comerciales definidos.
La calidad tampoco debe reducirse a una sola cifra. Conviene distinguir disponibilidad de la conexión, comportamiento de DLR, tiempo hasta estado final, errores de integración y señales de comportamiento de sender o contenido. La interpretación debe conservar el contexto de la ruta, el destino y el periodo observado.
- Filtro 1: cumplimiento y documentación exigida.
- Filtro 2: aptitud para perfil de tráfico y sender ID.
- Filtro 3: capacidad operativa disponible.
- Comparación: evidencia técnica observada y coste contractual.
- Control continuo: revisión de cambios, incidentes y resultados posteriores.
Qué evidencia reunir antes de aprobar una ruta
Antes de aprobar una ruta, reúna evidencia declarada y evidencia observada, y manténgalas diferenciadas. La procedencia declarada puede incluir las condiciones de uso, restricciones de sender ID, perfiles de tráfico admitidos y capacidad comunicada. La evidencia observada procede de pruebas controladas y de la supervisión operativa posterior.
Las pruebas deben poder reconstruirse. Para cada mensaje de prueba, preserve la correlación entre identificador interno, identificador de mensaje, destino tratado conforme a las reglas de privacidad aplicables, ruta utilizada, marcas temporales, DLR recibido, estado final y código de error. En SMPP, el formato de receipt contenido en el short message de un delivery receipt puede incluir identificador de mensaje, fecha de envío, fecha de estado final, estado final y error; su disponibilidad y semántica práctica dependen de la implementación y del proveedor.
La evidencia debe evaluarse por segmentos comparables. No es prudente combinar en una misma conclusión resultados de perfiles de tráfico diferentes, remitentes con comportamientos distintos o ventanas temporales incompatibles. También debe evitarse convertir una muestra pequeña en una regla permanente.
- Procedencia y condiciones declaradas de la ruta.
- Restricciones de tráfico, sender ID y contenido comunicadas.
- Pruebas controladas con correlación completa de eventos.
- DLR bruto, estado normalizado y código de error original.
- Latencia hasta estado final y disponibilidad de la conexión.
- Fecha, tamaño y alcance de la muestra evaluada.
Cómo interpretar DLR y pruebas de entrega sin convertirlas en una garantía de recepción en terminal
SMS móvil terminado, o SM-MT, transfiere un mensaje desde un centro de servicio a una estación móvil y puede proporcionar informes de entrega o fallo. Sin embargo, una DLR debe interpretarse según la semántica de la interfaz y de la red que la emite. No es una prueba universal de lectura del mensaje ni una garantía homogénea de recepción en el terminal.
En SMPP v3.4 aparecen estados finales como DELIVRD, EXPIRED, UNDELIV, ACCEPTD, UNKNOWN y REJECTD. Además, los códigos de error pueden ser específicos de red o de SMSC. Por ello, la política debe conservar el valor bruto recibido, el estado normalizado usado internamente, el código de error, la marca temporal y la fuente que emitió el evento.
La documentación de algunos proveedores distingue entre aceptación por el carrier ascendente, confirmación de entrega y, cuando esté disponible, confirmación desde el terminal. Esa distinción ilustra un principio operativo general: no agregue aceptación, envío y entrega reportada en una única tasa de éxito. Compare cada fase por separado y describa explícitamente qué confirma cada métrica.
- No interprete una DLR como confirmación de lectura.
- Diferencie aceptación por proveedor, envío, entrega reportada y no entrega.
- Conserve estados y errores originales antes de normalizarlos.
- Mida el tiempo hasta estado final, no solo la existencia de un estado.
- Registre la fuente y el contexto de cada DLR.
Definir perfiles de tráfico y reglas de elegibilidad
Los perfiles de tráfico deben mantenerse separados porque cambian la utilidad temporal, el riesgo operativo y las obligaciones de consentimiento. Una clasificación práctica puede incluir OTP, alertas transaccionales, notificaciones operativas y marketing consentido. Esta es una taxonomía operativa interna, no una clasificación normativa universal, y debe corresponder al propósito real del mensaje, no a la etiqueta comercial elegida por el remitente.
Para OTP, defina un periodo de validez y un límite interno de latencia compatible con la vida útil del código. Para alertas transaccionales y notificaciones operativas, defina la prioridad, el contenido permitido y los criterios de escalado. Para marketing consentido, incorpore controles de consentimiento, bajas y restricciones de campaña antes de que una ruta sea considerada elegible.
CTIA distingue tráfico conversacional, informativo y promocional, con expectativas de permiso diferentes. En los contextos donde estas prácticas apliquen, el marketing promocional requiere una gestión especialmente rigurosa del consentimiento. La ruta no sustituye las obligaciones que correspondan conforme a la jurisdicción, el operador y el programa de mensajería aplicables: si falta evidencia requerida, la política debe excluir el envío o dirigirlo a revisión.
- OTP: validez, prioridad y punto de corte de utilidad.
- Transaccional: finalidad concreta y reglas de contenido.
- Operativo: urgencia, destinatarios autorizados y escalado.
- Marketing consentido: evidencia de consentimiento, gestión de bajas y controles por campaña.
- Conversacional: respuesta relevante a una interacción iniciada por el consumidor cuando corresponda.
Crear una matriz de decisión auditable por destino
La matriz de decisión debe convertir la política en una herramienta operativa. Cada fila puede representar una combinación de destino y perfil, por ejemplo: país o rango E.164, red cuando esté confirmada, tipo de tráfico y tipo de sender ID. A esa combinación se asocian rutas elegibles, rutas excluidas, requisitos previos, evidencia disponible y responsables.
Defina umbrales internos solo cuando estén respaldados por una metodología estable. No es necesario publicar ni inventar cifras para trabajar con disciplina: la matriz puede registrar que una ruta requiere una muestra mínima interna, una ventana de observación definida, ausencia de determinados errores o revisión adicional ante cambios de comportamiento. Lo esencial es que el umbral, su propietario y su justificación queden documentados.
Cada decisión necesita vigencia y revisión. La información de una ruta puede cambiar por condiciones operativas, integración, comportamiento de sender o requisitos de mercado. Por eso, una aprobación no debe ser indefinida: incluya fecha de aprobación, fecha de revisión, evidencia de respaldo y condición de reversión.
- Identificador de política y versión.
- País o rango E.164; red solo si está confirmada.
- Perfil de tráfico y requisitos de sender ID.
- Rutas elegibles, preferidas y excluidas.
- Evidencia técnica, contractual y de cumplimiento.
- Umbrales o criterios internos aplicados.
- Aprobador, fecha de vigencia y fecha de revisión.
- Condiciones de reversión y ruta de escalado.
Cambios de ruta controlados y fallback routing
Un cambio de ruta debe tratarse como un cambio controlado, no como una simple sustitución en una tabla. Empiece con pruebas previas y una hipótesis clara: qué destino, perfil y condición se evaluarán; qué evidencia decidirá el avance; y qué señal obligará a detener o revertir el cambio. Mantenga la correlación de los eventos para que la comparación sea reproducible.
Cuando la operación lo permita, despliegue el cambio de forma gradual. Compare resultados dentro de segmentos equivalentes y durante una ventana definida. Si aparecen señales incompatibles con la política, aplique la condición de reversión, registre el incidente y comunique el cambio a las funciones internas afectadas.
El fallback routing puede proteger la continuidad, pero es una excepción que necesita gobierno. Defina qué estados finales, errores o condiciones pueden activar una alternativa. No elimine del registro el fallo inicial ni atribuya al fallback una entrega que impida evaluar la ruta primaria. Si el fallback se activa de manera persistente, debe abrir una revisión en lugar de normalizar el problema.
- Defina hipótesis, alcance y criterio de éxito antes de cambiar.
- Pruebe antes de desplegar y preserve los identificadores correlacionados.
- Aplique despliegue gradual cuando el contexto operativo lo permita.
- Establezca condiciones explícitas de detención y reversión.
- Registre el motivo, la ruta primaria y la alternativa en cada fallback.
- Escalé activaciones repetidas de fallback como posible incidente.
Preguntas frecuentes
¿Una DLR con estado delivered demuestra que el usuario leyó el SMS?
No. Una DLR es una señal de estado con una semántica que depende de la interfaz, la red y la información disponible. Puede indicar confirmación desde un carrier ascendente y, en algunos casos, desde el terminal, pero no prueba lectura por parte del destinatario.
¿Basta el prefijo telefónico para seleccionar una ruta A2P SMS?
No. E.164 estructura la numeración internacional, pero una decisión de routing puede requerir país, rango, red confirmada, perfil de tráfico, sender ID, ventana de validez y requisitos de cumplimiento.
¿Debe el coste decidir la ruta preferida?
El coste debe compararse únicamente entre rutas que ya hayan superado los filtros de cumplimiento, elegibilidad para el perfil de tráfico, sender ID y capacidad. Un precio menor no debe compensar una exclusión de cumplimiento o una incompatibilidad operativa.
¿Cuándo conviene activar fallback routing?
Solo ante condiciones definidas previamente, como determinados estados finales, códigos de error o incidentes de disponibilidad. La activación debe conservar la evidencia del fallo original y abrir revisión si se vuelve recurrente.
¿Qué debe conservarse para auditar un cambio de ruta?
La versión de la política, el alcance del cambio, aprobaciones, resultados de pruebas, identificadores de mensaje, DLR y errores brutos, marcas temporales, decisión de despliegue, condición de reversión y resultados posteriores.
¿Cómo puede ayudar BulkSMSMarket en este proceso?
BulkSMSMarket está desarrollando una plataforma empresarial para descubrir, comparar, comprar, vender y gestionar capacidad A2P SMS. Las funcionalidades operativas de marketplace, autenticación, balances, facturación y routing en vivo no son públicas. Su plataforma interna de pruebas realiza comprobaciones diarias en rutas, destinos y operadores, observando entrega, consistencia de DLR, latencia, disponibilidad y comportamiento de sender y contenido; estas observaciones son internas, no datos comerciales en tiempo real ni una garantía de rendimiento.
Fuentes consultadas
- ITU-T Recommendation E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)
- 3GPP TS 23.040: Technical realization of the Short Message Service (SMS)3GPP / ETSI
- 3GPP TS 23.040 specification record3GPP
- SMPP Protocol Specification v3.4, Issue 1.2SMPP Developers Forum
- Messaging Principles and Best PracticesCTIA
- Messages resource: message status definitionsTwilio Developer Documentation