Costruire un CRM da zero: si parte dagli attriti, non dai campi

Perché un CRM proprietario invece di HubSpot?

Non l'abbiamo deciso a tavolino. Ci siamo arrivati. Ho iniziato con le automazioni sui passaggi in cui il team perdeva tempo, poi una dashboard per vedere i numeri in un posto solo. A un certo punto avevamo in mano qualcosa di utile che non era ancora un CRM, ma ci assomigliava. Lì abbiamo deciso di costruircelo noi, sulle nostre esigenze.

Il CTO scriveva il codice. Io decidevo le priorità, cosa era P0 e cosa poteva aspettare, in base a quello che serviva al team. E davo input su dove usare l'AI e su come le funzioni dovevano essere usate nel lavoro di tutti i giorni.

È il motivo per cui ha funzionato: ogni pezzo esisteva già come risposta a un problema prima di diventare una feature.

Per la maggior parte delle aziende resta vero che HubSpot o Pipedrive bastano. Il CRM su misura ha senso quando ci arrivi così: hai già le automazioni, sai quali problemi risolvono, e c'è qualcuno che può mantenere il prodotto nel tempo.

Da dove si parte, se non dai campi?

Il riflesso naturale è disegnare oggetti, stage e campi. È il lavoro più facile e il meno utile: un campo si cambia in un pomeriggio. Quello che non si cambia in un pomeriggio è l'abitudine del team a lavorare fuori dal CRM.

Il punto di partenza è il lavoro, non lo schema. Si guarda dove le cose si bloccano: un lead che nessuno prende, una call saltata che nessuno richiama, un preventivo rifatto a mano, una commissione calcolata su un foglio a parte. Ogni blocco diventa una riga del backlog.

Quali automazioni sono nate così?

Nessuna di queste è una feature originale. La differenza è che ognuna risponde a un problema che il team aveva già nominato, quindi nessuno ha dovuto essere convinto a usarla.

Come decidi l'ordine?

Per costo dell'attrito, non per facilità di sviluppo. Le domande sono tre: quanto costa ogni volta che succede, quante volte succede a settimana, chi ne paga il prezzo.

In pratica era la mia lista dei P0: entrava per primo quello che serviva al team in quel momento, non quello che era più bello da costruire. Quello che perde lead batte quello che fa risparmiare tempo. Ne ho scritto a maggio, in "Quanto ti costa davvero l'attrito commerciale".

Come fai in modo che il team lo usi davvero?

Un CRM viene usato quando è il posto dove il lavoro succede, non il posto dove lo si registra dopo. Il pre-call brief e il follow-up automatico portano il rep dentro il CRM perché gli conviene, non perché qualcuno lo controlla.

La regola che uso: ogni volta che una feature chiede al rep un dato in più, deve restituirgli qualcosa subito. Un campo obbligatorio senza ritorno è un attrito nuovo, costruito da te.

Cosa rifarei diversamente?

Misurerei l'adozione dal primo giorno. Chiedevo spesso al team di cosa avesse bisogno, ma non tracciavo quali funzioni venivano usate davvero. Una funzione poco usata è un segnale: o il problema non era quello giusto, o nessuno ha spiegato perché conviene. Nei primi mesi traccerei l'uso funzione per funzione e spingerei l'adozione dove resta indietro.

Quando è finito?

Un CRM è finito quando il team smette di tenere fogli paralleli. Finché esiste un Excel "di supporto", c'è un attrito che il sistema non ha ancora assorbito. È lo stesso principio di "Non hai un problema di lead. Hai un problema di sistema": il lavoro che vive fuori dal sistema è il sistema che manca.

FAQ

Meglio un CRM su misura o HubSpot?

Per la maggior parte delle PMI, HubSpot o Pipedrive. Il su misura ha senso quando il processo ha passaggi che un CRM standard copre solo con workaround e c'è chi può mantenerlo nel tempo.

Da quale automazione conviene partire?

Da quella che perde lead. Di solito è l'assegnazione dei lead ai rep o la gestione degli appuntamenti saltati.

Serve uno sviluppatore per automatizzare il CRM?

Per un CRM proprietario sì. Per automatizzare un CRM esistente spesso basta uno strumento come n8n collegato alle sue API.

Quanto costa costruire un CRM da zero?

Il costo vero non è lo sviluppo iniziale ma la manutenzione. Un CRM custom va trattato come un prodotto, con qualcuno che ne tiene la roadmap.

Un CRM non si disegna. Si accumula, un attrito risolto alla volta, finché il team non ha più motivo di lavorare altrove.