Ventanas de quietud en SMS A2P: horarios locales y trazabilidad

Qué es una ventana de quietud y por qué importa la hora local

Una ventana de quietud es un intervalo en el que una política impide o aplaza determinados envíos. Puede responder a requisitos aplicables, a una política interna o a una preferencia registrada por el destinatario. No existe, según la evidencia disponible, un horario universal que pueda aplicarse sin verificar el mercado, el tipo de mensaje y la regla concreta.

La hora del servidor indica cuándo procesa una plataforma una solicitud; no determina por sí sola la hora del destinatario. Si la regla usa hora local, el sistema debe resolver esa hora para el destino antes de decidir si envía, pone el mensaje en espera o lo descarta. Algunas herramientas describen sus horas de silencio en la zona horaria local del contacto, pero eso no establece un requisito general para todos los servicios.

• Mantén separadas la hora de recepción, la hora del sistema y la hora local utilizada para evaluar la política.
• No adoptes una franja horaria recomendada por una herramienta como si fuera una obligación aplicable a todos los mercados.
• Define qué tipos de mensaje están sujetos a cada regla y documenta la fuente de esa decisión.

Separa requisitos, políticas internas y preferencias

Antes de configurar horarios, clasifica cada regla por su origen. Un requisito aplicable puede proceder de normas del mercado; una política interna puede establecer controles más estrictos; y una preferencia del destinatario puede reflejar una opción registrada. No las combines en una etiqueta genérica de «horas de silencio»: cada una puede tener alcance, prioridad y condiciones distintos.

Verifica los requisitos con fuentes adecuadas para cada mercado y clase de tráfico. Las fuentes generales no bastan para deducir horarios, excepciones o plazos de conservación. Este artículo ofrece pautas operativas, no asesoramiento jurídico ni una lista de requisitos por país.

• Registra para cada regla su ámbito, tipo de tráfico, mercado y fuente de validación.
• Establece una precedencia explícita cuando coincidan una restricción aplicable, una política interna y una preferencia.
• Define quién puede aprobar cambios y cómo se revisan cuando cambian las condiciones de operación.

Resolver y mantener la hora local

No deduzcas una zona horaria actual únicamente del número telefónico. La recomendación E.164 se refiere al plan internacional de numeración, pero la evidencia disponible no demuestra que el número identifique de forma fiable la zona horaria actual de una persona. Un destinatario puede cambiar de ubicación o usar un número que no refleje dónde se encuentra.

Elige y documenta una fuente de zona horaria adecuada para tu caso de uso, su nivel de confianza y qué hacer si falta o es ambigua. Mantén actualizadas las reglas de zona horaria y de horario estacional mediante una fuente técnica controlada; no codifiques desplazamientos horarios fijos como sustituto de reglas actualizadas.

Si no puedes resolver la hora local con confianza suficiente, aplica una salida segura definida por tu política: por ejemplo, retener para revisión o no enviar hasta poder evaluar la regla. La opción concreta depende de las obligaciones y del riesgo del caso.

• Guarda la zona horaria utilizada junto con la decisión, no solo la hora del servidor.
• Define el comportamiento ante datos de destino ausentes, ambiguos o desactualizados.
• Prueba transiciones de horario estacional y cambios de zona con una fuente de reglas mantenida.

Diseña el flujo: validar, esperar, reprogramar o cancelar

Un flujo operativo claro evita que la ventana se aplique de manera distinta según el componente que procese el mensaje. Al recibir una solicitud, valida el propósito y la vigencia, consulta la regla pertinente y calcula la hora local. Después, decide entre enviar, poner en espera hasta una hora permitida, reprogramar o cancelar.

La reprogramación solo es adecuada si el mensaje seguirá siendo válido cuando se envíe y si la regla aplicable lo permite. No conviertas una cola de espera en un mecanismo que envíe automáticamente contenido obsoleto. Si cambian las preferencias o las reglas mientras el mensaje está en cola, vuelve a evaluarlo antes del envío.

• Recibir: identificar el propósito del mensaje y su límite de vigencia, si existe.
• Validar: consultar preferencias y reglas aplicables al destino y al tipo de tráfico.
• Decidir: enviar, retener, reprogramar o cancelar con una razón explícita.
• Reevaluar: comprobar de nuevo la regla y la vigencia antes de liberar mensajes retenidos.

OTP y notificaciones sensibles al tiempo: no supongas excepciones

Que un mensaje sea un OTP o tenga valor temporal no demuestra, por sí solo, que pueda eludir una ventana de quietud. La evidencia disponible no establece una excepción general para OTP ni para otras notificaciones sensibles al tiempo. Verifica los requisitos y las políticas aplicables antes de definir un tratamiento distinto.

Diseña el flujo teniendo en cuenta la vigencia real del contenido. Si un código caduca antes de que termine la ventana, enviarlo más tarde puede ser inútil o confuso. Decide de antemano si se cancela, si se ofrece otra alternativa autorizada o si se solicita una nueva operación. No reenvíes códigos expirados como si siguieran siendo válidos ni presentes una excepción técnica como exención de cumplimiento.

• Define la expiración y el comportamiento de reintento en coordinación con el servicio que valida el código.
• Comprueba si el envío diferido conserva utilidad y está permitido para ese propósito y mercado.
• Si existe una excepción documentada y aprobada, limita su alcance y registra su fundamento.

Trazabilidad: conserva la regla aplicada y el motivo

Como control interno, conserva suficiente información para reconstruir por qué una solicitud se envió, aplazó o canceló. La evidencia disponible no establece un conjunto universal de campos obligatorios ni un plazo de retención; define ambos con asesoramiento y requisitos aplicables a tu organización y mercado.

Registra la decisión de forma consistente y protege los datos personales asociados. Evita almacenar contenido o identificadores más allá de lo necesario para el propósito operativo y de auditoría. La retención debe seguir la política y las obligaciones que correspondan, no un plazo genérico supuesto.

• Campos operativos posibles: identificador interno, tipo de mensaje, zona horaria evaluada, hora local, hora programada y resultado.
• Incluye la versión o identificador de la regla aplicada y el motivo de cualquier excepción o cancelación.
• Anota si la hora se calculó, si el destino estaba en espera y cuándo se reevaluó.
• Restringe el acceso a los registros y establece un período de conservación conforme a las reglas aplicables.

Prueba los casos límite antes de activar reglas

Las pruebas deben abarcar cambios de fecha y de horario estacional, además de destinos con reglas diferentes. Comprueba también qué ocurre cuando una persona modifica sus preferencias después de que el mensaje haya entrado en cola. Una prueba satisfactoria del reloj del sistema no valida automáticamente el cálculo de hora local.

Incluye mensajes cuya vigencia termina antes de la siguiente ventana permitida. Confirma que el sistema los cancela o deriva según el flujo definido y que no los libera por una ruta alternativa sin volver a evaluar la regla.

• Probar instantes inmediatamente anteriores y posteriores a medianoche local.
• Probar el inicio y el fin del horario estacional en los destinos pertinentes.
• Probar destinos para los que la zona horaria no esté disponible o resulte ambigua.
• Modificar una preferencia mientras hay mensajes retenidos y confirmar la reevaluación.
• Simular expiración antes de la hora permitida y verificar que no se envía contenido obsoleto.

Lista de comprobación para implantar y auditar

Antes de activar ventanas de quietud, confirma que cada regla tiene un ámbito claro, una fuente verificada y un responsable. Después, valida la resolución de hora local, los comportamientos de espera y cancelación y la reevaluación de mensajes pendientes. Revisa los registros y los casos de excepción de forma periódica.

Las ventanas de quietud son un control de programación, no una garantía de entrega ni una prueba de que un mensaje cumple todos los requisitos. Mantén separadas las decisiones de cumplimiento, la lógica de envío y la observación posterior del resultado.

• ¿La regla distingue mercado, tipo de tráfico y origen de la política?
• ¿La hora local procede de datos adecuados y se actualizan las reglas temporales?
• ¿El sistema define qué hacer si la zona horaria es incierta?
• ¿Los mensajes en espera se revalidan y se cancelan si caducan?
• ¿Las excepciones tienen alcance, aprobación y motivo documentados?
• ¿Los registros se protegen y conservan según requisitos confirmados?
• ¿Las pruebas cubren transiciones horarias, cambios de preferencias y rutas de cancelación?