Reconstruir el CRM de Nextmol en un sistema que qualifica sense dependre de la memòria d’una persona

L’organització

Nextmol ven química computacional a equips de R+D de la indústria química, com a servei i com a plataforma de programari. Els projectes són llargs i tècnics. Passen uns dotze mesos des del primer contacte fins a la signatura, i cada proposta l’escriu des de zero el director científic de l’empresa. L’equip comercial és petit i el CEO porta la majoria de les relacions.

La situació

Les eines s’havien anat afegint a mesura que calien, mai no es van dissenyar com un sistema. HubSpot guardava l’historial de la feina, però es consultava en lloc de fer-se servir per operar, i el registre de qualsevol deal estava repartit en cinc llocs: el CRM, la plataforma de reunions, el repositori de documents, un full de càlcul personal i una agenda de paper. Només el CEO podia reconstruir en quin punt era cada cosa.

El problema real

L’encàrrec obvi era una neteja del CRM. Aquesta mai no va ser la part difícil.

El pipeline s’havia construït per registrar el que ja havia passat, no per decidir què passava després. S’obrien deals sobre prospectes que mai no havien tingut una conversa comercial, així que el nombre de deals, la taxa de tancament i l’antiguitat dels deals mesuraven cadascun una cosa diferent del que deien mesurar.

Què estava trencat

Dos pipelines per a un sol procés de venda. L’embut estava dividit segons com s’havia de lliurar la feina, tot i que la venda era idèntica en tots dos casos. El reporting es dividia amb ell.

Leads i oportunitats al mateix lloc. S’obrien deals sobre prospectes que mai no havien tingut una conversa comercial.

Res amb què fer forecast ni atribució. La majoria dels deals no tenien valor, i la majoria dels contactes no tenien registre d’on venien. Res no avisava d’un deal que s’havia quedat en silenci.

Les decisions d’arquitectura

Un sol pipeline, amb el model de lliurament com a propietat. Els dos pipelines registraven com es faria la feina, no com es venia. Convertir això en un camp mantenia la distinció sense fragmentar el forecast.

Un objecte a part per a tot el que encara no és una oportunitat. Un deal es crea en un únic moment: qualificació superada, primera reunió feta, encaix de capacitats confirmat. Tot el que és anterior, i tot el que s’ha refredat, viu en un pipeline de leads. Aquesta regla és el que fa llegibles la taxa de tancament i l’antiguitat dels deals.

Scoring sobre el lead, perquè la qualificació es pugui traspassar. Havia viscut sencera en el criteri d’una persona, així que no es podia ensenyar ni delegar. L’encaix de l’empresa i l’engagement puntuen per separat en lloc de barrejar-se: un compte equivocat i en silenci i un compte correcte i en silenci necessiten accions oposades. Un tercer score ordena els deals oberts, perquè la redacció de propostes faci cua segons l’evidència.

Automatització que vigila el silenci. Res en el sistema anterior no podia dir quins deals s’havien quedat en silenci. Un deal o un lead sense activitat durant quaranta-cinc dies ara genera una tasca i una alerta per al seu propietari, i el llindar és en un sol lloc per poder ajustar-lo a mesura que s’acumula historial.

Què vam construir

Un pipeline de sis etapes amb criteris d’entrada a cada etapa i camps obligatoris que controlen l’avanç. Un pipeline de leads, onze propietats de deal, una taxonomia de nou canals connectada a cada formulari web. Dotze workflows que cobreixen cicle de vida, atribució, creació de tasques i detecció d’estancament. Tres scores i dos dashboards.

Com es va fer la feina

Primer van venir dues auditories, una de la configuració de HubSpot i una altra de com ven realment l’equip, totes dues lliurades al juny amb cada xifra mesurada al portal en lloc d’estimada. L’arquitectura es va proposar i aprovar abans de tocar res en producció. La base es va muntar a finals de juliol, construïda en paral·lel als pipelines existents per no alterar res del que estava en ús.

La migració es va fer a l’agost contra un mapa aprovat, deal per deal, amb els registres d’etapes inicials enviats al nou pipeline de leads en lloc d’esborrats. La documentació es va escriure a mesura que es construïa el sistema i després es va revisar línia per línia contra el portal en viu abans del lliurament. Aquesta revisió és el que va detectar un conjunt d’afirmacions que ja no coincidien amb el que s’havia construït, i les va corregir abans que el client les llegís, no després.

Què va canviar

El pipeline obert conté només oportunitats vives, i res no es queda en silenci sense que algú se n’assabenti. La qualificació funciona amb un model i no amb la memòria d’una persona: cada compte porta un score d’encaix i un altre d’engagement, i els deals oberts porten un score de prioritat que ordena la cua de propostes. El que el model no pot aportar és la part que només coneix l’equip, i la construcció va deixar establert exactament quins camps són aquests.

Per què importa

En aquest cas no hi ha mètriques de campanya. El sistema es va posar en marxa en les últimes setmanes del projecte, i el més honest és reconèixer que els números que ho demostrarien encara no existeixen.

El que existeix és un sistema comercial amb les seves regles per escrit. Un deal significa una sola cosa. La qualificació que vivia al cap d’una persona ara té un model al darrere. Res no es queda en silenci sense que algú se n’assabenti. Aquestes són les condicions en què val la pena mesurar mètriques, i cap no es complia abans.

Per a qui és això

Empreses on el CRM guarda l’historial però no sap dir què és viu. On el pipeline s’ha convertit en una llista de tothom amb qui algú va parlar alguna vegada, així que ningú no es refia del forecast. On la qualificació funciona perquè una persona la té al cap, i tothom sap que és un risc però ningú no ha tingut un trimestre per arreglar-ho.

El problema poques vegades és l’eina. És que ningú no va decidir mai per a què serveix el pipeline.