Empreses matriu i filial a HubSpot i arquitectura de comptes multientitat

El que HubSpot us dona de debò

Val la pena ser precisos, perquè gairebé tota la confusió ve de gent que espera un model de dades i rep un camp.

Una empresa filial pot tenir exactament una matriu. Això serveix per a una estructura de holding neta i falla quan teniu una seu que ven a dues divisions, o un distribuïdor que és alhora client i canal. Les accions natives de workflow sobre matriu i filial són escasses, així que qualsevol herència que vulgueu (propietari, territori, tier, SLA) s’ha de construir a propòsit. No baixa sola per la jerarquia.

I els reps llegeixen el registre matriu com «tot el d’aquest grup». No mostra gairebé res si no construïu l’agregació. Així que la jerarquia es vincula, el registre matriu es queda buit, la confiança mor i tothom torna a preguntar a Slack.

Després hi ha les dues mecàniques que creen l’embolic en silenci des del principi.

El domini és l’identificador únic de les empreses en importar. L’email per als contactes, el domini per a les empreses. La importació fusiona o sobreescriu quan hi ha coincidència en lloc de crear tots dos. Això vol dir que quan importeu una llista de seus que comparteixen un domini corporatiu, HubSpot les col·lapsa en un sol registre d’empresa i ningú no rep cap error. Les vostres tres plantes en tres països s’han convertit en una fila, i l’única prova és un recompte de deals que sembla lleugerament estrany.

La creació i associació automàtica d’empreses s’inventa registres a partir dels dominis d’email. HubSpot llegeix el domini de l’email d’un contacte, fabrica una empresa i l’associa. Aquest interruptor hauria d’estar apagat en gairebé tots els portals que toquem. Hem vist com una integració de formularis d’anuncis el tornava a encendre i omplia un portal de centenars d’empreses duplicades en poques setmanes. Netejar amb l’aixeta oberta és teatre.

Tres problemes que semblen un

«Tenim empreses duplicades» són tres problemes diferents amb el mateix abric, i la solució d’un farà mal als altres dos.

La mateixa entitat, dues vegades. Una entitat legal, dos registres, el mateix domini normalitzat. És un problema de coincidència. Fusioneu-la.

Entitats diferents, un domini. Acme Iberia i Acme France viuen totes dues a acme.com. Dues entitats legals, dos clients a l’ERP, potser dues monedes, un domini. És un problema de modelatge. Fusioneu-les i haureu destruït informació comercial real que algú necessitarà a la renovació.

La mateixa entitat, dominis diferents. Acme Group SL a acmegroup.es i l’empresa operativa a acme.com. És un problema de resolució, i és el que us castiga per endevinar. No fem mai coincidir per nom d’empresa justament per això: la coincidència difusa per nom suprimeix Acme i envia emails a Acme Group SL, així que les coincidències per nom es marquen per a revisió en lloc de fusionar-se automàticament.

En el marc de fuites d’ingressos que fem servir a les auditories, això cau de ple a la Fuita #2, qualitat de dades i enrichment, i aflora com la Fuita #4, un CRM inflat amb un pipeline del qual ningú no es refia. És un problema de prevenció, no de neteja.

Decidiu què és un registre d’empresa

Quatre preguntes, respostes per escrit, abans que ningú vinculi una matriu.

Un registre és una entitat legal, una seu o una unitat de compra? Trieu-ne una i mantingueu-la. Els comptes industrials i multiseu gairebé sempre volen la seu com a registre, perquè és on viuen el territori, l’SLA de servei i l’adreça d’enviament. Els comptes de software solen voler l’entitat legal, perquè és on viu el contracte.

Quina és la clau d’unió? Escriviu la jerarquia d’identitat com una llista ordenada, no com a folklore. La nostra sol quedar així: ID de client de facturació o de l’ERP, després ID de tenant, després domini normalitzat, després nom. El nom sempre es marca per a revisió i mai no es fusiona automàticament. Si els ingressos no se sincronitzen, normalment no és perquè la integració s’hagi trencat. És perquè dos sistemes fan servir com a clau dues identitats diferents.

Quin registre és amo dels ingressos? Un deal és un esdeveniment. Una empresa és el client. Si els ingressos es reflecteixen al deal o al contacte en lloc de a l’empresa, les renovacions i les ampliacions es dispersen i cap registre no pot respondre «quant val aquest client».

Què s’agrega i què no? Els ingressos s’agreguen. La supressió s’agrega, perquè la relació és amb l’empresa i no amb la bústia. El propietari no s’agrega. El territori no s’agrega. L’SLA no s’agrega. En els projectes industrials això ho és tot: en el projecte d’operacions de servei d’Elesa+Ganter, la propietat va per zona i codi postal amb SLA i escalat a sobre, cosa que vol dir que el propietari viu al registre de la seu i el registre del grup no té cap motiu per sobreescriure’l.

Aquí és també on l’encaixada de mans per ID es guanya el sou. La producció i l’ERP es queden a la seva pròpia base de dades, units al CRM per IDs en lloc de duplicats a dins. El producte 85421 es va vendre al client 248. En un compte industrial, l’encaixada de mans és la major part de la feina. Vam escriure més sobre aquesta separació a Arquitectura de CRM: les vostres eines no són el problema.

Tanqueu l’aixeta i després construïu una única via de creació

L’ordre de la neteja importa més que la tècnica de neteja.

Apagueu l’autocreació nativa i confirmeu que continua apagada, revisant també el que la va encendre. Les integracions de formularis d’anuncis i els fluxos de reserva de calendari són reincidents, i la tornaran a activar quan hàgiu acabat.

Després busqueu els vostres orfes, perquè apagar l’autocreació obre un forat nou. En un projecte, la creació d’empreses només passava per la via d’outbound a Clay. Totes les altres vies d’entrada (reserves de reunions, formularis, creació manual) generaven contactes amb dominis d’empresa perfectament vàlids i cap empresa associada. La solució va ser un únic workflow que s’encarrega de l’associació d’empreses sigui quina sigui la via d’entrada: inscriure amb un domini d’empresa vàlid més un tipus de compte real més cap empresa associada, cercar el domini, associar a l’empresa canònica si existeix, crear-la si no existeix i deixar-la en revisió manual si el domini és genèric o compartit.

La part innegociable: sigui el que sigui que creï empreses ha de fer servir la mateixa normalització de dominis i la mateixa lògica de selecció d’empresa canònica que tota la resta. Si Clay normalitza els dominis d’una manera i el vostre workflow de HubSpot d’una altra, no teniu un model d’empreses. En teniu dos. Més sobre com mantenir-los alineats a Com sincronitzar Clay amb HubSpot sense destrossar el vostre CRM.

Fusioneu sense destruir la jerarquia

La nostra deduplicació d’empreses va per nivells, amb aturades dures, i s’executa després dels contactes.

Primer contactes, després empreses. Sempre. Passar una ronda d’empreses sobre contactes desalineats destrossa les associacions.

El nivell 1 és el domini normalitzat exacte i el nivell 2 és nom més arrel del domini, i aquests es fusionen automàticament. Els nivells 3 a 5 els valida la IA i els revisa una persona abans que s’escrigui res. Les escriptures continuen depenent d’un botó. Ningú no ho posa en execució automàtica.

Les aturades dures són la part interessant, perquè són justament les proteccions multientitat:

• No fusioneu mai entre dos dominis plens i diferents.
• Un desajust d’ID de facturació o de tenant és una aturada total. No es fusionen mai dos clients que paguen en un sol registre.
• Els conflictes de propietari es marquen i es resolen a propòsit, perquè una fusió mou una empresa d’un rep a un altre i reescriu l’atribució en silenci.
• Els registres ja marcats per esborrar no entren mai a la lògica de nivells.

Exporteu abans de fusionar. La taula de restauració és una xarxa de seguretat, no una garantia. Valideu el resultat amb una mostra del deu per cent.

Un detall operatiu que sorprèn: els grups de tres o més duplicats no es col·lapsen en una sola passada. La fusió gestiona un parell principal i secundari cada vegada, així que torneu a resoldre els IDs canònics contra el registre que sobreviu i l’executeu una altra vegada, i una altra, fins que el grup desapareix. Després passeu una ronda de col·lisions posterior a la fusió en aquest ordre: domini, nom estricte, nom flexible. Un duplicat residual després d’una passada vol dir que el grup era gran, no que alguna cosa s’hagi trencat.

I la regla permanent: marcar per a revisió abans que forçar la fusió. Una fusió insegura que sobreescriu les dades de primer contacte és pitjor que una coincidència perduda.

Construïu l’agregació o la jerarquia és decoració

El registre matriu respon «quant val aquest client» només si el feu respondre. Res no s’agrega sol.

Construïu propietats a nivell de grup a la matriu: ingressos totals del grup, pipeline obert de totes les filials, nombre d’entitats o seus i últim contacte rellevant en qualsevol punt del grup. Després informeu en els dos nivells a propòsit. Els informes de deals i de servei van al registre de la seu, on passa la feina. Els informes d’ingressos i renovacions van al registre del grup, on hi ha els diners.

Quan migreu els ingressos fora dels camps equivocats per fer això, amagueu les propietats antigues i demostreu la paritat dels informes contra l’exportació abans d’esborrar res. L’ordre de retirada és amagar, demostrar i després esborrar.

Com es veu quan està bé

Podeu respondre, sense obrir un full de càlcul: quant val aquest grup, a quantes entitats venem, qui és el propietari de cada seu i quin registre és l’únic client vertader. Les empreses noves entren per exactament una via amb un únic estàndard de normalització. Dues entitats en un domini continuen sent dos registres a propòsit, i hi ha un motiu escrit. I ningú del vostre equip no ha de preguntar a Slack si el registre d’Acme és el bo.

Si la resposta honesta és que no sabeu quants registres d’empresa teniu per al vostre compte més gran, això és una fuita amb un número associat, no un problema d’ordre. La nostra Auditoria de fuites d’ingressos la quantifica, i el mòdul de Fonaments de CRM i Arquitectura de dades és on reconstruïm el model de comptes com cal. Comenceu pel que us doni abans un número honest.