Checklist per il modulo di contatto B2B: campi, microcopy, privacy e routing
17 Settembre 2026 · Dati e misurazione
Perché usare questa checklist
Questa checklist serve a seguire una richiesta dal primo campo visualizzato fino alla corretta registrazione nel CRM. Va applicata separatamente a contatto, RFQ, assistenza e altri intenti presenti sul sito, provando condizioni, allegati, messaggi di errore, consenso, conferma e destinazione finale su dispositivi e lingue pertinenti.
Separare gli intenti
Contatto esplorativo, RFQ, assistenza, candidatura e distributore non dovrebbero generare lo stesso flusso. Il primo bivio deve modificare davvero campi e destinazione.
Chiedere il minimo utile
Ogni campo obbligatorio deve cambiare fattibilità, routing, compliance o qualità della risposta. I dati che il buyer non può conoscere devono avere un’opzione aperta.
Gestire allegati e sicurezza
Disegni e capitolati richiedono formati, limiti, scansione, conservazione e accessi. La conferma deve indicare che il file è stato ricevuto.
Scrivere microcopy operativa
Etichette, unità, esempi e spiegazioni riducono errori. Il visitatore deve sapere chi risponderà e in quali tempi realistici.
Misurare oltre l’invio
Start, errore, abbandono, submit, spam, lead accettato e opportunità descrivono fasi diverse.
Checklist operativa
| Area | Controllo | Evidenza richiesta | Priorità |
|---|---|---|---|
| Intento | Il modulo ha un compito preciso? | Inventario form–intento | Alta |
| Contesto | Pagina, prodotto, lingua e campagna vengono conservati? | Payload e CRM | Alta |
| Campi | Ogni campo obbligatorio cambia una decisione? | Matrice campo–uso | Alta |
| Condizioni | Le domande successive compaiono solo quando rilevanti? | Test logiche | Media |
| Valori aperti | Il buyer può indicare «da definire»? | UX test | Media |
| Allegati | Formato, dimensione, scansione e accessi sono governati? | Policy upload | Alta |
| Microcopy | Etichette, esempi e unità sono comprensibili? | Revisione UX | Alta |
| Errori | I messaggi indicano problema e soluzione? | Test mobile/tastiera | Alta |
| Privacy | Informativa, consenso e conservazione sono coerenti? | Verifica legale/tecnica | Alta |
| Conferma | Il messaggio successivo spiega tempi e referente? | Email e pagina grazie | Media |
| Routing | I dati alimentano owner, stato e SLA? | Test CRM | Alta |
| Qualità | Submit, accettazione e opportunità sono collegati? | Dashboard end-to-end | Alta |
Come leggere la checklist
L’esito deve derivare da una prova del modulo e dal record generato. «Sì» indica che campo, messaggio o regola funzionano nel percorso previsto; «parziale» segnala differenze tra intenti, lingue o dispositivi; «no» si usa per errori, dati persi o destinazioni scorrette; «non applicabile» richiede che quella funzione, come l’upload, non sia disponibile né necessaria nel modulo verificato.
La priorità va assegnata considerando l’effetto sulla possibilità di inviare la richiesta, sulla protezione dei dati e sulla capacità di rispondere correttamente. Un errore che blocca il submit o inoltra un allegato al destinatario sbagliato precede una microcopy migliorabile; modificare i campi, però, richiede di verificare anche payload, automazioni, CRM e report collegati.
| Esito | Significato | Azione |
|---|---|---|
| Conforme | Regola documentata, applicata e controllata. | Mantenere e fissare la revisione. |
| Parziale | Pratica incompleta, incoerente o non misurabile. | Definire lacuna, owner e scadenza. |
| Non conforme | Regola assente o problema osservabile. | Aprire intervento e gestire le dipendenze. |
| N/A | Controllo realmente estraneo al perimetro. | Documentare la motivazione. |
Interpretazione dei controlli più bloccanti
Intento
Verificare se il modulo ha un compito preciso?. Evidenza minima: Inventario form–intento. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Contesto
Verificare se pagina, prodotto, lingua e campagna vengono conservati?. Evidenza minima: Payload e CRM. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Campi
Verificare se ogni campo obbligatorio cambia una decisione?. Evidenza minima: Matrice campo–uso. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Allegati
Verificare se formato, dimensione, scansione e accessi sono governati?. Evidenza minima: Policy upload. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Microcopy
Verificare se etichette, esempi e unità sono comprensibili?. Evidenza minima: Revisione UX. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Errori
Verificare se i messaggi indicano problema e soluzione?. Evidenza minima: Test mobile/tastiera. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Output obbligatori
- Inventario dei form
- Matrice campi e logiche
- Policy allegati
- Specifiche routing/CRM
- Piano eventi e QA
Inventario, matrice dei campi e specifiche CRM devono guidare configurazione e collaudo del modulo. Per ogni modifica vanno provati valori validi e non validi, logiche condizionali, upload, messaggi, consenso, conferma e record ricevuto; la correzione è conclusa solo se non interrompe routing, notifiche ed eventi di misurazione già necessari.
Scenario applicativo
Un form RFQ rende obbligatori quantità, tolleranza e data di consegna. I buyer esplorativi inseriscono dati casuali o abbandonano.
Il nuovo flusso chiede il livello di definizione e mostra campi tecnici solo quando disponibili. Le richieste complete e quelle esplorative seguono routing diversi.
Errori da evitare
- Rendere obbligatorio tutto ciò che piacerebbe conoscere.
- Usare un modulo universale per processi incompatibili.
- Accettare file senza regole.
- Mostrare errori generici.
- Misurare il solo tasso di completamento.
Domande frequenti
Quanti campi sono troppi?
Quelli che non migliorano risposta, routing o conformità.
Il telefono deve essere obbligatorio?
Solo quando serve realmente e la motivazione è chiara.
Il form a più passaggi è migliore?
Può esserlo per processi complessi, ma va testato su progressione, mobile e trasparenza.
Fonti e riferimenti
- W3C WAI — Forms Tutorial — https://www.w3.org/WAI/tutorials/forms/
- W3C WAI — Labeling Controls — https://www.w3.org/WAI/tutorials/forms/labels/
- European Commission — Principles of personal data processing under the GDPR — https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en
Approfondisci il servizio: Analytics e conversioni.