Cómo automatizar reservas de coworking sin ejecutar nada dos veces
Una automatización útil no es solo «cuando ocurre X, haz Y». Debe saber cuándo ejecutarse, qué condiciones siguen siendo ciertas y cómo demostrar que la misma acción no se repetirá.
Dos tipos de trigger que no son intercambiables
Un trigger de evento reacciona a algo que acaba de suceder: una reserva fue confirmada, un pago cambió de estado o un check-in terminó. Puede ejecutarse inmediatamente porque el evento ya contiene la identidad de la reserva.
Un trigger programado responde a una relación con el tiempo: 24 horas antes de la llegada, cada mañana o después de un vencimiento. Necesita buscar qué reservas cumplen la ventana en ese momento. Convertirlo en un retraso iniciado al crear la reserva falla cuando la fecha cambia o el proceso se reinicia.
La clave de idempotencia es el diseño
Los jobs se repiten. Un worker puede morir después de enviar un correo y antes de marcarlo como completado; el siguiente intento no sabe que el envío salió. Por eso cada ejecución necesita una clave estable, por ejemplo:
automation:{rule_id}:booking:{booking_id}:event:{event_key}Antes de actuar, el sistema intenta registrar esa clave como única. Si ya existe, la acción fue solicitada anteriormente y no se repite. No basta con consultar «¿hay un correo parecido?»: dos reglas legítimas pueden enviar mensajes distintos sobre la misma reserva.
Las condiciones son filtros, no triggers
«Reserva confirmada» puede ser el trigger. «Pago pendiente», «canal directo» y «el cliente tiene email» son condiciones evaluadas justo antes de actuar. Separarlas evita crear decenas de eventos casi idénticos y permite explicar por qué una ejecución se omitió.
Las reglas deben invocar servicios, no reimplementarlos
La acción «enviar invitación de check-in» debe llamar al mismo servicio que utiliza el botón manual. Ese servicio ya conoce el idioma, la plantilla, la caducidad del enlace y el historial. Copiar esa lógica dentro del motor de automatizaciones crea un segundo comportamiento que terminará divergiendo.
Las primeras reglas que merece la pena crear
- Enviar confirmación cuando una reserva pasa a confirmada.
- Recordar el pago cuando sigue pendiente cerca del vencimiento.
- Enviar el enlace de check-in dentro de una ventana configurable.
- Avisar al equipo cuando falla una acción obligatoria.
- Solicitar feedback después de una reserva completada.
Antes de activar una regla
- Define una clave de idempotencia que represente exactamente una intención.
- Conserva trigger, condiciones, resultado y error en el historial.
- Coloca las restricciones en condiciones, no en nuevos tipos de trigger.
- Haz que la acción utilice el servicio real del producto.
- Asegúrate de que los fallos aparezcan en una pantalla que alguien revise.
Preguntas frecuentes
¿Qué es una clave de idempotencia y por qué la necesita una regla?
Es la identidad estable de una ejecución, calculada a partir de la regla, el tipo de disparador, la entidad y la fecha del evento. Los disparadores programados se reevalúan constantemente —una factura vencida hoy lo sigue estando dentro de cinco minutos—, así que sin una clave registrada el mismo recordatorio sale en cada pasada.
¿Cuándo conviene un disparador programado en vez de uno por evento?
Un disparador por evento salta porque algo acaba de ocurrir en un instante concreto: se creó una reserva, entró un pago. Uno programado salta porque una condición se volvió cierta con el tiempo: una estancia empieza mañana, una membresía va a caducar. Si no puedes señalar el instante, es programado.
¿Puede una condición actuar como disparador?
No. Las condiciones filtran candidatos que el disparador ya produjo; por sí solas no se enteran de nada. Una regla con disparador «membresía por caducar» y una condición que la limite a un plan funciona. Una regla que espera que la condición la ponga en marcha no se ejecutará nunca.