Deux working sessions cette semaine, même client, même pièce, deux problèmes différents au tableau, et l'un d'entre eux était un diagnostic silencieux de pipeline que l'équipe traînait depuis un an. Leur head of sales a ouvert la pipeline HubSpot officielle, a parcouru les deal stages, puis a posé à la salle une question qui est restée suspendue une seconde. Et les cinquante SQL qu'on n'a pas encore basculés ? Personne n'a répondu, parce que personne n'avait la réponse. Cinquante leads qui avaient pris un sales meeting, passé la qualification initiale, et qui étaient posés quelque part sur un contact record avec un lifecycle stage de SQL, mais aucun deal record. Invisibles pour le forecast. Invisibles pour la pipeline review. Invisibles pour la conversation de capacity du trimestre suivant. Cet écart est le choix structurel le plus coûteux dans les instances HubSpot B2B SaaS en mid-stage en ce moment, et il n'a rien à voir avec HubSpot. Il a à voir avec le moment où vous décidez que le deal commence.
Pourquoi cela compte maintenant
Le readout de janvier de Jason Lemkin sur le 2026 sales reckoning était sans détour sur le changement structurel en cours : les équipes B2B AI-native font tourner des bancs de sales à peu près moitié moins gros que leurs prédécesseurs, et l'outbound piloté par l'IA génère un quart de la nouvelle pipeline dans son propre org en quatre-vingt-dix jours. C'est dans ce tableau macro que cet écart apparaît. Les équipes de sales rétrécies par l'IA aggravent le problème structurel, il n'y a plus de couche SDR pour curatorialiser à la main l'écart entre un MQL et un deal record, donc c'est l'AE qui tient la discovery, et l'AE a toutes les incitations à différer la création du deal jusqu'à ce qu'il soit sûr que c'est réel. Multipliez cela sur dix reps et un trimestre, et vous obtenez le tiroir de cinquante SQL. Les forecasts ne sont pas faux parce que le modèle de close date est mauvais. Ils sont faux parce que la pipeline ne contient pas les deals.
Où vit le SQL gap dans HubSpot
Le lifecycle de HubSpot est structuré par contact-property: subscriber, lead, MQL, SQL, opportunity, customer. Le deal est un objet séparé qui est créé, en général, quand le lifecycle du contact passe à opportunity. La convention est raisonnable en principe et un désastre en pratique, parce que la définition opératoire d'opportunity dans la plupart des équipes de sales c'est « je suis assez confiant pour committer cela dans la pipeline ». Ce seuil de confiance est sain, mais il est haut. Un meeting booked n'est pas opportunity. Un premier discovery call n'est pas opportunity. Même un follow-up demo n'est pas opportunity si le budget n'a pas été validé. Un vrai lead peut donc passer quatre à huit semaines dans le lifecycle stage SQL, sur un contact record, sans deal attaché. L'AE fait du travail. Le système ne montre rien.
Le tiroir de cinquante SQL en est le résultat. Ce n'est pas un échec de processus. C'est l'architecture qui fonctionne comme conçue, appliquée à une sales motion qui ne correspond plus au schéma. Le coût n'est pas visible jusqu'à la pipeline review, quand quelqu'un demande ce qui se passe entre le chiffre MQL du marketing et le compte de deals de la deal pipeline, et personne ne peut produire le pont.
La sagesse dominante est de créer le deal plus tard
Le conseil standard, la Q&A de Lemkin sur SaaStr sur cette question exacte est l'articulation la plus propre que vous trouverez, c'est d'attendre. Ne convertissez un lead en opportunity que lorsque ICP, pain, engagement et buying intent sont tous confirmés. Le raisonnement tient. Créez des deals trop tôt et la pipeline gonfle, les coverage ratios se déforment, le forecast devient du bruit, et les reps perdent la discipline de traiter un deal comme un véritable engagement. La formulation précise de Lemkin est que convertir trop tôt encombre les pipelines et gâche les ressources de sales ; convertir trop tard fait perdre du momentum. La plupart des CROs lisent cela et choisissent le côté plus sûr : tard.
Choisissez tard et vous protégez la forecast accuracy, mais vous renoncez à deux choses dont vous avez davantage besoin en 2026 : la pipeline visibility, et l'accountability de l'AE pour le travail in-flight qui ne compte pas encore comme un deal. Les cinquante SQL dans le tiroir sont exactement le travail que l'AE est en train de faire. Ils ne sont pas dans le système. Donc l'AE n'en est pas responsable, le head of sales ne peut pas les voir, le forecast ne peut pas les valoriser, et le modèle de ramp ne peut pas planifier la capacity contre eux. C'est un prix trop élevé pour une coverage ratio propre.
Le stage pre-pipeline : une troisième option
Ce que je recommanderais, ce n'est ni tard ni tôt. C'est les deux, séparés par un filtre. Créez le deal au meeting booked: le signal le moins cher et fiable qu'un AE a engagé du temps et que le prospect a engagé du calendrier, mais créez-le dans un deal stage appelé pre-pipeline, avec une win probability par défaut de zéro ou cinq pour cent, qui est filtré hors de chaque report de forecast, widget de dashboard, calcul de coverage et vue de weighted pipeline dans l'instance. Le deal existe pour l'accountability, la visibility et le tracking. Il n'existe pas pour le forecast. Tant qu'il n'a pas gagné sa place dans la pipeline en passant un exit criterion défini, il n'agrège dans aucun chiffre de revenue nulle part.
C'est le move keep-edit-delete appliqué à l'architecture elle-même. La règle standard « créer le deal à la qualification » avait en elle deux objectifs qui faisaient des travaux différents : protéger le forecast du bruit, et réserver le deal record pour le travail committé. Le stage pre-pipeline garde le premier objectif intact à travers le filtrage, et édite le second en disant que le deal record peut porter du travail non-committé tant qu'il est ségrégué. Le forecast reste propre. Le tiroir de cinquante SQL cesse d'exister.
Trois garde-fous
Le stage pre-pipeline ne fonctionne que si trois filtres sont non-négociables dès le jour un. Si l'un d'eux est mou, le bloat revient en rampant en un trimestre, et le head of sales annule le changement.
Premièrement, chaque report de forecast, widget de dashboard et calcul de pipeline coverage doit filtrer le stage pre-pipeline comme condition par défaut. Pas un filtre opt-in. Un défaut. Auditez chaque vue sauvegardée, chaque dashboard CRO, chaque deck de weekly forecast meeting. Si un seul chart montre pre-pipeline à côté de la pipeline qualifiée comme la même colonne, vous avez perdu la discipline qui justifie l'architecture.
Deuxièmement, la win probability par défaut de pre-pipeline est de zéro ou cinq pour cent, jamais plus haut. Certaines équipes vont chercher dix à trente pour cent parce que ça leur paraît plus honnête. Résistez. Le point est que le chiffre de weighted pipeline ne peut pas bouger en fonction de ce qui est dans pre-pipeline. Zéro est le plus propre, cinq est acceptable, tout ce qui est au-dessus invite des deals pre-pipeline à apparaître dans les projections de revenue le moment où quelqu'un change un filtre.
Troisièmement, les deals pre-pipeline s'auto-archivent sur une règle dure de no-advance à quatre-vingt-dix jours. Un workflow HubSpot vérifie les deals pre-pipeline chaque nuit. Si le stage n'a pas changé en quatre-vingt-dix jours, le deal passe à Closed Lost avec un lost reason de « no advance from pre-pipeline ». Pas d'exceptions, pas de prolongations. Le problème de zombie deal qui ruine les pipelines en late-creation ruine aussi pre-pipeline si vous le laissez faire. La règle des quatre-vingt-dix jours est ce qui garde pre-pipeline visible et petit.
Un pattern du terrain
Nous avons récemment travaillé avec une équipe B2B SaaS Series B en DACH faisant tourner une mid-market motion avec un petit banc d'AE et pas de couche SDR. Chaque pipeline review trimestrielle tombait sur le même mur. Le head of sales parcourait la pipeline officielle, vingt ou trente deals de qualified jusqu'à commit, puis demandait à l'équipe au sujet « de ceux qu'on n'a pas formellement basculés ». La réponse était toujours une variante de « j'attends d'avoir la confirmation de budget », ou « je veux m'assurer qu'ils passent la discovery proprement avant d'ouvrir un deal ». Les AEs ne se trompaient sur aucun des deux points. Ils appliquaient la règle de late-creation telle qu'écrite. Le résultat, c'était qu'environ la moitié du travail in-flight réel de l'équipe était hors du système. La pipeline coverage paraissait maigre. Le modèle de capacity du trimestre suivant disait que nous étions sous-approvisionnés. Les deux lectures étaient fausses ; l'équipe portait plus de pipeline que l'instance ne le rapportait.
Nous avons ajouté un stage pre-pipeline comme nouveau premier stage dans la deal pipeline, défaulté à zéro pour cent de win probability, et réécrit chaque vue de forecast pour le filtrer. Le workflow meeting-booked était déjà câblé à travers leur outil de scheduling ; nous l'avons étendu pour créer un deal pre-pipeline automatiquement et l'associer au contact et à la company. En deux semaines, le compte de deals visible pour l'équipe a doublé. En trois semaines, le head of sales a filtré sur non-pre-pipeline et a confirmé que le chiffre de forecast n'avait pas bougé, ce qui était le test que nous voulions passer. Deux mois plus tard, le pipeline review meeting s'était restructuré de lui-même : la première moitié faisait tourner la pipeline officielle comme avant, la seconde moitié faisait tourner une liste pre-pipeline triée avec une question par deal, quel est le prochain move pour faire avancer celui-ci hors de pre-pipeline. Le tiroir de cinquante SQL a cessé d'exister. La conversation de capacity du trimestre suivant est passée du spéculatif au spécifique.
Comment câbler le stage pre-pipeline dans HubSpot
- Ajoutez un nouveau premier stage à votre deal pipeline principale. Appelez-le « pre-pipeline » ou « engaged », le label compte moins que la discipline de filtrage qui vient après. Mettez la win probability par défaut à zéro pour cent. Gardez le type de stage en open stage, pas closed.
- Construisez le workflow meeting-booked. Trigger : un meeting est booké sur le calendrier d'un sales rep via votre outil de scheduling (l'outil meetings natif de HubSpot, ou quel que soit le scheduler câblé). Enrollment criterion : le type de meeting est une conversation de sales, pas un customer touchpoint. Actions , créez un deal dans le stage pre-pipeline, associez-le au contact et à sa primary company, mettez deal owner sur le meeting host, mettez deal name sur une chaîne templatée avec le nom du contact et la date du meeting.
- Auditez chaque report de forecast, widget de dashboard et calcul de pipeline coverage dans l'instance. Ajoutez un filtre à chacun : deal stage différent de pre-pipeline. Vues par défaut, dashboards par défaut, decks de weekly forecast meeting, widgets de CRO summary. Tous. Si vous en oubliez un seul, la discipline qui justifie l'architecture commence à fuir le jour où quelqu'un montre un chart dans un board meeting.
- Construisez un report de pre-pipeline review séparé. Triez par dernier engagement, puis par ICP fit score. C'est l'artefact à partir duquel les AEs et leurs managers travaillent dans la seconde moitié des pipeline review meetings. Question différente par ligne, pas « est-ce sur la voie de clore » mais « quel est le prochain move pour faire avancer celui-ci hors de pre-pipeline ».
- Définissez l'exit criterion. Le minimum que nous utilisons est une discovery SPICED-validée : situation, pain et impact confirmés par écrit sur le deal record ou une discovery note liée. Une fois ces trois confirmés, le deal avance à votre premier qualified stage (appelez-le « qualified », « discovery complete » ou comme votre deuxième stage est nommé dans votre instance). L'exit criterion est la différence entre un stage pre-pipeline propre et une lente expansion du problème de bloat que vous essayiez de résoudre.
- Construisez le workflow auto-archive. Trigger : un workflow planifié quotidien. Filtre : deal stage égal pre-pipeline ET date de dernier changement de deal stage à plus de quatre-vingt-dix jours. Action , faites passer le deal à Closed Lost, mettez le lost reason à « no advance from pre-pipeline », notifiez le deal owner. Quatre-vingt-dix jours est le bon chiffre pour la plupart des sales motions B2B SaaS mid-market. Pour des motions enterprise avec des cycles de budget annuels, cent vingt jours est défendable. Pas plus haut.
- Restructurez le pipeline review meeting. Première moitié : pipeline officielle. Seconde moitié : pre-pipeline. Question différente. Cadence différente. Owner différent de la conversation si vous en avez un. La séparation structurelle dans le meeting est ce qui enseigne à l'équipe que la séparation architecturale dans le système est réelle, pas un filtre fantaisiste.
Là où Checkpoint entre en jeu
La plupart de nos implémentations HubSpot qui touchent à l'architecture deal-stage finissent par livrer une version du stage pre-pipeline. Ce n'est pas une best practice HubSpot, la guidance officielle continue à défaulter sur la règle de late-creation, et ce n'est pas un changement de paramètre d'une ligne. C'est un choix architectural avec trois garde-fous qui doivent être respectés. Le payoff est ce qui apparaît à la prochaine pipeline review. Les cinquante SQL chauds dans le tiroir deviennent vingt deals pre-pipeline que vous pouvez voir, discuter et prioriser, pendant que le chiffre de forecast reste exactement aussi précis qu'avant. Si votre instance de revenue operations contient un tiroir silencieux de SQL contre lesquels personne ne forecaste et que personne ne trouve, le stage pre-pipeline est le plus petit changement architectural qui résout le problème de visibility sans casser le forecast.
Sources
- Lemkin, Jason. « The 2026 Sales Reckoning: Why Your Traditional Sales Team Is About To Look Very Different. » SaaStr, janvier 2026. saastr.com
- Lemkin, Jason. « Dear SaaStr: At What Point Should a Lead Convert to an Opportunity? » SaaStr. saastr.com