Il Data Model è la struttura logica delle informazioni che all'azienda servono per gestire la propria attività. In termini generali, tutte le informazioni che attraversano l'azienda fanno parte del Data Model.
In questo articolo vogliamo tracciare solo quello che passa nel CRM e che quindi riguarda la relazione tra l'azienda e i suoi clienti nelle varie fasi del Buyer's Journey, prima, durante e dopo l'acquisto.
Che cos'è il Data Model
L'obiettivo di questa rappresentazione digitale è quello di creare un Twin Model informatizzato da cui ricavare informazioni o grazie a cui progettare azioni e interazioni con l'oggetto reale per stimolare, spingere o facilitare la relazione d'acquisto tra l'azienda e i propri clienti, nel breve, medio e/o lungo termine.
In particolare, il Data Model riguarda le informazioni che interessano ai seguenti reparti:
- Marketing
- Commerciale
- Post Vendita
- Logistica
- Amministrazione
Non è detto che ad altri reparti (IT, legal, produzione) non possano interessare informazioni di relazione con cliente. Anzi, è opportuno che tutta l'azienda sia orientata a risolvere i problemi dei clienti, e quindi a conoscerli.
Qual è la composizione del Data Model
Il Data Model si compone di più parti:
Vediamole di seguito nel dettaglio.
1. Infrastruttura
L'infrastruttura del Data Model è lo schema generale che identifica gli oggetti da tracciare all'interno del mio CRM. Per oggetto intendo dire un record complesso, composto di informazioni associate a quel record, che rappresenta un "oggetto" della realtà.
I più comuni oggetti tracciati dai CRM sono:
- Contatti
- Aziende
- Offerte
- Prodotti
- Consegna ordini
- Processi di assistenza
Di base, un buon CRM offre questo tipo di struttura nella sua versione di default, e consente di aggiungere o modificare oggetti secondo il bisogno. In HubSpot, ad esempio, esistono i Custom Objects che consentono di andare oltre l'infrastruttura di default, che pure è già molto articolata e nel 70% dei casi è più che sufficiente a trattare l'esistente.
Un paio di considerazioni sull'infrastruttura:
a. Le cose sembrano semplici, ma non lo sono
Ogni azienda ha abitudini diverse, chiama gli oggetti in modo diverso e li tratta secondo una logica particolare e personalizzata.
Ad esempio, un primo classico problema si ha nella distinzione tra Contatti (persone a cui ci rivolgiamo) e Aziende (organizzazioni con le quali intratteniamo relazioni commerciali).
Molte aziende B2B confondono le aziende con le persone, registrando sotto la Company anche i dati personali di uno (o più) dei propri referenti, come l'email, il cellulare, il ruolo aziendale.
Non è semplice, a volte, comprendere come qualsiasi azienda ha una natura giuridica e dei bisogni dettati dal proprio modello di business, ed è distinta dalle persone che la compongono, con le proprie caratteristiche personali, anche nel caso in cui le due cose coincidano. Lo studio dell'Avvocato Rossi, con le sue specializzazioni, il suo fatturato, i suoi acquisti è diverso dalla persona Rossi Sig. XYZ, con la propria data di nascita, le proprie passioni, il proprio numero di cellulare e i propri comportamenti personali.
b. La complessità si può standardizzare
Gli oggetti standard di un CRM evoluto come HubSpot sono spesso più che sufficienti a mappare le relazioni aziendali. A volte, però, è necessario andare oltre. Se la mia azienda è un Centro Medico privato con un certo numero di sedi, di prestazioni, di medici, di macchinari, di laboratori e di clienti, potrei aver bisogno di un Data Model particolare. Prendiamo quello base e vediamo cosa non rientra:
- Contatti: qui possono starci sia i pazienti che i medici, distinti con una proprietà ad hoc;
- Aziende: potremmo avere aziende clienti (ad esempio, per la medicina del lavoro), aziende fornitrici, laboratori di analisi, anche in questo caso distinti con una semplice proprietà;
- Offerte: le offerte potrebbero tracciare tutti gli esami prenotati dai clienti, in ogni area e disciplina;
- Prodotti: i prodotti potrebbero tracciare tutte le prestazioni che il Centro Medico mette a disposizione;
- Consegna ordini: in questo caso si potrebbe tenere traccia del processo di consegna degli esiti delle analisi;
- Processi di assistenza: con questo oggetto si possono gestire le vere e proprie richieste di assistenza dei clienti.
Quello che potrebbe restare fuori dalla struttura base del CRM è, ad esempio, la gestione delle sedi in cui avviene la prestazione, che potrebbero essere un Custom Object da associare agli altri elementi di volta in volta. Dipende comunque dal numero e dalla complessità dei dati da rilevare.
Quindi, per partire col piede giusto nella costruzione del Data Model, è fondamentale stabilire l'infrastruttura di oggetti da monitorare.
2. Proprietà
Le proprietà sono gli attributi degli oggetti che possono assumere diversi valori e rendere gli oggetti distinguibili e segmentabili.
- Una classica proprietà dell'oggetto Contatto è, ad esempio, il ruolo aziendale (produzione o commerciale?);
- Una classica proprietà dell'oggetto Azienda è, ad esempio, il settore operativo (farmaceutico o food?);
- Una classica proprietà dell'oggetto Trattativa è, ad esempio, l'ambito oggetto della trattativa (si tratta di ricambi, macchinari o manutenzione?).
L'insieme di queste proprietà definisce l'oggetto e consente di distinguere determinate categorie di oggetti (per esempio, tutte le aziende del settore food che hanno aperto trattative per macchinari nell'ultimo anno).
Se la definizione dell'Infrastruttura è complessa solo nelle aziende più grandi, la definizione delle proprietà è uno sforzo anche per le aziende più piccole. Nella maggior parte dei casi, la soluzione del Data Model sta proprio nel definire la combinazione di proprietà da associare agli oggetti standard, senza duplicazioni o sovrapposizioni.
3. Relazioni
La relazione tra diversi oggetti tra loro è uno step spesso scontato ma che va analizzato e definito. Tipicamente, un contatto è associato a una sola azienda, mentre un'azienda potrebbe essere associata a più contatti.
Ma non è sempre così: un Commercialista, al contrario, avrà molte aziende associate, e un'azienda avrà un solo Commercialista ma molti dipendenti. Come distinguere questi ruoli nel CRM? Esistono etichette di associazione? Si possono personalizzare?
Un altro esempio classico è la possibilità di associare Contatti tra loro (ad esempio, a formare famiglie).
Insomma, anche le relazioni vanno mappate e descritte nel Data Model.
4. Interazioni
Le interazioni sono l'ultimo tassello del Data Model e indicano quali interazioni è importante mappare. Vogliamo sapere quante email scambia un certo contatto con i nostri commerciali e quanti appuntamenti richiede per ogni nuovo acquisto? Vogliamo vedere come interagisce con le nostre newsletter e con le nostre landing page? Vogliamo controllare a quanti webinar si è iscritto nell'ultimo anno?
Tutte le interazioni attive o passive del nostro cliente nei nostri confronti possono essere oggetto di tracciamento (manuale o automatico) e quindi far parte di quegli elementi che ne definiscono il profilo complessivo.
Perché dovresti scegliere un Data Model
La definizione del Data Model del CRM non è un esercizio teorico, al contrario. Un buon Data Model, per quanto semplice, consente all'azienda di intraprendere azioni verso i clienti per aumentare le proprie vendite e i propri fatturati, con una precisione e un'efficacia che senza questo tipo di strumento sono sostanzialmente impossibili.
