KLC Richiedi un’analisi
Passa al contenuto principale
Duplicati nel CRM: unire contatti e aziende senza perdere attività, consenso e attribuzione

Duplicati nel CRM: unire contatti e aziende senza perdere attività, consenso e attribuzione

Scritto da KLC il . Pubblicato in Dati e misurazione.

12 Ottobre 2026 · Dati e misurazione

Due contatti con lo stesso nome, tre aziende con varianti della ragione sociale, un cliente registrato sia con dominio italiano sia internazionale. I duplicati sembrano un problema estetico finché non provocano email ripetute, ownership in conflitto, opportunità separate e consensi incoerenti.

Eliminare le copie non basta. Serve una politica che definisca che cosa rappresentano i record, quali dati prevalgono, chi può unirli e come prevenire nuove duplicazioni.

Prima distinguere duplicati veri e relazioni legittime

Non ogni somiglianza indica la stessa entità:

  • due omonimi nella stessa azienda sono persone diverse;
  • sedi dello stesso gruppo possono richiedere account distinti ma collegati;
  • un distributore e un cliente finale possono condividere un progetto;
  • una persona può cambiare azienda mantenendo una relazione storica;
  • alias e caselle funzionali possono riferirsi a più utenti;
  • società con marchio comune possono avere identità legali differenti.

Il modello dati deve chiarire quando usare account separati, gerarchie, sedi, contatti e relazioni. Senza questa scelta, il merge diventa una decisione commerciale improvvisata.

Le chiavi di confronto hanno affidabilità diversa

Contatti

Email aziendale identica è un segnale forte, ma può cambiare o essere condivisa. Telefono, nome, cognome, account e profilo possono contribuire. Le email personali richiedono maggiore cautela.

Account

Dominio, partita IVA o identificativo gestionale sono più utili del solo nome. Ragioni sociali possono cambiare; domini possono essere multipli; gruppi possono condividere servizi.

Lead

Un nuovo form può essere una nuova richiesta dello stesso contatto, non un nuovo contatto. Il sistema dovrebbe creare un’attività o lead collegato invece di duplicare la persona.

Le regole possono classificare corrispondenze certe, probabili e da rivedere. Automatizzare il merge dei casi probabili senza controllo rischia di perdere dati.

Il record master non è semplicemente il più recente

Per ogni campo servono regole di sopravvivenza:

  • identificativi gestionali prevalgono sulle varianti manuali;
  • dati verificati prevalgono su dati arricchiti;
  • il valore più recente prevale solo se il campo rappresenta uno stato attuale;
  • la fonte originaria più antica va conservata;
  • attività, opportunità e consensi non devono essere cancellati;
  • note in conflitto richiedono revisione;
  • ownership deve seguire la governance dell’account, non il record scelto casualmente.

Il merge dovrebbe produrre un log: record coinvolti, operatore, data, regole applicate e campi modificati.

Il consenso non si risolve scegliendo la casella più permissiva

Se due record hanno preferenze diverse, non è corretto mantenere automaticamente il consenso positivo. Occorre capire finalità, fonte, data e stato più recente, secondo la configurazione giuridica e tecnica dell’organizzazione. Le preferenze possono risiedere in un sistema dedicato e il CRM deve sincronizzarle senza reinterpretarle.

La deduplicazione deve inoltre rispettare richieste di rettifica o cancellazione. Ricreare un record eliminato attraverso una successiva importazione può vanificare il processo. Sono necessari identificativi o liste di soppressione gestiti in modo appropriato.

Prevenzione al punto di ingresso

I controlli più efficaci avvengono prima della creazione:

  • ricerca per email e dominio durante l’inserimento;
  • suggerimento di account esistenti;
  • normalizzazione di maiuscole, spazi, suffissi societari e telefoni;
  • validazione dei domini;
  • mapping tra sistemi;
  • identificativi esterni stabili;
  • regole su importazioni e integrazioni;
  • permessi per creare nuovi account;
  • gestione dei form ripetuti come nuove attività.

Bloccare ogni possibile duplicato può però rallentare il lavoro. Meglio avvisare e consentire una scelta motivata nei casi ambigui.

Una coda di revisione con priorità

Non tutti i duplicati hanno lo stesso rischio. Si può dare priorità a:

  1. account con opportunità aperte;
  2. contatti con comunicazioni o consensi divergenti;
  3. record con ownership diversa;
  4. clienti attivi;
  5. duplicati creati da integrazioni ricorrenti;
  6. archivi inattivi senza impatto operativo.

La coda dovrebbe mostrare campi affiancati, attività, relazioni e una proposta di master. L’operatore deve poter decidere “merge”, “mantieni separati” o “collega come relazione”.

Esempio: gruppo industriale con più stabilimenti

Il CRM contiene “Alfa S.p.A.”, “Alfa Spa – Milano”, “Alfa Group” e “Alfa Manufacturing”. Alcuni record sono duplicati; altri rappresentano stabilimenti con acquisti autonomi. Un merge totale assegnerebbe tutte le opportunità allo stesso commerciale e cancellerebbe la distinzione territoriale.

La soluzione crea un account capogruppo, account figli per le entità che prendono decisioni separate e una relazione di gruppo. I domini vengono mappati; l’identificativo ERP distingue le società legali. I contatti sono collegati alla sede corrente, mantenendo lo storico del cambio. Le opportunità restano sull’account che acquista, mentre il reporting può aggregare il gruppo.

Il lavoro di deduplicazione diventa così modellazione della realtà, non pulizia di nomi.

Metriche che mostrano la causa

  • tasso di duplicati per fonte di creazione;
  • duplicati bloccati o segnalati;
  • tempo medio di revisione;
  • account con più owner in conflitto;
  • opportunità distribuite su duplicati;
  • record ricreati dopo merge;
  • percentuale di domini associati a più account;
  • importazioni con identificativi mancanti;
  • errori di sincronizzazione tra CRM, marketing automation ed ERP.

Se i duplicati tornano dopo ogni pulizia, la causa è nel processo o nelle integrazioni. Una bonifica annuale non basta.

Procedura sicura di bonifica

  1. Fare backup ed esportare identificativi e relazioni.
  2. Definire oggetti, chiavi e regole di sopravvivenza.
  3. Segmentare casi certi, probabili e complessi.
  4. Testare il merge in ambiente controllato.
  5. Verificare attività, opportunità, campagne, consensi e ownership.
  6. Eseguire per lotti con log e possibilità di rollback.
  7. Correggere fonti che generano duplicati.
  8. Monitorare ricorrenza e nuovi pattern.

Domande frequenti

Si possono unire automaticamente i record con la stessa email?

Spesso sì per contatti aziendali, ma servono eccezioni per caselle condivise, cambi di azienda e dati provenienti da sistemi diversi. Il test è indispensabile.

Quale account deve restare master?

Quello che conserva gli identificativi e le relazioni corrette, non necessariamente il più vecchio o il più completo. Le regole vanno definite campo per campo.

È meglio cancellare i record inattivi?

La cancellazione dipende da finalità, obblighi, retention e valore storico. Va distinta dalla deduplicazione e valutata con le funzioni competenti.

Fonti e riferimenti per la revisione

Approfondisci il servizio: Analytics e conversioni.