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.