In genere, quando un revenue leader ci chiede di sistemare il forecast, il forecast non è il problema. Le fasi di pipeline sotto hanno smesso di significare la stessa cosa per i rep che vi muovono i deal. Discovery è la prima call per un rep e un mutual action plan firmato per un altro. Closed Won è contratto firmato in un team e kickoff schedulato nell'altro. La matematica della conversione è corretta e operativamente inutile, i numeri tornano contro definizioni che nessuno condivide.
Perché conta proprio adesso
La pressione sulle definizioni delle fasi è peggiorata, non migliorata, da quando l'AI ha cominciato a comparire dentro il funnel. Il pezzo Harvard Business Review di settembre di Sinha, Shastri, Lorimer e Mantrala sui team di vendita che crescono accanto all'AI ha sostenuto che i team che stanno tirando avanti sono quelli che trattano l'AI come un layer di coaching e orchestrazione sopra un processo di vendita già pulito, non come sostituto di esso. Quella è l'asimmetria. Se le definizioni delle Sue fasi sono strette, il tooling agentico accelera un sistema che già funziona. Se sono lasche, l'AI automatizza allegramente il drift, instradando deal su un segnale di fase che già significa tre cose diverse.
La diagnosi, «Closed Won» significa tre cose diverse a tre rep
Faccia un piccolo test sulla Sua istanza. Tiri fuori le ultime decine di deal passati da una fase tipo proposal-sent a una fase tipo negotiation, e chieda a ogni rep cosa significava quella transizione. Otterrà risposte tipo, il pricing è stato inviato; il pricing è stato inviato e riconosciuto; il pricing è stato inviato, riconosciuto, e procurement è coinvolto; il pricing è stato inviato e il champion ha detto verbalmente di sì. Quattro realtà operative, un valore di fase, un modello di forecast che le tratta come equivalenti.
Non è un problema di disciplina dei rep. È un problema di definizione. I rep fanno quello che le persone fanno sempre quando un sistema dà loro input ambigui, riempiono l'ambiguità con la propria definizione operativa, e il team poi ottimizza intorno al gap. È per questo che le pipeline review finiscono per sembrare deposizioni. Il manager non sta davvero rivedendo il deal; sta facendo reverse engineering di cosa il rep intendesse con la fase.
Il template criteri di entrata/uscita in una pagina
La soluzione è piccola e poco glamorosa. Ogni fase nella pipeline riceve quattro righe su una singola pagina condivisa:
- Definizione in una frase. Cos'è questa fase, in un linguaggio che un nuovo rep possa leggere il terzo giorno e applicare immediatamente. Se non riesce a scriverla in una frase, la fase sta facendo due lavori e va spezzata.
- Criteri di ingresso. La cosa specifica e verificabile che deve essere vera sul record del deal perché la fase venga aperta. «Il champion ha confermato che il budget esiste in questo anno fiscale, catturato nella proprietà Budget Confirmed».
- Criteri di uscita. La cosa specifica e verificabile che deve essere vera perché il deal lasci la fase in avanti. Diversa dall'ingresso, questo è il punto.
- Owner. Il ruolo responsabile della transizione. A volte l'AE; a volte il SE; a volte il deal desk. Nominare l'owner è ciò che rende la fase un passo di processo invece che un'etichetta.
Questo è tutto il template. Sta in una pagina. Il costo non è nella scrittura. Il costo è nel disaccordo che emerge mentre lo si scrive, ed è per questo che il template funziona solo come workshop, non come doc consegnato a una persona perché lo redassi da sola.
Camminarlo su un deal, cosa succede a ogni bordo di fase
Quindi per esempio: un team B2B SaaS con cui ho lavorato di recente aveva una pipeline a sei fasi. La fase intermedia, chiamiamola la fase di valutazione, non aveva criteri di ingresso e aveva criteri di uscita che combaciavano con i criteri di ingresso della fase successiva quasi parola per parola. Funzionalmente, la fase era un parcheggio. I deal vivevano lì per una mediana di circa tre settimane in più rispetto a ogni altra fase, e il team aveva accettato silenziosamente questo come il modo in cui funzionava la metà del pipeline. Quando abbiamo eseguito il workshop di riscrittura, due cose sono successe nei primi 20 minuti. Gli AE si sono resi conto che usavano quella fase per dire che il deal era in stallo e non volevano perderlo dal forecast. Il CRO si è reso conto che la fase esisteva perché qualcuno cinque anni prima voleva un posto per tracciare i POC e nessuno l'aveva più rivisitata. La decisione è stata semplice una volta che entrambe le cose erano sul tavolo, spezzarla. I POC hanno avuto la propria fase con il proprio ingresso e uscita; la versione parcheggio della fase intermedia è stata cancellata.
Ecco perché conta il workshop. L'artefatto alla fine è la pagina. Il lavoro è il far emergere.
Fasi che non si riescono a definire
Alcune fasi sopravvivono pulite alla riscrittura. Altre no. Il pattern, dopo aver girato questo su abbastanza istanze HubSpot da perdere il conto, circa un terzo delle fasi ha bisogno di un irrigidimento di definizione ma resta; circa un terzo va spezzata in due perché sta facendo due lavori operativi diversi; il resto viene fuso o cancellato. Se non riesce a scrivere una definizione in una frase nella stanza, la fase non è una fase. È un flag, e dovrebbe vivere come proprietà sul record del deal, non come posizione di pipeline.
Fasi operative vs. fasi di reporting
Da un lato, i Suoi rep hanno bisogno di fasi che corrispondano a ciò che fanno realmente ogni giorno: la forma dell'azione, la prossima call, l'artefatto richiesto per andare avanti. Dall'altro, il Suo CFO ha bisogno di fasi che si aggreghino pulite in un modello di forecast che regga a livello board. Quei due bisogni non sono sempre della stessa forma. Il modo in cui di solito risolvo: tenga le fasi di pipeline operative (rivolte ai rep, a forma di azione, da quattro a sei) e usi una proprietà forecast category separata, commit, most-likely, best-case, pipeline, che il manager possiede. Il rep muove la fase del deal; il manager assegna la forecast category. Campi diversi, owner diversi, niente lotta su cosa debba significare una singola colonna.
Pattern dal campo
Un team B2B SaaS DACH in Series B è venuto da noi chiedendo aiuto sul forecasting. Il problema dichiarato dal CRO era che il forecast pesato sbagliava di un margine significativo ogni trimestre. Il problema reale, emerso nella prima working session, era che la pipeline a otto fasi aveva tre fasi con criteri di uscita sovrapposti e una fase che il team SDR usava come holding pen per lead non qualificati. Abbiamo eseguito la riscrittura come workshop di due ore con i lead AE, il lead SDR, il CRO e il lead RevOps nella stanza. L'output: pipeline collassata da otto fasi a cinque; una fase promossa a proprietà; una fase spezzata perché POC e pilot a pagamento erano motion diverse. Il modello di forecast ricostruito contro la nuova architettura è atterrato entro il dieci percento del reale il trimestre successivo, non perché la matematica fosse diventata più intelligente, ma perché gli input finalmente significavano qualcosa.
Risoluzione, un playbook per la riscrittura
Se sta per eseguirla sulla Sua istanza, l'ordine conta:
- Blocchi due ore e metta le persone giuste nella stanza. Lead AE, lead SDR o BDR se il top of funnel è condiviso, il CRO e chi possiede RevOps. Niente spettatori. Il disaccordo è il lavoro.
- Cammini la pipeline attuale fase per fase e legga ad alta voce le definizioni esistenti. Se non c'è una definizione scritta, chieda a ogni rep nella stanza di scriverne una in 60 secondi e confronti. I delta sono la diagnosi.
- Per ogni fase, riempia le quattro righe. Definizione, ingresso, uscita, owner. Se la stanza non concorda su una definizione in una frase in tre minuti, la fase sta facendo due lavori. La spezzi.
- Segnali ogni fase in cui criteri di ingresso e uscita coincidono. Quella non è una fase; è una proprietà del deal travestita da fase. La promuova a proprietà e la rimuova dalla pipeline.
- Decida operativo vs. reporting adesso, non dopo. Le fasi di pipeline restano rivolte ai rep e a forma di azione. La forecast category diventa un campo separato del manager.
- Configuri i cambiamenti in HubSpot prima che chiunque lasci la stanza. Nomi delle fasi, criteri di entrata/uscita catturati come proprietà obbligatorie o gate di workflow, assegnazioni di owner. Se rinvia la configurazione, l'accordo decade in una settimana.
- Ribasi il forecast contro la nuova architettura. Le vecchie conversion rate non si trasferiscono. Esegua le prossime due pipeline review contro le nuove fasi prima di fidarsi di nuovo del modello.
Dove entra in gioco Checkpoint
Le riscritture delle fasi di pipeline sono una delle working session più comuni che eseguiamo dentro i nostri RevOps engagement a Checkpoint, di solito nel primo mese, quasi sempre prima di qualunque lavoro di forecasting o reporting. Se il Suo forecast manca, la matematica della conversione le sembra inaffidabile, oppure i Suoi rep litigano su cosa significa una fase in pipeline review, questo è il workshop da eseguire prima di passare un altro trimestre a modellare sopra definizioni che nessuno condivide.
Noah Charak