El problema no es la falta de datos, es que llegan tarde
Una desarrolladora con tres torres activas en Monterrey tiene datos de sobra: el asesor registra prospectos en el CRM, el administrador actualiza el inventario en Excel, y el director de obra manda avances por WhatsApp cada viernes. El problema es que nadie consolida todo eso hasta el lunes por la mañana, cuando el equipo de ventas ya lleva dos días tomando decisiones con información de la semana anterior.
El dashboard por desarrollo no es una pantalla bonita para la sala de juntas. Es la diferencia entre enterarte el lunes de que la torre B ya vendió el 80% de sus unidades de dos recámaras, o saberlo el jueves cuando aún puedes mover el presupuesto de publicidad hacia la torre C.
Qué información debe centralizar el dashboard
No todo lo que se puede medir vale la pena mostrarlo. El criterio que usamos en Eurema para definir qué entra al dashboard es simple: si el dato no cambia una decisión comercial esta semana, no ocupa pantalla.
Las vistas que sí cambian decisiones en ventas inmobiliarias son estas:
- Inventario en tiempo real por fase y tipo de unidad: cuántas unidades están disponibles, apartadas, en proceso de escrituración y escrituradas. Desglosado por fase de obra si el desarrollo es por etapas.
- Embudo de conversión por canal: de dónde vienen los prospectos (Meta Ads, Google, referidos, sala de ventas) y cuántos cierran. Si el costo por lead de digital es el doble que el de referidos pero convierte a la mitad, eso tiene que ser visible.
- Tiempo promedio de cierre: cuántos días tarda un prospecto en pasar de primer contacto a firma de promesa. Si ese número sube de 18 a 27 días en un mes, algo cambió en el proceso o en las objeciones del mercado.
- Cartera y estatus de escrituración: cuántos contratos están en proceso legal, cuántos tienen documentación incompleta y cuántos están bloqueados por el banco. Esta vista suele ser la más ignorada y la que más retrasos genera.
Un dashboard que muestre estas cuatro vistas en una sola pantalla elimina la mayoría de las juntas de seguimiento que no producen nada.
Cómo conectar las fuentes sin reescribir todo el stack
El error más común que vemos en desarrolladoras medianas es creer que necesitan cambiar de CRM o implementar un ERP nuevo antes de poder tener un dashboard útil. No es así.
En proyectos de Análisis de datos con clientes del sector inmobiliario, el punto de partida casi siempre es el stack existente: HubSpot o Zoho para prospectos, Google Sheets para inventario y un archivo de Excel del administrador para escrituración. Con conectores estándar —Zapier, Make, o conectores nativos de Power BI— se pueden unificar esas fuentes en un modelo de datos limpio sin tocar los sistemas que el equipo ya usa.
Lo que sí requiere trabajo es la limpieza previa: campos sin estandarizar, unidades registradas con nombres distintos en cada hoja, prospectos duplicados entre el CRM y el Excel de sala. Ese proceso tarda entre dos y cuatro semanas dependiendo del volumen, y es el que más se subestima en los proyectos.
El resultado después de la limpieza: el dashboard se actualiza automáticamente cada hora o cada día, sin que nadie tenga que consolidar nada manualmente.
El dashboard como herramienta de gestión del equipo de ventas
Un dashboard bien construido no solo informa al director comercial — también cambia cómo trabaja el equipo de asesores.
Cuando cada asesor puede ver su propio embudo en tiempo real —cuántos prospectos tiene activos, cuántos llevan más de 15 días sin contacto, cuántos cierres lleva en el mes— el seguimiento deja de depender de que el gerente pregunte. Lo vemos seguido en Eurema con clientes de inmobiliario: después de implementar visibilidad individual, el número de prospectos que caen por falta de seguimiento baja entre 30% y 40% en los primeros dos meses.
Esto no es magia de datos. Es que la información disponible reduce la fricción de hacer bien el trabajo. El asesor no necesita que le recuerden llamar al prospecto de la torre B que lleva 12 días sin respuesta — el dashboard ya le muestra ese nombre en rojo.
Qué no debe hacer el dashboard
Igual de importante que saber qué mostrar es saber qué no mostrar. Algunos errores frecuentes:
Demasiadas métricas en una sola vista. Un dashboard con 20 KPIs no es más útil que uno con 6. El equipo de ventas necesita saber qué hacer hoy, no analizar tendencias de 18 meses.
Datos sin contexto. “Conversión: 4.2%” no dice nada si no hay un benchmark. ¿Es bueno o malo para este tipo de desarrollo, en este rango de precio, en este mercado? El dashboard debe incluir metas o promedios históricos como referencia.
Actualización manual. Si alguien tiene que “subir el reporte” para que el dashboard se actualice, en tres semanas nadie lo estará usando. La automatización de la carga de datos no es opcional.
Vista única para todos los roles. El director comercial necesita ver el embudo completo y la cartera. El asesor necesita ver sus prospectos activos. El director de obra necesita ver el avance por fase. Un buen dashboard tiene vistas diferenciadas por rol, no una pantalla genérica para todos.
Por dónde empezar si tienes varios desarrollos activos
Si manejas más de un desarrollo simultáneamente, la prioridad es construir primero el dashboard del desarrollo con más unidades en proceso de venta activa — ahí es donde la visibilidad tiene mayor impacto inmediato.
El proceso en términos prácticos: auditar las fuentes de datos existentes (1 semana), limpiar y estandarizar (2–4 semanas), construir el modelo de datos y las vistas (2–3 semanas), iterar con el equipo de ventas (1–2 semanas). Total: entre 6 y 10 semanas para un dashboard funcional que el equipo realmente use.
Si quieres entender qué tan ordenadas están tus fuentes de datos antes de arrancar, el diagnóstico es el primer paso. Puedes ver cómo trabajamos este proceso en la página de Análisis de datos de Eurema.