Respuesta
Cuando el dashboard “no cuadra” casi nunca es un problema de gráficos, sino de definiciones, fuentes y modelo de datos. La solución en ANAM se resumió en cinco acciones: unificar definiciones, fijar una única fuente de verdad por métrica, estandarizar el modelo de datos, imponer reglas de calidad con controles, y formalizar una gobernanza de reporting. Si haces esto en ese orden, los números dejan de “discutir” y empiezan a contar la misma historia. Y sí, el objetivo es que Dirección deje de preguntar “cuál es el bueno” cada lunes.
- Diagnóstico: identificar exactamente dónde “no cuadra” (ANAM)
El síntoma típico en ANAM fue este: Marketing mostraba “leads y MQL” crecientes, Ventas decía que “no hay oportunidades reales”, y Servicio reportaba “más tickets y menos satisfacción”, todo en el mismo periodo. En HubSpot eso pasa cuando estás midiendo el mismo fenómeno con objetos distintos, fechas distintas, filtros distintos o criterios que cambiaron sin avisar.
Antes de tocar nada, haz un diagnóstico corto y brutalmente concreto de 30 a 60 minutos. El objetivo no es arreglar, es localizar el punto exacto donde se rompe la coherencia.
Checklist rápido de diagnóstico, pensado para Dirección y para que no se convierta en arqueología digital:
Compara definiciones por escrito. Pide a cada área que te escriba en una frase qué entiende por Lead, MQL, SQL, Oportunidad y Cliente. Si no coinciden, ya encontraste una causa raíz.
Revisa el objeto y el evento. Confirma si cada KPI se calcula en contactos, negocios o tickets, y qué fecha manda. Por ejemplo create date no equivale a lifecycle stage date y close date no equivale a fecha de creación del deal.
Audita filtros clave. Pipeline seleccionado, etapa, equipo, propietario, región, moneda, y estado de asociación. Un filtro distinto produce un “otro universo” de datos.
Identifica métricas duplicadas por diseño. Múltiples pipelines de ventas sin reglas claras suelen crear dos “realidades” en paralelo.
Atribución y fuentes. Confirma si Marketing reporta por Original source, Latest source o por UTMs. Si cambia el criterio, el rendimiento por canal “se mueve” como por arte de magia.
Duplicados y asociaciones. Revisa si hay contactos duplicados, empresas duplicadas y deals sin empresa asociada. Eso rompe conversiones y revenue por segmento.
Permisos y visibilidad. A veces el reporte “no cuadra” porque alguien no ve todos los registros o usa un dashboard con permisos distintos.
Integraciones e importaciones. Cambios de mapeo con ERP, formularios, WhatsApp o herramientas de soporte pueden poblar propiedades de forma inconsistente.
Resultado esperado del diagnóstico ANAM: un mapa de discrepancias priorizado por impacto directivo. No empieces por “limpiar todo”, empieza por lo que cambia decisiones: pipeline, fechas oficiales y definiciones de etapa.
Si cada área trae su propia calculadora, el problema no es la suma, es que cada quien está contando manzanas, peras y algún plátano infiltrado.
Acción 1: Unificar definiciones operativas (glosario + reglas de cómputo)
En ANAM, el primer desbloqueo fue aceptar que “un KPI no existe hasta que existe su definición operativa”. No vale “MQL es un lead bueno”. Dirección necesita una definición que se pueda auditar en HubSpot.
Glosario mínimo recomendado, con el esquema que mejor funcionó:
Lead. Objeto contacto. Propiedad Lifecycle stage en Lead. Evento oficial: fecha de entrada a Lifecycle stage Lead, no la fecha de creación si importas bases. Regla anti ambigüedad: un contacto cuenta una vez por periodo según su primera entrada a la etapa.
MQL. Objeto contacto. Propiedad Lifecycle stage en MQL, o una propiedad de scoring acordada que dispare el cambio de etapa. Evento oficial: fecha de paso a MQL. Regla anti ambigüedad: si un contacto vuelve atrás por limpieza, no “recuentes” MQL del mes.
SQL. Objeto contacto o negocio, pero se decide uno. En ANAM se forzó consistencia: SQL como contacto que pasa a etapa SQL y que además tiene un deal asociado creado dentro de una ventana definida. Evento oficial: fecha de SQL. Regla: si no hay deal asociado en X días, se considera SQL incompleto y se revisa proceso.
Oportunidad. Objeto deal. Propiedad Deal stage dentro del pipeline oficial. Evento oficial: fecha de creación del deal y fecha de entrada a primera etapa de pipeline. Regla: un deal debe tener asociado al menos un contacto y una empresa.
Cierre. Objeto deal. Propiedad Deal stage en Won o Lost. Evento oficial: close date del deal, no la fecha de última modificación.
Tiempo de respuesta. Objeto contacto y actividad, o ticket si aplica a soporte. Define desde qué evento empieza el reloj, por ejemplo primera conversión o creación del ticket, y qué evento lo detiene, por ejemplo primera llamada registrada o primer correo de respuesta.
SLA de servicio. Objeto ticket. Propiedad Ticket status y timestamps. Evento oficial: fecha de creación del ticket y fecha de primera respuesta y resolución.
Tip práctico 1: escribe estas definiciones dentro de HubSpot en una nota visible, por ejemplo en la descripción del dashboard o en un documento interno vinculado, y nombra los reportes con el criterio incluido, como “MQL por fecha de etapa, contactos únicos”. Es feo, pero evita discusiones.
Error común: mezclar etapas de lifecycle con etapas de deals como si fueran equivalentes. Luego Marketing reporta MQL y Ventas reporta deals creados, y alguien pregunta por qué la conversión MQL a oportunidad es “imposible”. En su lugar, define explícitamente el puente, por ejemplo “SQL válido requiere deal asociado”, y mide esa transición como un KPI propio.
Acción 2: Definir una “única fuente de verdad” por métrica (y congelar criterios)
El segundo paso ANAM fue dejar de tener “tres verdades razonables” y pasar a “una verdad acordada”. Esto no es político, es operativo. Si una métrica cambia de definición cada trimestre, el dashboard se convierte en literatura, no en gestión.
Crea una matriz KPI a Fuente de verdad con estas columnas, simple y suficiente:
KPI. Definición operativa. Objeto HubSpot. Propiedad clave. Fecha oficial. Segmentaciones permitidas. Reporte oficial en HubSpot con nombre único. Owner del dato, no del dashboard. Cadencia de revisión.
Reglas que suelen resolver el 80 por ciento de los descuadres:
Congela criterios por trimestre. Si cambias la definición de MQL, la cambias con fecha de entrada en vigor y versión.
Separa tiempo real de cierre contable. Dirección suele necesitar ambos. Un “snapshot” mensual para comité y un tablero operativo en tiempo real para gestión semanal.
Ajustes manuales sólo con procedimiento. Por ejemplo, si Finanzas ajusta revenue por notas de crédito, que exista un campo o proceso documentado. Lo manual no es pecado, lo invisible sí.
Tip práctico 2: define una convención de nombres y carpetas para reportes y dashboards. En ANAM funcionó dividir en “Ejecutivo”, “Marketing”, “Ventas”, “Servicio”, y dentro usar prefijos como “EJ” o “OP” y añadir la fecha oficial, por ejemplo “EJ Revenue Won por close date”. Esto reduce el efecto “hice un reporte parecido y ahora nadie sabe cuál mirar”.
Acción 3: Estandarizar el modelo de datos (propiedades, asociaciones y etapas)
Una vez acordadas definiciones y fuentes, lo que sigue es alinear el CRM para que pueda producir esas métricas sin trucos. En ANAM, la mayoría de discrepancias venían de tres cosas: etapas mal usadas, propiedades no obligatorias, y asociaciones incompletas.
Estándares recomendados para estabilizar el modelo de datos, sin hacerlo pesado:
Lifecycle stages habilitados y reglas de avance. Decide cuáles usas de verdad y cuándo se permite retroceder. Si cualquiera edita lifecycle sin criterio, tu embudo se derrite.
Pipeline de deals con criterios de entrada. Define qué condiciones crean una oportunidad real. Por ejemplo, “deal creado sólo cuando hay necesidad confirmada y presupuesto estimado”, o el criterio que aplique.
Múltiples pipelines sólo si hay procesos realmente distintos. Si tienes venta nueva y renovación, o SMB y enterprise, puede tener sentido. Si es sólo por preferencia del equipo, te complicas sin valor.
Propiedades obligatorias por etapa. En etapas avanzadas, pide importe, fecha estimada de cierre, tipo de servicio, y motivo de pérdida en Lost.
Asociaciones requeridas. Estándar mínimo: todo deal debe estar asociado a un contacto y a una empresa, y todo ticket a un contacto y si aplica a una empresa.
Normalización de fuente. Define si reportas por Original source o por UTMs, y deja claro para qué sirve cada una.
Moneda y montos. Asegura consistencia de divisa y define el campo oficial para revenue reportable.
Fechas de referencia. Crea una propiedad única para “Fecha de calificación” si tu proceso lo necesita, y evita tener tres “fechas inicio” compitiendo.
A continuación tienes una tabla comparativa que ayuda a decidir controles típicos del modelo de datos según tu realidad, por ejemplo si te conviene un pipeline único o varios, y qué estandarizar primero.
Pipeline Único: úsalo cuando quieras claridad y reportes sencillos en un proceso de venta uniforme. Asociaciones requeridas (Deal Contacto Empresa): priorízalas para asegurar integridad y evitar conversiones rotas. Múltiples Pipelines: resérvalos para procesos realmente distintos, no para acomodar preferencias. Propiedades obligatorias por etapa: aplícalas para que el pronóstico deje de depender de “memoria del comercial”.
Acción 4: Reglas de calidad de datos + controles (validaciones, dedupe y auditoría)
En ANAM, el dashboard dejó de “no cuadrar” cuando se aceptó una verdad incómoda: reporting es un espejo, y si el dato está sucio, el espejo no miente, sólo refleja.
Define un set de reglas de calidad de datos que puedas medir con umbrales. Algunas prácticas que suelen dar resultados rápidos:
Completitud. Por ejemplo, menos de 2 por ciento de deals sin importe en etapas de propuesta en adelante. Menos de 1 por ciento de tickets sin owner.
Consistencia. Valores permitidos para motivo de pérdida, tipo de ticket, industria, región. Evita campos libres cuando el dato va a un KPI.
Unicidad. Deduplicación de contactos y empresas con una regla clara de “registro maestro”. Si tu tasa de duplicados es alta, el embudo se infla.
Puntualidad. SLAs internos para actualizar etapas. Por ejemplo, deal sin actividad registrada en 14 días se revisa.
Trazabilidad. Revisión de cambios críticos. Quién cambió el monto, quién movió a Won, quién editó fuente.
Controles prácticos que no convierten esto en burocracia:
Validaciones en propiedades y etapas. Haz campos requeridos en la etapa donde de verdad se conocen, no antes.
Dedupe semanal ligero. Un responsable revisa duplicados y casos de alto impacto, como empresas con revenue.
Auditoría mensual de calidad. Un reporte fijo con cinco cosas: deals sin empresa, deals sin importe, deals en etapa avanzada sin close date, tickets sin owner, contactos sin fuente.
Error común: intentar “limpiar el CRM” de una sola vez con un gran proyecto y luego no sostenerlo. En su lugar, instala controles mínimos y una auditoría recurrente, y deja que la limpieza sea continua y enfocada en lo que afecta KPIs.
Acción 5: Gobernanza de reporting (dashboard único ejecutivo + comité + playbook)
El último paso en ANAM fue institucionalizar el reporting para que no dependa del entusiasmo de una persona. Si no hay gobernanza, cada área volverá a crear su tablero “porque el otro no me sirve”.
Diseña un dashboard ejecutivo único con 8 a 12 KPIs que conecten Marketing, Ventas y Servicio. Un set que suele funcionar bien:
- Nuevos contactos netos y su fuente.
- MQL creados por fecha de etapa.
- SQL válidos con deal asociado.
- Deals creados y valor pipeline.
- Revenue Won por close date.
- Tasa de conversión MQL a SQL y SQL a Won.
- Ciclo de venta mediano, desde fecha de calificación a cierre.
- Cobertura de pipeline, por ejemplo pipeline de próximos 90 días versus objetivo.
- Tickets creados y tiempo a primera respuesta.
- CSAT o métrica de satisfacción disponible.
- Motivos de pérdida y motivos de tickets más frecuentes.
Luego define un RACI sencillo. Quién define métricas suele ser Dirección con Revenue Operations o equivalente. Quién construye reportes puede ser Ops o BI. Quién valida es cada líder de área. Quién aprueba cambios es un comité pequeño.
Cadencia recomendada:
Semanal operativo. Revisión de pipeline, conversión y SLAs. Mensual ejecutivo. Cierre de snapshot, explicación de variaciones y decisiones.
Y el detalle que evita guerras santas: un playbook de cambios. Si alguien quiere cambiar una definición, debe pedirlo, justificarlo, versionarlo y comunicarlo. Si hay discrepancia, gana el reporte oficial definido en la matriz de fuentes de verdad, y la corrección se hace en la causa raíz, no en el gráfico.
Resumen ejecutivo: las 5 acciones ANAM (lista accionable)
Diagnóstico de discrepancias. Qué cambia: mapa de causas por KPI, objeto, fecha y filtro. Impacto: dejas de discutir opiniones y atacas puntos concretos. Dueño: RevOps o Admin HubSpot con líderes de área. Plazo: 48 a 72 horas. Indicador de éxito: lista priorizada de 10 discrepancias con su reporte afectado.
Unificar definiciones operativas. Qué cambia: glosario mínimo y reglas de cómputo escritas y aceptadas. Impacto: conversiones y embudo comparables entre áreas. Dueño: Dirección comercial o RevOps. Plazo: 1 semana. Indicador de éxito: cada KPI crítico tiene definición, objeto y fecha oficial.
Única fuente de verdad por métrica. Qué cambia: matriz KPI a reporte oficial y criterios congelados por trimestre, incluyendo snapshots mensuales. Impacto: Dirección ve una sola versión y se acabó el “mi número es otro”. Dueño: RevOps con Finanzas para revenue. Plazo: 1 a 2 semanas. Indicador de éxito: dashboard ejecutivo alimentado sólo por reportes oficiales.
Estandarizar modelo de datos. Qué cambia: pipelines, etapas, asociaciones requeridas y propiedades obligatorias por etapa, más automatizaciones puntuales de fechas si aplica. Impacto: el CRM produce datos completos sin depender de heroicidades del equipo. Dueño: Admin HubSpot y líderes de proceso. Plazo: 2 a 4 semanas. Indicador de éxito: caída fuerte de deals sin empresa, sin importe y sin close date.
Calidad y gobernanza de reporting. Qué cambia: reglas de calidad con umbrales, dedupe recurrente, auditoría mensual y comité de reporting con playbook de cambios. Impacto: sostenibilidad, menos ruido y decisiones más rápidas. Dueño: RevOps con líderes de Marketing, Ventas y Servicio. Plazo: 30 a 45 días para dejarlo estable. Indicador de éxito: variación explicable y consistente entre semanas, y reducción sostenida de excepciones de datos.
Si quieres una forma práctica de empezar mañana sin volverte loco, haz primero el diagnóstico y la matriz de fuente de verdad, y deja las automatizaciones finas para después. Lo que no debes sobrecomplicar al inicio es el diseño del dashboard, porque el dashboard es la punta del iceberg: si el modelo y las definiciones están bien, el tablero casi se construye solo.
| Opción | Mejor para | Qué ganas | Qué arriesgas | Elige si |
|---|---|---|---|---|
| Pipeline Único | Proceso de venta lineal, simple | Claridad, reportes sencillos | Pierdes matices de procesos complejos | Tu ciclo de venta es uniforme (todos los productos/servicios) |
| Asociaciones requeridas (Deal-Contacto-Empresa) | Integridad de la información en CRM | Visión 360 del cliente, reportes precisos | Errores si no se gestionan bien | Necesitas entender la relación completa entre objetos para KPIs |
| Múltiples Pipelines | Procesos de venta distintos (ej. nuevo vs. recurrente) | Visibilidad granular por tipo de venta | Complejidad si no se definen bien | Necesitas métricas separadas por modelo de negocio |
| Propiedades obligatorias por etapa | Asegurar datos críticos completos | Datos fiables para pronósticos | Fricción del equipo de ventas | La calidad del dato es prioritaria para decisiones |
| Automatización de fechas de etapa (Workflows) | Registrar tiempo en cada fase | Precisión en duración de etapas | Datos erróneos por configuración incorrecta | Quieres medir eficiencia sin intervención manual |
| Propiedad 'Fecha de Calificación' | Medir tiempo de calificación a cierre | Análisis consistente del embudo | Confusión con otras fechas de etapa | Necesitas un punto de partida claro para el ciclo de oportunidad |
Fuentes
- Dashboards confiables en HubSpot: el caso ANAM - Efeonce
- Cómo alinear ventas y marketing con HubSpot en España | Posizionate
- ¿Los Informes de HubSpot No Cuadran? | GrupoCRM - El Bombero de HubSpot
- El dashboard comercial que todo CEO necesita
- Crea reportes y dashboards personalizados sin exportar datos | HubSpot
- ¿Por qué usar HubSpot como Head of Revenue Operations?
Última actualización: 2026-08-01 | Calypso

