Checklist per l’audit del sistema di acquisizione: dalla domanda alla pipeline
31 Agosto 2026 · Strategia
Perché usare questa checklist
Questa checklist serve a ricostruire dove una richiesta perde contesto, viene qualificata male o non raggiunge le vendite. Va applicata a offerte e percorsi concreti, confrontando tracciamento, CRM e gestione commerciale: un controllo formalmente presente non vale se il passaggio end-to-end mostra un comportamento diverso.
Definire il perimetro prima degli strumenti
L’audit parte dalle offerte prioritarie, dai mercati servibili e dalla definizione condivisa di lead accettato e opportunità. Senza questi riferimenti, traffico e conversioni restano numeri privi di un criterio commerciale.
Seguire richieste reali
Un campione di richieste vinte, perse, fuori target e non lavorate permette di osservare il sistema reale. La ricostruzione deve conservare fonte, pagina, dati inviati, owner, tempi e risultato.
Separare perdita di volume e perdita di qualità
Un sistema può generare poche richieste pertinenti o molte richieste inutili. Le cause e le correzioni sono diverse: domanda, messaggio, esperienza, qualifica, routing o capacità commerciale.
Chiudere il ciclo dei dati
Gli esiti delle vendite devono tornare a dashboard e piattaforme. Se il sistema ottimizza soltanto sull’invio del form, può premiare fonti che producono volume ma non opportunità.
Trasformare l’audit in una roadmap
Ogni problema deve avere evidenza, impatto, owner, dipendenze, test e data. Le correzioni bloccanti precedono l’aumento di budget.
Checklist operativa
| Area | Controllo | Evidenza richiesta | Priorità |
|---|---|---|---|
| Offerta | Sono documentate priorità, margini, territori e richieste non servibili? | Documento commerciale approvato | Alta |
| Domanda | Query e pubblici corrispondono a problemi realmente servibili? | Mappa domanda–offerta | Alta |
| Messaggio | Annunci e pagine dichiarano condizioni e differenze verificabili? | Campione di annunci e landing | Alta |
| Percorsi | Ogni intento ha una destinazione e una CTA coerente? | Mappa fonte–pagina–azione | Alta |
| Form | I moduli raccolgono dati utili senza bloccare richieste valide? | Test e analisi errori | Alta |
| Routing | Prodotto, territorio e priorità determinano l’owner corretto? | Regole e log di assegnazione | Alta |
| SLA | Sono definiti presa in carico, escalation e risposta? | SLA e timestamp CRM | Media |
| Tassonomia | Contatto, lead, MQL, SQL e opportunità hanno criteri condivisi? | Glossario lifecycle | Alta |
| Feedback | Motivi di accettazione e rifiuto ritornano al marketing? | Campi CRM e report | Alta |
| Tracking | Fonte, pagina e identificativi arrivano nel CRM? | Test end-to-end | Alta |
| Valore | Le opportunità hanno valore o classe di valore? | Pipeline e regole | Media |
| Governance | Ogni passaggio ha owner e controllo periodico? | RACI e calendario | Alta |
Come leggere la checklist
Per ciascuna riga, «conforme» richiede un riscontro nel flusso reale, come un test end-to-end, un timestamp CRM o una regola applicata a un caso. «Parziale» segnala copertura discontinua; «non conforme» identifica un’assenza o un errore osservato; «N/A» è ammesso solo quando quel controllo non interviene nell’offerta o nel percorso esaminato.
Le etichette Alta e Media indicano quanto una lacuna può compromettere la lettura della pipeline, non una coda di esecuzione già pronta. Prima si affrontano i difetti che falsano fonte, qualifica o assegnazione e che impediscono di valutare gli interventi successivi; a parità di impatto, contano dipendenze tecniche, rischio di interruzione e facilità di verifica.
| 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
Offerta
Verificare se sono documentate priorità, margini, territori e richieste non servibili?. Evidenza minima: Documento commerciale approvato. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Domanda
Verificare se query e pubblici corrispondono a problemi realmente servibili?. Evidenza minima: Mappa domanda–offerta. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Messaggio
Verificare se annunci e pagine dichiarano condizioni e differenze verificabili?. Evidenza minima: Campione di annunci e landing. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Percorsi
Verificare se ogni intento ha una destinazione e una CTA coerente?. Evidenza minima: Mappa fonte–pagina–azione. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Form
Verificare se i moduli raccolgono dati utili senza bloccare richieste valide?. Evidenza minima: Test e analisi errori. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Routing
Verificare se prodotto, territorio e priorità determinano l’owner corretto?. Evidenza minima: Regole e log di assegnazione. Il controllo si chiude quando la prova è accessibile, l’eccezione è documentata e un owner garantisce la manutenzione.
Output obbligatori
- Mappa end-to-end del sistema
- Registro delle perdite
- Tassonomia lead e opportunità
- Roadmap ordinata per dipendenze
- Dashboard qualità e tempi
Il risultato operativo è una lista di correzioni collegate ai punti di perdita: per esempio preservare il prodotto consultato nel CRM, distinguere gli stati di rifiuto o verificare il routing per territorio. Ogni voce deve indicare il comportamento errato, il riscontro che lo dimostra, chi può correggerlo, i sistemi coinvolti e la prova end-to-end che ne confermerà la risoluzione.
Scenario applicativo
L’account Ads mostra un CPL accettabile, ma le vendite dichiarano lead scarsi. La ricostruzione rivela che il form non conserva il prodotto consultato e che tutte le richieste vengono assegnate alla stessa casella.
La priorità non è cambiare bidding: prima si correggono contesto, routing e feedback. Solo dopo la piattaforma riceve segnali commerciali migliori.
Errori da evitare
- Partire dal canale che spende di più senza ricostruire il sistema.
- Usare il numero di form come sinonimo di opportunità.
- Produrre un backlog per reparto senza dipendenze comuni.
- Ignorare richieste non lavorate o prive di stato.
- Aumentare volume prima di chiudere le perdite bloccanti.
Domande frequenti
Quanto deve essere ampio il campione?
Deve coprire offerte, fonti ed esiti differenti. La completezza del percorso è più importante del numero grezzo.
L’audit deve includere le vendite?
Sì. Senza esiti e motivi commerciali non è possibile valutare la qualità del sistema.
Qual è il primo output?
Una mappa condivisa dei passaggi e delle definizioni, prima delle raccomandazioni tecniche.
Fonti e riferimenti
- Microsoft Learn — Lead management overview — https://learn.microsoft.com/en-us/dynamics365/sales/lead-management-overview
- Google Analytics — Recommended events for lead generation — https://support.google.com/analytics/answer/9267735?hl=en
- Salesforce — Sales and Marketing Alignment — https://www.salesforce.com/marketing/sales-marketing-alignment/
Approfondisci il servizio: Consulenza marketing B2B.