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.
Il percorso mostra dove cercare la prova che il modulo funzioni, oltre al semplice invio.
Scarica l’infografica (PNG ad alta risoluzione)
Incorpora l’infografica nel tuo sito
Puoi ripubblicare l’infografica usando questo codice, con il collegamento all’articolo originale.
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
Per un distributore di valvole, una richiesta inviata dalla scheda di una valvola deve riportare il relativo codice nel CRM, il sistema in cui i commerciali seguono i contatti. Il collaudo confronta la scheda visitata con la richiesta ricevuta. Il codice deve arrivare al referente senza che il cliente debba riscriverlo nel messaggio.
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
Nel modulo di un costruttore di impianti, il microcopy è il breve testo accanto al campo che aiuta a compilarlo. Sotto «Produzione richiesta» può comparire «Indica i pezzi all’ora; puoi scrivere da definire». Durante la prova si controlla che questa indicazione sia leggibile dal telefono e che la risposta aperta venga accettata dal modulo.
Errori
La prova degli errori deve mostrare quale campo impedisce l’invio e come correggerlo, mantenendo i dati già inseriti. Il controllo comprende l’uso della tastiera e del telefono. Chi segue il sito deve poter ritrovare il problema segnalato e ripetere la prova dopo la correzione.
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.
Un modulo curato fino alla consegna della richiesta aiuta il commerciale a rispondere con le informazioni già disponibili, senza chiedere di nuovo ciò che il cliente ha compilato. Le richieste raggiungono il referente adatto e i messaggi di errore risolti riducono gli ostacoli per chi vuole un preventivo.
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.