Anagrafiche clienti tra due software: quale dato prevale?

Automazione · · 5 min di lettura

Il commerciale corregge il recapito nel CRM. L’amministrazione aggiorna l’indirizzo nel gestionale. Il giorno dopo uno dei due dati è tornato com’era: il collegamento ha copiato una versione vecchia sopra quella corretta. Sincronizzare le anagrafiche clienti significa anche decidere chi può modificare ogni informazione e quale modifica deve prevalere.

Prima di attivare lo scambio, preparate una mappa dei campi e delle responsabilità. Potete partire da pochi dati, in una sola direzione, mantenendo visibili le differenze da verificare. Ecco le decisioni da prendere insieme a chi userà i programmi e a chi realizzerà l’integrazione.

1. Scegliere quali informazioni devono passare

Elencate i campi davvero necessari nel programma di destinazione: codice cliente, denominazione, indirizzo, referente, recapito operativo. Distinguete l’azienda dalle persone e dalle sedi. Una società può avere più contatti e più luoghi di consegna: comprimerli in un unico campo rende ambigua anche una copia tecnicamente riuscita.

Per ogni campo annotate nome nei due programmi, formato e significato. «Indirizzo» potrebbe indicare la sede legale in uno e il luogo dell’intervento nell’altro. Controllate lunghezze massime, campi obbligatori e valori ammessi. Un telefono va trattato come recapito, conservando prefisso e zeri iniziali, senza trasformarlo in un numero da calcolare.

2. Stabilire dove si corregge ciascun dato

Assegnate un archivio di riferimento e un responsabile a ogni gruppo di informazioni. Potreste gestire la denominazione nell’amministrazione e il referente commerciale nel CRM. È una scelta organizzativa da concordare sul vostro processo: non esiste un programma che debba prevalere sempre su tutto.

Nel suo esempio di sincronizzazione fra ambienti Dataverse, Microsoft descrive una fonte autorevole che alimenta un secondo ambiente. Il caso riguarda quella piattaforma; per la vostra integrazione il punto da chiarire è chi controlla l’informazione prima di propagarla.

  • Quale ufficio può cambiare il campo nel sistema di riferimento?
  • Nel secondo programma il campo è consultabile oppure modificabile?
  • Una correzione proposta altrove viene approvata, respinta o riportata al responsabile?

3. Riconoscere lo stesso cliente nei due archivi

Conservate una corrispondenza stabile tra i codici dei due programmi. Il cliente 245 nel gestionale può essere il contatto 891 nel CRM. Non unite automaticamente record soltanto perché hanno un nome simile o condividono una casella email: potrebbero riferirsi a soggetti, persone o sedi diverse.

La documentazione Microsoft sulla sincronizzazione Dataverse illustra identificatori esterni e chiavi alternative per individuare i record. Verificate quali possibilità offrono i vostri strumenti. I casi ambigui vanno risolti prima della prima copia, conservando ordini, attività e riferimenti collegati.

4. Decidere cosa succede quando le versioni divergono

Definite almeno tre situazioni: un campo aggiornato nella fonte, una modifica contemporanea nei due programmi e un valore vuoto. Un campo non compilato significa «nessuna informazione» oppure «cancellare il dato precedente»? La regola deve essere esplicita, altrimenti un’importazione incompleta può svuotare informazioni valide.

Usare sempre l’ultima modifica richiede cautela: un’importazione tardiva può contenere dati più vecchi, pur essendo stata eseguita dopo. Quando manca una regola affidabile, conservate entrambe le versioni e chiedete una decisione al referente. Anche disattivazioni e cancellazioni devono avere comportamenti concordati, evitando che la scheda riappaia dalla copia rimasta nell’altro archivio.

Esempio illustrativo: amministrazione e assistenza

Scenario ipotetico, senza riferimenti a clienti o risultati reali di Ethinova.

Un distributore usa il gestionale per l’anagrafica aziendale e un portale per gli interventi. L’amministrazione aggiorna la sede legale; l’assistenza aggiunge un recapito per il magazzino. Le informazioni hanno significati diversi e vengono conservate in campi distinti, associati allo stesso codice cliente.

Se un operatore propone dal portale una correzione della sede legale, la richiesta arriva all’amministrazione: non sovrascrive subito il gestionale. Dopo la conferma, il collegamento riporta la nuova versione nel portale. Il recapito del magazzino resta gestito dall’assistenza e non viene cancellato durante l’aggiornamento degli altri campi.

5. Rendere visibile quanto sono aggiornati i dati

Stabilite il ritardo accettabile per ogni uso. Consultare un referente e preparare una spedizione possono richiedere tempi diversi. Chiedete di mostrare l’ultima sincronizzazione riuscita e di distinguere un aggiornamento ancora in attesa da un errore che richiede intervento.

Non basta vedere che il collegamento è attivo. Confrontate periodicamente un campione di schede nei due archivi e assegnate le differenze a una persona. Accesso alle API, limiti del piano, frequenza, disponibilità dei fornitori e manutenzione incidono su fattibilità e costi: vanno verificati prima del preventivo, senza presumere che basti un connettore già pronto.

La prova da chiedere prima di estendere il collegamento

In un ambiente di prova, usate anagrafiche fittizie e controllate insieme questi casi:

  • Creazione di un cliente nuovo e associazione dei suoi codici.
  • Correzione di un solo campo senza alterare gli altri.
  • Modifiche diverse nello stesso momento, con decisione tracciabile.
  • Valore vuoto, nuova sede e contatto aggiuntivo.
  • Disattivazione della scheda e ripartenza dopo un’interruzione.

Se oggi il problema principale sono gli effetti ripetuti, approfondite come evitare duplicati e doppi invii. Per scegliere un primo perimetro leggete da dove iniziare con l’automazione. Per il collegamento tra archivi, invece, partite dalla mappa dei campi: è la base per valutare le automazioni e integrazioni.

Fonti