El vostre forecast no està malament. Les vostres etapes de deal sí.

El pipeline fantasma és la fuga a la qual ningú no posa preu

Quan fem una auditoria de GTM, les mateixes cinc fugues d’ingressos apareixen en gairebé tots els equips que facturen entre 1 milió i 30 milions d’ARR. La fuga número quatre és la gestió del CRM i del pipeline: conjunts de propietats inflats, etapes incoherents, deals encallats i pipeline fantasma comptat en el número del consell.

La fuga quatre és la que més discuteixen els clients, perquè no sembla una fuga. No hi ha res trencat. Els informes carreguen. Els dashboards es mostren. Els deals existeixen. El sistema es comporta exactament com es va construir.

Això és el que la fa cara. Un deal mort no llança cap error. Es queda a Demo Complete, conserva el seu import, conserva la seva data de tancament i es compta en silenci cada vegada que algú suma el pipeline. Als proveïdors els agrada citar quina part del pipeline és morta, i les xifres suren entre una cinquena i una tercera part segons quin benchmark trieu. Jo no construiria un pla sobre cap d’elles. La resposta honesta és que en la majoria de portals aquest número simplement no es mesura, que és pitjor posició que una mala estimació.

Feu millor el compte en el vostre propi portal. Agafeu el vostre pipeline obert. Suposeu que una quarta part no es tancarà mai i no s’havia de tancar mai. Si el vostre número del consell és 4 milions, esteu fixant quotes, plantilla i plans de caixa contra 1 milió de ficció. Ningú no ha mentit. El sistema simplement no tenia manera de dir que no.

I es multiplica en tres direccions. Les ràtios de cobertura s’inflen, així que la direcció inverteix de menys en pipeline nou just quan cal. Les mitjanes de temps en etapa i de velocitat queden arrossegades per deals que van deixar de moure’s al març, així que cada benchmark d’etapa que reporteu és una barreja de deals vius i cadàvers. I el win rate es torna il·legible, perquè el denominador és ple d’oportunitats que no van ser mai oportunitats.

Si un rep pot canviar el vostre número del consell editant un camp, no és un número del consell. I si un rep el pot inflar per no editar un camp, tampoc no ho és.

Què és de debò un deal estancat

La majoria d’equips no sap respondre aquesta pregunta en una frase, i aquesta és la veritable causa de fons. «Estancat» no és una regla. És una sensació que té un cap de vendes un divendres.

Aquesta és la definició que escrivim al model de dades. Un deal està estancat quan es compleixen almenys dues d’aquestes condicions:

1. Sense activitat bidireccional a la finestra. Ni un enviament registrat, ni una tasca que el rep es va crear per a si mateix. Un intercanvi real, iniciat o respost pel comprador. El nostre llindar per defecte per considerar fred un contacte és de 90 dies sense activitat bidireccional, i per als deals en un cicle actiu l’ajustem, normalment a entre 21 i 30 dies segons la durada del cicle.
2. L’antiguitat a l’etapa supera el benchmark de l’etapa. No l’antiguitat del deal. L’antiguitat a l’etapa. Un deal que porta a Proposal Sent quatre vegades la mediana de temps que qualsevol deal passa a Proposal Sent us està dient una cosa que un filtre d’antiguitat total no pot.
3. La data de tancament s’ha ajornat més de dues vegades. Un ajornament és cosa del comprador. Tres ajornaments són un rep protegint un número.
4. No es van complir mai els criteris de sortida de l’etapa. El deal és a Negotiation i no hi ha comprador econòmic identificat, ni preu enviat, ni següent pas agendat. Es va moure per optimisme.

Fixeu-vos en el que no és a la llista: la sensació del rep. «Diu que encara és viu» no és una prova, i «commit» no és una etapa. Si la càrrega de la prova recau en el sistema, un deal s’hi queda fins que es guanya el lloc. Si la càrrega de la prova recau en el rep per demostrar que és mort, el deal s’hi queda per sempre.

Escriviu-ho com una sola frase amb un responsable i un llindar, igual que escrivim les regles de supressió per a outbound. «Deals estancats» no és una regla. «Sense activitat bidireccional del comprador en 30 dies, més antiguitat a l’etapa superior a 2x la mediana de l’etapa, responsabilitat de Vendes, revisat cada setmana, amb salvaguarda davant qualsevol resposta entrant» sí que és una regla.

Tres errors de disseny que creen deals estancats

Les etapes descriuen el vostre procés, no el del comprador

El més habitual i el menys evident. Les etapes es construeixen a partir d’un document d’especificacions en lloc d’una sessió de treball amb la persona que de debò porta el procés de principi a fi.

Ens va passar a la migració de Tech Barcelona. Les etapes del pipeline de visites a HubSpot no coincidien amb com portava realment una visita la persona responsable de les visites. La causa de fons va quedar escrita al tiquet de correcció en llenguatge planer: les etapes s’havien construït de manera genèrica a partir de l’especificació original de mapatge de propietats, sense una sessió dedicada amb la responsable del procés per confirmar el seu pas a pas real. La solució no va ser automatitzar. La solució va ser reconstruir el pipeline amb les quatre etapes que ella fa servir de debò, confirmades contra una segona font abans que ningú toqués HubSpot.

Un detall d’aquella correcció val la pena copiar-lo: l’historial d’etapes no es pot omplir cap enrere. Si reconstruïu les etapes, tot el que hi havia abans de la reconstrucció desapareix com a sèrie temporal. Així que equivocar-se amb les etapes no només costa el desordre d’avui, costa la pèrdua permanent de l’historial que necessitaríeu per mesurar la correcció. Construïu les etapes abans de construir els informes.

Les etapes tenen criteris d’entrada i cap criteri de sortida

Gairebé tots els portals que auditem tenen alguna idea de què fa entrar un deal en una etapa. Gairebé cap no té una condició escrita de què el treu, a part de guanyar-lo.

Governar el lifecycle es redueix a cinc regles, i els criteris de sortida són la que tothom se salta: criteris d’entrada, criteris de sortida, lògica de reinici, regles de propietat i automatització. Els criteris de sortida són la regla que diu que un registre surt d’una etapa perquè es desqualifica, es converteix o es perd. Sense ella teniu zombis per construcció, a cada etapa, per sempre.

Els senyals són sempre els mateixos. MQLs sense següent pas. Deals aturats a Demo Complete durant mesos. Un informe de win rate que marca més del 100 per cent perquè closed-lost no es va fer servir mai bé. Contactes duplicats amb lifecycle stages diferents. Si veieu això, el vostre lifecycle no està governat, està endevinat.

Els mateixos valors de les etapes estan trencats per dins

Aquest és invisible des de la interfície, i és la raó per la qual no em fio d’un informe de pipeline fins que n’he mirat els valors interns.

En un projecte amb HeyReach, el pipeline de Tier 2 tenia una etapa Closed Won amb el valor intern equivocat. No l’etiqueta equivocada, el valor intern equivocat, que és el que de debò llegeixen els informes i l’automatització. Arreglar-ho va suposar crear l’etapa correcta, migrar-hi els deals i esborrar l’antiga, i va bloquejar tot el que venia darrere: 3,917 deals migrats amb historial des del 2023 no es podien segmentar per als informes històrics d’ingressos fins que l’etapa mateixa no fos correcta.

Aquesta és la forma d’aquest tipus de bug. El gràfic es continua mostrant. Simplement el número està malament, i fa anys que ho està. El mateix mode de fallada que guardar els ingressos en una propietat de text d’una sola línia: HubSpot us ofereix COUNT en lloc de SUM i el dashboard sembla que estigui bé.

La construcció: set passos, en aquest ordre

L’ordre importa més que qualsevol pas concret. Salteu-vos el pas u i la resta és automatització sobre un procés sense definir, que és com s’acaba amb un workflow que tanca deals vius.

1. Escriviu criteris de sortida per a cada etapa, amb la persona que porta el procés

De cinc a set etapes, no més. Per a cadascuna, escriviu dues coses: què ha de ser cert perquè un deal hi entri i què ha de ser cert perquè en surti. Per sortir hi ha tres portes, no una: guanyat, perdut o desqualificat. Desqualificat no és perdut, i ajuntar-los destrueix la vostra capacitat de distingir un problema de preu d’un problema de targeting.

Feu-ho en una sala amb la persona responsable del procés i exigiu una segona font. A Tech Barcelona, el conjunt d’etapes acordat només va quedar tancat en creuar la resposta de la responsable del procés amb un tracker independent de l’estat dels contractes. Dues fonts que coincideixen són un fet. El record d’una persona és una hipòtesi.

2. Instrumenteu els rellotges abans d’automatitzar res

No podeu ramificar sobre una activitat que no heu derivat. Construïu primer les propietats i després escriviu la lògica contra les propietats. Mai contra l’activitat en brut.

El conjunt mínim al deal:

• last_buyer_activity_date, que només s’omple amb interacció bidireccional, perquè un rep que envia un cinquè seguiment no reiniciï el rellotge
• date_entered_current_stage, i un days_in_current_stage derivat
• close_date_push_count, que incrementa un workflow que es dispara quan s’actualitza la data de tancament (HubSpot no té un comptador natiu per a això, i els fils de la comunitat que el demanen vénen de fa anys)
• stale_flag i stale_reason, escrits per la lògica de detecció, mai per una persona

Això replica el rastre d’auditoria que considerem innegociable en els canvis de propietari: owner_assigned_date, owner_assignment_reason, previous_owner. El principi es trasllada tal qual. Tres propietats converteixen un deal estancat d’una opinió en un informe.

3. Detecteu amb una vista en directe, no amb un CSV

Materialitzeu el conjunt de deals estancats com una vista desada de HubSpot amb filtres reals, no com una exportació mensual que algú neteja a mà. Un CSV estàtic és una foto d’un problema. Una vista és un sistema.

Comenceu amb aquestes vistes i poseu-les davant dels managers, no en una carpeta:

• Encallats 30 dies o més a l’etapa
• Sense activitat bidireccional del comprador en 21 dies
• Data de tancament ajornada 3 vegades o més
• Data de tancament en el passat, deal encara obert
• Deal obert, sense tasca de següent pas, sense reunió agendada

La quarta, tota sola, sol trobar una quantitat sorprenent de pipeline. Un deal amb una data de tancament de fa tres mesos no és una previsió, és un rebut.

4. Primer la salvaguarda, sempre

Aquest és el pas que tothom se salta, i saltar-se’l és com acabeu traient el propietari d’una oportunitat viva o tancant automàticament un deal el dia abans de la signatura.

La branca de salvaguarda va la primera al llenç del workflow, abans que s’executi cap lògica de detecció. Qualsevol senyal real del comprador congela el deal: una resposta, una reunió agendada, una proposta vista, una prova iniciada, una factura emesa. El senyal guanya qualsevol rellotge.

Aquí hi ha una restricció dura que ve del nostre propi protocol de neteja de CRM. Les nostres exclusions de no tocar durant qualsevol feina d’higiene són els clients actius, els deals oberts i tot el que està vinculat a ingressos. Els deals oberts són en aquesta llista expressament. Així que un sistema que actua sobre deals oberts s’ha de guanyar l’excepció, i se la guanya no tancant mai res de manera automàtica. Cosa que ens porta al pas cinc.

5. Marqueu per a revisió, no tanqueu automàticament

L’automatització marca. Les persones tanquen. No és timidesa, és la mateixa regla que apliquem a la deduplicació: marcar per a revisió els registres sense coincidència en lloc de forçar la fusió, perquè una fusió insegura que sobreescriu les dades del primer toc és pitjor que una coincidència perduda. Un deal viu tancat automàticament és pitjor que un d’estancat que s’hi va quedar una setmana de més.

La mecànica que funciona: la marca crea una tasca per al propietari del deal amb un termini de 5 dies laborables i una notificació al manager. El rep fa una de tres coses. Aporta proves i el deal s’hi queda, amb les proves registrades. El passa a un estat de nurture o de reciclatge. O el tanca amb un motiu.

Després, etiqueteu, no esborreu. Un deal closed-lost amb motiu i caducitat és un actiu. Fixeu la caducitat igual que fixem les caducitats de supressió, per exemple un closed-lost dels darrers 180 dies queda exclòs de la prospecció i després torna a estar en joc automàticament. Esborrar el registre només vol dir que torna el trimestre següent per una altra via i sense memòria.

6. Feu snapshots del pipeline perquè l’historial deixi de moure’s

Un CRM sobreescriu l’historial per defecte. Editeu un registre avui i canvia el número del trimestre passat, cosa que vol dir que el vostre historial de pipeline no és un registre, és una representació de l’estat actual.

Feu snapshots del pipeline datats i immutables al tancament de cada trimestre, i deseu-los en propietats en lloc de confiar que un informe els reconstrueixi. És la mateixa raó per la qual desem Initial MRR i Matured MRR com a propietats separades en lloc d’un únic camp que va canviant. Sense snapshots podeu netejar el pipeline i després no ser capaços de demostrar que la neteja va funcionar, perquè la línia de base es va moure amb vosaltres.

7. Reporteu el número d’estancats cada setmana, per motiu

Un número al mateix dashboard on viu l’informe de rendiment dels reps: deals oberts marcats com a estancats, en nombre i en import, desglossats per motiu.

Aquest desglossament és un diagnòstic, no un marcador. Si domina «sense activitat del comprador», teniu un problema de seguiment i d’encaminament. Si domina «antiguitat a l’etapa» en una etapa concreta, aquesta etapa no té criteris de sortida o s’han fusionat dues etapes en una. Si domina «data de tancament ajornada», els vostres reps estan gestionant una conversa de previsió, no un deal. I si el total no para de pujar, la detecció funciona i la desqualificació no.

Després, congeleu les etiquetes de motiu. Un cop definit, no redefiniu mai un motiu; afegiu-ne de nous amb etiquetes noves. Si redefiniu una etiqueta, perdeu la comparabilitat setmana a setmana, que és l’única cosa que fa que valgui la pena llegir l’informe.

L’auditoria de pipeline de 20 minuts que podeu fer avui

Cinc comprovacions. Les podeu fer en una trucada de descoberta, i jo les faig.

1. Demaneu a dos reps que defineixin per separat els criteris de sortida de la mateixa etapa. Respostes diferents volen dir que l’etapa no existeix com a concepte, només com a valor d’un desplegable.
2. Filtreu els deals oberts amb data de tancament en el passat. Qualsevol xifra per sobre d’un grapat vol dir que ningú no és responsable de la higiene de la previsió.
3. Comproveu els valors interns que hi ha darrere de les vostres etapes Closed Won i Closed Lost, no les etiquetes. Verifiqueu-los contra el que de debò llegeixen els vostres informes.
4. Ordeneu els deals oberts per dies a l’etapa actual, de més a menys, i mireu els vint primers. Pregunteu què hauria de ser cert perquè cadascun es tanqués aquest trimestre.
5. Demaneu l’snapshot del pipeline del trimestre passat. Si ningú no en pot presentar un que no hagi canviat des de llavors, no teniu línia de base ni manera de mesurar cap correcció.

Si en falleu dues o més, el problema és el vostre model de dades, no la vostra capa de reporting. Si en falleu quatre, deixeu de construir dashboards fins que les etapes estiguin reconstruïdes, perquè només estareu mostrant la mateixa ficció més de pressa.

On es trenca això

Dues advertències honestes, perquè prefereixo que ho instal·leu bé abans que amb entusiasme.

Els llindars depenen del cicle. Una regla de 21 dies d’inactivitat és correcta per a un cicle de venda de 45 dies i directament perjudicial en una motion enterprise amb un cicle de 9 mesos i llargues aturades de compres. Compareu els llindars amb el vostre propi historial de closed-won abans de fixar-los. No copieu els meus.

I cada vegada que despleguem una cosa així, trobem casos límit els dies següents. Renovacions que estan inactives amb tota legitimitat. Deals en pausa pel calendari fiscal del comprador. Contractes plurianuals on la següent activitat real és a onze mesos vista. Executeu la detecció en mode només marcar durant un cicle complet abans d’associar-hi cap conseqüència, i poseu-ho tot dins d’una revisió de salut setmanal, perquè un workflow que va deixar d’executar-se en silenci sembla idèntic a un que funciona.

La part que no és un problema de HubSpot

Res d’això no va realment de HubSpot. Va de si el vostre pipeline és un model de com es compra a la vostra empresa o un conjunt de valors de desplegable que algú va escriure una vegada. Amb l’ arquitectura correcta, l’eina és un detall. Amb l’arquitectura equivocada, cap eina no ho salva.

Un deal estancat no és un mal registre. És una previsió que ja vau presentar al vostre consell.

Si voleu saber quina part del vostre pipeline és ficció abans de la propera reunió del consell, el nostre GTM Maturity and Revenue Leak Assessment és un diagnòstic de 30 minuts sobre cinc àrees, i us dona un nivell de maduresa, les vostres tres principals fugues d’ingressos en dòlars i el mòdul que arregla la més gran. El pipeline sol ser la fuga número quatre, i sol ser la més barata d’arreglar.

Si ja sabeu que el problema són les etapes, aquesta feina forma part del nostre Revenue Machine Analysis, on l’arquitectura del lifecycle, les definicions d’etapa, els criteris de sortida i els dashboards que els llegeixen es dissenyen com un sol sistema en lloc de com cinc tiquets.