Qué evento abre la ventana y cómo debes registrarlo
La referencia operativa debe partir del último mensaje relevante del usuario que abre la ventana de servicio. Guarda el timestamp recibido por webhook y calcula el estado en el backend; no confíes únicamente en un temporizador visual del agente. En sistemas distribuidos, utiliza una única fuente de verdad para evitar que dos servicios discrepen sobre si la ventana sigue abierta.
Cuando llega un nuevo mensaje del usuario, actualiza el vencimiento. Conserva zona horaria solo para presentación humana; internamente trabaja con timestamps inequívocos para evitar errores de horario.
Qué significa realmente trabajar “dentro de la ventana”
Dentro de la ventana puedes mantener una conversación de servicio de forma flexible conforme a las reglas aplicables. Eso no significa que cualquier contenido sea apropiado: el mensaje debe seguir respetando políticas, consentimiento y expectativas. Un agente no debería aprovechar una consulta de soporte para iniciar una campaña no relacionada.
Diseña el CRM para mostrar el tiempo restante y para distinguir mensajes libres de comunicaciones que siguen requiriendo una plantilla o un flujo específico. Así el agente comprende la regla sin memorizar cálculos.
Qué hacer cuando la ventana está cerrada
Cuando la ventana ya no permite la respuesta libre, utiliza la modalidad correspondiente —habitualmente una plantilla aprobada cuando el caso de uso lo permite— en lugar de intentar evadir la restricción. El sistema debería bloquear automáticamente tipos de mensaje incompatibles y ofrecer las plantillas pertinentes.
Si el usuario responde a esa comunicación, el estado de la conversación vuelve a cambiar y la operación debe actualizarlo a partir del evento real, no de una suposición del agente.
Ventana, categoría y precio son conceptos relacionados pero distintos
No construyas la lógica financiera suponiendo que “ventana abierta = gratis”. La política de precios puede cambiar y distinguir tipos de mensajes. Mantén las tarifas en una tabla versionada por fecha y país, separada de la lógica que decide si un mensaje está permitido.
Para presupuestar campañas y servicio, registra categoría, timestamp, país de destino y tipo de mensaje. Esa granularidad permite recalcular costos cuando Meta actualiza el modelo sin perder el historial.
Implementación técnica del temporizador
Guarda en la conversación un campo como service_window_expires_at derivado del último evento que abre la ventana. Actualízalo de forma transaccional al procesar el webhook y muestra el valor al frontend. El agente puede ver “vence en 2 h 14 min”, pero la decisión de permitir un tipo de mensaje debe tomarse en backend.
Evita calcular el vencimiento a partir de la hora del último mensaje visible si tu sistema filtra eventos, importa conversaciones o recibe mensajes fuera de orden. Conserva el timestamp de plataforma y diseña el worker para procesar duplicados de forma idempotente.
En operaciones 24/7, agrega alertas para conversaciones próximas a vencer que todavía esperan una acción humana. La alerta no debe provocar mensajes innecesarios; sirve para priorizar casos que ya requieren respuesta.
Ejemplos de flujo según el estado de la ventana
Caso soporte: el usuario pregunta por su factura, el agente responde dentro del periodo permitido y resuelve. Caso recuperación: el agente encuentra la conversación al día siguiente; el sistema no ofrece texto libre y muestra plantillas aptas para retomar el caso. Caso automatizado: un bot recibe un nuevo mensaje, abre contexto, consulta CRM y responde; si transfiere a una persona, el vencimiento sigue siendo el mismo evento de plataforma, no el momento de transferencia.
Para auditoría, registra qué modalidad de mensaje se utilizó y qué regla la autorizó. Ese dato es útil cuando una campaña o automatización genera costos inesperados.
Tabla práctica para tomar decisiones
| Situación | Acción recomendada | Control del sistema |
|---|---|---|
| Usuario acaba de escribir | Continuar atención relevante | Actualizar vencimiento con webhook |
| Ventana próxima a cerrar | Resolver o explicar siguiente paso | Mostrar contador al agente |
| Ventana cerrada | Usar plantilla apropiada si procede | Bloquear mensaje libre |
| Usuario responde a plantilla | Retomar contexto con estado actualizado | Registrar nuevo evento |
Checklist antes de llevarlo a producción
- El backend registra el timestamp que abre o renueva la ventana.
- El agente puede ver si la conversación admite respuesta libre.
- El sistema evita mensajes incompatibles cuando la ventana está cerrada.
- Los cálculos de precio están separados de la regla de ventana.
Haz visible la ventana de atención para cada conversación
Una bandeja multiagente como Optimify puede concentrar contexto, asignación y seguimiento para que el equipo atienda WhatsApp API con reglas operativas claras.
Ver chat multiagente en OptimifyPreguntas prácticas que suelen aparecer al implementar este tema
¿La ventana pertenece al agente o al cliente?
Es un estado de la conversación con el usuario, no de un agente específico. Si transfieres el caso entre personas o bots, el vencimiento no reinicia por esa transferencia; tu sistema debe conservar un único estado derivado de la interacción del usuario.
¿Puedo guardar “ventana abierta” como booleano?
Es mejor guardar el timestamp de vencimiento y calcular el estado. Un booleano se vuelve obsoleto si un worker falla o el proceso reinicia. Con el timestamp puedes mostrar tiempo restante, auditar y recalcular de forma determinista.
¿Ventana abierta significa costo cero?
No debes asumirlo. Permiso de mensajería y precio son dimensiones distintas y la estructura de precios cambia con el tiempo. Usa una tabla de tarifas versionada por fecha y aplica la política vigente para cada tipo de mensaje.