Piattaforma unica per pratiche assicurative

Un’agenzia assicurativa gestiva le proprie pratiche su due sistemi separati. Ci ha chiesto di unificarli in un’unica piattaforma, costruita database-first, con gestionale, area cliente e canale digitale. Progetto in corso, messa in produzione prevista in autunno 2026.

Settore Assicurazioni

La situazione di partenza

Il cliente è un’agenzia assicurativa che vende e gestisce polizze attraverso una rete di collaboratori organizzata su più livelli: chi sta sopra coordina chi sta sotto, e una sede centrale vede tutto. Il lavoro girava su due sistemi: un gestionale comprato come pacchetto base e ampliato negli anni, dove vivevano rete, portafoglio e provvigioni, e una seconda piattaforma per trattative e proposte. Intorno, fogli di calcolo e passaggi fatti a mano.

Alcuni esempi di come si lavorava. Ogni mese in amministrazione qualcuno scaricava a mano l’estratto conto di ogni singolo operatore, perché è quel documento a governare il pagamento delle provvigioni. L’elenco dei pagamenti non andati a buon fine arrivava dalla banca una volta al mese in Excel, e da lì si avvisavano i collaboratori uno per uno. I prodotti caricati nella piattaforma delle trattative non si potevano nemmeno esportare.

Ci ha chiesto una piattaforma sola che sostituisse entrambi i sistemi, con tre esperienze sopra lo stesso nucleo di dati: il gestionale per la sede e per la rete, la vendita online per chi compra una polizza (preventivo, questionario, firma e pagamento) e l’area riservata per l’assicurato, con le sue polizze, il nucleo familiare e i documenti.

Cosa stiamo costruendo

Il cuore del gestionale è la catena del lavoro in un posto solo: trattativa, contratto, titolo, incasso.Da ogni incasso nascono le provvigioni maturate, operatore per operatore, con la base, l’aliquota e l’importo. L’estratto conto mensile, che prima si scaricava a mano per ciascuno, diventa un’estrazione che parte dagli stessi dati.

Ogni ruolo vede la sua parte. Amministratore e back office lavorano su tutta la rete, gestiscono incarichi, mandati, ruoli e permessi. Il collaboratore vede le proprie trattative e i propri clienti; il partner vede la parte di rete che coordina; il cliente vede soltanto le sue polizze. La gerarchia della rete, con i suoi livelli, è un albero dentro il database: chi sta sopra vede chi sta sotto, senza eccezioni scritte a mano.

Tre scelte tecniche reggono il resto. La prima: i prodotti sono dati. Una garanzia nuova, un ruolo nuovo o un campo che chiede una sola banca si dichiarano dal gestionale, senza sviluppo. La seconda: i permessi li decide il database, con una regola per ogni riga, così una schermata scritta male resta comunque senza il dato che quell’utente non deve vedere. La terza: le tre esperienze leggono lo stesso nucleo, quindi la polizza che l’assicurato apre nella sua area è la stessa riga su cui lavora il back office.

Come stiamo lavorando

L’analisi è partita dalle riunioni in cui il team del cliente ci ha mostrato a schermo i due sistemi in uso.Le abbiamo registrate e trascritte, e ogni requisito porta con sé la fonte: la riunione e il minuto in cui è stato detto. Le domande aperte stanno in un registro con la risposta e la data, così nessuna si chiede due volte.

Abbiamo lavorato presto sui dati veri. Il portafoglio attivo esportato dal vecchio gestionale, oltre undicimila righe, è passato da un lettore che controlla ogni riga prima di scrivere qualsiasi cosa: le poche righe scartate hanno la ragione scritta accanto, per esempio una rata che scade prima di cominciare, e tornano al cliente da correggere alla fonte.

Venticinque controlli automatici girano prima di ogni salvataggio del codice, e il database ha una sua suite di test che verifica permessi e regole. Ai controlli si aggiunge lo sguardo: ogni pagina si apre a video prima di dirla finita. Da settembre il team del cliente lavora su un ambiente di prova protetto, con dati di prova, mentre si completano le ultime pagine.

Dove siamo oggi

Il gestionale è quasi completo: 95 pagine costruite sulle 106 del perimetro, misurate a metà settembre.L’area riservata dell’assicurato esiste e funziona sopra lo stesso database. La vendita online è nel perimetro e parte dopo, per scelta del cliente. La messa in produzione è prevista in autunno 2026, e il codice passa al cliente.

324

Migrazioni database

Lo schema costruito un passo alla volta, ogni passo provato

2.530

Verifiche automatiche

Su 231 file di test dedicati al database

1.153

Salvataggi del codice

Da agosto 2026, con i controlli a ogni passaggio

95/106

Pagine del gestionale

Costruite sul perimetro concordato

Stack tecnologico

Next.js
Next.js (App Router)
Supabase (Postgres, RLS-first)
pgTAP (test del database)
TypeScript
TypeScript
Vercel
Vercel

Servizi coinvolti

Altri case study

Avete un progetto simile?

Raccontateci come lavorate oggi. Si comincia dall’analisi, compresa nel prezzo del progetto.