El CEO entra a la reunión semanal y pregunta lo mismo de siempre: cómo va el proyecto de Banco Itaú, cuánto facturamos este mes, qué cuentas están en riesgo. El PM abre tres pestañas, busca en WhatsApp, pide a finanzas que mande el reporte actualizado. El cliente, en paralelo, manda un correo preguntando en qué quedó la entrega del viernes pasado.
Las tres preguntas tienen la misma raíz: nadie tiene un lugar donde ver lo que le importa sin pedírselo a otra persona. Y la respuesta convencional —hacer más reuniones, mandar más reportes en PDF— es exactamente lo que perpetúa el problema. El diseño de dashboards por rol resuelve esto, pero solo si se hace con criterio operativo, no con criterio estético.
La mayoría de las empresas de servicios profesionales que ya tienen HubSpot, Salesforce u otro CRM viven con la ilusión de que sus dashboards funcionan. La realidad: tienen tres dashboards genéricos —ventas, marketing, operaciones— que muestran métricas de embudo de producto masivo aplicadas a un negocio de proyectos. No es lo mismo.
Una empresa que vende proyectos tiene tres realidades simultáneas conviviendo en cada cuenta: una realidad comercial (deals abiertos, propuestas vivas, pipeline futuro), una realidad de ejecución (proyectos en marcha, incidentes, fees cobrados y pendientes) y una realidad financiera (margen real por cuenta, cash flow proyectado). Un solo dashboard no puede mostrar las tres bien.
Si tu director comercial necesita preguntarle al PM cómo va un proyecto antes de hablar con el cliente, tu sistema de visibilidad está roto. Si tu CEO necesita una reunión semanal para entender la salud de la operación, tu sistema de visibilidad está roto. Si tu cliente necesita escribir un correo para saber en qué quedó la última entrega, tu sistema de visibilidad está roto.
El dashboard no es decoración. Es la interfaz por la cual cada rol toma decisiones sin tener que interrumpir a otro.
La objeción típica del equipo interno es "ya tenemos dashboards, solo que la gente no los usa". Eso es media verdad. La gente no los usa porque no fueron diseñados para sus decisiones. Fueron diseñados para verse bien en una presentación al board.
El problema estructural está en el modelo de datos subyacente. Si los negocios, proyectos, tickets y facturas no están conectados con la lógica correcta —si un negocio tiene cinco proyectos asociados y nadie los modeló como objetos separados— ningún dashboard va a poder mostrar la realidad operativa. La data está, pero está mal organizada para responder las preguntas que cada rol necesita responder.
Sin esta arquitectura, los dashboards muestran totales agregados que no le sirven a nadie en particular. El CEO ve facturación del mes pero no sabe cuánto es nuevo y cuánto es recurrente. El PM ve sus proyectos pero no ve cuáles tienen fees pendientes de cobro. El cliente —si tiene acceso— ve un Gantt genérico que no refleja decisiones reales.
La respuesta típica del mercado es contratar a un analista de BI para que construya dashboards en Power BI, Tableau o Looker conectados al CRM por API. El resultado: tres meses después hay un dashboard hermoso, con filtros, drill-downs y gráficos animados. Nadie lo usa después del segundo mes.
Falla por dos razones concretas. Primera: el dashboard vive fuera del sistema donde la gente trabaja. Un PM que está en HubSpot todo el día no va a abrir otra pestaña para ver métricas. Segunda: el dashboard refleja datos pasados, no acciones presentes. Te dice qué pasó, no qué hacer ahora. Y cuando la realidad cambia —se agrega un servicio nuevo, cambia un proceso de cobro— el dashboard queda desactualizado y nadie sabe quién lo arregla.
La otra solución convencional es peor: reportes en PDF enviados por correo cada lunes. Eso no es visibilidad, es archivismo. Para cuando alguien lee el reporte, los datos ya cambiaron y la decisión ya se tomó con información obsoleta.
El cambio de paradigma es este: un dashboard no es un reporte. Es una herramienta de decisión. Cada rol toma decisiones distintas, en horizontes de tiempo distintos, con criterios distintos. Por lo tanto necesita información distinta, presentada distinto, dentro del mismo sistema donde trabaja.
El CEO toma decisiones sobre dónde poner capital y atención. Horizonte: trimestre. Criterio: salud financiera y comercial agregada, con capacidad de hacer drill-down a la cuenta específica cuando algo se sale de rango. El PM toma decisiones sobre qué hacer hoy y esta semana en su portafolio de proyectos. Horizonte: días. Criterio: dónde hay riesgo, dónde hay bloqueo, qué fees están por vencer. El cliente toma decisiones sobre si confiar más o menos en el proveedor. Horizonte: continuo. Criterio: visibilidad sobre el trabajo que ya pagó.
Cada dashboard debe responder, en menos de 10 segundos, la pregunta primaria que ese rol se hace todos los días. Si necesitas más de 10 segundos, está mal diseñado. Si necesitas interpretarlo con ayuda, está mal diseñado. Si necesitas exportarlo para compartirlo, está mal diseñado.
La pregunta primaria del CEO es: ¿la operación está sana esta semana? Eso se traduce en cinco bloques de información en un dashboard único:
La pregunta primaria del PM es: ¿qué necesita mi atención hoy? El dashboard del PM no es un reporte de estado — es una lista priorizada de acciones, generada por el sistema.
Este es el dashboard más subestimado y el que más impacto tiene en retención. La pregunta primaria del cliente es: ¿está pasando lo que pagué? Y la respuesta no es un Gantt — es información concreta sobre el estado real del trabajo.
El error más común al construir dashboards por rol es empezar por el dashboard. Hay que empezar por el modelo de datos. Si los proyectos no son objetos separados, si las facturas no están asociadas a negocios, si los tickets no tienen pipelines por equipo — no hay dashboard que arregle eso.
Una vez que la arquitectura está en su lugar, la construcción del dashboard es rápida. Pero la trampa habitual es querer mostrar todo lo que técnicamente se puede mostrar. La disciplina está en cortar: cada métrica que no genera una decisión es ruido y debe salir.
Cuando cada rol tiene un dashboard diseñado para sus decisiones, las reuniones de estado desaparecen o se transforman. Dejan de ser reuniones donde alguien reporta y otros escuchan, y se vuelven reuniones donde se discuten las dos o tres excepciones que el sistema ya marcó como problemáticas. El tiempo agregado que esto libera en una empresa de servicios profesionales con varios PMs y un equipo comercial activo es significativo — y se vuelve capacidad operativa real.
Si querés ver cómo se ve un modelo de objetos diseñado específicamente para que estos dashboards sean posibles desde el día uno, acá está la arquitectura que implementamos para empresas que venden proyectos. La diferencia entre un CRM que muestra reportes y uno donde cada rol toma decisiones sin pedirle nada a nadie está en cómo se modelan los datos antes de tocar la primera pantalla.