Mensajes SMS A2P en estado incierto: cómo reconciliar evidencias sin reenviar prematuramente

Qué significa que un mensaje esté en estado incierto

«Incierto» puede usarse como una categoría interna para señalar que la evidencia disponible no permite determinar el resultado según los criterios definidos para una integración. La información proporcionada aquí no respalda una definición técnica universal de este estado.

Conviene diferenciar los hechos que se conocen, como un intento de envío o una respuesta de una interfaz, de las conclusiones que no están demostradas. No presupongas que una aceptación significa entrega, ni que la falta de respuesta prueba un fallo.

El significado de cada estado y la evidencia que lo respalda dependen de la interfaz y de la documentación aplicable. Sin documentación pertinente, no es posible establecer reglas generales sobre las respuestas de API, las sesiones SMPP o los informes de entrega (DLR).

• Registra por separado los hechos observados y la interpretación interna que se les asigna.
• No conviertas la falta de respuesta en una afirmación sobre lo ocurrido en el sistema remoto.
• Define cualquier categoría operativa según la documentación disponible y el acuerdo específico.

Reúne evidencias y conserva la información disponible

La revisión puede empezar por reunir los registros que ya estén disponibles en la aplicación, la interfaz y la plataforma de mensajería. Anota qué sistema aporta cada dato y cuándo se registró. Estas son sugerencias de organización interna, no una descripción del comportamiento de una tecnología concreta.

No supongas que los identificadores de distintos sistemas son equivalentes o que permiten correlacionar eventos de forma automática. Para establecer una relación entre ellos, consulta la documentación de la integración correspondiente.

Si el equipo crea una clasificación interna o normaliza estados, puede conservar también el valor recibido y documentar la regla interna aplicada. La evidencia proporcionada no determina cómo deben implementarse la correlación o el tratamiento de eventos.

• Como control interno sugerido, registra las referencias disponibles, las marcas temporales y el sistema de origen.
• Documenta las limitaciones de correlación en lugar de atribuir una evidencia a un envío sin fundamento.
• Conserva la distinción entre el dato recibido y la interpretación interna, si el proceso de tu equipo lo permite.

Define criterios internos dependientes de la interfaz

Un equipo puede establecer criterios internos para clasificar los casos y decidir cuándo revisarlos. Sin documentación técnica suficiente, esos criterios deben presentarse como controles del propio equipo, no como una máquina de estados universal ni como un comportamiento esperado de todos los proveedores.

Documenta qué información disponible conduce a cada decisión interna y cómo se revisan los casos con datos incompletos o contradictorios. La evidencia proporcionada no permite especificar el comportamiento de eventos duplicados o tardíos, ni establecer transiciones técnicas generales.

Si dos registros parecen incompatibles, conserva la discrepancia como tal y consulta la documentación aplicable. No elijas automáticamente un estado por ser más reciente o favorable.

• Identifica como internas las categorías y reglas que no estén definidas por la documentación de la interfaz.
• Adapta cualquier criterio a la información realmente disponible para la integración.
• Registra las discrepancias y evita resolverlas mediante suposiciones.

Aplica reglas de cierre prudentes

El cierre de un caso es una decisión operativa que debe basarse en los criterios definidos para la integración. La evidencia disponible no establece un plazo común ni una lista universal de estados finales.

Con estas fuentes no puede confirmarse directamente qué significa un DLR con estado «entregado» en cada plataforma. Por ello, no lo presentes como prueba universal de recepción en el terminal, ni atribuyas a todas las plataformas una misma semántica.

Al cerrar un caso, separa el estado reportado por el sistema de cualquier conclusión adicional sobre recepción. Afirma que la recepción está verificada solo cuando la integración ofrezca evidencia adecuada y se conozcan sus límites.

• Define los criterios de cierre según la documentación y los acuerdos aplicables.
• Describe un DLR como un estado reportado; no generalices sobre lo que demuestra.
• Deja constancia de las incertidumbres que persistan al cerrar el caso.

Elegir entre esperar, consultar, cerrar o escalar

La acción depende de las herramientas documentadas para la integración y de los criterios acordados por el equipo. La evidencia suministrada no confirma que exista una función de consulta para todos los proveedores o interfaces.

Como control interno sugerido, el equipo puede definir cuándo mantener un caso abierto, cuándo consultar una función documentada y cuándo elevar una discrepancia. Si no puede determinar el resultado, puede marcarlo como indeterminado según su propio proceso.

Al compartir un caso con un proveedor, utiliza la información necesaria para describir la discrepancia y sigue las reglas de protección de datos aplicables. Estas recomendaciones son pautas organizativas, no capacidades técnicas confirmadas.

• Esperar: opción de proceso interno si el caso aún está dentro del criterio acordado.
• Consultar: solo si la documentación de la interfaz describe una consulta aplicable.
• Escalar: opción interna ante una discrepancia o información insuficiente que requiera revisión.
• Cerrar como indeterminado: decisión interna cuando el proceso acordado no permite concluir otro resultado.

Evita reenvíos automáticos, sobre todo en flujos OTP

La evidencia disponible no permite determinar qué mecanismos de deduplicación, consulta o reintento ofrecen las distintas plataformas. Por eso, un timeout, un DLR ausente o un estado pendiente no deben tratarse aquí como prueba suficiente de fallo ni como señal técnica universal para reenviar.

Como control interno sugerido, separa la investigación del envío original de la decisión de iniciar otro envío. Antes de un nuevo intento, aplica la política de reintentos documentada para la aplicación y la integración; no presupongas que el sistema reconocerá una solicitud repetida como la misma operación.

En flujos OTP, sigue las reglas de negocio, seguridad, privacidad y consentimiento aplicables. Informa con claridad sobre el estado que se conoce, sin presentar un reintento como garantía de entrega.

• No atribuyas deduplicación o idempotencia a una interfaz sin documentación que lo confirme.
• Aplica los controles de reintento definidos por la aplicación y la integración.
• En comunicaciones OTP, evita presentar un nuevo intento como garantía de resultado.

Marco práctico de decisión

Este marco es una ayuda interna, no una especificación de API ni una descripción universal de los estados que ofrecen los proveedores. Adáptalo a la documentación y los acuerdos aplicables.

Antes de usarlo, confirma qué información ofrece la interfaz y qué conclusiones permite extraer. Si no se puede identificar la fuente o la relación entre registros, anota esa limitación.

• Respuesta de aceptación sin información posterior: interpreta la respuesta solo según la documentación aplicable; cualquier espera o consulta es una decisión de proceso interno.
• Sin respuesta a la solicitud: registra el hecho observado; no concluyas automáticamente si fue aceptada o qué ocurrió después.
• DLR recibido: conserva el estado reportado y consulta su definición; no lo conviertas en una afirmación universal de recepción en el terminal.
• DLR sin correlación fiable: no lo atribuyas a un envío sin base documentada.
• Información incompatible: conserva los datos disponibles y sigue el proceso interno de revisión o escalado.
• Sin evidencia suficiente: clasifica el caso de acuerdo con el proceso interno, sin afirmar un resultado que no esté demostrado.

Revisa la incertidumbre y las decisiones

Un indicador de casos inciertos solo es interpretable si el equipo define qué casos incluye, el periodo observado y cómo registra los cambios posteriores. La evidencia disponible no proporciona referencias de rendimiento ni cifras que deban emplearse.

Un proceso interno puede revisar los casos abiertos, las discrepancias, las limitaciones de correlación y las decisiones de reenvío. Mantén separadas las categorías basadas en estados reportados y las afirmaciones de recepción verificada.

La revisión puede ayudar a encontrar lagunas de documentación o de proceso. No atribuyas a un indicador conclusiones que los datos no permitan sostener.

• Define el periodo y los criterios usados para identificar casos inciertos.
• Registra discrepancias y limitaciones en la información disponible.
• Revisa las decisiones de reenvío según la política interna aplicable.
• Distingue los estados reportados de cualquier recepción verificada.