Omnia Leads Manager: il CRM su misura che ha sostituito tre fogli Excel

La scheda del progetto

Settore

Elettronica, rete commerciale su tre paesi

Cliente

Azienda con divisioni commerciali in Italia, Spagna e Stati Uniti

Utenti

Commerciali delle tre divisioni, responsabili, amministratore

Prima versione

Dal 18 al 24 giugno 2025, live dallo stesso mese

Revisione

Giugno 2026: sicurezza, prestazioni e nuova interfaccia (versione 2.3.5)

Dimensione

Una decina di schermate, tre lingue, notifiche e processi pianificati

Costi ricorrenti

Piani gratuiti o di base di hosting, database e posta: nessuna licenza per utente

Modalità di lavoro

Progetto a corpo, con interventi successivi a consuntivo

Il contesto: tre divisioni, tre fogli, nessuna vista d'insieme

I lead arrivavano da fiere, dal sito, da segnalazioni e da campagne, e finivano in un foglio di calcolo per divisione. Ogni foglio aveva colonne un po' diverse, date scritte in formati diversi, e un solo proprietario che sapeva leggerlo. Nessuno poteva rispondere alla domanda «quanti contatti aperti abbiamo in Spagna e chi li segue».

Il cliente aveva già valutato i CRM pronti. Il problema non era il prezzo di ingresso, era il costo per utente su tre paesi, la fatica di piegare un prodotto generalista a un processo che era già chiaro, e soprattutto l'importazione: anni di contatti stavano in fogli con sedici colonne e formati locali, e nessun importatore standard li accettava senza una pulizia manuale che nessuno avrebbe fatto.

Cosa serviva davvero, e cosa avrebbe dato un CRM pronto

L'ultima riga è quella che decide: se al cliente fossero servite pipeline complesse, telefonia integrata e automazioni di marketing, un CRM pronto sarebbe stata la scelta giusta e l'avremmo detto. Serviva invece un posto ordinato, in tre lingue, che accettasse i loro file. È il caso tipico in cui il su misura conviene.

La soluzione: un gestionale piccolo, fatto bene

Omnia Leads Manager fa poche cose: accoglie i contatti, li importa dai fogli, li fa cercare e filtrare, avvisa chi deve essere avvisato e ricorda i seguiti. Ogni funzione è stata scelta perché il cliente la usava già, in forma manuale.

Accesso e ruoli

Chi si registra non entra subito: l'amministratore approva l'account e lo assegna a una divisione. Tre ruoli (utente, responsabile, amministratore) decidono chi vede, chi modifica e chi cancella. Un lead può essere modificato da chi lo ha creato o da un responsabile; la lettura è condivisa, perché il punto del progetto era proprio smettere di avere informazioni chiuse in un file.

L'importazione dai fogli, la parte che ha fatto la differenza

L'importatore è stato costruito sul formato reale dei fogli del cliente: sedici colonne, con date che in un file erano numeri di Excel e in un altro testo. Prima di scrivere una riga controlla il tipo di file dai primi byte e non dall'estensione, limita la dimensione, converte le date e mette a NULL quelle illeggibili invece di bloccare tutto, riconosce i duplicati per azienda e referente, scrive a lotti e alla fine manda un riepilogo con gli errori riga per riga.

Ricerca, filtri e cruscotto

La lista dei lead si cerca e si filtra per divisione, canale, settore, stato del seguito, con ordinamento e paginazione fatti dal database e non in memoria: con qualche migliaio di righe la differenza è fra una pagina che risponde subito e una che si blocca. Il cruscotto mostra i contatti per stato di conversione e per canale, e le statistiche dei seguiti in scadenza.

Le notifiche che sostituiscono la memoria

Quattro tipi di email, con modelli modificabili dall'amministratore in tre lingue: nuovo lead assegnato, importazione completata, promemoria mensile dei seguiti per divisione, account approvato o rifiutato. Le email passano da una coda e da un processo pianificato che le spedisce, così un problema del servizio di posta non fa perdere il messaggio. Un rapporto giornaliero riepiloga l'attività.

Le decisioni tecniche

Per un sistema usato da poche decine di persone, la scelta più importante è quanto costa tenerlo acceso e quanto è facile intervenirci fra un anno. Le decisioni sono tutte in questa direzione.

1. Nessun framework frontend Pagine HTML, JavaScript in moduli e Bootstrap. Per dieci schermate e un team che non avrebbe avuto uno sviluppatore interno, un framework avrebbe aggiunto una catena di build da mantenere senza dare nulla in cambio. Il codice si legge e si modifica con un editor di testo.
2. Funzioni serverless e database serverless Funzioni e database a consumo: si paga l'uso, che per questo sistema rientra nei piani di base. Niente server da aggiornare, niente notti a controllare che sia acceso. I processi pianificati, come l'invio delle email in coda e il rapporto giornaliero, girano sulla stessa infrastruttura.
3. Tre lingue dal primo giorno Interfaccia, email e formati di data e numero seguono la lingua preferita dell'utente, con ricaduta automatica sull'italiano per le chiavi mancanti. Aggiungerle dopo avrebbe significato toccare ogni schermata due volte.
4. Il processo del cliente è nel codice, non nelle abitudini Chi può cambiare cosa, quali campi sono obbligatori, come si riconosce un duplicato, quando parte un promemoria: sono regole scritte nelle funzioni, uguali per tutte le divisioni. È il motivo per cui un file arrivato dalla Spagna e uno dall'Italia finiscono nella stessa forma.

Un anno dopo: la revisione di sicurezza e prestazioni

A giugno 2026 il sistema è stato riesaminato da capo, con una revisione di sicurezza a più passaggi e un controllo delle prestazioni. È la parte del caso studio che raccontiamo più volentieri, perché un software di un anno che non ha nulla da correggere di solito non è stato guardato.

• Autenticazione: rimosso un percorso di accesso di ripiego che poteva essere abusato; autenticazione obbligatoria su tutte le funzioni; limite ai tentativi di accesso con messaggi che non rivelano se un'email esiste; sessioni invalidate al cambio password.
• Proprietà dei dati: modifica e cancellazione di un lead riservate a chi lo ha creato o a un responsabile, con l'autore preso dalla sessione e non dal modulo.
• Posta: le funzioni di invio erano raggiungibili senza sessione e potevano essere usate per spedire email a terzi; ora richiedono un token interno o una sessione di amministratore. Contenuti delle email sempre codificati, oggetti protetti dall'iniezione di intestazioni.
• Intestazioni di sicurezza: politica di contenuto, HSTS, permessi del browser, CORS ristretto al dominio del sito.
• Prestazioni: filtri, ordinamento e paginazione spostati nel database; importazione senza una query per riga; conteggi degli utenti in una sola query aggregata; indici sulle colonne più cercate.
• Tracciabilità: tabella delle azioni amministrative come registro di controllo, pulizia automatica dei tentativi di accesso dopo trenta giorni.

I risultati

Il cliente ha un solo archivio dei contatti per tre paesi, un'importazione che accetta i suoi file senza pulizia manuale e promemoria che partono da soli. I costi ricorrenti stanno nei piani di base di hosting, database e posta, senza licenze per utente.

1

settimana dalla prima riga di codice alla versione in uso (dal 18 al 24 giugno 2025)

3

lingue con formati locali (italiano, inglese, spagnolo)

16

campi importati dai fogli esistenti (con validazione e controllo dei duplicati)

0

licenze per utente (costi ricorrenti nei piani di base dei servizi)

Cosa si porta in un progetto simile

Un CRM su misura ha senso quando il processo è già chiaro e i dati esistenti hanno una forma che i prodotti pronti non accettano. In quel caso costa meno di quanto si pensi, a patto di non ricostruire quello che non serve.

• Partire dall'importazione dei dati reali: se il sistema non accetta i file di oggi, non verrà usato.
• Scegliere l'infrastruttura in base al costo di tenerla accesa, non alla moda: per poche decine di utenti il serverless a consumo è quasi gratuito.
• Mettere le lingue e i ruoli nel primo giorno, non nel secondo anno.
• Prevedere una revisione dopo il primo anno d'uso, e metterla nel preventivo.

Per capire come si struttura un progetto così, dai costi alle fasi, leggi come lavoriamo e quanto costa. Per una panoramica di quello che facciamo su questo tipo di sistemi, la pagina sviluppo software su misura.

Tecnologie usate

Scelte fatte per un sistema piccolo, usato ogni giorno, con costi di esercizio minimi e nessuno sviluppatore interno dalla parte del cliente.

Domande frequenti

Scritto da Maximilian Giurastante

Founder e software developer, MAXYMIZE. Progetta e sviluppa piattaforme SaaS, gestionali su misura e automazioni con modelli linguistici. Oltre vent'anni come project leader nell'integrazione di sistemi tecnologici, audio e video.

• https://linkedin.com/in/maximiliangiurastante
• https://github.com/Maxymize
• https://youtube.com/@MAXYMIZE

Hai contatti sparsi in fogli che nessuno tiene allineati?

Portaci un file di esempio. In trenta minuti vediamo se ha senso un sistema su misura o se ti conviene un prodotto pronto, e te lo diciamo in entrambi i casi.

Prenota una consulenza gratuita