Un catalogo che cambia ogni tre mesi: Relazione di un progetto Zoho per un broker assicurativo

In molte aziende il listino è la parte semplice del sistema informativo: si carica una volta, si aggiornano i prezzi ogni tanto e il lavoro finisce lì. Nelle aziende commerciali che vendono prodotti di terzi è il contrario. Ogni fornitore ha le sue condizioni, il catalogo cambia al ritmo delle campagne dei fornitori e su ogni riga si calcola una provvigione che dipende da tutte quelle condizioni insieme.

Questa è la relazione di un progetto di quel tipo. Il cliente è un broker di servizi assicurativi che vende online e al telefono, con un fatturato entro i dieci milioni di euro e diverse decine di persone coinvolte. Il nome resta riservato, come per tutti i nostri case study. Il caso riguarda chi si riconosce in un’azienda che gestisce decine di migliaia di articoli a listino con condizioni diverse per fornitore.

Il punto di partenza

Il contatto è arrivato dal CTO. Il team di sviluppo interno aveva costruito un sistema proprio per gestire lead e pratiche, e aveva raggiunto il punto in cui il costo di mantenerlo e di adattarlo superava il valore di averlo. Succede spesso a chi parte da uno sviluppo su misura o da una base open source: la prima versione si fa in fretta, poi ogni variazione del business richiede un intervento di programmazione, e in un settore dove le variazioni sono continue il team finisce per lavorare quasi solo su quello.

La seconda esigenza riguardava il processo. Servizi e passaggi erano frammentati fra più strumenti, e la direzione aveva poca visibilità sullo stato dei lead e su come venivano gestiti dal primo contatto alla polizza attiva.

La terza era la gestione dei reclami, cioè il customer care: un broker ne riceve molti e deve gestirli entro tempi fissati per legge, con tracciabilità dei tempi di risposta e di lavorazione.

Il perimetro

L’analisi ha richiesto molti più incontri del solito, perché le interviste ai reparti tecnico, commerciale e amministrativo prendevano più tempo del normale: bisognava capire la complessità dei prodotti, le procedure di gestione delle pratiche e le logiche di calcolo delle provvigioni.

Il ciclo parte dalla cattura del lead. I punti di ingresso erano molti: campagne a pagamento, traffico organico, portali comparativi, il sito dell’azienda, le campagne sui social. Il requisito centrale su questa fase era che l’origine del contatto restasse agganciata al record per tutta la sua vita, perché senza tracciare la fonte del lead non si potevano misurare le performance dei canali di acquisizione.

Ogni lead veniva assegnato a un operatore di telemarketing, incaricato di ricontattarlo, profilarlo e costruire la pratica assicurativa con le coperture utili a quella persona.

Chiusa la fase commerciale, il contatto passava al back office e all’amministrazione per la firma dei documenti e l’incasso. A questo si aggiungeva il flusso dei rinnovi: chi aveva sottoscritto una polizza andava ricontattato in prossimità della scadenza, e alla conferma la pratica rientrava nel ciclo, di nuovo verso il back office e verso l’incasso del premio annuale.

Le applicazioni attivate in Zoho One

Il progetto è stato costruito su Zoho One, attivando le applicazioni necessarie al perimetro. Zoho CRM ospita l’intero flusso dal lead al rinnovo. A monte lavorano Zoho Campaigns per l’email marketing promozionale e Zoho Social per raccogliere i contatti dalle campagne pubblicitarie sui social network. Zoho SalesIQ gestisce le chat, integrate con WhatsApp Business: una persona può scrivere in chat per chiedere un contatto commerciale o per aprire un reclamo, e la conversazione entra nel sistema con il resto delle informazioni sul cliente.

Nel CRM sono stati costruiti moduli personalizzati per la gestione del contratto. La sfida principale nella configurazione è stata però la costruzione dell’anagrafica prodotti.

Un prodotto assicurativo è il classico articolo che va descritto con molte variabili: la compagnia che lo emette, la procedura di attivazione, chi raccoglie le firme, i termini e le modalità di pagamento, la durata, le coperture, cosa è compatibile con cosa. A questo si aggiunge che il catalogo cambia ogni pochi mesi, perché il broker vende i prodotti che le compagnie spingono in quel periodo, e ogni prodotto nuovo arriva con condizioni sue.

Su ogni prodotto c’è poi il tema delle provvigioni, che è sempre quello più difficile da calcolare e delicato per natura. Il flusso è doppio. In ingresso, la compagnia paga al broker una provvigione per ogni polizza venduta, con condizioni diverse per compagnia e per prodotto. In uscita, il broker paga una provvigione ai canali che hanno portato il lead da cui è nata la polizza. La liquidazione dipende quindi dal prodotto, dalla compagnia, dal canale di origine e dalle condizioni di pagamento. Se l’anagrafica non le contiene in forma strutturata, la provvigione si deve calcolare a mano, allungando i tempi e la possibilità di errore.

L’anagrafica prodotti è stata quindi personalizzata in profondità. Ogni prodotto registra la compagnia, la procedura di attivazione, la modalità di firma, il piano di pagamento, le coperture e le regole per il calcolo delle provvigioni. I moduli dei contratti e i flussi di gestione delle pratiche leggono queste informazioni dal prodotto, quindi quando cambia una condizione si aggiorna l’anagrafica e non la procedura.

I reclami

Per la gestione dei reclami è stata attivata Zoho Desk. Ogni reclamo diventa un ticket con un responsabile assegnato, e i tempi di prima risposta e di chiusura sono misurati sul ticket stesso. La conversazione con il cliente, arrivi da email, da chat o da WhatsApp, resta fascicolata in un unico posto. In caso di ispezione o di audit l’azienda può produrre un report puntuale su come ogni reclamo è stato trattato e in quanto tempo.

L’implementazione

L’implementazione è stata ibrida. Gosnail si è occupata dell’analisi, della progettazione e di parte del setup. Il team di sviluppo interno del cliente ha realizzato le integrazioni con il sito e con gli altri strumenti già in uso. Il nostro ruolo è stato principalmente consulenziale, con un obiettivo dichiarato fin dall’inizio: mettere il team interno in condizione di mantenere e far evolvere il sistema in autonomia.

Il lavoro complessivo è durato più di un anno.

La formazione

Abbiamo individuato dei key user per reparto, le stesse persone intervistate durante l’analisi, e abbiamo formato loro. Sono stati loro a fare da riferimento per gli utenti finali e a passare le informazioni all’interno del proprio gruppo. Il numero di key user variava per reparto, da uno a tre o quattro, in proporzione a quante persone quel reparto coinvolgeva nel processo.

Cosa è cambiato

Il primo cambiamento riguarda la visibilità sul commerciale e sul marketing. Prima il record di un lead era disperso su più strumenti e in più formati, e capire quale canale producesse polizze richiedeva di ricostruire il percorso a mano. Ora ogni lead entra in un flusso unico nel CRM con l’origine agganciata, e il rendimento dei canali si legge dal sistema.

Il secondo riguarda il prodotto. Il progetto ha portato l’azienda a definire in forma esplicita la struttura dei propri prodotti: quali attributi contano, come si raggruppano, quali guidano il processo e quali la provvigione. Quella mappatura è un risultato in sé, indipendente dal software che la ospita.

Il terzo riguarda i reclami, che ora hanno un responsabile, una scadenza e uno storico consultabile, e possono essere rendicontati quando serve.

Cosa portiamo via da questo progetto

Quando il catalogo è governato da terzi e cambia di continuo, il lavoro parte dall’anagrafica e non dal processo. Se il prodotto porta con sé le regole che lo riguardano, i flussi le leggono; se non le porta, ogni cambiamento di catalogo diventa un cambiamento di procedura.

Le provvigioni sono il banco di prova dell’anagrafica. Se si calcolano a mano, all’anagrafica manca qualcosa.

Gosnail è partner autorizzato Zoho, e i progetti che raccontiamo usano quella piattaforma. La scelta degli strumenti è stata fatta a valle dell’analisi, non prima. Il modo in cui lavoriamo è descritto nella pagina sul nostro metodo.

Redazione Gosnail. Revisione: Fabio Baraldo.

Domande frequenti

Il caso riguarda solo i broker assicurativi?

No. Il broker è l’esempio, ma il problema è quello di ogni azienda commerciale che vende prodotti di terzi con condizioni diverse per fornitore: distribuzione, rivendita tecnica, intermediazione di servizi. Se il listino ha decine di migliaia di righe e le regole cambiano per fornitore, il ragionamento sull’anagrafica è lo stesso.

Un team di sviluppo interno rende inutile un partner?

No, cambia il ruolo del partner. In questo progetto il team interno ha realizzato le integrazioni e ha preso in carico il sistema alla fine, mentre l’analisi, la progettazione e la modellazione dei dati sono state fatte insieme.

Perché Zoho Desk e non un modulo del CRM per i reclami?

Perché i reclami hanno tempi di risposta e di chiusura da misurare e da dimostrare, e un help desk nasce per quello: assegnazione, scadenze, storico della conversazione in un unico posto. Un modulo nel CRM avrebbe richiesto di ricostruire quelle funzioni.