Excel non è un database, e la lista dei clienti non è un CRM

In quasi ogni azienda che chiama per un progetto esiste un file che nessuno chiama database e che si comporta come se lo fosse. Sta su un disco condiviso, ha un nome che finisce per «_def» oppure «_ultimo», e dentro ci sono i clienti: ragione sociale, telefono, ultima offerta fatta, e una colonna «note» dove il commerciale scrive a mano quello che si ricorda della telefonata di marzo. Funziona, nel senso che qualcuno lo apre ogni mattina e ci lavora.

Poi arriva il giorno in cui due persone lo aprono insieme, oppure quello in cui il commerciale che teneva la colonna «note» cambia lavoro, e si scopre che quel file non era un archivio: era la memoria di una persona sola, tenuta in un posto che sembrava condiviso.

La confusione ha una radice tecnica precisa, e vale la pena guardarla da vicino, perché è la stessa che porta un'azienda a comprare un CRM e a usarlo come un foglio di calcolo con le colonne più belle.

Un foglio di calcolo e un database non sono due gradi dello stesso strumento

Microsoft, che di Excel è il produttore e non ha nessun interesse a sminuirlo, lo scrive nella propria documentazione con parole che non lasciano margine: Excel è un flat file database, un archivio piatto, e come programma di fogli di calcolo è ottimizzato per l'analisi e il calcolo dei dati piuttosto che per fare da sistema di gestione di un database. La stessa pagina elenca quando conviene passare ad Access, e il primo criterio della lista è quello che riguarda ogni azienda con una rete commerciale: quando molte persone lavorano dentro l'archivio e servono opzioni robuste per gestire gli aggiornamenti in sicurezza.

«Piatto» non è un giudizio, è la descrizione di una forma. In un foglio ogni riga sta per conto suo e le colonne sono etichette: se lo stesso cliente compra due volte, o ha due sedi, o parla con due commerciali, la scelta è fra ripetere la ragione sociale su più righe e infilare due informazioni nella stessa cella. In un database relazionale quel cliente è un'entità sola, con un identificatore, e ordini, sedi e conversazioni sono tabelle separate che lo puntano. La documentazione Microsoft porta esattamente questo esempio: in un archivio relazionale ben disegnato i nomi dei clienti stanno in una tabella e gli indirizzi di fatturazione e spedizione in un'altra, perché ogni cliente può avere più di un indirizzo.

Il limite di righe arriva molto dopo il limite vero

Il numero lo citano tutti come se fosse il confine: un foglio in formato xlsx regge 1.048.576 righe per 16.384 colonne, mentre il vecchio xls si fermava a 65.536 righe. Nessuna azienda italiana di taglia media ci arriva con l'anagrafica dei clienti, e per questo il limite di righe è il meno interessante dei limiti. Quello che si incontra davvero, e si incontra a tremila righe come a trecento, è che il foglio non ha modo di rifiutare un dato scritto male, di garantire che una modifica passi tutta o niente, e di distinguere chi può cambiare che cosa.

Le quattro cose che un database fa e un foglio no

Sono quattro proprietà, e non sono funzioni avanzate da comprare a parte: sono il motivo per cui «database» esiste come categoria separata da «foglio di calcolo».

Il vincolo, cioè il dato che non si può scrivere sbagliato

In un database una colonna partita IVA accetta undici caratteri e rifiuta il resto, un campo obbligatorio non si lascia vuoto, una chiave unica impedisce che lo stesso codice cliente esista due volte. Il rifiuto arriva nel momento in cui qualcuno prova a scrivere, che è l'unico momento in cui costa poco. In un foglio la convalida dei dati esiste e si può impostare, ma protegge la digitazione e non l'incolla, e le anagrafiche si sporcano sempre nello stesso modo: «S.r.l.», «srl» e «S.R.L.» diventano tre aziende diverse per qualunque conteggio, e nessun conteggio avverte che sta contando tre volte la stessa.

La transazione, cioè il salvataggio che non riesce a metà

Spostare un ordine da un cliente a un altro significa toccare due righe. Se la prima modifica passa e la seconda no, l'archivio resta in uno stato che non è né il prima né il dopo, e la cosa peggiore è che nessuno lo sa. Un database tratta le due scritture come una sola operazione che riesce o viene annullata, e questa proprietà, che nel gergo si chiama transazione, è la ragione per cui i sistemi contabili non sono fogli di calcolo. In un foglio l'unità di salvataggio è il file: se si chiude a metà di un lavoro, la parte fatta resta e la parte da fare no.

La relazione, cioè il cliente che resta uno

Un cliente con tre sedi, dodici ordini e due referenti è, in un foglio, un problema di layout: o si ripete la riga e si accetta che il totale dei clienti sia sbagliato, o si aprono altre colonne fino a farne quaranta, oppure si spezza in tre fogli che poi qualcuno deve tenere allineati a mano. In un archivio relazionale la stessa situazione è la normalità: un record cliente, tre record sede, dodici record ordine, e ogni conteggio torna perché il cliente è contato una volta. Il momento in cui il foglio si rompe non è quando i dati sono troppi, è quando smettono di essere una lista e diventano una rete.

Il permesso, cioè chi può scrivere che cosa

La formulazione prudente su questo punto è quella di Microsoft, che indica Access invece di Excel quando molte persone lavorano nell'archivio e servono opzioni robuste per gestire gli aggiornamenti in sicurezza. Il punto non è che un foglio non registri niente, perché la cronologia delle versioni dei servizi cloud registra parecchio: il punto è che il permesso di un file si concede sul file, mentre in un archivio strutturato si concede sulla colonna e sulla riga. Un commerciale può avere il diritto di aggiornare lo stato di una trattativa e non quello di cambiare il listino applicato, e in un foglio condiviso quella distinzione si tiene con un accordo fra persone invece che con una regola del sistema.

Perché una lista di nomi non è un CRM

Fin qui la differenza è fra un foglio e un archivio. La seconda confusione costa di più, e riguarda quello che il commerciale usa ogni giorno: un elenco di nomi con i recapiti non diventa un CRM perché lo si chiama così, e non lo diventa nemmeno aggiungendo le colonne giuste.

Un CRM tiene tre cose che un elenco non tiene. La prima è lo stato, cioè dove sta ogni trattativa adesso, dentro una lista di stati possibili in cui il passaggio da uno all'altro significa la stessa cosa per tutti quelli che lo leggono. La seconda è la storia, cioè che cosa è stato detto, quando e da chi, con le mail e le chiamate attaccate al cliente e non alla casella di posta di chi le ha scritte. La terza è la responsabilità, cioè di chi è quel cliente e che cosa deve succedere dopo, con una data.

Un elenco di nomi non ha uno stato, ha una colonna dove qualcuno scrive una parola che vuole dire cose diverse a seconda di chi la scrive. Non ha una storia, ha una cella «note» che si sovrascrive. E non ha un passo successivo, ha la memoria del commerciale, che è un archivio eccellente e ha il difetto di andarsene con lui. Il giorno in cui va a lavorare da un concorrente, l'azienda scopre di possedere i recapiti e non le relazioni, e la distanza fra le due cose vale il fatturato che quei clienti facevano.

C'è un modo semplice per capire da che parte del confine si è: provare a rispondere, senza chiamare nessuno, alla domanda «che cosa abbiamo detto a questo cliente l'ultima volta e chi gliel'ha detto». Se la risposta richiede di girarsi verso una persona, l'informazione non è nell'archivio, e l'archivio non è un archivio. Che cosa faccia un CRM aziendale per intero, e quali problemi risolva dentro l'azienda prima che verso il cliente, è il seguito naturale di questa constatazione.

Il momento in cui il foglio smette di essere gratuito

Il costo di un foglio di calcolo non si vede nella riga di un bilancio, e si paga in due valute. La prima è il tempo di riconciliazione: le ore che qualcuno passa ogni mese a capire perché il totale del foglio commerciale non coincide con quello del gestionale, e che si ripetono identiche il mese dopo perché nessuna delle due parti ha torto abbastanza per cedere.

La seconda si presenta tutta insieme il giorno in cui si decide di uscirne, e nessuno la mette nel preventivo. Portare un'anagrafica da un insieme di fogli a un sistema non è un'importazione, è una riconciliazione: bisogna decidere quale delle tre versioni dello stesso cliente sia quella buona, che fare delle righe in cui la ragione sociale è scritta in due modi, come trattare i contatti che esistono in un foglio e non nell'altro. Chi ci è passato ricorda le giornate spese a incrociare colonne con CERCA.VERT per sapere quanti clienti si avesse davvero, e il numero che salta fuori è sempre più basso di quello che si credeva.

È l'unica volta in cui un'azienda misura la qualità del proprio archivio, e la misura da fuori. Prima di quel momento il foglio sembrava pieno di dati, dopo si sa quanti erano utilizzabili, e il costo di quel conteggio cresce con gli anni di foglio più che con il numero di righe. Sul lato opposto della stessa decisione, quello di quanto costi un sistema invece di un file, il confronto fra i piani dei CRM gratuiti fa i conti su contatti e invii e dice dove finisce la parte che non si paga.

Che cosa cambia quando l'anagrafica sta dentro l'ecommerce

Per chi vende online la questione ha una particolarità che ribalta le abitudini: l'anagrafica non si compila, si genera. Ogni ordine crea o aggiorna un cliente, e il numero di persone in archivio cresce da solo, senza che nessuno apra un file e senza che nessuno decida di farlo crescere.

Su Shopify il modo in cui quell'anagrafica si interroga dice bene la differenza di cui parla tutto questo pezzo. Un segmento di clienti non è una lista che si copia da qualche parte: è una query scritta in ShopifyQL, e la documentazione ne mostra la forma completa, con le clausole FROM e SHOW già fissate e il WHERE come unico posto da riempire. Nel WHERE si mettono i filtri, per esempio number_of_orders maggiore o uguale a cinque per chi ha fatto almeno cinque ordini, oppure la data dell'ultimo ordine, e si combinano con AND e OR: AND restringe, perché il cliente deve soddisfare tutti i criteri, mentre OR allarga, perché gli basta soddisfarne uno.

La proprietà che conta viene dopo, e non è nel modo in cui si scrive la query. Una volta creato il segmento, i clienti entrano ed escono da soli in base al fatto che soddisfino o no il criterio: non c'è un elenco da aggiornare perché non c'è un elenco, c'è una domanda che viene rifatta ogni volta che qualcuno la guarda. Un foglio filtrato, per confronto, è la fotografia della risposta di ieri, e resta corretta fino al primo ordine nuovo.

Un dettaglio da conoscere prima di costruirci sopra un automatismo, e non dopo: i filtri sulle date lavorano su giornate intere di ventiquattro ore e prendono per default il fuso orario del negozio, che è il genere di assunzione che spiega la differenza di qualche decina di clienti fra due segmenti che sembravano identici.

Fare in modo che l'anagrafica del negozio e quella del gestionale siano la stessa anagrafica è un lavoro a sé, con le sue scelte su chi tiene il dato buono e in quale direzione si sincronizza, e sta nella guida sulle integrazioni fra i sistemi. Quando invece il tema è leggere quei dati per decidere, e non farli circolare, il confronto fra gli strumenti di business intelligence parte dai nativi di Shopify e spiega quando smettono di bastare.

E se la domanda è che cosa cambi dentro un CRM quando dietro c'è un negozio online invece di una rete di agenti, la parte del discorso che riguarda ordini, resi e valore nel tempo di un cliente è quella del CRM per l'ecommerce, dove l'archivio non è più solo il posto in cui si scrive chi ha comprato.

Quando il foglio di calcolo è la risposta giusta

Un pezzo che dicesse che Excel non va mai bene sarebbe smontato dal primo direttore commerciale che lo legge, e avrebbe ragione lui. Il foglio di calcolo è lo strumento migliore che esista per tre lavori precisi, e in tutti e tre un sistema strutturato è la scelta peggiore.

Il primo è il calcolo esplorativo: provare un'ipotesi di sconto su un listino, costruire uno scenario, vedere che numero esce cambiando un'assunzione. È esattamente dove Microsoft colloca il vantaggio di Excel, che è ottimizzato per l'analisi e il calcolo, e chi prova a fare la stessa cosa dentro un CRM finisce per esportare in Excel, che è la dimostrazione pratica del punto.

Il secondo è il foglio che vive tre settimane e poi si butta: i partecipanti a una fiera, i trenta clienti da chiamare per una promozione, l'inventario contato a mano un sabato. Costruire una struttura per una cosa che muore in venti giorni è uno spreco, e il file temporaneo è il posto corretto.

Il terzo è la fase in cui l'azienda non sa ancora che cosa voglia tracciare. Un CRM configurato prima di aver capito quali siano gli stati di una trattativa produce campi che nessuno compila, ed è peggio di un foglio, perché a un archivio mezzo vuoto le persone smettono di credere in fretta e poi non ci tornano. In quella fase il foglio è il prototipo, serve a scoprire quali colonne servano davvero, e va usato sapendo che è quello.

La regola che tiene insieme le tre eccezioni è una. Il foglio va bene quando è di una persona, o di poche che si parlano, e quando ciò che contiene non è l'unica copia esistente di un'informazione da cui dipende il lavoro di qualcun altro. Nel momento in cui diventa l'unico posto in cui una cosa è scritta, ha cambiato mestiere senza che nessuno lo abbia deciso, e da quel giorno il rischio non è più di sbagliare un calcolo.

Come si esce, senza fermare chi vende

Il passaggio che funziona non comincia dall'importazione, comincia dal disegno di dove stanno i dati adesso: quanti fogli esistono, chi li tiene, e quale dei tre è quello che si guarda quando i numeri divergono. È un lavoro di mezza giornata e serve a scoprire una cosa che quasi sempre sorprende, cioè che i fogli sono più di quanti l'azienda credesse e che almeno due si contraddicono su qualcosa che nessuno aveva mai confrontato.

Poi si importa poco. La tentazione, davanti a un sistema che non mette limiti stretti al numero di contatti, è di portare dentro tutto quello che c'è, e il risultato è un archivio in cui il commerciale non trova il cliente che cerca e torna al suo foglio entro un mese. Si portano dentro i clienti attivi e le trattative aperte, e il resto resta dove sta, recuperabile e fuori dalla vista.

Serve anche mettersi d'accordo sulle parole, che è il punto in cui le importazioni si sporcano davvero: chi è un contatto, chi è un lead, chi è già un cliente. Le distinzioni fra prospect e contatti non sono lessico, sono le regole che decidono in quale tabella finisce una riga e quindi che cosa un conteggio conterà.

Il resto è un progetto, con le sue scelte su quale sistema tiene il dato buono e su che cosa succede quando due sistemi non sono d'accordo, e su questo lato del lavoro ICT Sviluppo interviene con i progetti CRM. Vale una precisazione, perché è il genere di cosa che si scopre a metà: la scelta dello strumento è la parte facile, e quella difficile è decidere chi in azienda risponde della qualità di quell'archivio, perché un sistema senza un responsabile del dato torna a essere un foglio di calcolo con l'interfaccia migliore.

Domande frequenti

Si può usare Excel come database?

Si può, e per un archivio semplice funziona: intestazioni univoche nella prima riga, un identificatore per ogni record, l'area convertita in tabella. Resta però un archivio piatto per sua natura, e la documentazione Microsoft indica di passare a uno strumento relazionale quando molte persone lavorano sugli stessi dati e servono garanzie sugli aggiornamenti. La domanda utile non è se si possa, è per quanto tempo conviene.

Quante righe regge un foglio di Excel?

Nel formato xlsx il foglio arriva a 1.048.576 righe e 16.384 colonne, mentre il vecchio formato xls si fermava a 65.536 righe, e i limiti non sono modificabili. Nella pratica un'anagrafica clienti diventa ingestibile molto prima di quei numeri, per ragioni che non riguardano la capienza ma il fatto che più persone la scrivono insieme.

Meglio Excel o Access per gestire i clienti?

Microsoft mette il confine dove serve: Excel quando i dati sono in prevalenza numerici e servono calcoli, analisi e tabelle pivot, Access quando molte persone lavorano nell'archivio, quando si prevede di aggiungere altre tabelle a un insieme nato piatto, e quando servono interrogazioni complesse. Per un'anagrafica clienti condivisa fra vendite e amministrazione i criteri corrispondono al secondo caso. Se poi la scelta debba cadere su Access o su un sistema pensato per la relazione con il cliente è un'altra domanda, e dipende da quanto quell'anagrafica deve parlare con le mail, il sito e gli ordini.

Excel può funzionare come CRM?

Per una fase iniziale, e per una persona sola, un foglio con le trattative, la data dell'ultimo contatto e il prossimo passo copre il bisogno meglio di un CRM configurato male. Non tiene lo stato condiviso, la storia delle conversazioni e la responsabilità su chi fa che cosa, che sono le tre proprietà per cui la categoria esiste, e ognuna delle tre manca in un modo che si nota solo quando serve.

Fogli Google risolve i problemi di Excel?

Risolve il più visibile, cioè le copie del file che si moltiplicano, perché più persone modificano lo stesso documento e la versione unica esiste per costruzione. Permette anche di proteggere singoli intervalli e di scegliere chi possa modificarli, con la funzione che sta in Dati e poi Proteggi fogli e intervalli, ma è Google stessa a scrivere che quella protezione non va usata come misura di sicurezza. Non cambia invece la forma dei dati, che resta piatta: un foglio condiviso bene resta un foglio.

Come si passa da Excel a un CRM senza perdere i dati?

Prima si censiscono i fogli che esistono e si decide quale sia la fonte buona per ogni tipo di informazione, poi si importano solo i clienti attivi e le trattative aperte, e i duplicati si risolvono prima di importare e non dopo. La parte che richiede più tempo non è tecnica, è mettersi d'accordo su che cosa significhi «cliente attivo», e conviene farlo con chi vende nella stanza, perché è la persona che poi dovrà trovarci dentro il proprio lavoro.