Quando ho aperto Salesforce per la prima volta in questa azienda, la prima cosa che ho pensato è stata: da dove si comincia?
Venendo da esperienze lavorative focalizzate su piattaforme più intuitive e native per l’inbound come HubSpot, l’impatto con un ecosistema enterprise decisamente più strutturato, rigido e orientato ai processi complessi come Salesforce è stato uno shock culturale.
La sfida non era solo sanare un database compromesso, ma adattare rapidamente il mio mindset a una logica di gestione del dato completamente diversa.
All’interno della piattaforma vedevo solo account duplicati. Contatti senza associazioni. Record incompleti. Una struttura che rispecchiava anni di inserimenti frettolosi, fatti da persone diverse, senza un modello condiviso.
Un database che avrebbe dovuto essere il cuore operativo del team commerciale, ma che di fatto nessuno usava più perché non ci si fidava dei dati che conteneva. Gestire questo passaggio tecnologico e metodologico è una delle competenze più concrete e sottovalutate nel lavoro di un CRM Specialist.
Cos’è la data governance in un CRM e perché è critica
Prima di parlare di automazioni, lead scoring o pipeline ottimizzate, c’è una domanda fondamentale a cui un CRM deve saper rispondere: i dati al suo interno sono affidabili?
La data governance (ovvero l’insieme di regole, strutture e processi che garantiscono qualità e coerenza dei dati) è la base su cui tutto il resto si costruisce. Senza di essa, ogni report è inattendibile, ogni campagna di marketing è mal targettizzata, ogni previsione commerciale è un’ipotesi nel buio.
Nel contesto B2B della logistica per il mondo moda, questa sfida è amplificata da una complessità strutturale specifica: gli account di Salesforce non sono entità semplici da gestire.
Un gruppo controlla decine di brand. Ogni brand opera attraverso legal entity diverse in paesi diversi. Le divisioni commerciali cambiano. I contatti si spostano. Le relazioni tra entità sono fluide e stratificate.
Su strumenti come HubSpot le relazioni tra aziende e contatti sono flessibili e facilmente modificabili, Salesforce invece richiede una definizione a monte rigorosa.
Il caso reale: ridisegnare l’architettura degli account su Salesforce
Il contesto in cui mi sono trovato a lavorare è quello di una società di logistica conto terzi specializzata nel fashion e luxury. I clienti sono brand (spesso parte di gruppi più grandi) che operano attraverso entità legali distribuite in più paesi.
Il problema era chiaro: il database Salesforce esistente non rifletteva questa struttura. Gli account erano stati creati in modo non uniforme, con criteri diversi a seconda di chi li aveva inseriti. Il risultato: duplicati, associazioni mancanti, impossibilità di avere una visione chiara di un cliente o prospect.
La soluzione non era pulire i dati uno per uno senza una logica di fondo. Era ridefinire prima il modello, poi sistemare i dati in funzione di quel modello.
La nuova tassonomia degli account su tre livelli
Per mappare correttamente il business, ho strutturato l’architettura dei dati su tre livelli gerarchici:
- Livello 1 – Gruppo / Holding: Rappresenta il gruppo industriale o la holding di controllo. Permette di aggregare tutto ciò che vi appartiene e di capire immediatamente le associazioni tra gruppi e brand di proprietà.
- Livello 2 – Brand: L’entità centrale del lavoro commerciale. È sul brand che si concentra la relazione, la trattativa, lo status (cliente attivo, prospect, lead, ex-cliente). Ogni brand è collegato al gruppo di appartenenza (se presente) e alle sue legal entity nei vari mercati.
- Livello 3 – Legal Entity: La società legale operativa, specifica per paese o divisione. È il soggetto contrattuale reale. Associare le legal entity al brand permette di gestire le complessità multi-paese senza perdere la visione d’insieme sul brand e di associare le opportunità in modo corretto.
Oltre ai tre livelli gerarchici ho definito altri record tipe utili per la suddivisione degli account.
La configurazione tecnica implementata su Salesforce
Passare dalla fluidità a cui ero abituato alla rigidità strutturale di Salesforce ha richiesto l’utilizzo combinato di due funzionalità core della piattaforma:
Record Type Dedicati
Per evitare che gli utenti visualizzassero campi irrilevanti, ho creato tre Record Type specifici sull’oggetto Account (Holding, Brand, Legal Entity e altri tipi per esigenze specifiche. Ogni Record Type è associato a una Page Layout personalizzata che mostra solo i dati rilevanti per il record type.
Ad esempio, il layout della “Legal Entity” mostra i campi fiscali (Partita IVA, codice identificativo, indirizzo di fatturazione), mentre il layout del “Brand” dà risalto a informazioni strategiche come settore, posizionamento di mercato o tipologia di prodotto gestito.
Associazioni Relazionali Flessibili (Lookup)
Inizialmente ho valutato l’adozione della gerarchia nativa degli account di Salesforce (Parent ID) su tre livelli, ma una scelta simile avrebbe irrigidito eccessivamente il sistema e bloccato la gestione delle relazioni, che nel fashion sono molto fluide. Ho opato quindi per un’architettura più snella e flessibile: ho implementato un’associazione diretta in cui ogni Legal Entity richiama semplicemente il suo Brand di riferimento.
Questa scelta architetturale ha garantito la massima agilità operativa nel caricamento e nello spostamento dei dati, senza compromettere la capacità di estrarre report commerciali e KPI aggregati.
Il processo di Data Cleansing: come ho risanato il database
Un’architettura perfetta è inutile se applicata a un database compromesso. Per sanare lo storico e rimuovere i duplicati strategici, ho strutturato un processo di pulizia e normalizzazione diviso in tre fasi tecniche principali:
1. Audit e mappatura dello storico (Data Extraction & Matching)
Il primo passo non è stato cancellare, ma capire. Ho esportato l’intero database di Account e Contatti tramite Data Loader. Utilizzando chiavi di tracciamento univoche (come i domini web delle aziende e i codici fiscali/Partite IVA ove presenti), ho eseguito uno screening massivo per identificare i record ridondanti e mappare i legami di parentela nascosti tra le varie anagrafiche.
2. Fusione dei record e consolidamento dello storico (Data Merging)
Identificati i macro-problemi, sono passato al consolidamento pratico dei dati. Per farlo in modo sistematico, ho configurato le logiche interne di Salesforce:
Prima ho creato delle Matching Rules (regole di corrispondenza) per istruire la piattaforma su come riconoscere due aziende identiche, impostando come criterio principale l’uguaglianza del sito web (Website Domain).
Subito dopo ho attivato le relative Duplicate Rules (regole di duplicazione) per fare in modo che Salesforce intercettasse e segnalasse i record sovrapposti basandosi su quel criterio.
Una volta isolate le anagrafiche ridondanti tramite le regole, ho utilizzato gli strumenti nativi di Merge di Salesforce per unire i record duplicati salvaguardando l’integrità dello storico.
Questo passaggio è cruciale: la fusione nativa ha permesso di non perdere il patrimonio informativo pregresso (come email inviate, note e task commerciali) e di riassociare automaticamente tutte le Opportunities e i Contacts all’anagrafica corretta. Quest’ultima è stata definita come Master Record applicando un criterio meritocratico basato sulla completezza e freschezza delle informazioni.
3. Il passo successivo: la protezione proattiva (da attivare al bisogno)
Per il momento, ho scelto di non attivare regole di blocco automatico e preventivo all’inserimento (come le Duplicate Rules rigide di Salesforce). Con i volumi attuali, un controllo umano e una buona cultura del dato sono più che sufficienti, e volevo evitare di introdurre troppi vincoli tecnici che avrebbero potuto rallentare l’operatività quotidiana dei commerciali in questa prima fase.
Tuttavia, il percorso di governance è già tracciato. Se in futuro il volume delle anagrafiche dovesse aumentare o se dovessimo notare una nuova crescita di record ridondanti, lo step successivo sarà già pronto: implementare Matching e Duplicate Rules native su Salesforce.
Change Management: la strategia per l’adozione interna
Un CRM ridisegnato funziona solo se chi lo usa ogni giorno ne comprende il valore e ne rispetta le regole. Molti progetti falliscono qui, non per motivi tecnici, ma per mancanza di adozione da parte del team commerciale.
Per superare questa resistenza, ho adottato un approccio in due step:
- La Call di Allineamento: Prima di rendere definitive le modifiche su Salesforce, ho organizzato una sessione di condivisione con il team commerciale e i responsabili operativi. L’obiettivo non era imporre una struttura dall’alto, ma mostrare come questo nuovo modello avrebbe risolto i loro problemi quotidiani (es. non trovare i contatti giusti o sovrapporsi sullo stesso cliente). Questo momento di confronto è stato fondamentale per limare la tassonomia e validare sul campo la soluzione più pratica e fluida per il loro flusso di lavoro.
- La Guida Operativa Semplificata: Subito dopo il rilascio, ho distribuito una guida breve, visiva e priva di tecnicismi inutili. Poche pagine focalizzate esclusivamente sul “come fare”: come inserire un nuovo Brand, come associare una Legal Entity e quale Record Type scegliere a seconda della situazione. Uno strumento di consultazione rapida che ha azzerato l’attrito iniziale e ha standardizzato l’inserimento dei dati fin dal primo giorno.
Risultati ottenuti
Il risultato più immediato non è stato quantitativo, ma qualitativo: il CRM è tornato ad essere uno strumento consultato. Quando i dati sono affidabili, le persone li usano.
In termini più concreti:
- Eliminazione dei duplicati principali sugli account strategici e blocco preventivo dei nuovi inserimenti errati.
- Visione chiara e immediata delle relazioni gruppo-brand-legal entity per tutto il portafoglio clienti e prospect.
- Base dati pulita e segmentata, finalmente utilizzabile per attività di reporting commerciale e campagne marketing mirate.
- Fondamenta solide per future automazioni basate sui dati (es. assegnazione automatica dei lead in base alla gerarchia dell’account).
Riflessione professionale
Lavorare su un database mal gestito ti insegna qualcosa che nessun corso CRM ti dice esplicitamente: la tecnologia non è il problema. Il modello concettuale è il problema.
Il passaggio da un ecosistema agile come HubSpot a uno iper-strutturato come Salesforce mi ha dimostrato che le competenze di un CRM Specialist vanno ben oltre la conoscenza dei singoli pulsanti di un software.
Saper gestire la transizione tra strumenti con filosofie così diverse significa saper tradurre le necessità di business in architetture rigide senza perdere la flessibilità operativa. Salesforce è uno strumento incredibilmente potente. Ma uno strumento potente con dati incoerenti è inutile.
Prima di pensare a workflow, automazioni o dashboard, bisogna chiedersi: questo CRM riflette la realtà del business in modo accurato? Se la risposta è no, da lì si comincia.