# CRM B2B: quali campi servono davvero e quali creano soltanto lavoro inutile | KLC

Tipo: articolo informativo
Sito: KLC (www.klc.it)
URL canonico: https://www.klc.it/blog/dati-e-misurazione/crm-b2b-quali-campi-servono-davvero-e-quali/
Autore: KLC
Pubblicato: 2 Ottobre 2026
Ultimo aggiornamento: 24 Agosto 2026
Lingua: it-IT
Categoria: Dati e misurazione

## Sintesi

Ogni nuovo problema organizzativo tende a produrre un nuovo campo nel CRM. Dopo alcuni anni, il record contiene decine di menu, caselle e note; molti valori sono vuoti, altri vengono compilati con scelte casuali e nessuno sa quali siano realmente usati.

## CRM B2B: quali campi servono davvero e quali creano soltanto lavoro inutile

Scritto da KLC il 2 Ottobre 2026. Pubblicato in Dati e misurazione.

2 Ottobre 2026 · Dati e misurazione

Ogni nuovo problema organizzativo tende a produrre un nuovo campo nel CRM. Dopo alcuni anni, il record contiene decine di menu, caselle e note; molti valori sono vuoti, altri vengono compilati con scelte casuali e nessuno sa quali siano realmente usati. Il costo non è soltanto il tempo di inserimento: dati incoerenti rendono routing, reporting e automazioni meno affidabili.

Il modello corretto non è quello che raccoglie più informazioni. È quello che conserva le informazioni necessarie alla prossima decisione, con una responsabilità e un momento di compilazione chiari.

## Ogni campo deve superare quattro prove

Prima di creare un campo, chiedere:

1. Quale decisione sostiene? Routing, qualifica, priorità, forecast, personalizzazione, conformità o analisi.
2. Chi conosce il dato? Utente, marketing, commerciale, amministrazione, sistema o fonte esterna.
3. Quando diventa conoscibile? Al form, dopo la prima chiamata, alla proposta, alla chiusura.
4. Che cosa accade se manca o cambia? Blocco, avviso, valore “non noto”, aggiornamento o nessuna conseguenza.

Se nessuno sa quale decisione dipenda dal campo, probabilmente è un desiderio informativo, non un requisito.

## Separare dati di identità, relazione e opportunità

Una struttura minima può distinguere:

## Account

Ragione sociale, dominio, Paese, settore, gruppo, stato cliente/prospect/partner, owner, eventuale identificativo gestionale.

## Contatto

Nome, ruolo, funzione, recapiti, lingua, relazione con l’account, preferenze o basi giuridiche gestite dai sistemi competenti.

## Lead o richiesta

Data, fonte originaria, pagina o campagna, tipo di richiesta, interesse espresso, testo originale, owner, stato e motivo finale.

## Opportunità

Problema, soluzione o famiglia, valore o intervallo, fase, probabilità gestita, data prevista, prossimo passo, persone coinvolte, concorrenti o alternative quando rilevanti.

Confondere questi livelli genera duplicazioni. Il settore appartiene normalmente all’account; la richiesta specifica appartiene al lead; il valore appartiene all’opportunità. Copiare tutto su ogni oggetto produce divergenze.

## Dati dichiarati, derivati e osservati

Non tutti i valori hanno la stessa affidabilità. Conviene indicare la provenienza:

- dichiarato dal contatto, per esempio quantità prevista;
- inserito da un commerciale, per esempio fase;
- derivato da una regola, per esempio macrosettore;
- osservato da sistemi, per esempio pagina di conversione;
- arricchito da un fornitore esterno.

Il fatturato stimato da un database non dovrebbe apparire come dato certo fornito dall’azienda. Anche il settore automatico può essere errato per gruppi diversificati. La provenienza aiuta a decidere quanto fidarsi e quando verificare.

## Menu controllato o testo libero?

Un menu è utile quando il valore deve alimentare una regola o un confronto: motivo di esclusione, fase, territorio, famiglia di prodotto. Il testo libero è migliore quando il contesto è troppo ricco per una tassonomia: descrizione del problema, vincoli, citazione del cliente.

La soluzione spesso combina entrambi:

- categoria strutturata per l’analisi;
- nota sintetica per il caso specifico.

Un menu con cinquanta opzioni non è davvero strutturato: spinge a scegliere la prima voce plausibile. Le tassonomie devono essere brevi, mutuamente distinguibili e accompagnate da esempi.

## Obbligatorietà progressiva

Rendere tutto obbligatorio all’apertura porta a valori inventati. Un commerciale che non conosce la data prevista selezionerà fine trimestre; il forecast sembrerà completo ma sarà falso.

I campi vanno richiesti quando servono per avanzare:

| Momento | Campi ragionevoli |
| --- | --- |
| Nuova richiesta | origine, tipo, recapito, testo, owner |
| Accettazione | esito verifica, priorità, prossimo passo |
| Qualifica | fit, problema, processo, timing o evento |
| Opportunità | fase, valore/intervallo, data, stakeholder |
| Proposta | soluzione, importo, condizioni, decisione attesa |
| Chiusura | esito, motivo, concorrente/inerzia, note finali |

“Non noto” può essere un valore valido se il sistema distingue ciò che manca da ciò che non si applica.

## Campi calcolati e automazioni

Calcolare automaticamente ciò che può essere derivato riduce il lavoro, ma la formula deve essere documentata. Esempi:

- giorni nella fase;
- tempo dalla richiesta alla prima azione;
- numero di contatti attivi nell’account;
- fascia di valore;
- regione da provincia;
- stato SLA;
- ultimo evento significativo.

Non conviene automatizzare interpretazioni fragili. Dedurre “interesse alto” da una visita o “decisore” dal titolo professionale può introdurre errori nascosti.

## Privacy, minimizzazione e conservazione

Raccogliere un dato perché “potrebbe servire” non è una giustificazione sufficiente. Il principio di minimizzazione richiede che i dati personali siano adeguati, pertinenti e limitati a ciò che serve rispetto alle finalità. Anche i tempi di conservazione devono essere definiti e revisionati.

Sul piano operativo significa:

- non chiedere informazioni sensibili non necessarie;
- distinguere dati commerciali da consensi e preferenze;
- limitare accessi in base ai ruoli;
- definire retention per lead inattivi, clienti e log;
- documentare fonti e aggiornamenti;
- gestire cancellazione, rettifica e opposizione nei processi competenti;
- evitare copie incontrollate in fogli ed email.

La configurazione tecnica deve essere verificata con chi gestisce privacy e sicurezza; un articolo non sostituisce la valutazione giuridica.

## Audit dei campi esistenti

Per ogni campo esportare:

- percentuale compilata;
- valori unici e distribuzione;
- data dell’ultimo aggiornamento;
- automazioni e report che lo usano;
- oggetto e proprietario;
- eventuali duplicati semantici;
- presenza di dati personali;
- decisione: mantenere, unire, calcolare, archiviare o rimuovere.

Un campo compilato al 5% non è automaticamente inutile: potrebbe essere fondamentale per un segmento raro. Ma deve avere un proprietario e una ragione. Un campo compilato al 100% può essere peggiore se contiene “N/D” forzati o valori predefiniti.

## Un esempio di semplificazione

Un’azienda possiede 94 campi sul lead. L’audit mostra che 31 non compaiono in alcun report o automazione, 12 duplicano dati dell’account, 9 vengono compilati soltanto dopo la conversione e 7 contengono note che dovrebbero stare nell’opportunità. Il nuovo modello mantiene 28 campi, di cui solo 8 visibili alla creazione.

Il miglioramento viene misurato non dal numero ridotto, ma da:

- tempo di aggiornamento;
- completezza nei momenti decisionali;
- errori di routing;
- opportunità senza prossimo passo;
- affidabilità dei report;
- richieste di supporto degli utenti.

## Quanti campi dovrebbe avere un CRM B2B?

Non esiste un numero corretto. Conta quanti sono necessari per i diversi oggetti e passaggi, e quanti devono essere visibili in ciascun momento.

## Conviene cancellare subito i campi inutilizzati?

Prima verificare report, integrazioni, automazioni e storico. Spesso è più sicuro disattivarli dalle viste, documentarli e rimuoverli dopo un periodo di controllo.

## Chi deve approvare un nuovo campo?

Un responsabile del modello dati, con verifica di chi usa il processo, chi gestisce integrazioni e, quando necessario, privacy e sicurezza.

## Fonti e riferimenti per la revisione

- EUR-Lex — Regulation (EU) 2016/679 – GDPR — https://eur-lex.europa.eu/eli/reg/2016/679/oj
- European Commission — How much data can be collected? — https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr/how-much-data-can-be-collected_en
- European Commission — For how long can data be kept? — https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/principles-gdpr/how-long-can-personal-data-be-kept_en
- Salesforce Help — Guidelines for managing leads — https://help.salesforce.com/s/articleView?id=sales.leads_guidelines.htm&type=5
- Salesforce Help — Manage duplicate records — https://help.salesforce.com/s/articleView?id=sales.duplicate_management_manage_duplicates.htm&type=5

Approfondisci il servizio: Analytics e conversioni.

## Vedi anche

- [Attribuzione nel B2B: perché l’ultimo clic non racconta il processo di vendita](https://www.klc.it/blog/dati-e-misurazione/attribuzione-nel-b2b-perche-lultimo-clic-non-racconta/)
- [Dal lead alla pipeline: come costruire un modello economico collegato al CRM](https://www.klc.it/blog/dati-e-misurazione/dal-lead-alla-pipeline-come-costruire-un-modello/)
- [ROI del marketing B2B: formula, limiti e dati necessari](https://www.klc.it/blog/dati-e-misurazione/roi-del-marketing-b2b-formula-limiti-e-dati/)
- [Incrementalità: capire che cosa sarebbe successo anche senza la campagna](https://www.klc.it/blog/dati-e-misurazione/incrementalita-capire-che-cosa-sarebbe-successo-anche-senza/)
- [Costo dello stack MarTech: strumenti, integrazioni e lavoro invisibile](https://www.klc.it/blog/dati-e-misurazione/costo-dello-stack-martech-strumenti-integrazioni-e-lavoro/)

---

Versioni alternative di questo contenuto:
- HTML completo: https://www.klc.it/blog/dati-e-misurazione/crm-b2b-quali-campi-servono-davvero-e-quali/
- JSON strutturato: https://www.klc.it/blog/dati-e-misurazione/crm-b2b-quali-campi-servono-davvero-e-quali.json

Fonte: KLC
Licenza: All rights reserved
Generato da AI Discovery Bridge v1.9.3