Schema di pipeline di vendita per founder B2B: campi minimi, stadi e tracciamento attività per prevedere chiaramente e mantenere i deal in movimento senza appesantire il CRM.
All'inizio la pipeline ti sembra chiara perché ci sono pochi deal e gran parte del contesto sta nella tua testa. Poi la lista cresce, perdi un follow-up e la pipeline comincia a raccontare una storia più bella della realtà. Quello è il “mentire della pipeline”: non intenzionale, ma dovuto al fatto che nulla nel sistema obbliga a dire la verità.
Si manifesta negli stessi schemi:
Una reazione comune è sovradimensionare il CRM: più campi, più stadi personalizzati, note più lunghe. Ironia della sorte, questo di solito peggiora la previsione. Quando aggiornare diventa pesante, le persone aggiornano di meno e la pipeline marcisce in silenzio.
Uno schema di pipeline minimo fa il contrario. È la struttura giusta per prendere decisioni. Non cerca di catturare tutto. Cattura i pochi fatti che ti impediscono di illuderti.
Se usi una sola regola, usa questa: ogni deal aperto deve avere (1) un prossimo passo esplicito, (2) una data per quell'azione e (3) una data di chiusura legata a una vera timeline del compratore (una riunione, una fase legale, una revisione del budget). Se manca uno di questi, il deal non è attivo.
Gli stadi dovrebbero avere anche un significato. Un deal avanza solo quando è successo qualcosa di concreto, non perché fa sentire bene. L'obiettivo non è una dashboard carina. L'obiettivo è una vista onesta su cui puoi gestire il business.
Uno schema di pipeline funziona solo se tutti lo usano nello stesso modo. Prima di aggiungere campi o discutere di stadi, decidete cosa rappresenta un singolo elemento della pipeline.
Un default pulito per il B2B è: un deal equivale a una decisione d'acquisto. Se la stessa azienda potrebbe comprare due volte (due team, due prodotti, due budget), allora sono due deal, non un singolo record confuso.
Mantieni gli oggetti semplici. Puoi fare molto con tre contenitori: un lead (una persona che puoi contattare), un account (l'azienda) e un deal (l'acquisto specifico che stai cercando di chiudere). Se sei da solo, puoi anche saltare lead e account formali e semplicemente assicurarti che ogni deal nomini chiaramente l'azienda e il contatto principale.
Scrivi poche regole operative, soprattutto se qualcuno oltre a te tocca la pipeline:
Esempio: parli con Alex di Northwind per un pilot al team finance. Quello è un deal. Se un mese dopo il prodotto vuole un contratto separato, crea un secondo deal. Non stirare un record per coprire due decisioni.
Una pipeline resta utile quando ogni deal ha i pochi campi che controlli realmente ogni settimana. Aggiungi campi “per ogni evenienza” e diventano decorazione.
Comincia con un formato nome deal che prevenga duplicati. Un pattern semplice funziona: Azienda - Prodotto/Scope - Trimestre/Mese. Esempio: “Acme - Team plan - Mar 2026.” Così è ovvio quando “Acme - Demo” e “Acme - Follow-up” sono lo stesso deal.
Ogni deal ha anche bisogno di identità chiara:
Il ruolo conta perché cambia cosa fai dopo. Un champion ha bisogno di abilitazione. Un decision maker ha bisogno di un business case.
Aggiungi campi di responsabilità:
Poi aggiungi solo i soldi e i tempi che userai:
Se non sei sicuro su un campo, lascialo fuori. Puoi sempre aggiungerlo dopo. Rimuovere campi dopo che si sono formate abitudini è molto più difficile.
La maggior parte delle pipeline “grandi” non è grande. È piena di deal che sono belli da vedere ma non hanno una chiara via verso un sì.
Inizia con un campo che obbliga alla chiarezza: Use case (scope). Scrivi cosa il compratore sta cercando di ottenere in parole semplici, più come si vede il “fatto” cioè cosa significa essere completato. Se non riesci a descrivere l'outcome in due frasi, probabilmente non capisci ancora il deal.
Poi cattura il processo decisionale in un unico posto. Non è una lista di contatti. È la storia di come si prende la decisione: chi firma, chi può bloccarla e quali passaggi devono seguire (revisione sicurezza, legale, procurement). Se non conosci il firmatario, considera il deal ancora in fase iniziale.
Aggiungi un segnale di compatibilità di prezzo, anche approssimativo. Fasce (“<$5k”, “$5-25k”, “$25k+”) vanno bene, oppure un semplice Likely / Unclear / Unlikely basato su quello che hai sentito. L'obiettivo è smettere di far avanzare deal che non possono permettersi la tua offerta.
Infine, tieni un campo red flags di una riga. Se servono paragrafi, vanno nelle note.
Un set compatto che funziona per la maggior parte dei founder B2B:
Esempio: “Vuole pulizia CRM prima del rinnovo, firmatario VP Sales, revisione sicurezza richiesta, budget probabile $10-20k, compete con fare nulla, red flag: champion non guida il progetto.” Quel singolo record è più difficile da ingannare.
Una pipeline peggiora quando diventa una lista dei desideri. La soluzione non è più campi. Sono pochi segnali di attività che costringono ogni deal a rispondere a una domanda: cosa succede dopo?
Se aggiungi un solo layer allo schema della pipeline, fallo con questi campi di attività:
Una regola pratica: se un deal non ha un prossimo passo o una data di scadenza, non è un vero deal. Mettilo in parcheggio o chiudilo. Questo migliora la precisione della previsione più di qualsiasi modello di scoring.
Mantieni “Motivo perdita” breve così lo userai davvero: prezzo, niente budget, nessuna decisione, scelto competitor, tempistica, non adatto.
Cosa significa nella pratica: fai una demo con un ops lead martedì. Subito dopo la chiamata imposti data ultima attività = martedì, canale ultimo contatto = meeting, prossimo passo = “Inviare 2 case study e confermare chi firma”, data scadenza prossimo passo = giovedì. Se giovedì passa senza risposta, il deal diventa rosso senza che nessuno discuta di “progresso pipeline”.
Un buon modello di stadi fa una cosa: dice la verità su dove si trova ogni deal, senza farti sorvegliare dozzine di piccoli passi. Se non riesci a dire cosa deve essere vero perché un deal sia in uno stadio, lo stadio diventa una sensazione.
Questa impostazione a sei stadi funziona per la maggior parte dei founder B2B:
New: Hai un nome e una ragione per contattare. Il primo contatto è fatto o pianificato.
Qualified: Il fit di base è confermato. Il problema è reale, il cliente corrisponde al tuo ICP e c'è una strada plausibile per l'acquisto.
Discovery done: Hai avuto una conversazione vera. Capisci use case, criteri di successo e chi è coinvolto.
Proposal sent: Prezzo e scope sono nelle mani del cliente. Un prossimo passo è prenotato o esplicitamente richiesto.
Negotiation/Legal: Procurement, sicurezza, approvazione budget o modifiche contrattuali sono in corso.
Closed won / Closed lost: L'esito è segnato e viene catturata una ragione.
Avanza un deal solo quando è successo qualcosa nel mondo reale (una riunione completata, una proposta inviata, il legale introdotto). Se non è successo nulla, lo stadio resta fermo.
Un nome di stadio non è una definizione di stadio. Se etichetti una colonna “Qualified” o “Negotiation” senza regole, ti ritroverai con deal che stazionano lì perché nessuno è d'accordo su cosa significhi “completo”.
Scrivi le regole di stadio come controlli semplici vero/falso. Quando ogni deal in uno stadio condivide gli stessi fatti, la tua pipeline rimane affidabile.
Il criterio di ingresso dice cosa deve essere già vero prima che un deal entri in uno stadio. Il criterio di uscita dice cosa deve cambiare prima che possa andare avanti. Mantieni entrambi brevi e misurabili.
Esempi:
Se non riesci a scrivere criteri senza parole come “buono”, “forte” o “interessato”, lo stadio è troppo vago.
Imposta un'età massima per ciascuno stadio come avviso precoce, non come punizione. Esempio: Discovery max 14 giorni, Proposal max 21 giorni. Quando un deal raggiunge il limite, attiva un reset: prenota un next step, riportalo indietro o chiudilo.
Decidi l'azione predefinita quando i criteri non sono soddisfatti:
Questo impedisce ai “deal zombie” di gonfiare la tua previsione.
Puoi costruire uno schema di pipeline in poche ore se lo tratti come un piccolo prodotto: prima le regole, poi solo ciò che le supporta.
Inizia su una pagina bianca, non dentro uno strumento. Scrivi i tuoi stadi e i criteri di ingresso/uscita in inglese semplice. Se non riesci a spiegare uno stadio in una frase, probabilmente sono due stadi (o non è uno stadio).
Un flusso di costruzione semplice:
Fai un test realistico durante la configurazione: prendi un deal su cui stai lavorando e prova a spostarlo stadio per stadio. Se continui a indovinare, i criteri sono troppo vaghi.
Una regola da applicare subito: se la data prossima attività è vuota, il deal non può restare in uno stadio attivo.
La maggior parte del bloat del CRM nasce da buone intenzioni: vuoi più accuratezza, quindi aggiungi più campi, più stadi e più note. Il risultato è l'opposto. Le persone smettono di aggiornare e la pipeline diventa un luogo dove i deal vanno ad invecchiare.
Se due stadi sembrano uguali, verranno usati allo stesso modo. “Discovery”, “Deep discovery” e “Discovery follow-up” spesso significano “abbiamo parlato”, senza un chiaro prossimo evento. Gli stadi dovrebbero cambiare solo quando succede qualcosa di reale.
Test rapido: se non riesci a dire cosa deve essere vero per entrare nello stadio in una frase, probabilmente è superfluo.
La data di chiusura è utile solo se è legata a una ragione. Trattala come la data del prossimo punto decisionale (approvazione budget, riunione procurement, scadenza firma) e spostala quando quell'evento si sposta.
Le note lunghe nascondono la cosa che ti serve: cosa è successo per ultimo e cosa succede dopo. Mantieni le note brevi e traccia le attività con data ultima attività più prossimo passo (con un owner e una data di scadenza).
Senza una definizione, “qualified” diventa “sembravano carini”. Scegli 3-4 controlli che devono essere veri (problema, compratore, timeline e qualche forma di budget). Se manca uno, non è ancora qualificato.
Le pipeline che crescono senza mai ridursi smettono di essere una pipeline e diventano un cimitero. Chiudi come perso rapidamente quando il deal è inattivo o non è in fit, e registra una ragione chiara così puoi imparare.
Scegli un momento fisso ogni settimana (30 minuti bastano) e trattalo come una riunione con il tuo futuro sé. L'igiene della pipeline riguarda meno l'aggiunta di campi e più il verificare che ogni deal abbia ancora una reale strada in avanti.
Un flusso di revisione semplice:
Esempio concreto: se un deal è segnato “Proposal sent” ma non c'è una riunione prenotata per rivederla, non è uno stato proposal. Riportalo indietro, imposta il prossimo passo e smetti di contarci finché il compratore non è di nuovo coinvolto.
Vendi uno strumento di analytics B2B a una azienda e-commerce da 50 persone. Dopo la prima chiamata crei un deal e compili solo ciò che userai la settimana successiva. Uno schema semplice paga qui perché costringe chiarezza, non burocrazia.
Subito dopo la chiamata il record appare così:
Il deal parte in Discovery. Lo sposti avanti solo quando l'invito del calendario è accettato (non quando qualcuno “sembra interessato”). Dopo la demo, il trigger per passare in evaluation è una richiesta concreta (per esempio, “Potete collegarvi a Shopify e ai nostri dati di magazzino?”), seguita da un check tecnico concordato.
Ora lo stallo: il CFO si zittisce dopo i prezzi. Il tuo log mostra due follow-up, nessuna risposta e la data del prossimo passo passa. La regola è semplice: se non c'è un next step concordato, il deal non può restare in Proposal.
Quindi fai una mossa onesta: o lo riporta in evaluation (se serve un nuovo sponsor o informazioni mancanti) o lo chiudi come perso (se il decision maker non si impegna entro una data stabilita). In questo esempio lo riporti indietro, aggiorni gli stakeholder (Ops coinvolge il finance manager), imposti una nuova data per il prossimo passo e torni in Proposal solo quando il CFO conferma una riunione decisionale.
Uno schema di pipeline funziona solo se ti fidi di esso. Il modo più veloce per arrivarci è partire minimo e usarlo per 30 giorni. Questo ti mostra ciò che usi davvero, non ciò che pensi di potresti aver bisogno.
Per il primo mese sii severo: se un campo non cambia una decisione, rimuovilo. Se una decisione continua a emergere e non riesci a rispondere dal pipeline, aggiungi esattamente un campo per coprire quel gap.
Un test semplice prima di aggiungere un nuovo campo: “Se questo è vuoto, non possiamo decidere se ___.”
Se vuoi costruire un CRM leggero e personalizzato invece di adattare uno generico, strumenti come Koder.ai possono aiutare una volta che hai scritto i tuoi stadi, i campi richiesti e le regole di validazione. È molto più facile generare e iterare su una semplice app quando lo schema è chiaro.
Una pipeline “mente” quando mostra progressi non supportati da azioni reali del compratore. Le cause più comuni sono next step mancanti, date dell'ultima attività obsolete e date di chiusura spostate in avanti senza una timeline confermata dal cliente.
Rendi non negoziabili tre campi per ogni deal aperto: un'azione concreta successiva, una data di scadenza per quell'azione e una data di chiusura legata a un evento reale del compratore (riunione, revisione, firma). Se uno di questi manca, considera il deal inattivo finché non vengono compilati.
Per default: “un deal = una decisione di acquisto”. Se la stessa azienda potrebbe comprare due volte attraverso team, budget o contratti diversi, crea deal separati così non mescoli timeline e stakeholder diversi in un unico record confuso.
Inizia con un formato di nome deal che prevenga duplicati, una società, un contatto primario, un owner, valore atteso, data obiettivo di chiusura e una fonte chiara. Poi aggiungi solo la qualificazione necessaria: use case, processo decisionale e adattamento del prezzo.
Un use case di una frase più i criteri di successo ti costringono a capire il risultato, non solo l'interesse del compratore. Se non riesci a descrivere chiaramente il risultato, di solito il deal è ancora troppo precoce per prevederlo.
Scrivilo come una breve storia di come viene presa la decisione: chi firma, chi può bloccarla e quali passaggi devono accadere (sicurezza, legale, procurement). Se non conosci ancora il firmatario, mantieni il deal in uno stadio iniziale e concentra il prossimo passo nel trovarlo.
Usa una fascia approssimativa o un semplice Likely/Unclear/Unlikely basato su ciò che hai sentito. L'obiettivo non è la matematica perfetta del prezzo, ma evitare di far avanzare deal con un budget incompatibile con la tua offerta.
Traccia data ultima attività, prossimo passo, data di scadenza del prossimo passo e una ragione di chiusura quando finisce. Le note possono esistere, ma sono questi campi di attività a impedire che i deal deraglino e a costringerti a decidere il prossimo passo.
Sposta gli stadi solo quando qualcosa di reale è successo, come una chiamata di discovery completata, una proposta veramente inviata o l'introduzione del team legale. Se il cambio di stadio può avvenire solo perché “ci si sente bene”, la definizione dello stadio è troppo vaga e la tua previsione deraglierà.
Imposta un numero massimo di giorni per ciascuno stadio come avviso precoce, poi attiva un reset quando il limite è raggiunto. L'azione predefinita è semplice: prenota un next step reale, riporta il deal allo stadio precedente che corrisponde ai fatti, o chiudilo come nessuna decisione dopo tentativi di follow-up chiari.
