Arquitectura de dades i servei

Reconstruir les dades de clients d’Elesa+Ganter en alguna cosa sobre la qual el negoci pugui actuar

Cas d’estudi d’Elesa+Ganter

Oriol SerraFounder & CEO
Enriquidabase de clients, retornada a l'ERP
6 mesosentre cicles d'enrichment
En construccióregles d'entrada i automatització del servei
Continucol·laboració fraccional des de març de 2026

Elesa+Ganter Ibérica és la filial ibèrica d’ELESA+GANTER, la joint venture comercial entre dos líders mundials en elements mecànics estàndard de plàstic i metall per a la indústria de maquinària.

La situació

Elesa+Ganter ven components mecànics estàndard a fabricants industrials d’Espanya i Portugal. La part comercial del negoci funciona a HubSpot i la transaccional a SAP, i totes dues havien crescut durant anys sense normalització i sense cap control sobre el que hi entrava. Les dades que contenien havien envellit fins al punt que ningú no podia actuar-hi amb seguretat, i tota la feina d’atenció al client que s’hi recolzava es feia a mà.

El problema real

La resposta òbvia era una neteja, i una neteja no hauria aguantat. Res del sistema no s’havia actualitzat mai per si sol, així que els registres haurien començat a quedar obsolets un altre cop el mateix dia del lliurament. El mateix passava a l’altre extrem. Nou bústies compartides creaven un contacte amb cada email entrant, aquest comportament no es pot desactivar a HubSpot, i cap regla no decidia què passava després amb cap d’aquests contactes.

Netejar el contingut sense arreglar l’entrada produeix una base de dades endreçada amb una fuita.

I per sota de totes dues coses, la feina de servei. Cada petició de client la llegia, classificava, encaminava i responia una persona, cosa que funciona fins que el volum es mou i aleshores deixa de funcionar.

L’enfocament

Enrichment periòdic, no una neteja puntual. Les dades de clients queden desactualitzades per si soles, així que es mantenen en lloc de netejar-se un cop. La base de clients es torna a enriquir cada sis mesos amb fonts externes, i cada adreça de lliurament es normalitza i es geocodifica en la mateixa passada. Les adreces importen més del que sembla: els lliuraments sortien amb registres que ni tan sols tenien un camp de codi postal, i amb la població buida en gairebé totes les files.

Decidir al punt d’entrada, i donar a una persona els casos que demanen criteri. Cada contacte nou s’admet, es reté per a revisió o es rebutja segons el canal pel qual va arribar. Només els contactes admesos passen a l’ERP, així que res sense verificar no arriba al registre mestre, i els retinguts van a una llista de revisió en lloc d’impedir a ningú respondre a un client. La regla, expressament, no és una barrera que atura la feina; és un filtre que funciona en paral·lel.

Automatitzar el que és segur, i enviar la resta a una persona. Una petició es respon automàticament només quan la resposta ja existeix a les dades, com l’estat d’una comanda. Tot el que és dubtós, delicat o d’alt valor va a una persona. En tots dos casos la resposta queda registrada a la mateixa petició, així que el cas guarda l’historial complet en lloc de tenir-ne la meitat a la bústia d’algú.

Què vam construir

Enrichment i una actualització recurrent de la base de clients a Clay, a partir del registre mercantil públic i d’un proveïdor de dades de crèdit, amb les adreces de lliurament normalitzades i geocodificades. Regles a HubSpot que admeten, retenen o rebutgen cada contacte nou segons el canal del qual va venir, amb una llista de revisió per als retinguts i només els contactes admesos passant a l’ERP. I a la part de servei, respostes automàtiques a través de n8n per a les peticions la resposta de les quals ja existeix a les dades, amb tota la resta encaminada a una persona.

Què va canviar

La base de clients s’ha enriquit i s’ha retornat a l’ERP, i ja no és una cosa que calgui netejar a mà quan algú s’adona que s’ha desviat. La solvència creditícia i els dipòsits públics ara són a la fitxa del client, on abans no hi havia res semblant, tot i que encara no s’hi ha construït res a sobre. Les regles d’entrada i l’automatització del servei estan especificades i en construcció. Aquí no es descriu com a operatiu res que no ho sigui.

Per què importa

La major part de la feina de CRM es ven com una neteja, i una neteja és una resposta puntual a un problema continu. Els registres queden obsolets perquè res no els actualitza i la base de dades es torna a omplir perquè res no decideix què hi pot entrar, així que la pregunta útil no és com de brutes són avui les dades, sinó què les mantindrà netes sense que ningú se n’hagi de recordar. Aquesta és una pregunta d’arquitectura, i es respon abans que ningú toqui cap registre.

Per a qui és això

Empreses que tenen un CRM al costat d’un ERP, on el sistema comercial s’ha desviat del transaccional i l’equip de servei absorbeix la diferència a mà. Normalment el símptoma no és que alguna cosa estigui trencada. És que ningú no es fia prou de les dades per automatitzar-hi res a sobre.

La col·laboració
DuradaDes de març de 2026
EquipOriol Serra, direcció · Francesca Terziani, construcció
SistemesHubSpot Suite Pro, SAP Business One, Clay, n8n
Oriol Serra

Si el vostre CRM i el vostre ERP no coincideixen, una neteja no és la solució.

Les dades que res no actualitza tornen a quedar obsoletes, i un sistema sense regles al punt d’entrada es torna a omplir. 30 minuts, i en sortiu sabent què cal arreglar primer.

Demanar una trucada estratègica