El problema
Gestihogar es una inmobiliaria mediana en Pucallpa, Perú, con foco en propiedades para vivir, no para inversión. Su canal principal de adquisición es Facebook Lead Ads — pagan por leads que descargan brochure o piden info — y todo el follow-up ocurre por WhatsApp.
Cuando empezamos a trabajar juntos, el flujo era:
- Cliente hace clic en anuncio de Facebook
- Llena formulario en Facebook
- Vendedor revisa Facebook Ads Manager cada cierto tiempo
- Copia el lead a un Excel
- Escribe al cliente por WhatsApp Business desde su celular personal
- Si responde, agenda visita en Google Calendar
- Si no responde, el lead queda muerto en el Excel
Los problemas obvios:
- Tiempo de respuesta variable entre 5 minutos y 6 horas. En inmobiliario, después de 30 minutos el lead se enfrió.
- 3 vendedores compitiendo por el mismo WhatsApp Business: mensajes "robados", duplicados, perdidos.
- Sin atribución real: ¿qué anuncio dio mejor resultado? ¿qué vendedor convierte más? Nadie sabía con certeza.
- Un lead = un negocio en el CRM, cuando la realidad es que un lead suele estar interesado en 2-3 propiedades distintas a la vez.
La solución que construimos
Decidimos no reinventar la rueda visual del CRM y usar Teable como base de datos colaborativa — es como Airtable pero open-source y self-hosted. Encima de eso, construimos toda la lógica de negocio con n8n y Evolution API para WhatsApp.
Flujo nuevo
- Lead llega a Facebook Lead Ads → webhook a n8n
- n8n valida que el formulario sea nuevo (no re-procesa los viejos) y filtra por
Active = true - Sync por código al inicio del nombre (cada vendedor tiene un prefijo)
- Multi-propiedad por lead modelado correctamente: una fila por interés en propiedad, no una fila por persona
- Bot Andrea (Evolution API por QR) califica si nadie responde en 5 minutos
- Gate Active controla si el lead sigue caliente o se archiva
- Métricas por anuncio + propiedad + vendedor en Teable views
Por qué Baileys/QR y no Business API
Para el volumen de Gestihogar (cientos de mensajes/día, no miles), la API oficial era sobre-ingeniería. Baileys conecta cada vendedor por QR como si fuera su WhatsApp Web — sin BSP, sin certificaciones, sin templates aprobados. La lógica anti-baneo está en cómo escribe el bot: delays humanos, no masivos sin contexto, respuesta solo cuando el contacto ya escribió.
El stack en una imagen
- Teable como CRM base (multi-tabla, multi-vista, multi-usuario)
- n8n orquestando todos los flujos (FB → Teable → WhatsApp)
- Evolution API para WhatsApp por QR, multi-instancia (un servidor, 3 vendedores)
- Facebook Marketing API para tracking de anuncios y atribución
- Google Calendar API para agendamiento de visitas
- Dokploy en VPS propio para hostear todo
Resultados
A los 3 meses de operación:
- +40% de leads atendidos en menos de 5 minutos vs el flujo anterior
- 0 mensajes perdidos en el handoff entre vendedores
- Atribución por anuncio + propiedad + vendedor correcta y consultable en cualquier momento
- Multi-propiedad por lead ya no es "raro": un lead interesado en 3 deptos tiene 3 registros vinculados
Lo que aprendí
Para inmobiliarias pequeñas-medianas, el problema no es la sofisticación del CRM — es la velocidad del primer contacto y no perder leads en el handoff humano. Si arreglas eso, las métricas mejoran solas.
Tampoco hace falta WhatsApp Business API (oficial Meta) para esto. Bien implementado con Baileys y disciplina anti-baneo, dura años sin problemas y cuesta una fracción.