e-Mail Marketing in Italia e per gli Italiani Capitolo 3: Database e Mailing List

Capitolo tosto, questo, che ripartiremo in due filoni complementari, affrontando l’argomento prima dal punto di vista funzionale, poi da quello strutturale.

Dopo di che prenderemo in esame gli aspetti organizzativi ed operativi, fondamentali per la riuscita e la vita del nostro sistema.

Partiamo però dalla domanda finale: quando inviamo un qualsiasi messaggio stiamo scrivendo a degli indirizzi, a dei record di un Database, o a delle persone che possono essere i nostri clienti, i futuri clienti, i partner, in ogni caso gli individui che ritenuamo cruciali per la nostra attività?

Sembra una domanda sciocca, ma basta guardare l’attenzione, l’impostazione, la cura che molte aziende mettono nell’allestire, nel gestire, nel proteggere il proprio Database per rendersi conto della trascuratezza con la quale viene normalmente considerato.

I dati, il Vero Patrimonio dell’Azienda 2.0

Nel mio libro «Fare Impresa nell’Era 2.0» tratteggio le componenti strutturali delle aziende di nuova generazione che virtualizzandosi e fondando il proprio successo sulla generazione di valore aggiunto «riconosciuto» dai clienti, perdono il legami tradizionali che le volevano vincolate ad una sede, ad una gerarchia organizzativa, a dei dipendenti, ad un capitale o a delle materie prime.

Il denaro diventa così «componente produttiva acquistabile», così come lo sono il lavoro, le infrastrutture, le merci, i diritti d’uso di eventuali brevetti e via dicendo. Ma la logica è che si comprano «servizi», non componenti, e sul mercato vince chi è in grado di fornire il più elevato Valore Aggiunto, alle Condizioni Migliori.

Chi e ciò che genera valore aggiunto viene ripagato di conseguenza, mentre tutti gli altri vengono considerati costi, da ridurre o eliminare quanto più possibile.

L’azienda può quindi esser ovunque, affacciandosi al mondo attraverso la rete, risultando riconoscibile attraverso il proprio marchio, funzionando in base a processi che collegano nodi che generano valore aggiunto indipendentemente dalla loro collocazione dei mondo, e fondando il proprio successo sul sistema di relazioni che è in grado di impiantare e sviluppare nel tempo.

A questo punto, il valore del Database, che è il motore grazie al quale si gestisce il sistema di Relazioni, diventa evidente in tutta la sua portata: non semplicemente un archivio di nomi, ma uno dei perni attorno ai quali costruire l’intera organizzazione.

Alcuni esempi? Pensiamo a Google, che sa tutto dei propri clienti e dei clienti dei propri clienti, che gestisce le proprie attività attraverso procedure informatizzate e che attira i clienti attraverso il proprio marchio. Stesso discorso anche per Ryanair che, a differenza di Google, opera nel tradizionale mercato del trasporto aereo o per Amazon che, partita dai libri, oggi vende beni di ogni genere…

Il Database, perno del sistema di relazioni: aspetti funzionali

So che a questo punto sto per sfondare molti tabù, ma penso valga la pena di farlo, anche a rischio di creare molte tensioni tra gli attori coinvolti nella gestione dei dati dell’azienda.

Partiamo da una vista allargata, per poi scendere ad aspetti più pratici e arrivare a definire un percorso «virtuoso», ma soprattutto praticabile. 

Molto spesso, in azienda troviamo vari Database gestiti di volta in volta da organizzazioni chiamate e svolgere ruoli ben specifici. Ad esempio, legato alle procedure di contabilità ci sono l’archivio dei clienti, che normalmente è diverso da quello dei fornitori, quello degli Agenti, che di fatto è come se fossero dei fornitori, ma in realtà sono dei collaboratori dell’azienda, quello dei partner.

In un altro reparto dell’azienda ci sarà l’archivio dei dipendenti, che fa capo alla funzione del Personale, mentre da qualche altra parte c’è quello dei potenziali clienti e dei clienti non più attivi, gestito dal Marketing e/o dalle Vendite.

Se poi andiamo in una Banca, è facile trovare un archivio con i correntitsti, uno con i titolari di depositi titoli, uno per chi ha sottoscritto dei mutui e via dicendo.

Ma se pensiamo in termini logici – e funzionali – un dipendente può essere anche un cliente dell’azienda, così come lo può essere una persona che è nello stesso tempo dipendente di una società partner o fornitrice dell’azienda.

Nel momento in cui ci indirizziamo con i nostri messaggi a degli individui dovremo pertanto esser ben consapevoli di verso chi ci stiamo dirigendo, avendo una vista coerente, strutturata e aggiornata dell’insieme. Ad esempio, supponiamo di voler lanciare un’offerta riservata ai dipendenti o ai nuovi clienti: se l’archivio dal quale attingo tali dati non è aggiornato o non dispone della possibilità di farvi delle estrazioni mirate, l’iniziativa cade risultando impossibile o rischiosa da svolgere. Ma anche se l’archivio non è aggiornato, rischiamo di inviare messaggi che tornano indietro, o che arrivano a destinatari che non volevamo coinvolgere in questa iniziativa…

Il che impone la necessità di affidare ad un unico responsabile la gestione dell’archivio, definendovi i campi da inserire, i criteri di selezione, quelli di accesso, di aggiornamento e tutti i meccanismi di integrazione affinche i dati suano fruibili da tutti coloro che ne hanno diritto. Il problema è aggravato da due elementi particolarmente critici: da un lato, la necessità di proteggere i dati che essendo patrimonio dell’azienda non vanno dispersi, né «rubati», dall’altro l’obbligo di rispettare le normative in tema di «privacy».

Il Database: Fonti e Motori

Una volta stabilito il «responsabile» del Database, che nella moderna terminologia assume il ruolo di «Data Stewart», il passo successivo è costituire una sorta di Comitato trasversale dell’azienda attraverso il quale individuare i campi, definire la terminologia con la quale definirli, le frequenze ed i meccanismi di aggiornamento partendo dagli archivi già presenti in azienda.

Le fonti possono esser molte: gli ERP della contabilità, i sistemi di gestione del personale, gli esiti delle verifiche di affidabilità dei potenziali clienti a fronte di forniture di una certa consistenza, le schede che provengono dai partecipanti ad un determinato evento, i moduli compilati in risposta a campagne promozionali o via Web, i dati acquisiti da fornitori di servizi esterni, tutti i dati raccolti dal personale di vendita nel corso delle sue attività di contatto con i clienti.

Un modo per far confluire tutti questi dati in un unico ambiente è rappresentato dai sistemi di CRM (Customer Relationship Management), che però nella gran parte dei casi, in mancanza della regia unica data da un Data Stewart, vivono di vita propria, gestiti dal personale di Marketing e Vendite.

Anche i più diffusi sistemi di Mail Management offrono un motore per la gestione dei contatti, ma in questo caso il servizio si limita a monitorare gli invii e le eventuali iscrizioni/cancellazioni dalle liste di invio, risultando così estremamente limitati rispetto alle vere necessità dal punto di vista aziendale.

Il Database: esempio di dati individuali per assicurare servizi di Mailing Management di qualità

Giusto come esempio, forniamo un paio di maschere estratte dal Database di BCI Italia, sviluppato in ormai oltre venti anni di attività.

Qui c’è la vista sugli «individui» (con i riferimenti diretti resi incomplensibili per questioni di riservatezza) che, accedibile via cognome, propone l’anagrafica della persona completa della sua storia: il curriculim vitae, i contatti avuti e quelli in corso, le presenze ad eventi, i prodotti acquistati, l’azienda di appartenenza, i recapiti.

Di recente, la voce «fax» è stata sostituita da quella «skype».

Alcune parti sono «libere», tipo l’area che contiene la storia dei contatti, con anche gli eventuali collegamenti a fotografie, documenti e altro, mentre i campi «Qualifica», «Attività» sono codificati in modo da poter fare ricerche mirate per funzione, area di interesse, lavoro.

Da qui, si percepisce chiara l’idea che noi ci rivolgiamo ad «individui» e non ad «anagrafiche», cercando di mantenere un rapporto tra persone, mirato e documentato, potendo sempre optare tra gli approcci individuali e quelli di tipo più generico e formale.

Un punto importante, sul quale torneremo, è la casella «No Send». Per rispettare le normative sulla Privacy, quando un utente chiede di essere eliminato dalle liste di distribuzione delle newsletter – nel nostro caso di ITware – l’indirizzo non va «cancellato», ma mantenuto con l’indicazione di non invio, proprio per evitare di riutilizzarlo in modo inappropriato.

Un secondo campo molto importante è quello della «Fonte», in questo caso vuoto. Serve a documentare la provenienza del contatto quando non è diretta, così da evitare qualsiasi inconveniente e contestazione, rimanendo sempre nella piena legittimità delle normative vigenti.

Il campo «limbo» viene invece usato quando la persona non risulta più essere presente nell’azienda indicata nella scheda.

E’ importante sottolineare che le persone, nell’arco della propria vita professionale, possono cambiare azienda, ruolo, funzione, trasformarsi da clienti a fornitori, a dipendenti e viceveresa. Indipendentemente da tutto, nel bene e nel male, la relazione con esse continua ad essere sempre parte cruciale del patrimonio dell’azienda, per cui va mantenuta attiva e aggiornata: se una persona cambia azienda, spesso è sua cura segnalarci il cambiamento, ma se così non è, va ricercata non appena se ne percepiscono i cambiamenti.

Il Database: esempio di dati aziendali per i servizi di Mail Marketing

Qui c’è la vista sull’azienda e le sue sedi, dalla quale si può accedere anche agli «individui» (con i riferimenti diretti resi incomplensibili per questioni di riservatezza). Accedibile via ragione sociale o Partita IVA, propone l’anagrafica completa, sia in modo riepilogativo, sia in dettaglio con tanto di profilo, storia e parametri di ricerca codificati: Area Mercelogica, Dimensioni per Fatturato e numero dipendenti totali e della Direzione Sistemi Informativi, CAP, Città, ecc.

Dati che riguardano indifferentemente le aziende «clienti», «partner» e «prospect» essendo condivisi e costantemente aggiornati sia dalle funzioni Amministrative, sia da quelle Marketing, Vendite e Documentazione.

Il Database: il Sistema di Codifica

Chiarito dunque che anche ai fini del Mailing Management è sconsigliabile utilizzare Database esterni dedicati, nell’impostare il proprio Database sarà indispensabile stabilire a priori i possibili criteri di selezione da adottare.

L’analisi deve prendere in esame i parametri di ricerca, ma anche i range da adottare, così come il sistema di codifica da utilizzare in seguito nel corso delle interrogazioni. Ad esempio, pensando alla segmentazione mercelologica sarà bene prendere come riferimento i codici ISTAT, semplificandoli in funzione delle proprie esigenze aziendali. Allo stesso modo, per le funzioni del personale si potrà ragionare in termini di classi di responsabilità, per poi scendere sempre più nello specifico mano a mano che le esigenze lo dovessero richiedere.

La Qualità dei Dati per i servizi di Mail Marketing

Dopo di che, si pone il problema della Qualità dei Dati: duplicazioni, omonimie errori di digitazione, imprecisione, incompletezza possono generare una grande quantità di costi evitabili, la cui difficoltà di indivuduazione è esponenziale rispetto al crescere delle dimensioni e dell’uso dei Database. Per tale ragione occorre procedere in due direzioni

1. Sensibilizzando tutti gli «attori» coinvolti nei processi di aggiornamento, così come i responsabili ed i controllori, sulla necessità di garantire la qualità dei dati immessi e di aggiornarli costantemente;
2. Attrezzarsi con strumenti specifici di controllo della qualità, in grado ad esempio di rilevare potenziali duplicazioni, di completare o correggere CAP errati, partite iva inconsistenti e via dicendo.

Su questo argomento torneremo nel capitolo riguardante gli invii in massa, esaminando nel dettaglio alcuni strumenti e servizi specifici per la verifica degli indirizzi di posta elettronica.

Il Database: Aspetti Strutturali

Strutturare il Database è un lavoro critico, serio e molto complesso, che non va improvvisato ma affidato a specialisti. Ad esempio, pensare di usare un’unica tabella Excel può risultare molto pratico, ma altrettanto dispendioso in termini di tempo e soprattutto assolutamente senza futuro.

Per la stessa ragione, studiare le tabelle da creare è molto importante per garantirsi la sopravvivenza del proprio Database.

Faccio alcuni esempi. L’azienda è un’entità unica in fatto di Partita IVA, Ragione Sociale, Sede Legale e casella di posta certificata. Ma una stessa azienda può avere molte sedi ed un numero ancora più elevato di individui.

Nel tempo, gli individui possono cambiare sede o azienda, per cui un loro spostamento deve poter esser fatto semplicemente ricollocandoli nella nuova sede e/o azienda.

Ma anche un’azienda può riconfigurare le proprie sedi, accorpandole, trasferendole o cancellandole. Così come l’azienda stessa può fondersi con altre per dar vita a nuove aziende che mantengono le stesse sedi di prima. Basti pensare a cos’è successo in questi ultimi anni all’intero sistema bancario nazionale tra acquisizioni, fusioni, cessioni di intere reti distributive. Questo vuol dire che da un lato dovremo avere la tabella con le aziende, dall’altro quella con le sedi, quindi quella con gli individui.

A loro volta, le sedi hanno un CAP, mentre gli individui possono avere un ruolo o un’area di interesse. Ed uno stesso individuo può avere vari interessi, effettuare diversi acquisti, sottoscrivere una lista di distrubuzione e non altre. Di conseguenza si dovranno creare tabelle per i ruoli, gli interessi, i prodotti, gli acquisti e così via. Gli interessati alle funzioni dovranno esser precisi nel dettare le proprie esigenze agli specialisti che dovranno poi strutturare correttamente il Database e dotarlo di tutte le funzioni di interrogazione e controllo per minimizzare le difficoltà d’uso, evitare duplicazioni ed errori, automatizzare l’inserimento di dati ricorrenti o derivanti in modo univoco da altri elementi, tipo il CAP con l’indirizzo.

Se fatto bene si dall’inizio se ne potranno trarre numerosi vantaggi in fase di inserimento, aggiornamento, selezione dei destinatari delle nostre mail. In caso contrario si dovrà continuamente sopperire «arrangiandosi» alle mancanze iniziali.

Si potranno inoltre creare dei programmi per inserire in automatico nuovi indirizzi o rimuovere quelli che risultano non più aggiornati, riducendo al minimo il lavoro manuale ed i pericoli di creare duplicati.