Vuestro número de ingresos en HubSpot es una nota, no una métrica

Primero: no toda diferencia es un bug

Antes de auditar nada, aceptad que en cualquier negocio de suscripción o de contratos existen tres números distintos, y se supone que no coinciden:

• Valor de contrato firmado. El Deal Amount de HubSpot. Es de ventas. Es un número de forecast, fijado cuando se cierra el deal.
• Facturado y cobrado. Lo que Stripe o vuestro sistema de facturación ha facturado y recibido de verdad. Es de finance operations.
• Ingresos reconocidos. Lo que contabilidad registra cada mes. Es de finanzas.

Un contrato anual de $120K es un número en el CRM y doce números en contabilidad, y nadie miente. El primer fallo de la mayoría del reporting de ingresos no es técnico. Es que la empresa nunca dejó por escrito cuál de los tres números muestra cada dashboard, ni quién es su dueño.

Así que regla uno: un dueño por número, y la definición va en la descripción del informe. No en una wiki que nadie abre. En el campo de descripción del propio informe, para que la definición se lea antes que el gráfico. Si vuestro CFO y vuestro VP de Ventas no pueden escribir cada uno una definición de «ingresos» en una frase y que las dos frases coincidan, parad. Todavía no estáis ante un problema de reporting. Estáis ante un problema de vocabulario, y ningún cambio de propiedad lo va a arreglar.

Una vez escritas las definiciones, la diferencia que queda es el bug. Eso es lo que encuentra la auditoría.

La auditoría de reporting de ingresos en 30 minutos

La podéis hacer en una llamada de discovery o un viernes por la tarde. Cinco comprobaciones, sin más acceso que admin de HubSpot y lectura en facturación.

1. Contad los campos de texto con forma de ingresos. Id a las propiedades de Deal, filtrad por tipo de campo y listad cada propiedad de texto de una línea que contenga algo con forma de dinero: valor de contrato, MRR, ARR, importe de renovación, valor de upsell. Apuntad el total.
2. Cuadrad diez empresas closed-won contra facturación. Elegid diez al azar. Comparad lo que dice HubSpot con lo que dice Stripe. Una variación superior al 2% es un problema de sistema, no de redondeo.
3. Preguntad cuál es la clave de cruce. ¿Cómo se empareja una empresa de HubSpot con un cliente de facturación? Si la respuesta es el email o el nombre de la empresa, habéis encontrado una fuga.
4. Haced la prueba del registro único. Abrid el registro de empresa de cualquier cliente. ¿Veis los ingresos totales hasta la fecha en ese registro sin abrir un solo deal? Si no, ningún registro de vuestro CRM puede responder «cuánto vale este cliente».
5. Haced la prueba de la definición. Pedid al CFO y al VP de Ventas que definan los ingresos en una frase escrita cada uno, por separado. Comparad.

Si falláis dos o más, el problema es el modelo de datos. Si falláis las cinco, no estáis reportando ingresos en absoluto. Estáis reportando una colección de notas que casualmente contienen números.

Cada comprobación corresponde a un fallo. Aquí están, en el orden en que los arreglo.

Fallo 1: los ingresos viven en texto de una línea

Es el más común y el más vergonzoso, porque el gráfico se sigue pintando.

Si una cifra de ingresos está guardada en una propiedad de texto de una línea, HubSpot os deja construir un informe sobre ella. No os deja sumarla. Os da COUNT, porque el texto no tiene aritmética. El dashboard muestra un gráfico de barras, las barras tienen la forma correcta y los totales no significan nada. Alguien acaba notando que el «valor del pipeline» es igual al número de deals.

O peor, nadie lo nota nunca, porque alguien exportó a una hoja de cálculo e hizo la suma a mano, y ahora el número real de ingresos vive en una hoja de cálculo en un portátil.

Si vuestros ingresos están en una propiedad de texto, no tenéis una métrica de ingresos. Tenéis una nota.

El arreglo, por orden:

• Cread propiedades Number o Currency de verdad en el Deal y en la Company.
• Exportad los valores existentes, limpiadlos (quitad símbolos de moneda, comas, los «aprox.» y los «TBC» que escribieron los reps) y reimportadlos usando como clave el ID de registro de HubSpot, nunca el nombre.
• Ocultad el campo de texto antiguo. No lo borréis. Mantenedlo hasta demostrar que el reporting cuadra con la exportación, porque el día que lo borréis será el día que alguien necesite saber qué decía.

Trabajo aburrido. También la hora de más valor de toda la auditoría.

Fallo 2: dos sistemas, dos identidades, ningún apretón de manos

Los ingresos no dejan de sincronizarse porque se rompa la integración. Fallan porque dos sistemas se identifican con dos identidades distintas y nadie dejó por escrito cuál gana.

HubSpot conoce una empresa por dominio y nombre. Stripe conoce un cliente por customer ID y un email de facturación. Vuestra base de datos de producto conoce un tenant por tenant ID y un email de registro. Son tres identidades para un mismo cliente, y el email de registro muy a menudo no es el de facturación. El fundador se da de alta con una dirección personal, finanzas paga desde accounts@ y el CRM ve a dos personas sin relación.

Cuando una sincronización intenta cruzar por email, falla en todos esos casos. O crea una empresa duplicada o, peor, asigna los ingresos al registro equivocado.

El arreglo es una jerarquía de identidad por escrito, la misma disciplina que aplicamos en el CleanOps Protocol para la deduplicación. Para un cliente SaaS quedó así: primero el Stripe Customer ID, luego el Tenant ID, luego el dominio normalizado y luego el nombre de la empresa. El nombre va el último y se marca para revisión humana, nunca se fusiona automáticamente. Gana la primera coincidencia de la jerarquía. Una coincidencia solo por nombre nunca escribe ingresos por sí sola.

Escribid la jerarquía. Ponedla en el mismo sitio que las definiciones de las métricas. Después verificadla con una prueba deliberada: cread un cliente cuya respuesta conozcáis y seguidlo a través de todos los sistemas.

Fallo 3: los ingresos se reflejan en el deal en lugar de en la empresa

Un deal es un evento. Una empresa es el cliente.

Cuando los ingresos se reflejan en el Deal, cada renovación, upsell y expansión crea o edita un registro distinto, y el valor real del cliente queda repartido entre cinco deals y tres propietarios. Ningún registro puede responder «cuánto vale este cliente», que es justo la pregunta que vuestro equipo de CS, vuestro consejo y vuestro modelo de forecast no paran de hacer.

El arreglo es guardar los ingresos a nivel de cliente en la Company: MRR o ARR actual, ingresos totales hasta la fecha y la fecha de la última actualización de la cifra. Los deals mantienen su propio Amount para el proceso de venta. La Company lleva la verdad del cliente.

Una trampa más que va aquí. En un proyecto reciente, el deal amount estaba mapeado al MRR, así que un contrato anual de unos $18K aparecía en el pipeline como unos $1,500. Es un MRR perfectamente válido metido en un campo sobre el que se calculan las comisiones de los reps y que el informe de pipeline suma. Corrompió el valor del pipeline y el seguimiento de comisiones a la vez. El arreglo fue mapear el deal amount al importe de la próxima factura del sistema de facturación, no al MRR, con un tratamiento explícito para varias suscripciones activas, trials sin próxima factura y monedas distintas del USD. Después, revisar a mano cinco deals anuales para demostrarlo.

La lección es general: el nombre de un campo y el valor mapeado en él son dos afirmaciones distintas, y tenéis que auditar las dos.

Fallo 4: sin snapshots fechados, el histórico se mueve

HubSpot sobrescribe. Es su trabajo. Cuando un registro cambia, el valor antiguo desaparece, y cada informe que leía ese campo ahora lee el valor nuevo.

Lo que significa que el número del trimestre pasado se mueve cada vez que alguien edita un registro. Un rep corrige una errata en marzo, y la cifra del Q4 que el consejo ya vio ahora es distinta en el dashboard en vivo. Si un rep que edita un campo puede cambiar vuestro número del consejo, no es un número del consejo.

El arreglo son snapshots inmutables:

• Un snapshot mensual programado de MRR y ARR, escrito en propiedades fechadas o en un objeto de snapshot, nunca sobrescrito.
• Un snapshot del pipeline a cierre de trimestre, tomado el día que cierra el trimestre y congelado.
• Initial MRR y Matured MRR guardados como dos valores separados, porque el número con el que firma un cliente y el número en el que se estabiliza son hechos distintos que responden a preguntas distintas.

La prueba de un buen snapshot es simple. Cambiad un registro en julio y luego sacad el número de marzo. Si marzo se ha movido, no tenéis un snapshot, tenéis una vista.

Fallo 5: nadie es dueño de la definición de la métrica

Este está debajo de los otros cuatro, y es la razón por la que vuelven después de arreglarlos.

Marketing cuenta el closed-won. Ventas cuenta la firma. Finanzas cuenta la factura. Customer success cuenta la fecha de go-live. Cada equipo tiene razón según su propia definición, cada informe es coherente por dentro y ninguno cuadra con los demás.

No lo podéis resolver con una propiedad. Lo resolvéis con un dueño. Para cada métrica de ingresos de cada dashboard ejecutivo, dejad por escrito tres cosas: la definición, el sistema de origen y la única persona con nombre y apellidos que responde por ella. Poned esas tres líneas en la descripción del informe.

Así, cuando se discute un número, hay una persona a quien preguntar y una definición que comprobar, en lugar de cuatro equipos defendiendo cada uno su gráfico.

El orden en que arreglar las cosas

Si los arregláis en el orden equivocado, reconstruiréis dos veces. La secuencia que aguanta:

1. Primero, definiciones y dueños. Gratis, rápido, y todo lo demás depende de ello.
2. Segundo, la jerarquía de identidad. No se deberían escribir ingresos en un registro hasta que podáis confiar en qué registro es.
3. Tercero, propiedades numéricas. Convertid el texto a Number o Currency, en el objeto correcto, con el ID de registro como clave.
4. Cuarto, ingresos a nivel de empresa. Llevad la verdad del cliente a la Company.
5. Los snapshots, al final. No tiene sentido congelar números que todavía no habéis corregido.

Después añadid la pieza poco glamurosa que lo mantiene funcionando: una comprobación automática semanal que compara una muestra de ingresos de HubSpot con facturación y marca para revisión manual cualquier variación por encima de vuestro umbral. Marcar, nunca forzar una fusión. Una sobrescritura insegura de una cifra de ingresos es peor que una coincidencia perdida, porque la coincidencia perdida se ve y la sobrescritura es silenciosa.

Lo que os cuesta saltároslo

No me voy a inventar una cifra para vuestra empresa, porque depende del tamaño de vuestros deals y de vuestro volumen. Pero la podéis calcular vosotros mismos en una tarde.

Tomad la variación entre el closed-won de HubSpot y los ingresos facturados de los últimos cuatro trimestres. Multiplicadla por las horas que vuestra gente de finanzas y RevOps dedica cada trimestre a cuadrarla a mano. Sumad el error de forecast que sale de un informe de pipeline que suma el campo equivocado. Sumad las disputas de comisiones. Esa es la factura recurrente que ya estáis pagando por el privilegio de no arreglar el modelo.

Y hay un coste más silencioso. Cuando la dirección no se fía del número de ingresos, deja de usar el CRM para tomar decisiones. Pide hojas de cálculo. Las hojas de cálculo se convierten en el sistema real, y vuestro caro CRM pasa a ser un sitio donde los reps registran actividad. Ese es el punto en que RevOps deja de ser una función y se convierte en un help desk.

La cuestión de la arquitectura

Fijaos en que nada de esta auditoría iba de una herramienta. Podríais hacerlo todo en HubSpot con propiedades y workflows nativos, y el stack que lo rodea (Stripe, Clay para traer los datos, una base de datos para los snapshots) es intercambiable. Con la arquitectura correcta, la herramienta es un detalle. Con la arquitectura equivocada, ninguna herramienta lo salva.

Un CRM no puede reportar ingresos que nunca se diseñó para contener. Diseñadlo para contener ingresos, dadle a cada número un dueño, congelad el histórico, y la pregunta del dashboard deja de ser una discusión.

Por dónde seguir

Si habéis hecho las cinco comprobaciones y habéis fallado dos o más, no necesitáis un dashboard mejor. Necesitáis corregir el modelo de datos que hay debajo, en el orden de arriba.

Ese es el trabajo de nuestro módulo de Dashboards and Reporting, que se apoya en el módulo de CRM Foundation and Data Architecture. Empezamos con la auditoría de 30 minutos, os entregamos un plan de arreglos priorizado y anclado en dólares, y después lo construimos. Si preferís ver primero dónde estáis, el GTM Maturity and Revenue Leak Assessment os dirá si el reporting de ingresos es vuestra mayor fuga o solo la que hace más ruido.