Come si crea un CRM (parte terza)

Ultima uscita prima delle vacanze. L’ho sempre detto: “le ferie si prendono, le vacanze si fanno!”. Quindi, prima di scordarmelo, buone vacanze a tutti!!
La volta scorsa abbiamo visto da dove recuperare i dati per creare il nostro CRM. Dall’esterno è la prima scelta, accettate questo suggerimento: costano, si pagano ma vi creano molti problemi in meno e avrete sempre qualcuno su cui far ricadere la colpa nel caso in cui (probabilissimo) i dati non siano corretti!

A questo punto possiamo caricare il nostro database e iniziare ad usarlo. Perché? Banalmente: è un database operativo, bisogna usarlo per trarne vantaggio, e più lo uso meglio è.

Non state a rimirare il vostro database, non state a dire “Oddio, e adesso?” Se l’avete creato usatelo. Un CRM, un e-CRM, un DBM è un qualcosa di operativo, un qualcosa che si usa tutti i giorni (o quasi) e che sfrutto e miglioro più lo uso.

Ho visto nella mia vita fantastici CRM usati per una-due campagne a semestre: può essere, perché no? Se una società si crea un database di marketing per una/due campagne al semestre ed è in grado di sostenerlo (operativamente ed economicamente) non c’è problema. Ma è chiaro che più lo uso più ne traggo vantaggio. Più lo uso più lo miglioro.

Un database di marketing va utilizzato. E anche se non ho completato il disegno architetturale al completo mi conviene iniziare ad usarlo. Perché solo sfruttandolo, solo vedendo come il mercato reagisce alle mie sollecitazioni, solo sfruttandolo appieno sono in gradi di migliorarlo.

Rendiamoci infatti conto che un database di marketing non è un qualcosa di immutabile nel tempo. 20 anni fa un DbM aveva indirizzo, telefono e fax. 10 anni fa aveva e-mail, cellulare, indirizzo e telefono. Oggi ha profilo Facebook, profilo Linkedin, profilo Twitter, e-mail, cellulare aziendale, cellulare privato, indirizzo. E fra dieci anni chissà cosa avrà. Un CRM non può nascere e morire con la stessa struttura, se lo uso quotidianamente. Anni fa le campagne via Internet non erano neanche immaginate, oggi lo sono. Anni fa il fax era lo strumento immediato per dialogare con i nostri clienti, oggi è usato principalmente per comunicazioni amministrative e/o per campagne di pronto ritorno.

Il nostro database, per quanto sia stato costruito accuratamente, non può essere immutabile. E Più lo uso più scopro le necessità del mercato e le mancanze del mio db.

Il processo per modificare la struttura del database deve essere codificato e condiviso all’interno dell’azienda: e più persone usano il db per più scopi più devo codificarlo da un lato e condividere le necessità di variazione dall’altro. Attenzione quindi a non compiere tre errori:

  • Non cambiare la struttura del db per problemi tecnici, relazionali, decisionali. SI BLOCCA IL CRM
  • Al contrario, cambiare la struttura frequentemente per allineare sempre il db alle mutate condizioni del mercato. SI CAMBIA TROPPO SPESSO IL CRM
  • Cercare sempre e comunque il consenso interno, non scontentando nessuno. NON SI MODIFICA IL CRM

I tre risultati sono i principali output delle tre scelte, ma ce ne sono molti altri derivanti da questi.

È fondamentale definire quindi il decisore finale sull’evoluzione del DBM/CRM: definire colui che decide, sempre e comunque. La democrazia, lo sapete meglio di me, non esiste in azienda (o esiste in poche e molto illuminate…): ci vuole un qualcuno che decida, sempre ed in termini piuttosto rapidi. Più gente parla e utilizza il DBM/CRM meglio è, ma alla fine deve esserci uno e uno solo (reparto, direzione, persona, non è questo il problema) che decide. Logica vuole che il DBM/CRM sia di proprietà del marketing, quindi dovrebbe essere questo reparto a decidere: ma in alcune aziende non è così, e non è compito nostro discutere queste scelte.

Sono quindi importanti due cose: utilizzare il DBM/CRM e farlo evolvere, per essere sempre allineati alle necessità aziendali e supportarle nella maniera appropriata.

A Settembre torneremo, e allora passeremo alla pratica: lanciare una campagna via CRM, aspettare i ritorni, misurarli, aggiornare il DBM, migliorarlo, etc. etc. etc. A Settembre, non adesso…buone vacanze!