El vostre número d’ingressos a HubSpot és una nota, no una mètrica

Primer: no tota diferència és un bug

Abans d’auditar res, accepteu que en qualsevol negoci de subscripció o de contractes hi ha tres números diferents, i se suposa que no coincideixen:

• Valor de contracte signat. El Deal Amount de HubSpot. És de vendes. És un número de forecast, fixat quan es tanca el deal.
• Facturat i cobrat. El que Stripe o el vostre sistema de facturació ha facturat i rebut de veritat. És de finance operations.
• Ingressos reconeguts. El que comptabilitat registra cada mes. És de finances.

Un contracte anual de $120K és un número al CRM i dotze números a comptabilitat, i ningú no menteix. La primera fallada de la majoria del reporting d’ingressos no és tècnica. És que l’empresa mai no va deixar per escrit quin dels tres números mostra cada dashboard, ni qui n’és l’amo.

Així que regla u: un amo per número, i la definició va a la descripció de l’informe. No en una wiki que ningú no obre. Al camp de descripció del mateix informe, perquè la definició es llegeixi abans que el gràfic. Si el vostre CFO i el vostre VP de Vendes no poden escriure cadascun una definició d’«ingressos» en una frase i que les dues frases coincideixin, pareu. Encara no esteu davant d’un problema de reporting. Esteu davant d’un problema de vocabulari, i cap canvi de propietat no l’arreglarà.

Un cop escrites les definicions, la diferència que queda és el bug. Això és el que troba l’auditoria.

L’auditoria de reporting d’ingressos en 30 minuts

La podeu fer en una trucada de discovery o un divendres a la tarda. Cinc comprovacions, sense més accés que admin de HubSpot i lectura a facturació.

1. Compteu els camps de text amb forma d’ingressos. Aneu a les propietats de Deal, filtreu per tipus de camp i llisteu cada propietat de text d’una línia que contingui alguna cosa amb forma de diners: valor de contracte, MRR, ARR, import de renovació, valor d’upsell. Apunteu el total.
2. Quadreu deu empreses closed-won contra facturació. Trieu-ne deu a l’atzar. Compareu el que diu HubSpot amb el que diu Stripe. Una variació superior al 2% és un problema de sistema, no d’arrodoniment.
3. Pregunteu quina és la clau de creuament. Com s’aparella una empresa de HubSpot amb un client de facturació? Si la resposta és l’email o el nom de l’empresa, heu trobat una fuita.
4. Feu la prova del registre únic. Obriu el registre d’empresa de qualsevol client. Veieu els ingressos totals fins avui en aquest registre sense obrir ni un sol deal? Si no, cap registre del vostre CRM no pot respondre «quant val aquest client».
5. Feu la prova de la definició. Demaneu al CFO i al VP de Vendes que defineixin els ingressos en una frase escrita cadascun, per separat. Compareu.

Si en falleu dues o més, el problema és el model de dades. Si falleu les cinc, no esteu reportant ingressos en absolut. Esteu reportant una col·lecció de notes que casualment contenen números.

Cada comprovació correspon a una fallada. Aquí les teniu, en l’ordre en què les arreglo.

Fallada 1: els ingressos viuen en text d’una línia

És la més comuna i la més vergonyosa, perquè el gràfic es continua pintant.

Si una xifra d’ingressos està guardada en una propietat de text d’una línia, HubSpot us deixa construir un informe a sobre. No us la deixa sumar. Us dona COUNT, perquè el text no té aritmètica. El dashboard mostra un gràfic de barres, les barres tenen la forma correcta i els totals no signifiquen res. Algú acaba adonant-se que el «valor del pipeline» és igual al nombre de deals.

O pitjor, ningú no se n’adona mai, perquè algú va exportar a un full de càlcul i va fer la suma a mà, i ara el número real d’ingressos viu en un full de càlcul en un portàtil.

Si els vostres ingressos són en una propietat de text, no teniu una mètrica d’ingressos. Teniu una nota.

L’arranjament, per ordre:

• Creeu propietats Number o Currency de veritat al Deal i a la Company.
• Exporteu els valors existents, netegeu-los (traieu símbols de moneda, comes, els «aprox.» i els «TBC» que van escriure els reps) i reimporteu-los fent servir com a clau l’ID de registre de HubSpot, mai el nom.
• Amagueu el camp de text antic. No l’esborreu. Mantingueu-lo fins a demostrar que el reporting quadra amb l’exportació, perquè el dia que l’esborreu serà el dia que algú necessiti saber què deia.

Feina avorrida. També l’hora de més valor de tota l’auditoria.

Fallada 2: dos sistemes, dues identitats, cap encaixada

Els ingressos no deixen de sincronitzar-se perquè es trenqui la integració. Fallen perquè dos sistemes s’identifiquen amb dues identitats diferents i ningú no va deixar per escrit quina guanya.

HubSpot coneix una empresa per domini i nom. Stripe coneix un client per customer ID i un email de facturació. La vostra base de dades de producte coneix un tenant per tenant ID i un email de registre. Són tres identitats per a un mateix client, i l’email de registre sovint no és el de facturació. El fundador es dona d’alta amb una adreça personal, finances paga des d’accounts@ i el CRM veu dues persones sense relació.

Quan una sincronització intenta creuar per email, falla en tots aquests casos. O crea una empresa duplicada o, pitjor, assigna els ingressos al registre equivocat.

L’arranjament és una jerarquia d’identitat per escrit, la mateixa disciplina que apliquem al CleanOps Protocol per a la deduplicació. Per a un client SaaS va quedar així: primer el Stripe Customer ID, després el Tenant ID, després el domini normalitzat i després el nom de l’empresa. El nom va l’últim i es marca per a revisió humana, mai no es fusiona automàticament. Guanya la primera coincidència de la jerarquia. Una coincidència només per nom mai no escriu ingressos per si sola.

Escriviu la jerarquia. Poseu-la al mateix lloc que les definicions de les mètriques. Després verifiqueu-la amb una prova deliberada: creeu un client del qual conegueu la resposta i seguiu-lo a través de tots els sistemes.

Fallada 3: els ingressos es reflecteixen al deal en lloc de l’empresa

Un deal és un esdeveniment. Una empresa és el client.

Quan els ingressos es reflecteixen al Deal, cada renovació, upsell i expansió crea o edita un registre diferent, i el valor real del client queda repartit entre cinc deals i tres propietaris. Cap registre no pot respondre «quant val aquest client», que és justament la pregunta que el vostre equip de CS, el vostre consell i el vostre model de forecast no paren de fer.

L’arranjament és guardar els ingressos a nivell de client a la Company: MRR o ARR actual, ingressos totals fins avui i la data de l’última actualització de la xifra. Els deals mantenen el seu propi Amount per al procés de venda. La Company porta la veritat del client.

Una trampa més que va aquí. En un projecte recent, el deal amount estava mapejat a l’MRR, així que un contracte anual d’uns $18K apareixia al pipeline com uns $1,500. És un MRR perfectament vàlid ficat en un camp sobre el qual es calculen les comissions dels reps i que l’informe de pipeline suma. Va corrompre el valor del pipeline i el seguiment de comissions alhora. L’arranjament va ser mapejar el deal amount a l’import de la propera factura del sistema de facturació, no a l’MRR, amb un tractament explícit per a diverses subscripcions actives, trials sense propera factura i monedes diferents de l’USD. Després, revisar a mà cinc deals anuals per demostrar-ho.

La lliçó és general: el nom d’un camp i el valor que s’hi mapeja són dues afirmacions diferents, i les heu d’auditar totes dues.

Fallada 4: sense snapshots datats, l’històric es mou

HubSpot sobreescriu. És la seva feina. Quan un registre canvia, el valor antic desapareix, i cada informe que llegia aquest camp ara llegeix el valor nou.

Això vol dir que el número del trimestre passat es mou cada vegada que algú edita un registre. Un rep corregeix una errada al març, i la xifra del Q4 que el consell ja va veure ara és diferent al dashboard en directe. Si un rep que edita un camp pot canviar el vostre número del consell, no és un número del consell.

L’arranjament són snapshots immutables:

• Un snapshot mensual programat d’MRR i ARR, escrit en propietats datades o en un objecte de snapshot, mai sobreescrit.
• Un snapshot del pipeline a tancament de trimestre, pres el dia que tanca el trimestre i congelat.
• Initial MRR i Matured MRR guardats com a dos valors separats, perquè el número amb què signa un client i el número en què s’estabilitza són fets diferents que responen preguntes diferents.

La prova d’un bon snapshot és simple. Canvieu un registre al juliol i després traieu el número de març. Si març s’ha mogut, no teniu un snapshot, teniu una vista.

Fallada 5: ningú no és amo de la definició de la mètrica

Aquesta és a sota de les altres quatre, i és la raó per la qual tornen després d’arreglar-les.

Màrqueting compta el closed-won. Vendes compta la signatura. Finances compta la factura. Customer success compta la data de go-live. Cada equip té raó segons la seva pròpia definició, cada informe és coherent per dins i cap no quadra amb els altres.

No ho podeu resoldre amb una propietat. Ho resoleu amb un amo. Per a cada mètrica d’ingressos de cada dashboard executiu, deixeu per escrit tres coses: la definició, el sistema d’origen i l’única persona amb nom i cognoms que en respon. Poseu aquestes tres línies a la descripció de l’informe.

Així, quan es discuteix un número, hi ha una persona a qui preguntar i una definició per comprovar, en lloc de quatre equips defensant cadascun el seu gràfic.

L’ordre en què cal arreglar les coses

Si les arregleu en l’ordre equivocat, reconstruireu dues vegades. La seqüència que aguanta:

1. Primer, definicions i amos. Gratis, ràpid, i tota la resta en depèn.
2. Segon, la jerarquia d’identitat. No s’haurien d’escriure ingressos en un registre fins que pugueu confiar en quin registre és.
3. Tercer, propietats numèriques. Convertiu el text a Number o Currency, a l’objecte correcte, amb l’ID de registre com a clau.
4. Quart, ingressos a nivell d’empresa. Porteu la veritat del client a la Company.
5. Els snapshots, al final. No té sentit congelar números que encara no heu corregit.

Després afegiu la peça poc glamurosa que ho manté funcionant: una comprovació automàtica setmanal que compara una mostra d’ingressos de HubSpot amb facturació i marca per a revisió manual qualsevol variació per sobre del vostre llindar. Marcar, mai forçar una fusió. Una sobreescriptura insegura d’una xifra d’ingressos és pitjor que una coincidència perduda, perquè la coincidència perduda es veu i la sobreescriptura és silenciosa.

El que us costa saltar-vos-ho

No m’inventaré una xifra per a la vostra empresa, perquè depèn de la mida dels vostres deals i del vostre volum. Però la podeu calcular vosaltres mateixos en una tarda.

Agafeu la variació entre el closed-won de HubSpot i els ingressos facturats dels últims quatre trimestres. Multipliqueu-la per les hores que la vostra gent de finances i RevOps dedica cada trimestre a quadrar-la a mà. Sumeu-hi l’ error de forecast que surt d’un informe de pipeline que suma el camp equivocat. Sumeu-hi les disputes de comissions. Aquesta és la factura recurrent que ja esteu pagant pel privilegi de no arreglar el model.

I hi ha un cost més silenciós. Quan la direcció no es refia del número d’ingressos, deixa de fer servir el CRM per prendre decisions. Demana fulls de càlcul. Els fulls de càlcul es converteixen en el sistema real, i el vostre car CRM passa a ser un lloc on els reps registren activitat. Aquest és el punt en què RevOps deixa de ser una funció i es converteix en un help desk.

La qüestió de l’arquitectura

Fixeu-vos que res d’aquesta auditoria no anava d’una eina. Podríeu fer-ho tot a HubSpot amb propietats i workflows nadius, i l’stack que l’envolta (Stripe, Clay per portar les dades, una base de dades per als snapshots) és intercanviable. Amb l’arquitectura correcta, l’eina és un detall. Amb l’arquitectura equivocada, cap eina no ho salva.

Un CRM no pot reportar ingressos que mai no es va dissenyar per contenir. Dissenyeu-lo per contenir ingressos, doneu a cada número un amo, congeleu l’històric, i la pregunta del dashboard deixa de ser una discussió.

Per on continuar

Si heu fet les cinc comprovacions i n’heu fallat dues o més, no necessiteu un dashboard millor. Necessiteu corregir el model de dades que hi ha a sota, en l’ordre d’abans.

Aquesta és la feina del nostre mòdul de Dashboards and Reporting, que es recolza en el mòdul de CRM Foundation and Data Architecture. Comencem amb l’auditoria de 30 minuts, us lliurem un pla d’arranjaments prioritzat i ancorat en dòlars, i després el construïm. Si preferiu veure primer on sou, el GTM Maturity and Revenue Leak Assessment us dirà si el reporting d’ingressos és la vostra fuita més gran o només la que fa més soroll.