Clienti duplicati: cosa confrontare prima di unire

Per rivedere i clienti duplicati, confronta prima l’identità e la funzione di ogni scheda; poi decidi se è necessario unirli. Un record nelle vendite e un altro nella fatturazione possono essere corretti. Ciò che manca potrebbe essere una corrispondenza affidabile tra i due.

Il problema sorge quando l’amministrazione trova due cronologie simili e qualcuno propone di tenere «la più completa». Una scheda potrebbe contenere il contatto attuale; l’altra, i riferimenti utilizzati da un’integrazione. Scegliere in base al numero di campi compilati non risolve tale conflitto. Questa guida fornisce una matrice e un registro delle decisioni per rivedere il caso prima di modificarlo.

Una scheda per strumento può essere la scelta giusta

Distingui la stessa entità rappresentata in due sistemi da due record ridondanti all’interno di uno. Il primo caso potrebbe richiedere una mappa di corrispondenze; il secondo, un’indagine sull’origine del duplicato. Nessuno autorizza l’eliminazione di una riga in base al suo nome.

Definisci anche cosa rappresenta ogni record: organizzazione, persona di contatto, sede o account commerciale. Una persona che lavora in un’azienda non è un duplicato di quell’azienda. Due sedi non devono essere unite se la tua attività richiede di trattarle separatamente.

Questa revisione si inserisce nella preparazione di una migrazione, ma serve anche senza cambiare strumento. Il suo risultato può essere quello di conservare due schede e spiegarne la relazione.

Conserva l’origine prima di normalizzare

Lavora su una copia di sola lettura. Per ogni riga salva sistema, spazio di lavoro, tipo di record, identificatore originale e data di estrazione. CRM / W1 / account / A17 identifica qualcosa di diverso da BILL / W1 / account / A17: ripetere il numero non dimostra che sia lo stesso cliente.

Mantieni i valori originali e crea colonne ausiliarie per confrontare spazi, maiuscole o varianti note del nome. Non eliminare suffissi, dipartimenti o riferimenti che possano distinguere le entità. Un campo vuoto significa «nessun dato», non «corrisponde a un altro vuoto».

Annota la provenienza di ogni segnale. Un codice comune ha più valore se sai chi lo ha assegnato e hai verificato la sua corrispondenza. Un codice copiato in un’importazione errata può propagare lo stesso errore a entrambe le schede. La data dell’ultima modifica non rende automaticamente un valore corretto.

Una matrice con tre risultati e quattro casi

Il seguente esempio è interamente fittizio. Tutti i record appartengono allo spazio W1; i codici ORG ed EV sono riferimenti di esercizio, non identificatori fiscali né dati dei clienti. Per questo esercizio, si presume che le prove descritte siano disponibili, al solo scopo di illustrare il ragionamento.

Non assegnare percentuali di fiducia inventate. «Probabile» apre una revisione: non è un’unione approvata. «Ambiguo» mantiene il blocco e spiega cosa manca. Anche quando confermi l’identità, resta da decidere se sia necessario modificare qualcosa.

L’assenza di ordini in una scheda non prova nemmeno che sia superflua: potrebbe essere una nuova registrazione o rappresentare un’altra funzione. Classifica con evidenza, non con il numero di campi vuoti.

La mappa degli alias non esegue un’unione

Supponiamo che il responsabile risolva il primo caso: A17 e B62 rappresentano ORG-07, ma entrambi gli strumenti necessitano della loro scheda. La decisione è conservare entrambe le schede e registrarne la corrispondenza. In un foglio indipendente, ENTITY-F07 può essere il tuo riferimento di lavoro:

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

Queste colonne sono un modello creato per questo esercizio, non un formato di importazione di Frihet né un ordine per un connettore. entity_key raggruppa le identità verificate; source_id conserva il riferimento originale. Un alias non modifica gli strumenti per il fatto di esistere in un foglio.

Non raggruppare persone, aziende e sedi sotto la stessa chiave. E non combinare per transitività senza verifica: se A assomiglia a B e B assomiglia a C, non hai ancora dimostrato che A e C siano la stessa cosa.

Registra una decisione che un’altra persona possa rivedere

Copia questa scheda per ogni coppia. Conserva la proposta precedente quando la decisione cambia, con una nuova versione che la sostituisca.

Revisione: R-01 / versione 1
Riferimenti completi: CRM/W1/account/A17; BILL/W1/account/B62
Evidenza: EV-01; corrispondenza ORG-07 verificata dal responsabile
Conflitto: contatto responsabile diverso; valore attuale confermato in EV-05
Decisione: conservare entrambe le schede e registrare la corrispondenza ENTITY-F07
Responsabile della revisione: ROLE-OPS
Azione negli strumenti: nessuna
In sospeso: rivedere come il connettore utilizza tale corrispondenza
Sostituisce: nessuna revisione precedente

I codici sono fittizi. Nell’uso reale, fai riferimento a prove accessibili a chi deve verificarle ed evita di copiare dati personali non necessari nel foglio. Se in seguito viene autorizzata una modifica, registra separatamente esecutore, momento, riferimenti precedenti e risultato osservato. «Approvato», «eseguito» e «verificato» sono stati distinti.

Questa cronologia è revisionabile, non una garanzia di ripristino. Rettificare una decisione scritta non ricostruisce automaticamente i dati già modificati.

Cosa verificare nel fornitore prima di unire

Il comportamento dipende dal prodotto e dal tipo di record. HubSpot documenta che un’unione non può essere annullata e che gli identificatori, le proprietà e le associazioni seguono regole specifiche. Non presumere che l’ID che hai contrassegnato come principale sopravviva sempre intatto.

Shopify avverte anche che l’operazione non è reversibile ed esclude alcuni profili, come quelli che hanno o hanno avuto contratti di abbonamento. Questi esempi non descrivono il comportamento di Frihet né di altri fornitori.

Prima di qualsiasi azione irreversibile, rispondi a queste domande:

• Questa combinazione di tipi è supportata e hai i permessi adeguati?
• Quali valori vengono conservati, quali scartati e quale ID avrà il risultato?
• Cosa succede con cronologia, relazioni e riferimenti esterni?
• Cosa farà la sincronizzazione: riconoscere il cambiamento, ricreare una scheda o fallire?
• Quale recupero esiste realmente e cosa non copre la tua copia?

Leggi l’ambito delle integrazioni (in inglese) e controlla il contratto del connettore utilizzato. Una funzione di lettura non dimostra che sappia propagare le unioni.

Chiudi il caso verificandone anche l’origine

Se viene autorizzata un’unione, concorda prima come limitare i suoi effetti sui sistemi connessi. Prova con dati sintetici in un ambiente di test compatibile; se non esiste, mantieni il blocco fino a risolvere le incognite con il fornitore. Un’esportazione isolata non dimostra che puoi ripristinare tutto.

Dopo una modifica autorizzata, confronta campi e riferimenti con quanto previsto e verifica la successiva sincronizzazione prima di ampliare il lotto. Se il risultato è incerto, indaga prima di ripetere l’azione.

Nella gestione clienti di Frihet è disponibile l’esportazione dell’elenco come CSV. Può servire come input per una revisione; non significa che questo modello possa essere importato né che i clienti possano essere uniti automaticamente.

Concludi annotando perché è apparso il duplicato: inserimento manuale, importazione o regola del connettore, se ci sono prove. Se non lo sai ancora, lascia un responsabile e una verifica in sospeso. Due schede conservate con una relazione chiara sono un risultato valido; un elenco più breve senza cronologia spiegabile non lo è.

Fonti consultate il 14 settembre 2026. Rivedi la documentazione vigente del tuo fornitore prima di modificare i dati.