Qualità dei dati nel CRM: duplicati e responsabilità, chi fa cosa in Zoho CRM

La qualità dei dati nel CRM, e in particolare il problema dei duplicati, dipende prima di tutto dalla responsabilità. I duplicati nascono quando nessuno risponde di un campo o di una fonte di ingresso. Per questo, in Zoho CRM, serve un proprietario per ogni campo e per ogni fonte prima di configurare qualsiasi regola di deduplica.

Una regola di deduplica confronta i record secondo un criterio. Il criterio però lo decide qualcuno. Se nessuno ha deciso che cosa identifica un cliente, la regola confronta il campo sbagliato oppure lascia passare record che andavano uniti.

Il caso tipico si vede dopo una migrazione. I dati vengono puliti con cura durante il progetto. Pochi mesi dopo, il form del sito, le importazioni dei commerciali e l'integrazione con il gestionale reintroducono gli stessi doppioni. Nessuna di queste fonti ha un responsabile, quindi nessuno se ne accorge finché i report non tornano.

Questa guida descrive come assegnare le responsabilità, come tradurle in impostazioni di Zoho CRM e dove le funzioni del prodotto richiedono una verifica manuale. Il punto di partenza è sempre la stessa domanda: chi risponde di questo dato quando è sbagliato?

La qualità dei dati nel CRM è il grado in cui i record descrivono clienti, contatti e trattative in modo completo e univoco. I record devono anche restare coerenti tra tutte le fonti. Un CRM di qualità ha un solo record per ogni persona o azienda reale. Ogni campo ha inoltre un significato condiviso da chi lo compila e da chi lo legge.

Un duplicato è un secondo record che descrive la stessa persona o la stessa azienda già presente nel CRM. Il duplicato può essere identico al primo, ma spesso non lo è. Un'email scritta in modo diverso, un nome abbreviato o una fonte diversa bastano a far sembrare nuovo un contatto esistente.

Il proprietario del dato è la persona che decide come un campo va compilato e quale fonte prevale in caso di conflitto. Decide anche chi corregge gli errori. Non coincide con il proprietario del record in Zoho CRM. Quest'ultimo è il commerciale a cui il record è assegnato, mentre il proprietario del dato risponde delle regole.

Un concetto vicino è il master data management, o MDM. Salesforce lo definisce come l'approccio che crea e mantiene un'unica fonte attendibile per entità come clienti, prodotti e personale. L'approccio elimina i duplicati e risolve i conflitti. Una piccola o media impresa non ha bisogno di un programma MDM formale. Le serve però lo stesso principio: per ogni entità, una sola fonte che fa testo.

I duplicati entrano nel CRM da quattro tipi di fonte. Sono i form del sito, le importazioni da file, le integrazioni con altri sistemi e l'inserimento manuale. A queste si aggiungono le conversioni tra moduli, che creano un nuovo record a partire da uno esistente. Ogni fonte ha un comportamento proprio e quindi richiede un controllo proprio.

Le integrazioni sono la fonte più insidiosa, perché i sistemi collegati spesso usano definizioni diverse. Salesforce porta un esempio chiaro. Un sistema può considerare "cliente attivo" chi ha acquistato negli ultimi 90 giorni. Un altro usa una soglia di 365 giorni. La stessa pagina ricorda che la riconciliazione dei dati è spesso un processo manuale e soggetto a errori.

Le conversioni tra moduli sono meno evidenti. In un thread della community Zoho sulla conversione dei record tra moduli, uno sviluppatore descrive un cliente con più di 15 moduli. Servivano oltre 50 pulsanti di conversione tra un modulo e l'altro. Lo stesso autore precisa un limite. Se un campo ha un nome diverso nei due moduli, la corrispondenza va aggiunta a mano nel codice. Ogni pulsante di conversione è quindi una fonte di ingresso a tutti gli effetti, con le sue mappature da sorvegliare.

Per l'inserimento manuale il rischio è diverso. Un commerciale che non trova un contatto con la ricerca tende a crearne uno nuovo. Se nessuno ha stabilito come cercare prima di creare, il doppione è quasi inevitabile.

Assegnare un proprietario significa scrivere, per ogni campo importante e per ogni fonte, il nome di una persona con tre compiti. Decide la regola di compilazione. Sceglie quale fonte prevale in caso di conflitto. Corregge o fa correggere gli errori entro un tempo stabilito. Un ruolo generico come "il commerciale" non basta: serve un nome.

I campi da coprire per primi sono quelli che identificano un record e quelli che alimentano report e assegnazioni. Il seguente elenco indica da dove partire:

• i campi chiave di identificazione, come Email, ragione sociale e partita IVA;
• i campi che determinano l'assegnazione, come area geografica o Lead_Source;
• i campi che alimentano i report direzionali, come stato del cliente e fase della trattativa;
• i campi che arrivano da un sistema esterno, come codici cliente del gestionale.

Per le fonti vale la stessa logica. Il form del sito appartiene di solito al marketing. L'integrazione con il gestionale appartiene a chi gestisce il gestionale. Le importazioni da file appartengono a chi le esegue, che deve conoscere la procedura descritta nella guida su come importare i dati in Zoho CRM con preparazione e verifica.

In Svennis compiliamo questa tabella dei proprietari prima di attivare qualsiasi regola di deduplica, e la facciamo approvare dal responsabile commerciale. Quando la saltiamo, vediamo i duplicati tornare proprio dalla fonte che nessuno sorveglia, di solito un'importazione occasionale o un form secondario.

La tabella delle responsabilità mette a confronto le fonti di ingresso di Zoho CRM su tre aspetti: chi ne risponde, quale chiave identifica un duplicato e quale controllo serve. La tabella che segue è un punto di partenza da adattare. I proprietari indicati sono una proposta, non una regola del prodotto.

Fonte di ingresso	Proprietario consigliato	Chiave di confronto	Controllo da prevedere
Form del sito via API (upsert)	Responsabile marketing	Email, eventualmente con Lead_Source	Verifica del campo duplicate_field nella risposta
Importazione da file	Chi esegue l'importazione	Email o partita IVA	Controllo dei record creati e aggiornati dopo il caricamento
Integrazione con il gestionale	Responsabile del gestionale	Codice cliente del gestionale	Definizioni condivise dei campi tra i due sistemi
Inserimento manuale	Responsabile commerciale	Ragione sociale ed Email	Ricerca obbligatoria prima di creare un record
Conversione tra moduli	Chi gestisce le personalizzazioni	API name dei campi mappati	Revisione della mappatura quando cambia un campo

La colonna più importante è l'ultima. Una responsabilità senza un controllo concreto resta sulla carta. Il controllo deve essere qualcosa che il proprietario può eseguire in pochi minuti, con regolarità.

Un'azienda che riceve contatti dal sito può inserirli in Zoho CRM con un upsert, cioè una chiamata API che aggiorna il record se esiste già e lo crea se non esiste. Il caso che segue viene da un thread della community Zoho sul parametro duplicate_check_fields. Mostra perché la scelta della chiave di confronto spetta a una persona, non solo al codice.

Lo scenario

Un utente inviava i contatti di un form di richiesta al modulo Contacts, con l'endpoint dell'API v2 sul data centre europeo: https://www.zohoapis.eu/crm/v2/Contacts/upsert. Voleva considerare duplicato un contatto solo quando coincidevano sia Email sia Lead_Source. In tutti gli altri casi voleva un nuovo record.

Che cosa è successo

Dopo aver indicato i campi nel parametro duplicate_check_fields, l'utente ha riferito che il controllo usava solo l'indirizzo email e ignorava l'altro campo. La risposta dell'API riportava "duplicate_field":"Email" e "action":"update". Lo stesso risultato si ripeteva anche indicando solo Lead_Source. Il thread risale al dicembre 2018, quindi il comportamento attuale va verificato sul proprio account.

Cosa insegna sulla responsabilità

La domanda decisiva non era tecnica. Il marketing doveva stabilire se lo stesso contatto arrivato da due campagne fosse una persona o due record. Il proprietario della fonte deve poi leggere i campi duplicate_field e action nelle risposte di prova. Solo così sa se il CRM sta applicando la sua regola o un'altra.

Quando un lead duplicato viene assegnato a rotazione, il Round Robin distribuisce anche il doppione e brucia il turno di un commerciale. Un utente lo descrive nel thread della community Zoho su duplicati, Round Robin e processo di approvazione. I commerciali nella rotazione, scrive, perdono il turno su un lead valido.

Il processo di approvazione in Zoho CRM è lo strumento che automatizza le approvazioni nell'organizzazione. Le richieste si approvano nel modulo My Jobs, da un unico punto. Nel caso descritto, l'approvazione dei duplicati spettava a una persona di livello diverso dal proprietario del lead. Ne nascevano due problemi:

• il proprietario del lead riceveva la notifica ma non poteva approvare;
• la persona incaricata dell'approvazione non riceveva l'email di notifica.

La soluzione proposta dall'utente segue un ordine preciso. Il lead duplicato va prima all'approvatore. Solo dopo l'approvazione il proprietario viene assegnato con il Round Robin. È la stessa logica di questa guida: prima si decide chi risponde del duplicato, poi si distribuisce il lavoro.

Lo stesso utente chiedeva se un workflow email parte alla creazione del lead o solo dopo l'approvazione. Il thread non dà una risposta definitiva. Prima di andare in produzione conviene quindi provarlo con un lead di prova. Un'altra domanda della community va nella stessa direzione: un utente chiedeva se una regola di assegnazione può controllare i record esistenti prima di assegnare.

Le regole di deduplica in Zoho CRM funzionano bene solo quando tre decisioni sono già state prese. Serve una chiave di confronto per ogni modulo. Serve una fonte che prevale in caso di conflitto. Serve infine un momento preciso in cui il controllo avviene. Senza queste decisioni, la regola automatizza un criterio che nessuno ha scelto.

Il momento del controllo conta più di quanto sembri. Salesforce distingue tra processi ETL ed ELT. Nell'ETL la preparazione e la validazione avvengono prima del caricamento. Nell'ELT la deduplicazione avviene dopo il caricamento nel sistema di destinazione. Per un CRM, controllare all'ingresso evita che il doppione venga assegnato, notificato e lavorato prima di essere scoperto.

La stessa pagina osserva che le soluzioni cloud possono ridurre i problemi dei dati frammentati, ma non eliminarli del tutto. Vale anche per gli strumenti automatici di Zoho. Chi valuta l'aiuto dell'intelligenza artificiale trova i dettagli nella guida su arricchimento dati e duplicati con Zia in Zoho CRM. Anche lì, prima dell'attivazione servono le stesse decisioni sui proprietari.

Un buon test finale è semplice. Si chiede al proprietario di ogni fonte quale record resta quando due record si scontrano. Se la risposta non è immediata, la regola non è pronta.

Per un'azienda italiana, i duplicati nel CRM toccano tre ambiti concreti: le integrazioni via API sul data centre europeo, il collegamento con il gestionale e la gestione dei dati personali. In tutti e tre i casi la responsabilità va assegnata a una persona, non a un sistema.

Le chiamate API di un account sul data centre europeo usano il dominio zohoapis.eu, come nell'esempio della community citato sopra. Chi scrive o mantiene l'integrazione del form deve sapere su quale dominio lavora. Deve anche verificare il comportamento del controllo duplicati su quell'account.

Il gestionale è spesso la fonte che fa testo per l'anagrafica dei clienti fatturati. Se Zoho CRM è collegato, per esempio con l'integrazione tra SAP Business One e Zoho CRM, la chiave di confronto più solida è il codice cliente del gestionale. Il proprietario del gestionale deve allora rispondere anche di come quel codice arriva nel CRM.

Per i dati personali, un contatto registrato due volte è più difficile da gestire. Una richiesta di un interessato va ricondotta a tutti i record che lo riguardano, e i doppioni rendono la ricerca incompleta. La guida sul GDPR nel CRM, tra consensi e richieste in Zoho CRM descrive come organizzare questa parte.

Il primo passo concreto è elencare tutte le fonti che oggi creano o aggiornano record in Zoho CRM. Accanto a ciascuna va scritto un nome. Il lavoro richiede di solito una riunione con marketing, commerciale e chi gestisce i sistemi collegati.

Le azioni successive, in ordine, sono queste:

1. compilare la tabella delle responsabilità con proprietario, chiave di confronto e controllo per ogni fonte;
2. decidere, modulo per modulo, quale fonte prevale in caso di conflitto;
3. provare ogni fonte con record di prova e leggere le risposte, come i campi duplicate_field e action di un upsert;
4. solo a questo punto configurare le regole di deduplica e di assegnazione;
5. fissare una verifica periodica in cui ogni proprietario controlla la propria fonte.

Per misurare l'effetto nel tempo è utile un report sul numero di nuovi record per fonte. La guida sulla prima dashboard di Zoho Analytics sui dati di Zoho CRM mostra come costruirlo.

Se la configurazione di Zoho CRM va rivista nel suo insieme, la pagina sull'implementazione di Zoho CRM in Italia descrive come impostiamo un progetto, dalle responsabilità sui dati fino al rilascio.

• Dati frammentati: cosa sono? (Salesforce)
• Copying/Converting Data from One Module to Another Module along with Notes (Zoho Community)
• How to correctly specify duplicate_check_fields via API (Zoho Community)
• Duplicate Leads Concerns with Round Robin and Lead Approval Process (Zoho Community)
• Assignment Rules (Zoho Community)