La gran parte dei CRM è pensata come se il territorio fosse un attributo testuale. Città, CAP, Provincia, magari un indirizzo. Fine. Funziona, finchè il tuo lavoro commerciale è soprattutto pipeline, follow-up, preventivi e negoziazione.
Quando invece la produttivita' dipende da dove sono i clienti, da come sono distribuiti, da chi presidia una zona, da quali visite puoi concatenare nella stessa giornata e da quali punti vendita non stai toccando da mesi, quel modello ecco che crolla.
Per questo stiamo guardando con interesse a Twenty come base CRM open source per progetti territoriali. E per questo diciamo anche, senza diplomazia inutile, che Twenty da solo non basta.
Che cosa abbiamo verificato su Twenty
Twenty non è presentato come il classico CRM da configurare una volta e dimenticare, ma come una piattaforma da costruire ed estendere. Il loro messaggio pubblico è coerente dappertutto, e include oggetti, campi, viste, automazioni e app come mattoni di base; stack tecnico moderno; opzione cloud o self-hosted; dati e codice sotto controllo del team.
La documentazione per sviluppatori conferma che sopra Twenty si possono costruire:
- oggetti e campi custom;
- viste e layout dedicati;
- componenti React nel workspace;
- funzioni server-side;
- app con ciclo di sviluppo vero, non con configurazioni proprietarie opache.
Anche i numeri pubblici del repository meritano nota. Alla nostra verifica del 28/07/2026, il progetto mostrava 53,8 mila stelle GitHub, 8,2 mila fork, 713 contributori e 91 release pubbliche. Non è una prova assoluta di qualità. Però è un segnale molto concreto che il progetto non è una demo abbandonata.
La tesi
Se hai un team tecnico o un partner tecnico serio, Twenty è una base convincente per costruire un CRM su misura.
Se non hai bisogno di territorio, può bastare molto a lungo.
Se invece il tuo business vive invece sulla geografia, devi aggiungere un livello in più. E quel livello non è cosmetico, ma architetturale.
Dove nasce il problema
Un account manager che segue clienti enterprise nazionali può vivere benissimo in un CRM classico. Un agente che deve visitare saloni, filiali, negozi, punti assistenza o concessionari distribuiti sul territorio ragiona in modo diverso.
Ragiona per:
- prossimità tra punti visita;
- scoperture territoriali;
- concentrazioni in uno stesso CAP;
- rotte possibili nella giornata;
- differenze di densità commerciale tra aree confinanti;
- allineamento tra territorio assegnato e portafoglio reale.
Se il software non rappresenta questa realtà, costringe il commerciale a compensare fuori piattaforma: Excel, Google Maps, note private, screenshot, gruppi WhatsApp, e il risultato è sempre lo stesso: dati dispersi, decisioni peggiori, occasioni mancate.
Che cosa manca a un CRM generico quando entri nel mondo GIS
Per trasformare un CRM in un CRM territoriale servono almeno sei cose.
1. Geocodifica e normalizzazione indirizzi
Il record cliente deve diventare un punto affidabile in mappa. Non basta un campo indirizzo scritto bene una volta su due.
2. Arricchimento amministrativo
CAP, Comune, Provincia e, in certi casi, sezioni di zona o aree commerciali interne. Se questi campi non sono consistenti, i filtri si rompono subito.
3. Query spaziali vere
Quali saloni stanno entro 10 km da questo cliente top? Quali sono gli inattivi dentro il Comune assegnato a questo agente? Quanti prospect ci sono in un'area oggi non coperta? Queste domande non si risolvono bene con una tabella SQL normale.
4. Permessi per territorio
I ruoli non sono solo "admin" e "user". In molte reti commerciali devi poter dire: questo Area Manager vede tutto il Lazio, questo agente solo la sua zona, quest'altro soltanto i punti vendita assegnati.
5. Simbologia operativa
Stati commerciali con colore e icona hanno senso pieno solo quando li leggi nello spazio. Un pallino rosso in tabella dice poco. Dieci pallini rossi in una stessa fascia urbana raccontano subito un problema.
6. Pianificazione visuale
Una buona parte del valore non sta nella raccolta del dato, ma nel colpo d'occhio: cosa visito oggi, cosa sto trascurando, dove si stanno accumulando clienti da ripassare, dove ho opportunità non ancora presidiate.
Perchè Twenty ha senso come base
Il punto forte di Twenty è che non costringe a reinventare la parte noiosa ma indispensabile di un CRM serio.
Noi leggiamo bene soprattutto quattro aspetti.
Primo: il modello dati estendibile. Oggetti e campi custom sono la base giusta se devi modellare saloni, agenti, visite, stati, cluster territoriali, aree di competenza.
Secondo: i permessi e le viste. Una rete vendita non usa tutti la stessa schermata. Area Manager, agente, direzione commerciale e back office non hanno bisogno dello stesso taglio di interfaccia.
Terzo: la self-hostability. In alcuni contesti non è opzionale. Se i dati cliente e le note commerciali devono stare dentro perimetri infrastrutturali controllati, questa opzione pesa.
Quarto: uno stack moderno e noto. React, TypeScript e PostgreSQL aprono il progetto a un numero molto piu' ampio di team e partner rispetto ai CRM proprietari che si appoggiano a linguaggi o ecosistemi chiusi.
Dove serve il pezzo Zornade
Il livello che aggiungiamo noi è quello territoriale vero:
- database PostgreSQL/PostGIS;
- geocodifica e controllo qualita' sugli indirizzi;
- arricchimento con confini e livelli amministrativi;
- componenti mappa e interazione cartografica;
- filtri spaziali e filtri commerciali nello stesso flusso;
- eventuali dati territoriali aggiuntivi, se servono al caso d'uso (densita', rischio, bacino, rete, accessibilita').
La cosa importante è che questo non sostituisce Twenty, ma lo completa.
Quando questo approccio ha senso davvero
Ha senso soprattutto se sei in uno di questi casi:
- rete vendita fisica distribuita;
- franchising o multi-sede;
- canale commerciale con agenti sul campo;
- gestione tecnica o commerciale per aree;
- bisogno di mappa e filtri territoriali come strumento quotidiano, non come cruscotto occasionale.
Ha molto meno senso se:
- vuoi un CRM chiuso, gia' pieno di integrazioni pronte e da non toccare mai;
- non hai nessuna intenzione di personalizzare il modello dati;
- il territorio, nella tua operativita', conta pochissimo.
Su questo punto la documentazione di Twenty è quasi sorprendentemente onesta: il prodotto non si vende come risposta universale a tutto. Ed è uno dei motivi per cui ci interessa.
Il caso Framesi ci sembra un esempio pulito
Stiamo lavorando proprio su un caso che chiarisce bene il problema: Framesi, rete professionale, saloni distribuiti, forza vendita sul territorio, bisogno di importare tutto il mercato potenziale e classificarlo operativamente, differenziare permessi tra Area Manager e agenti, e usare filtri geografici veri per la pianificazione.
Twenty, in questo quadro, è un ottimo scheletro. Ma senza il layer cartografico e geospaziale, resterebbe incompleto. E' il motivo per cui stiamo costruendo una soluzione ibrida, non un semplice workspace configurato.
La posizione finale
Noi la vediamo cosi'.
Il mercato dei CRM open source sta diventando interessante proprio adesso, non perchè abbia gia' tutte le funzionalita' dei grandi incumbent, ma perchè inizia a offrire basi tecniche abbastanza solide da rendere economico costruire sopra quello che davvero differenzia un cliente.
Per un CRM territoriale, la differenziazione non è la pipeline. Non è la nota attivita'. Non è il campo testo in piu'.
E' la geografia operativa.
Se quella parte conta davvero nel tuo business, ti serve un CRM che parli anche la lingua delle mappe.
Se vuoi ragionare su un progetto di questo tipo, qui trovi la pagina dei nostri servizi di sviluppo software su misura e qui il caso concreto su Framesi, Twenty e CRM territoriale.
Domande frequenti
Twenty è davvero open source?
Si'. E' una delle cose che emergono con piu' chiarezza sia dal sito ufficiale sia dal repository pubblico GitHub del progetto.
Posso costruire un CRM territoriale solo configurando Twenty?
Di rado. Per casi semplici puoi avvicinarti, ma appena servono mappa vera, query spaziali, geocodifica affidabile e permessi per area, devi aggiungere un livello geospaziale dedicato.
Che ruolo ha PostGIS in questo tipo di progetto?
È il punto in cui il dato cliente smette di essere solo anagrafica e diventa entità geografica interrogabile: punti, aree, distanze, inclusioni, filtri spaziali.
Vale la pena farlo anche per una rete vendita media, non enorme?
Spesso sì, se il collo di bottiglia non è il numero totale di clienti ma la dispersione territoriale e il costo di coordinamento della rete.
Perchè non usare direttamente un software di geomarketing separato?
Perchè se CRM e territorio vivono in due posti diversi, l'utente torna a fare copia-incolla tra sistemi. E lì perdi sia tempo sia qualità dei dati.