Due working session questa settimana, stesso cliente, stessa stanza, due problemi diversi alla lavagna, e uno di questi era una diagnosi silenziosa di pipeline su cui il team era seduto da un anno. Il loro head of sales ha aperto la pipeline HubSpot ufficiale, ha percorso i deal stage e poi ha posto alla stanza una domanda che è rimasta sospesa per un secondo. E i cinquanta SQL che non abbiamo ancora spostato? Nessuno ha risposto, perché nessuno aveva la risposta. Cinquanta lead che avevano preso un sales meeting, passato la qualificazione iniziale, e che erano fermi da qualche parte su un contact record con un lifecycle stage di SQL, ma senza deal record. Invisibili al forecast. Invisibili alla pipeline review. Invisibili alla conversazione di capacity del prossimo trimestre. Quel gap è la scelta strutturale più costosa nelle istanze HubSpot B2B SaaS mid-stage in questo momento, e non ha niente a che fare con HubSpot. Ha a che fare con quando lei decide che il deal inizia.
Perché questo conta ora
Il readout di gennaio di Jason Lemkin sul 2026 sales reckoning è stato schietto sul cambiamento strutturale in atto: i team B2B AI-native fanno girare panchine di sales grandi più o meno la metà rispetto ai loro predecessori, e l'outbound guidato da AI sta generando un quarto della nuova pipeline nella sua stessa organizzazione in novanta giorni. È il quadro macro dentro cui questo gap appare. I team sales rimpiccioliti dall'AI aggravano il problema strutturale, non c'è più uno strato SDR a curare a mano il gap tra un MQL e un deal record, quindi è l'AE a fare la discovery, e l'AE ha tutti gli incentivi a rinviare la creazione del deal finché non è sicuro che sia reale. Moltiplichi questo su dieci rep e un trimestre, e ottiene il cassetto dei cinquanta SQL. I forecast non sono sbagliati perché il modello di close date è cattivo. Sono sbagliati perché la pipeline non contiene i deal.
Dove vive il SQL gap in HubSpot
Il lifecycle di HubSpot è modellato sulla contact-property: subscriber, lead, MQL, SQL, opportunity, customer. Il deal è un oggetto separato che viene creato, di solito, quando il lifecycle del contact passa a opportunity. La convenzione è ragionevole in linea di principio e un disastro nella pratica, perché la definizione operativa di opportunity nella maggior parte dei team di sales è «sono abbastanza sicuro per committarlo nella pipeline». Quella soglia di confidenza è sana, ma è alta. Un meeting booked non è opportunity. Una prima discovery call non è opportunity. Anche un follow-up demo non è opportunity se il budget non è stato validato. Quindi un lead reale può passare quattro-otto settimane nel lifecycle stage SQL, su un contact record, senza deal attaccato. L'AE sta facendo lavoro. Il sistema non mostra nulla.
Il cassetto dei cinquanta SQL è il risultato. Non è un fallimento di processo. È l'architettura che funziona come disegnata, applicata a una sales motion che non corrisponde più allo schema. Il costo non è visibile fino alla pipeline review, quando qualcuno chiede cosa succede tra il numero di MQL del marketing e il conteggio di deal della deal pipeline, e nessuno riesce a produrre il ponte.
La saggezza prevalente è creare il deal più tardi
Il consiglio standard, la Q&A di Lemkin su SaaStr esattamente su questa domanda è l'articolazione più pulita, è di aspettare. Converta un lead in opportunity solo quando ICP, pain, engagement e buying intent sono tutti confermati. Il ragionamento è solido. Crei deal troppo presto e la pipeline si gonfia, le coverage ratio si distorcono, il forecast diventa rumore, e i rep perdono la disciplina di trattare un deal come un vero impegno. La formulazione precisa di Lemkin è che convertire troppo presto intasa le pipeline e spreca le risorse di sales; convertire troppo tardi perde momentum. La maggior parte dei CRO legge quello e sceglie il lato più sicuro: tardi.
Scelga tardi e protegge la forecast accuracy, ma rinuncia a due cose di cui ha più bisogno nel 2026: la pipeline visibility, e l'accountability dell'AE per il lavoro in-flight che ancora non conta come deal. I cinquanta SQL nel cassetto sono esattamente il lavoro che l'AE sta facendo. Non sono nel sistema. Quindi l'AE non ne è responsabile, l'head of sales non li può vedere, il forecast non li può valorizzare, e il modello di ramp non può fare capacity planning contro di loro. È un prezzo troppo alto per una coverage ratio pulita.
Lo stage pre-pipeline: una terza opzione
Quello che le raccomanderei non è né tardi né presto. È entrambi, separati da un filtro. Crei il deal al meeting booked: il segnale più economico e affidabile che un AE ha committato tempo e che il prospect ha committato calendario, ma lo crei in un deal stage chiamato pre-pipeline, con una win probability di default di zero o cinque per cento, che è filtrato fuori da ogni report di forecast, widget di dashboard, calcolo di coverage e view di weighted pipeline nell'istanza. Il deal esiste per accountability, visibility e tracking. Non esiste per il forecast. Finché non si guadagna il posto nella pipeline passando un exit criterion definito, non si aggrega in un numero di revenue da nessuna parte.
È la mossa keep-edit-delete applicata all'architettura stessa. La regola standard «crea il deal alla qualifica» aveva al suo interno due obiettivi che facevano lavori diversi: proteggere il forecast dal rumore, e riservare il deal record al lavoro committato. Lo stage pre-pipeline mantiene il primo obiettivo intatto attraverso il filtraggio, e modifica il secondo dicendo che il deal record può portare lavoro non committato finché è segregato. Il forecast resta pulito. Il cassetto dei cinquanta SQL smette di esistere.
Tre guardrail
Lo stage pre-pipeline funziona solo se tre filtri sono non negoziabili dal giorno uno. Se uno qualunque di essi è morbido, il bloat torna a insinuarsi entro un trimestre, e l'head of sales torna indietro sul cambiamento.
Primo, ogni report di forecast, widget di dashboard e calcolo di pipeline coverage deve filtrare fuori lo stage pre-pipeline come condizione di default. Non un filtro opt-in. Un default. Audisca ogni view salvata, ogni dashboard CRO, ogni deck di weekly forecast meeting. Se un solo chart mostra pre-pipeline accanto alla pipeline qualificata come stessa colonna, ha perso la disciplina che giustifica l'architettura.
Secondo, la win probability di default del pre-pipeline è zero o cinque per cento, mai più alta. Alcuni team allungano la mano fino al dieci-trenta per cento perché sembra più onesto. Resista. Il punto è che il numero di weighted pipeline non può muoversi in base a quello che c'è in pre-pipeline. Zero è il più pulito, cinque è accettabile, qualsiasi cosa sopra invita i deal pre-pipeline a comparire nelle proiezioni di revenue nel momento in cui qualcuno cambia un filtro.
Terzo, i deal pre-pipeline si auto-archiviano su una regola dura di no-advance a novanta giorni. Un workflow HubSpot controlla i deal pre-pipeline ogni notte. Se lo stage non è cambiato in novanta giorni, il deal passa a Closed Lost con un lost reason di «no advance from pre-pipeline». Nessuna eccezione, nessuna proroga. Il problema dei zombie deal che rovina le pipeline in late-creation rovina anche il pre-pipeline se glielo permette. La regola dei novanta giorni è ciò che tiene il pre-pipeline visibile e piccolo.
Un pattern dal campo
Abbiamo lavorato recentemente con un team B2B SaaS Series B in DACH che faceva girare una mid-market motion con una piccola panchina di AE e nessuno strato SDR. Ogni pipeline review trimestrale cadeva sullo stesso muro. L'head of sales percorreva la pipeline ufficiale, venti o trenta deal da qualified fino a commit, e poi chiedeva al team riguardo a «quelli che non abbiamo ancora formalmente spostato». La risposta era sempre una variante di «sto aspettando di avere la conferma del budget», oppure «voglio assicurarmi che passino la discovery puliti prima di aprire un deal». Gli AE non sbagliavano su nessuno dei due punti. Stavano applicando la regola di late-creation come scritta. Il risultato era che circa metà del lavoro in-flight reale del team era fuori dal sistema. La pipeline coverage sembrava sottile. Il modello di capacity del prossimo trimestre diceva che eravamo sotto-rifornimento. Entrambe le letture erano sbagliate; il team portava più pipeline di quella che l'istanza riportava.
Abbiamo aggiunto uno stage pre-pipeline come nuovo primo stage nella deal pipeline, defaultato a zero per cento di win probability, e riscritto ogni view di forecast per filtrarlo fuori. Il workflow meeting-booked era già cablato attraverso il loro tool di scheduling; lo abbiamo esteso per creare un deal pre-pipeline automaticamente e associarlo al contact e alla company. In due settimane, il conteggio di deal visibile al team è raddoppiato. In tre settimane, l'head of sales ha filtrato su non-pre-pipeline e ha confermato che il numero di forecast non si era mosso, che era il test che volevamo passare. Due mesi dopo, il pipeline review meeting si era ristrutturato da solo: la prima metà faceva girare la pipeline ufficiale come prima, la seconda metà faceva girare una lista pre-pipeline ordinata con una domanda per deal, qual è il prossimo move per farlo avanzare fuori dal pre-pipeline. Il cassetto dei cinquanta SQL ha smesso di esistere. La conversazione di capacity del prossimo trimestre è passata dallo speculativo allo specifico.
Come cablare lo stage pre-pipeline in HubSpot
- Aggiunga un nuovo primo stage alla sua deal pipeline principale. Lo chiami «pre-pipeline» o «engaged», il label conta meno della disciplina di filtraggio che viene dopo. Imposti la win probability di default a zero per cento. Mantenga il tipo di stage come open stage, non closed.
- Costruisca il workflow meeting-booked. Trigger: un meeting viene bookato sul calendario di un sales rep attraverso il suo tool di scheduling (il tool meetings nativo di HubSpot, o qualunque scheduler sia cablato). Enrollment criterion: il tipo di meeting è una conversazione di sales, non un customer touchpoint. Action, creare un deal nello stage pre-pipeline, associarlo al contact e alla primary company, impostare deal owner sul meeting host, impostare deal name su una stringa templated con nome del contact e data del meeting.
- Audisca ogni report di forecast, widget di dashboard e calcolo di pipeline coverage nell'istanza. Aggiunga un filtro a ciascuno: deal stage diverso da pre-pipeline. View di default, dashboard di default, deck di weekly forecast meeting, widget di CRO summary. Tutti. Se ne salta anche uno, la disciplina che giustifica l'architettura inizia a perdere il giorno in cui qualcuno mostra un chart in un board meeting.
- Costruisca un report di pre-pipeline review separato. Ordini per ultimo engagement, poi per ICP fit score. È l'artefatto da cui gli AE e i loro manager lavorano nella seconda metà dei pipeline review meeting. Domanda diversa per riga, non «è sulla strada per chiudere» ma «qual è il prossimo move per farlo avanzare fuori dal pre-pipeline».
- Definisca l'exit criterion. Il minimo che usiamo è una discovery SPICED-validata: situation, pain e impact confermati per iscritto sul deal record o su una discovery note collegata. Una volta confermati questi tre, il deal avanza al suo primo qualified stage (lo chiami «qualified», «discovery complete» o come è chiamato il suo secondo stage nella sua istanza). L'exit criterion è la differenza tra uno stage pre-pipeline pulito e una lenta espansione del problema di bloat che stava cercando di risolvere.
- Costruisca il workflow auto-archive. Trigger: un workflow schedulato giornaliero. Filtro: deal stage uguale a pre-pipeline E data di ultimo cambio di deal stage più di novanta giorni fa. Action, porti il deal a Closed Lost, imposti il lost reason su «no advance from pre-pipeline», notifichi il deal owner. Novanta giorni è il numero giusto per la maggior parte delle sales motion B2B SaaS mid-market. Per motion enterprise con cicli di budget annuali, centoventi giorni sono difendibili. Non più alto.
- Ristrutturi il pipeline review meeting. Prima metà: pipeline ufficiale. Seconda metà: pre-pipeline. Domanda diversa. Cadenza diversa. Owner diverso della conversazione, se ne ha uno. La separazione strutturale nel meeting è ciò che insegna al team che la separazione architetturale nel sistema è reale, non un filtro stravagante.
Dove entra in gioco Checkpoint
La maggior parte delle nostre implementazioni HubSpot che toccano l'architettura deal-stage finisce per spedire una versione dello stage pre-pipeline. Non è una HubSpot best practice, la guidance ufficiale continua a defaultare sulla regola di late-creation, e non è un cambio di settaggio da una riga. È una scelta architettonica con tre guardrail che vanno rispettati. Il payoff è ciò che appare alla prossima pipeline review. I cinquanta SQL caldi nel cassetto diventano venti deal pre-pipeline che lei può vedere, discutere e prioritizzare, mentre il numero di forecast resta esattamente accurato come prima. Se la sua istanza di revenue operations ha un cassetto silenzioso di SQL contro cui nessuno fa forecast e che nessuno trova, lo stage pre-pipeline è il più piccolo cambiamento architettonico che risolve il problema di visibility senza rompere il forecast.
Fonti
- Lemkin, Jason. «The 2026 Sales Reckoning: Why Your Traditional Sales Team Is About To Look Very Different.» SaaStr, gennaio 2026. saastr.com
- Lemkin, Jason. «Dear SaaStr: At What Point Should a Lead Convert to an Opportunity?» SaaStr. saastr.com