Arquitectura de CRM: el problema no són les eines

Què vol dir de debò «arquitectura»

Vam anomenar l’empresa Architects expressament. Les empreses no ens compren un CRM. Ens compren el disseny de com encaixen els seus sistemes. Aquest disseny es redueix a quatre preguntes:

1. Quins sistemes existeixen i per a què serveix de debò cadascun.
2. Com es connecten entre ells.
3. Quins passos hi ha dins de cada sistema, i en quin ordre.
4. Quines persones i equips intervenen a cada pas.

Responeu aquestes quatre amb honestedat i l’eina passa a ser un detall d’implementació. Equivoqueu-vos-hi i cap eina no us salva. Aquesta és la línia que ens separa dels partners de HubSpot, les agències de generació de leads i els integradors d’ERP. Ells venen una eina i hereten l’arquitectura que ja tinguéssiu. Nosaltres no estem casats amb cap eina: Clay, HubSpot, SAP, el que vingui després. Decideix l’arquitectura, no el proveïdor.

Imagineu l’empresa com un edifici

La manera més clara de veure la vostra pròpia operació és dibuixar-la com un edifici vist des de dalt i després fer-hi un tall. Quatre nivells.

Nivell 01, els equips

Màrqueting, vendes, customer success, producció, finances. Cadascun ocupa la seva pròpia planta i fa la seva pròpia feina.

Nivell menys 01, el canal humà

Slack, email, reunions, el passadís. Aquí és on les persones parlen entre elles. És real, és necessari i és on gairebé tothom creu que de debò funciona l’empresa.

Nivell 02, els sistemes

CRM, base de dades de producció, ticketing, facturació o ERP. Aquí és on les màquines parlen entre elles. Els registres es mouen aquí.

Nivell 03, el registre mestre

On existeix, una base de dades situada per sobre dels sistemes que guarda la versió oficial de la veritat. Els sistemes sincronitzen cap a ella i des d’ella, de manera que quan passa alguna cosa al món real cau en un sol lloc i es propaga a tots els altres.

I ara, el que importa. Els equips empenyen i estiren en vertical cap al seu propi sistema. Els sistemes parlen en horitzontal entre ells. Les persones parlen en horitzontal entre elles. Res no creua per si sol entre la capa humana i la capa de màquines.

Aquest buit és la fallada. Quan vendes i màrqueting s’han de coordinar, ho fan pel canal humà, que sembla comunicació i no deixa cap registre. Les màquines que tenen a sobre no s’assabenten mai que hagi passat res. Màrqueting llança una campanya, vendes no pot veure quins leads en van sortir i dos trimestres després ningú no pot fer un forecast perquè la prova del que va passar de debò va viure i morir en un fil de Slack. Dit clar: una conversa no és un registre.

L’error que mata el reporting sense fer soroll

Cada dashboard que voldreu depèn d’una sola cosa: es van escriure a la capa de màquines els esdeveniments que importen? Si no, esteu reconstruint la història de memòria, i la memòria no suma. Per això «fes-me un informe millor» és gairebé sempre la petició equivocada. La part difícil mai no és l’informe. Són les dades i la lògica que l’alimenten.

La fuita és diners de debò. Leads que mai no s’encaminen, deals que s’encallen perquè ningú no n’és el responsable, forecasts que fallen prou per tombar un pla de contractació. Tot CRM es degrada en silenci, i nosaltres quantifiquem aquesta degradació com a ingressos en risc cada mes. Gairebé mai no és una partida d’eines. És arquitectura, apareixent al compte de resultats.

Quin sistema serveix a quin equip

Una regla evita la major part del desordre: el CRM serveix només als equips comercials. Màrqueting, vendes, customer success. Guarda el que té a veure amb clients, i res més.

Producció no pertany al CRM i mai no s’hi ha de ficar a la força. Funciona amb la seva pròpia base de dades: matèries primeres en estoc, compres fetes, unitats enviades aquest mes. Aquestes dades no hi pinten res en un CRM perquè no tracten d’un client. Els dos sistemes s’uneixen per IDs, no per duplicació. El producte 85421 es va vendre al client 248. Aquesta encaixada de mans és la unió, i fer-la bé és la major part de la feina en qualsevol compte industrial.

Vam construir exactament això per a Elesa and Ganter, un fabricant industrial que treballa amb HubSpot al costat de SAP: encaminament de tickets i propietat per zona i codi postal, lògica de SLA i escalat, números de telèfon normalitzats a un únic estàndard i una escriptura de tornada neta cap a SAP perquè els dos sistemes es mantinguessin sincronitzats en lloc de barallar-se. El resultat no és «un CRM més bonic». Són dos sistemes que per fi estan d’acord sobre qui va comprar què.

La identitat és la base, no un ajust

Abans que es mogui cap registre, decidiu què és un registre i quin camp és la font de la veritat. En diem la jerarquia d’identitat, i en un compte SaaS sol anar Stripe, després Tenant, després Domain, després Name, en aquest ordre de confiança. Sona acadèmic fins que veieu una empresa intentar sumar els seus propis ingressos i descobrir tres coses alhora: un registration_email i un billing_email que apunten a dos «clients» diferents, un Tenant ID i un Stripe Customer ID que mai no es van reconciliar, i els ingressos dels deals desats com a text en lloc de números, així que no es poden sumar. Res d’això no són bugs de l’eina. Són decisions d’arquitectura que mai no es van prendre.

Per això cada projecte que fem té una barrera obligatòria anomenada Client Approval on Data Model abans de connectar cap workflow. Aproveu les regles d’identitat, els objectes i com es relacionen, en un diagrama de flux, en llenguatge planer, abans que toquem res. Saltar-se aquesta barrera és la manera d’aconseguir una construcció molt ràpida del que no tocava.

On encaixen de debò la IA i Clay

Els equips veuen Clay o un agent d’IA i donen per fet que és una arquitectura nova. No ho és. És un nou inquilí d’una que ja existeix. Clay s’asseu al costat del CRM al nivell de sistemes i absorbeix les tasques que els equips comercials feien a mà: enriquiment, construcció de llistes, scoring. Aquestes tasques surten de la planta humana i es converteixen en un sistema adjacent. La forma de l’edifici no canvia. Dir això en veu alta estalvia als clients l’error més car del mercat actual, que és comprar eines per tapar una arquitectura que ningú no va dibuixar mai.

Migrar és un problema de sistema operatiu

El lift and shift copia el desordre en una casa nova. Una migració és un problema de sistema operatiu, no de transferència de dades. Quan vam passar Tech Barcelona de Zoho a HubSpot, un projecte que tocava fins a cinquanta mil registres, no vam fer «exportar i importar». Primer vam redissenyar el model de dades, vam fer el canvi per fases i ho vam embolcallar amb governança i validació de QA, perquè l’objectiu mai no va ser traslladar les dades. Era canviar el que les dades signifiquen d’ara endavant. Si migreu sense refer l’arquitectura, heu pagat per reproduir els vostres vells problemes en un editor més car.

Com auditar la vostra pròpia arquitectura en deu minuts

No aneu a buscar «la nostra arquitectura». Gairebé ningú, directors inclosos, no coneix la paraula en aquest sentit, i preguntar-ho fa que la gent se senti ximple. Feu una pregunta més senzilla: quin és el vostre procés comercial? Un director de vendes que no sap respondre això és un pintor que no sap anomenar la seva pintura, i el balbuceig en si ja és el primer diagnòstic.

Després recorreu-lo, pas a pas, i marqueu cada trencament:

• D’on vénen els leads?
• Qui els recull, i com? («Ella els busca a Google» és manual. Marqueu-ho.)
• Com s’enriqueixen? («No s’enriqueixen». Marqueu-ho.)
• Com els feu scoring i com sabeu si alguna cosa és ICP? («No ho fem». Marqueu-ho.)
• Què passa després de la reunió, i on queda registrat?
• Si màrqueting llança alguna cosa, on ho veu vendes?
• Com feu el forecast de l’any que ve?

Aquesta última pregunta és la definitiva, sobretot en empreses consolidades que facturen entre 70 i 120 milions. La resposta és gairebé sempre alguna versió de «més o menys, pel que els clients ens diuen que demanaran, i ho tenen apuntat en algun lloc». Cada «marqueu-ho» és un punt on la capa humana i la capa de màquines no van aconseguir connectar-se. Compteu-los. Aquest total és la vostra arquitectura, l’hàgiu dissenyada o no.

El canvi d’enfocament

Un CRM us diu què està passant. No fa que ningú vengui millor, i no es dissenyarà sol. L’eina que compreu és l’última decisió, no la primera. Decidiu per a què serveixen els vostres sistemes, com es connecten i on viu la veritat. Després trieu el software que hi encaixi. Feu-ho en aquest ordre i la discussió sobre la plataforma gairebé desapareix, perquè qualsevol eina competent pot sostenir una bona arquitectura i cap no en pot rescatar una de dolenta.

Si ja sospiteu que el cablejat sota el vostre CRM és el veritable problema, per a això està pensat exactament el nostre treball de CRM Foundation and Data Architecture . Dibuixem l’edifici abans de construir-lo, aconseguim la vostra aprovació del model de dades i després connectem els sistemes perquè la veritat caigui en un sol lloc i es propagui. Comenceu pel vostre procés comercial. Tot el que mereix un informe depèn de tenir-lo sobre paper.