Due persone aprono lo stesso contatto nello stesso CRM. Una vede la data dell'ultima chiamata, il titolare del deal e il flag di rinnovo. L'altra non vede nulla di tutto questo, perché le colonne non sono mai state aggiunte al layout che sta guardando. Non stanno discutendo di strategia. Stanno discutendo di cosa dice il record, e hanno ragione entrambe, perché leggono due diverse superfici di visualizzazione sopra lo stesso insieme di dati.
È la modalità di guasto silenziosa dietro la maggior parte delle conversazioni «i nostri numeri non coincidono». Raramente è un problema di reporting. Quasi sempre è una questione di chi ha configurato quale layout, e di quanti di quei layout esistono ormai.
Un tempo questo disaccordo costava qualche minuto di confusione in una call. Ora si accumula. Quando i team GTM puntano agenti AI sul CRM per redigere follow-up, assegnare punteggi agli account e aggiornare record, il sistema di registrazione diventa il substrato da cui legge tutto. L'argomento di Jason Lemkin nel suo articolo del 2026 sul CRM agentico è che il CRM sta diventando l'hub centrale da cui più agenti attingono la storia e a cui rimandano segnali. Se i suoi stessi commerciali non concordano su cosa mostri un record, gli agenti che leggono lo stesso record ereditano la confusione alla velocità della macchina.
La disciplina che un tempo era un optional è quindi ora portante. Uno strato di visualizzazione disordinato era sopportabile finché lo leggevano solo persone. Non lo è più quando lo legge il software.
Il segnale è semplice. Chieda a due persone dello stesso team di aprire lo stesso account e di descrivere ciò che vedono. Se la risposta è «be', nella mia vista», l'ha già trovato. I dati sotto sono identici. I layout sopra no.
Ogni CRM moderno dotato di viste salvate, che sia HubSpot, Salesforce o Pipedrive, tratta una vista come una configurazione salvata di filtri, colonne ordinate e proprietà visibili. È una comodità. Il problema inizia quando la comodità diventa proprietà privata: ogni commerciale, ogni manager e ogni team costruisce le proprie viste salvate, e nessuno elimina quelle vecchie.
Non è negligenza. È il comportamento predefinito di uno strumento flessibile. Qualcuno a marzo ha bisogno di una colonna per una campagna, e la aggiunge a una vista personale. Un manager vuole i deal ordinati per data di chiusura per una call di forecast, e la salva. Una nuova persona copia una vista esistente e la ritocca. Nessuna di queste mosse è sbagliata di per sé. Sei mesi dopo esistono venti viste salvate, metà delle quali di proprietà di persone che hanno cambiato team, e nessuna mostra gli stessi campi.
Il risultato è uno strato di visualizzazione che si allontana da qualsiasi definizione condivisa del record. Quando qualcuno condivide un'informazione con un collega, il collega non la trova, perché è stata aggiunta a una vista e non all'altra. I dati erano lì da sempre. Semplicemente non erano visibili dal punto in cui quella persona si trovava.
Ecco il riposizionamento che corregge il ragionamento. Una vista salvata è una scelta di visualizzazione. Non sono i dati, e non è la verità. Trattare i layout come se portassero significato è il modo in cui i team finiscono per riconciliare dashboard invece di riparare ciò che sta sotto.
È la stessa lezione che Thomas Redman porta avanti da anni sulla qualità dei dati: nel suo lavoro per la Harvard Business Review, l'argomento è che la qualità si controlla nel punto in cui i dati vengono creati, e che ripulirli a valle è costoso e non scala. La proliferazione delle viste è un sintomo a valle. Ogni layout in più è un punto in più in cui l'immagine può divergere da quella di tutti gli altri. Non lo si risolve costruendo una dashboard migliore sopra. Lo si risolve riducendo prima il numero di superfici.
L'istinto, quando i numeri non coincidono, è costruire una nuova dashboard «fonte unica di verità» di cui tutti dovrebbero fidarsi. Questo aggiunge una superficie. Non rimuove quelle in conflitto, quindi ora ha una cosa in più da tenere sincronizzata.
Giochi la mossa opposta. Applichi alle sue viste salvate un passaggio di mantieni, modifica, elimina, esattamente come farebbe con una pipeline gonfia o una lista di proprietà cresciuta troppo. Tenga le poche viste condivise da cui legge tutto il team. Modifichi il layout predefinito del record perché porti i campi di cui le persone hanno davvero bisogno, così nessuno debba costruire una vista privata per vederli. Elimini il resto. L'obiettivo non è la vista più potente. Sono le viste condivise meno numerose che fanno ancora il lavoro, di proprietà del team e non dei singoli.
Non complichi troppo. La maggior parte dei team con qualche centinaio di postazioni ha bisogno di una manciata di viste condivise, non di venti viste private.
Di recente abbiamo lavorato con un team B2B SaaS in serie B nella regione DACH che stava consolidando su un unico CRM. Strada facendo, due persone in una sessione di lavoro hanno aperto ciò che ciascuna chiamava «la vista contatti» e hanno parlato l'una sopra l'altra, perché i campi non corrispondevano. Abbiamo contato le viste salvate sugli oggetti principali. Solo sui contatti erano più di una dozzina, diverse di proprietà di persone che avevano cambiato ruolo, ciascuna mostrava una fetta leggermente diversa.
La soluzione non è stata un progetto di migrazione a sé. Abbiamo fatto sì che il layout predefinito dei contatti portasse tutto ciò che aveva la vista personalizzata del team di servizio, ottenuto l'accordo per eliminare quelle ridondanti, e fissato l'aspettativa che il team lavori da viste condivise anziché personali. Il problema di riconciliazione è scomparso, perché non c'era più nulla da riconciliare. Finalmente tutti guardavano lo stesso record nello stesso modo.
- Faccia l'inventario di ogni vista salvata sui suoi oggetti principali. Elenchi ciascuna con il suo titolare e l'ultima volta in cui è stata effettivamente usata. Non può decidere cosa tagliare finché non vede tutta la proliferazione in un unico posto.
- Dismetta le viste orfane. Tutto ciò che appartiene a chi ha cambiato team o se n'è andato è un candidato all'eliminazione. Nessuno le difende, e sono le vittorie più facili.
- Definisca le viste condivise da cui legge tutto il team. Un piccolo insieme, per oggetto e per ruolo, non per individuo. L'unità di proprietà è il team, così una nuova persona eredita dal primo giorno la stessa vista di tutti gli altri.
- Sposti i campi necessari nel layout predefinito del record. La maggior parte delle viste private esiste perché al layout predefinito mancava una colonna. Metta quelle colonne nel layout predefinito e la ragione per costruire una vista personale svanisce.
- Elimini quelle ridondanti, e regoli le nuove. Stabilisca la norma che le nuove viste condivise passino dalla persona che governa il CRM, così da non riproliferare subito fino al punto di partenza.
- Punti le sue automazioni e i suoi agenti sulle stesse viste condivise. Ciò che leggono i suoi workflow e i suoi agenti AI deve essere la stessa immagine che leggono le persone, così che software e persone lavorino da un solo record, non da due.
Non può fidarsi di un forecast, di un'automazione o di un agente che gira su dati che il suo stesso team non riesce a vedere in modo coerente. Standardizzarsi su viste condivise è poco spettacolare, ma è la vittoria di affidabilità più economica nel CRM, e spostare un team su viste condivise di solito è mezza giornata di lavoro, non un progetto. Se desidera una seconda coppia di mani per la pulizia, è proprio il tipo di cosa per cui è pensato il nostro lavoro in Revenue Operations e in implementazione HubSpot. Per il problema affine di standardizzare tutto questo prima di un go-live, legga l'articolo di accompagnamento su la prova generale prima del go-live del CRM.
- Thomas Redman. «To Improve Data Quality, Start at the Source.» Harvard Business Review, febbraio 2020. hbr.org
- Jason Lemkin. «Which CRM Should You Use in 2026/2027? Follow the Agents.» SaaStr, 2026. saastr.com