Cas d’estudi de PHI
La majoria de les neteges de CRM són una cosa puntual. Algú exporta la base de dades, hi treballa unes setmanes i torna una versió més neta del mateix sistema que va crear el desordre.
Sis mesos després, els duplicats han tornat.
PHI havia arribat a un altre punt. Després de 6 anys de creixement, la seva instància de HubSpot tenia més de 45.000 registres, i el risc s’havia invertit. Netejar les dades a mà ja tenia més inconvenients que deixar-les com estaven, perquè una fusió equivocada destrueix un historial de deals que no es pot recuperar.
No fer res semblava més segur que fer canvis. Aquest és el veritable estat de fallada d’un CRM, i no és un problema de dades. És un problema d’arquitectura.
PHI és una agència d’estratègia digital i creixement amb seu a Espanya, que treballa amb equips d’Europa i LATAM. La seva feina abasta estratègia digital, màrqueting de performance, CRM i automatització, i execució de marca.
A mesura que el seu servei es tornava més integrat i orientat a resultats, el seu propi CRM va deixar de ser una base de dades i va passar a ser la columna vertebral del màrqueting, les vendes i la presa de decisions.
El sistema mai es va dissenyar per a aquest paper.
Hi havia dos problemes, l’un a sobre de l’altre, i calia resoldre’ls en aquest ordre.
Les dades no eren fiables. Els mateixos contactes existien diverses vegades amb emails, càrrecs o noms d’empresa diferents. Les empreses apareixien amb múltiples variants. Les associacions entre contactes, empreses, deals i historial d’activitat estaven trencades o incompletes. La segmentació no era fiable i els informes donaven xifres diferents segons la vista que obrissis.
Les dades no aportaven cap senyal per decidir. Fins i tot quan un registre estava net, tenia un nom, un email i res més. Sense criteris d’encaix, sense intenció, sense prioritat. Tothom semblava igual al CRM, així que la priorització funcionava per intuïció.
Netejar les dades era necessari. No era suficient. Un CRM net sense lògica de decisió és una versió més endreçada de les mateixes conjectures.
Sense enrichment, scoring i una priorització clara, el CRM no podia sostenir outbound ni automatització. Escalar l’activitat a sobre hauria amplificat el soroll, no els resultats.
Vam construir a Clay un sistema automatitzat de deduplicació de contactes i empreses, executat a través de l’API de HubSpot.
Els duplicats s’identificaven amb matching per nivells, de les senyals d’alta confiança a les de menys confiança.
Per a contactes: coincidències exactes d’email, després combinacions de nom i domini, després nom més empresa més telèfon.
Per a empreses: matching per domini i domini arrel, després normalització i comparació del nom d’empresa.
Només els nivells d’alta confiança es fusionaven automàticament. Tot el que quedava per sota d’aquest llindar es marcava per a revisió humana en lloc d’endevinar-ho.
El que va fer usable el sistema és el que passa abans de la fusió. Primer es fa còpia de seguretat de cada associació crítica, incloent-hi deals, notes, reunions i relacions amb empreses. Un workflow complet de restauració permet a PHI revertir una fusió incorrecta, recrear el contacte i tornar a associar-ne l’historial automàticament.
Res al sistema és irreversible. Això és el que el va fer segur per executar-lo sobre un CRM en producció del qual depèn el negoci.
Al final de la Fase 1, PHI podia netejar i deduplicar tot el seu CRM en menys d’una hora, sense risc manual i sense suport de desenvolupadors.
- Totalment automatitzat : els casos límit es treuen a revisió manual - Reversible per disseny : restauració completa si una fusió surt malament - Segur de tornar a executar en qualsevol moment : a mesura que entren dades noves al CRM - En mans de l’equip intern : l’opera l’equip de PHI, no una agència
Amb la base estable, l’objectiu va canviar. El CRM havia de deixar d’emmagatzemar informació i començar a dirigir l’acció comercial.
Vam construir un sistema automatitzat que enriqueix contactes i empreses, els avalua respecte a l’ICP de PHI i assigna prioritat segons encaix i intenció.
El model de scoring reflecteix els criteris reals de PHI, no un sistema de punts genèric. L’encaix d’empresa, l’activitat recent, la lifecycle stage i el context comercial es combinen en un únic resultat interpretable, i els contactes s’etiqueten com a Hot, Warm o Cold directament dins de HubSpot.
Ara el CRM respon una pregunta de manera consistent: amb qui hauríem de parlar a continuació, i per què.
Ara tenim una base de dades molt més sana, amb un sistema de scoring personalitzat i una capacitat real de prioritzar leads amb criteris reals.
Guillermo Peláez, Senior AE & Marketing Manager a PHI
Els resultats del sistema són mesurables: un CRM deduplicat, dades de contactes i empreses enriquides i validades, scoring d’encaix i intenció documentat, workflows a punt per automatitzar.
L’impacte en l’equip és més difícil de quantificar i pesa més. Menys temps qüestionant les dades. Priorització més ràpida. Workflows que es poden automatitzar sense por de trencar res més endavant. Una definició compartida del que és realment un bon lead.
El projecte va tractar els problemes de dades com a problemes de disseny de sistemes, no com una llista pendent de tasques de neteja.
La majoria dels CRM fallen no per l’eina, sinó perquè no hi ha una lògica explícita de com cal confiar en les dades, enriquir-les i fer-les servir. El sistema de PHI funciona perquè les dades es validen abans de fer-les servir, el scoring reflecteix el context real del negoci i les decisions estan codificades al CRM en lloc de viure en el criteri d’algú.
Ara tenen un CRM que escala amb el creixement en lloc de trencar-se a sota seu, la capacitat d’afegir-hi a sobre outbound, atribució i enrutament amb confiança, i la propietat total de la infraestructura.
Això no va ser un projecte de neteja. Va ser la instal·lació d’un sistema de dades preparat per generar ingressos.
Empreses on el CRM fa prou temps que funciona com per acumular el dany.
On no us podeu fiar de la segmentació, els informes donen xifres diferents segons la vista i ningú vol tocar la base de dades perquè el risc de trencar alguna cosa és real.
Si el vostre equip ha decidit que no fer res és més segur que fer canvis, el problema ja no són les dades. És que no hi ha una manera segura d’operar-hi.
30 minuts. Mapem on perd ingressos el vostre sistema i què cal arreglar primer. Marxeu amb la resposta, tant si treballeu amb nosaltres com si no.
Demanar una trucada estratègicaUna auditoria de 20 minuts, dues plantilles de treball i un capítol de The Architecture Behind Growth.
També rebràs The RevOps Build, una build pràctica per número. Et dones de baixa en un clic.
La guia va de camí. Si no arriba en un parell de minuts, mira a la pestanya de promocions.