Enrutamiento por establecimiento
Cada evento lleva el IdDoEstabelecimento, y es él quien decide la sucursal de destino. La regla vive en código versionado, no en un nodo condicional que nadie quiere abrir.
Una red de estética con 6 sucursales necesitaba confirmar turnos por WhatsApp sin nadie despachando mensajes a mano. Flouds cambió el flujo n8n por un sistema propio en Go que identifica la sucursal de cada evento y envía la confirmación sin intervención.
Hablar sobre mi caso.jpg&w=3840&q=75)
Cada sucursal tiene su número, su idEstablecimiento y su agenda propia. En n8n, eso se vuelve decenas de nodos condicionales que nadie quiere tocar.
Un enrutamiento flojo manda la confirmación de la sucursal A al cliente de la sucursal B.
La agenda exige confirmar el SubscriptionConfirmation del SNS. Olvidarlo tumba el flujo entero.
Cuando un recordatorio no sale, no hay log que explique el motivo. Queda solo el reclamo del cliente.
Con una sucursal, un flujo n8n aguanta. Con seis, cada una tiene su número de WhatsApp, su idEstablecimiento y su mapa de profesionales, y el enrutamiento se vuelve un laberinto de nodos condicionales que nadie se anima a tocar. Un evento cae en la sucursal equivocada y el cliente recibe el mensaje de otra tienda, o no recibe nada.
Flouds entregó un sistema propio en Go, Next.js y Postgres que recibe el webhook de la agenda (Trinks, vía SNS), confirma la suscripción del SNS automáticamente, registra cada evento y usa el IdDoEstabelecimento para enrutar hasta la sucursal correcta. La lógica queda en código versionado y testeable, dentro de tu infraestructura.
Cada evento lleva el IdDoEstabelecimento, y es él quien decide la sucursal de destino. La regla vive en código versionado, no en un nodo condicional que nadie quiere abrir.
La suscripción del SNS la acepta y confirma el propio sistema, sin que nadie esté pendiente. Es el paso que, olvidado, tumba el flujo entero de la agenda.
Cada webhook recibido queda grabado en Postgres antes de convertirse en mensaje. Cuando un recordatorio no sale, hay registro para explicar el motivo.
La confirmación sale por el número de WhatsApp de la propia sucursal, vía FZAP. Ninguna etapa depende de una plataforma de terceros en el camino.
La cita creada en Trinks se convierte en un evento que llega por webhook, vía AWS SNS. El sistema confirma la suscripción solo, en el primer contacto.
Sin confirmar SNS a mano
Antes de cualquier envío, el webhook se graba en Postgres con lo que vino de la agenda. Ese registro es lo que permite investigar después.
Rastro de cada cita
El IdDoEstabelecimento define la sucursal y la regla que se aplica a ese evento. Seis sucursales conviven en el mismo código, sin ramificación visual.
6 sucursales, un solo sistema
El mensaje sale por FZAP con el número de la sucursal correcta, sin nadie despachando a mano. El cliente recibe la confirmación de la tienda donde reservó.
93,5% de entrega
Tienes una aplicación real, que registra log, se levanta con un comando y queda en tu infraestructura. Cuando la agenda cambia, editas código en lugar de rearmar treinta nodos en un editor visual.
Producción real · cerca de 40 días en el aire
Son cerca de 1.467 eventos por día enrutados sin intervención manual, sobre una base de 22.586 clientes.
Flouds resuelve eso con software propio, hecho para aguantar producción.