DAL CODICE CONTRATTO AL CODICE CLIENTE Elena

DAL CODICE CONTRATTO AL CODICE CLIENTE
Elena Castaldi, Alberto Saccardi NUNATAC
Abstract
Identificare il ‘Cliente’ come cardine del disegno strategico aziendale porta alla necessità di disporre di
informazioni relative al comportamento della clientela stessa. Infatti, in un contesto di questo tipo, misurare
il numero dei nuovi clienti acquisiti è importante tanto quanto misurare l’incremento delle vendite, così
come valutare il ‘life time value’ è essenziale quanto valutare il margine sul prodotto.
Tuttavia dati di questo tipo non sempre sono prontamente disponibili. In particolare, questa difficoltà è
enfatizzata nei casi in cui il business è finalizzato alla sottoscrizione di una polizza, di un conto corrente o
di un abbonamento ed il sistema informativo è strutturato per la gestione del singolo contratto.
In questo lavoro, sintesi dell’esperienza maturata nella costruzione di Database di marketing (DBMa) in
diversi settori, esporremo come affrontare e risolvere alcune delle principali criticità nella realizzazione di
un DBMa partendo da un Sistema Informativo Gestionale organizzato per codice contratto.
Introduzione
Se a diverse aziende chiedessimo chi sono i loro
Clienti, molto probabilmente avremmo una risposta
immediata e certa; ma se chiedessimo: ‘Quanti sono
i vostri Clienti?’, che tipo di risposta ci si potrebbe
aspettare?
Sicuramente sapremmo che esistono un certo
numero di contratti, oppure un certo numero di conti
correnti, o, ancora, un certo numero di
abbonamenti; ma solo, forse, con molta
approssimazione riusciremmo a quantificare la
consistenza della clientela.
Questo dipende dal fatto che molti Sistemi
Informativi di tipo gestionale hanno strutture che,
pur gestendo l’anagrafica della clientela, talora
prescindono dal concetto di Cliente.
Le aziende, però, si stanno sempre più rendendo
conto di cosa significhi, in termini di vantaggio
competitivo, avere dati corretti e fruibili sulla loro
clientela, sia in termini qualitativi che quantitativi.
Come si può, infatti, definire quanto investire, in
termini promozionali, su un singolo cliente se non si
hanno informazioni relative al suo fatturato, oppure
se non si sa se un cliente ha sottoscritto tre contratti
nell’ultimo anno oppure solo uno? Ancora, come è
possibile definire gli obiettivi di una Rete di
Agenzie se non si conosce esattamente la
consistenza del loro portafoglio clienti?
Per dare risposte concrete a queste domande e
quindi gestire un approccio al mercato orientato al
cliente, definito Database Driven Direct Marketing,
occorre passare da un sistema informativo
incentrato sulla gestione del contratto (polizza, o
abbonamento che sia) ad un sistema che individui il
Cliente come soggetto logico di riferimento.
DDDM
Dati
Interni
Dati
Esterni
Gestore
anagrafiche
Data Mart
Analisi Cliente
Segmentazione comport.
Modelli di Scoring
Data Mart
Analisi Prodotto
Associazioni
Data Mart
Analisi Mercato
Segmentazione socio-demo
Potenziali di zona
Proposta commerciale:
selezione target e product mix.
R.O.I.
Gestore
campagne
Qui di seguito illustriamo l’approccio seguito da
Nunatac per l’individuazione e la gestione del
soggetto cliente.
In particolare prenderemo in considerazione i
seguenti punti:
1. La definizione del soggetto cliente.
2. La costruzione del codice cliente.
3. La gestione e la dimensione storica del codice
cliente.
4. Il modulo ‘cliente’ in un disegno di Database
di Marketing.
5. Conclusioni.
1. La definizione del soggetto cliente.
L’identificazione della propria clientela richiede che
vengano affrontati e risolti i seguenti punti,
apparentemente banali:
• definire il Cliente, logicamente e fisicamente;
• definire la regola di costruzione del Codice
Cliente.
1
Prima di illustrare le fasi sopra riportate, occorre
fare una distinzione sostanziale riguardo alla
tipologia di clientela cui ci possiamo trovare di
fronte. In particolare ci riferiamo alla tipologia
cliente-persona fisica, rispetto a quella relativa al
cliente-persona giuridica.
É intuitivo quanto l’individuazione e la gestione
delle due tipologie possano richiedere processi
diversi. Il cliente persona fisica, infatti, deve essere
identificato come unica entità e riconosciuto ogni
qualvolta si ripresenti nel sistema.
La gestione del cliente persona giuridica, è
evidentemente più complessa rispetto a quella del
cliente persona fisica: possiamo avere società con
sedi centrali e sedi periferiche ed all’interno delle
sedi diverse figure di riferimento; oppure studi di
professionisti con unica partita Iva, ma più persone
fisiche di riferimento al loro interno.
Persona Fisica
Persona Giuridica
Sede
Centrale
Rif.2
Nome Cognome
Indirizzo
Rif.1
Rif.3
Sede
Rif.a
Rif.b
Sede
1
4
Rif.c
Sede
Sede
2
3
Rif.d
Rif.e
Rif.g
Rif.f
Queste differenze devono essere tenute in
considerazione nel momento in cui ci si appresta a
definire codifiche di riferimento per l’entità cardine
del Database di Marketing (DBMa).
Fatte queste premesse affrontiamo il problema
dell’identificazione del cliente come entità logicofisica.
Per identificare il cliente occorre indagare su chi
sia, in primo luogo, il destinatario dell’offerta
commerciale. Questo dato, semplice nel caso in cui
si tratti con clienti persone fisiche, si complica
quando si considerano clienti persone giuridiche.
In questi casi spesso ci si trova di fronte a clienti
‘pagatori’ e clienti ‘destinatari’. Entrambi questi
soggetti devono essere considerati nel DBMa,
tuttavia sono diverse le informazioni che da essi ci
derivano ed è diverso il loro utilizzo: dai dati
raccolti sui ‘pagatori’ sarà possibile effettuare le
analisi di tipo economico, mentre sui ‘destinatari’
analisi di tipo commerciale – marketing.
Nel caso di persone giuridiche, quindi, risulta
fondamentale individuare strutture gerarchiche tra le
anagrafiche disponibili.
Il passaggio dalla definizione logica di cliente alla
sua identificazione fisica si sviluppa attraverso la
ricerca di:
• Indirizzabilità / Recapitabilità
• Univocità
Il primo punto si riferisce alla possibilità di
disporre di un’anagrafica corretta e normalizzata
tale da garantire la facilità del contatto e soprattutto
evitare inutili sprechi nel momento del contatto
commerciale. Per ottenerla occorrere disporre di
efficaci strumenti di normalizzazione anagrafica e
non sempre strumenti di questo tipo sono presenti
nell’ambito del sistema informativo aziendale.
Il secondo punto, l’Univocità, definisce la capacità
di determinare un’unica entità di riferimento,
identificazione necessaria per effettuare delle analisi
piuttosto che per svolgere efficacemente attività
commerciali. Anche in questo caso è necessario
disporre di strumenti informatici specifici proprio
per la gestione dei doppi. Solo l’utilizzo di
strumenti di riconoscimento di anagrafiche doppie,
insieme alla disponibilità di informazioni
aggiuntive, quali il codice fiscale, partita Iva, ecc.,
possono garantire l’individuazione univoca
dell’entità Cliente.
É importante sottolineare fin da subito quanto sia
fondamentale pianificare attività e risorse da
dedicare a queste funzioni, soprattutto in un’ottica
temporale. La creazione di procedure oggi efficaci,
infatti, deve essere controllata nel tempo; soprattutto
nel caso in cui esistano variazioni nei processi di
acquisizione dei dati anagrafici oppure si
aggiungano nuove fonti informative esterne al
sistema informativo aziendale, come ad esempio
liste esterne di nominativi.
2. La costruzione del codice cliente
Definito il Cliente logicamente e fisicamente è
necessario assegnare ad esso un codice
identificativo univoco: il Codice Cliente,
distinguendo tra persona fisica e persona giuridica.
Persona Fisica
Di norma quanto si tratta questo tipo di anagrafica
la problematica maggiore è quella di ottimizzare il
riconoscimento delle anagrafiche doppie. Una volta
risolta questa, l’attribuzione del codice ne deriva di
2
conseguenza: il codice cliente può essere
logicamente concepito come un codice di gruppo
che riunifica anagrafiche simili o uguali. Il Codice
Cliente diventa dunque il catalizzatore di più
anagrafiche che avranno dati strutturali e
comportamentali differenti.
Spesso attribuire un unico codice identificativo ad
anagrafiche di clienti persone fisiche non è
sufficiente: è necessario definire ulteriori regole per
associare, ad esempio, informazioni strutturali
presenti su anagrafiche diverse ad un unico codice
cliente. La definizione di un’anagrafica ‘principale’,
tra quelle presenti nel sistema informativo e
riconosciute come uguali, ci consentirà di associare
ad essa tutte le informazioni di tipo descrittivo,
seguendo regole che possono variare da caso a caso:
freschezza
dell’indirizzo,
data
dell’ultima
movimentazione, stato contabile.
serviamo per la nostra attività di una Rete
commerciale.
Un’ipotesi di soluzione è quella di introdurre una
struttura gerarchica di creazione del codice cliente.
In particolare si può creare una regola di creazione
del codice cliente costituito da:
• un codice primario, logicamente coincidente
con la partita Iva,
• un codice secondario o di destinazione,
logicamente coincidente con un codice di tipo
anagrafico.
Questa ‘doppia’ codifica consente di passare da un
livello macro ad un livello più di dettaglio in
funzione delle diverse esigenze di analisi.
L’esempio fornito è solo una delle diverse
possibilità di codifica; quest’ultima dipenderà
strettamente dal contesto in cui si opera e dalle
specifiche necessità.
Persone Fisiche
Anagr.1
$ 10Stato: A
Anagr.2
$ 30Stato: E
Anagr.4
$ 80
Stato: A
Codice
Cliente
Anagr.4
$ 70
Stato: F
$ 30
Stato: F
Anagrafica
Principale
Persona Giuridica
Nel caso di clienti persone giuridiche i problemi da
risolvere per codificare correttamente sono di
duplice natura:
- da un lato, riconoscere, come per il caso delle
persone fisiche, le anagrafiche doppie;
- dall’altro definire una gerarchia / struttura di
codici funzionale alle nostre necessità.
Per quanto riguarda il primo punto vale ciò che è
stato detto precedentemente, con l’aggiunta della
variabile partita Iva che può essere utilizzata come
identificativo di aggregazione. Supponiamo, infatti,
di avere nel nostro sistema gestionale informazioni
riguardanti una società che possiede sedi dislocate
su tutto il territorio nazionale. Tutte le fatture
emesse a carico di questa società fanno riferimento
ad un’unica partita Iva. Inoltre, in ogni sede,
esistono più persone cui fare riferimento per
proporre le offerte commerciali. Come poter gestire
tutto ciò? Non possiamo perdere certamente la
visione d’insieme di questo cliente, ma tanto meno
perdere le peculiarità territoriali, specie se ci
3. La gestione e la dimensione storica del codice
cliente.
La generazione di un’anagrafica cliente, nel
momento in cui il sistema informativo aziendale è
incentrato sulla gestione del contratto sottoscritto,
può avvenire in modo non controllato. Questo fatto
può determinare un disallineamento nel tempo tra il
codice che identifica in modo univoco il cliente e le
anagrafiche presenti nel sistema ad esso
riconducibili. E’ necessario, quindi, che la creazione
– modifica del codice cliente avvenga ad ogni
aggiornamento del DBMa e che si debba gestire
l’aspetto ‘storico’ della codifica.
Per quanto riguarda questo ultimo punto, le
soluzioni sono evidentemente più d’una.
In taluni casi è possibile mantenere sempre la
situazione di codifica corrente, e quindi ricostruire i
dati storici riconducibili al singolo codice cliente, in
altri gestire ‘storicamente’ i passaggi da un codice
cliente ad un altro, in altri ancora gestire il codice
attuale, mantenendo i dati storici immutati e non
ricostruendo come nel primo caso.
4. Il modulo ‘cliente’ in un disegno di Database
di Marketing.
Il Database di Marketing aziendale deve prevedere
due diverse strutture organizzative dei dati:
• tabelle tematiche (Fact Tables), fatti per
dimensioni, contenenti dati al massimo dettaglio
che si vuole mantenere.
3
• tabelle con struttura un record per cliente
(Customer Tables). Tali tabelle prevedono una
struttura denormalizzata che consenta di
misurare, a livello di cliente, tutte le dimensioni
interessanti per le analisi di marketing.
Le prime costituiscono la fonte per l’attività di
reporting, per le estrazioni ed alimentano le
Customer Tables. Sono strutture dati organizzate
per soggetti e costituiscono il DBMa di primo
livello.
Le seconde permetteranno di effettuare le analisi sul
cliente, esse costituiscono il DBMa di secondo
livello.
Dati
Gestionali
S.I.M.
•Anagrafiche
•Polizze (o contratti,…)
DBMa
Codice
Cliente
Fact
Tables
1 rec. x 1 fatto
Customer Tables
La realizzazione dell’attività di normalizzazione /
deduplica necessita di un software specifico.
Un altro punto da sottolineare è quello relativo alle
risorse da dedicare alla gestione dell’anagrafica e
del codice cliente: non è sufficiente allocare risorse
dedicate a questa funzione solo nella fase di
inizializzazione di un DBMa. La mancanza di
monitoraggio e controllo di questi aspetti, infatti,
può creare gravi deviazioni dall’originario concetto
di cliente e dalla sua corretta individuazione, con
impatti non trascurabili per le attività di targeting e
contatto commerciale. É necessario, quindi, allocare
nel tempo risorse dedicate a questa attività e
parallelamente sviluppare dei processi di controllo
sull’attività che determinano l’ingresso di una nuova
anagrafica nel sistema informativo aziendale.
La capacità di definire, infine, un’efficace regola di
codifica del Codice Cliente garantirà la bontà delle
attività di Database Driven Direct Marketing,
assicurando una corretta attività di analisi e
ottimizzando le iniziative commerciali che ne
conseguono.
1 rec. x 1 cliente
Il modulo di gestione delle anagrafiche e della
creazione del Codice Cliente si posiziona
parallelamente ai processi di creazione delle Fact
Tables, alimentando così il DBMa di primo e di
secondo livello.
Nella struttura di primo livello l’informazione sul
codice cliente viene associata al massimo dettaglio
dei fatti e anche alle singole anagrafiche di cui
disponiamo. Nella Customer Table, al contrario, si
perde il legame diretto con il sistema gestionale,
riassumendo non solo più fatti in un unico record,
bensì più anagrafiche in un unico Cliente.
Elena Castaldi
NUNATAC S.a.s.
Via San Martino 11C - 20122 Milano
Tel.: 02 58327005 Fax: 02 58327122
mailto:[email protected]
Alberto Saccardi
NUNATAC S.a.s.
Via San Martino 11C - 20122 Milano
Tel.: 02 58327005 Fax: 02 58327122
mailto:[email protected]
5. Conclusioni
In sintesi il passaggio da un sistema informativo
centrato sulla gestione di un ‘contratto’ ad un
sistema informativo focalizzato sul ‘Cliente’
richiede le seguenti fasi:
• normalizzare e deduplicare le anagrafiche, in
generale svolgere un’attività di pulizia e
standardizzazione delle anagrafiche, oltre al
riconoscimento dei doppi;
• definire la regola di codifica del Codice Cliente
e sviluppare i processi di costruzione / gestione
di tale codice.
4