La plupart des instances HubSpot B2B dont j'hérite ont un seul Pipeline qui fait deux jobs. Le Pipeline de Deal track le travail commercial de l'AE: discovery, qualification, proposal, négociation: et il track aussi du travail opérationnel que l'AE ne possède pas , génération d'offre, checks de fit technique, KYC, approbation de contrat, parfois onboarding. L'instinct de modéliser tout ça comme des stages de Deal paraît propre sur un whiteboard. Dans un système de revenu live, ça produit un Pipeline lent, non-forecastable, où l'AE est un coordinateur et la donnée est fausse.
Pourquoi cela compte maintenant
L'achat B2B n'est pas devenu plus simple. Brent Adamson, Matthew Dixon et Nick Toman ont argumenté dans Harvard Business Review en 2012 que le job traditionnel du sales rep: découvrir des besoins, recommander une solution, était déjà mangé par un procurement sophistiqué et un côté acheteur qui arrive avec ses propres réponses. La version de ce problème que je vois dans HubSpot en 2026 est structurelle. Dans les motions commerciales lourdes en service, énergie et utilities, industriels régulés, hardware-plus-onboarding, la décision d'achat est gatée par du travail qui vit hors de la journée de l'AE. Modéliser ce travail comme stages de Deal ne rend pas l'AE plus stratégique. Ça transforme le Pipeline de Deal en tracker de projet pour la file de quelqu'un d'autre.
Le pattern , un workflow est sales, l'autre est opérations
Une question diagnostique utile sur chaque Pipeline que je revois : qui doit prendre une action pour que ce stage avance ? Si la réponse est systématiquement l'AE, c'est un stage sales. Si la réponse est systématiquement quelqu'un d'autre: un deal desk, une équipe d'offre, un relecteur compliance, un lead CS, un onboarding engineer, c'est du travail opérationnel, et l'AE n'a pas le levier pour le tirer dans un calendrier forecastable.
L'erreur standard est de compresser le travail opérationnel dans le Pipeline de Deal comme stages du genre « offer in progress », « compliance review » ou « awaiting contract ». L'AE possède alors un Pipeline qu'il ne peut pas bouger. La précision du forecast s'effondre parce que l'âge des stages est dominé par du temps de file dans une fonction sur laquelle l'AE n'a aucun contrôle opérationnel. Les taux de conversion entre stages cessent de signifier quelque chose parce que le rythme auquel les deals quittent un stage compliance-review n'a rien à voir avec l'exécution sales.
L'architecture à deux pipelines
L'architecture que je recommanderais dans HubSpot pour toute motion service-gated est deux pipelines en parallèle :
Pipeline de Deal, possédé par l'AE
Les stages reflètent les décisions commerciales que l'AE pilote réellement : discovery, qualified, offering, contracting, Closed Won, Closed Lost. Les transitions de stage sont gatées par des preuves contrôlables par l'AE , un résumé de discovery capturé, un fit confirmé, une offre demandée, un contrat signé reçu. L'AE est forecastable sur ce Pipeline parce que chaque stage avance sur quelque chose qu'il peut faire.
Pipeline de tickets, possédé par RevOps ou l'équipe opérations
Sous le Deal siège un ticket sur un pipeline séparé, possédé par la fonction qui fait le travail opérationnel , offer requested, inputs validated, offer generated, compliance cleared, contract sent. Chaque stage représente un travail que cette équipe effectue réellement. Le ticket a ses propres SLAs, sa propre file, ses propres assignés, son propre reporting. RevOps ou l'équipe d'offre est forecastable sur ce pipeline parce que, là encore, chaque stage avance sur quelque chose qu'ils peuvent faire.
La barrière entre les deux
Le Deal ne peut atteindre Closed Won tant que le ticket associé n'est pas fermé. Cette barrière est tout l'enjeu architectural. L'AE n'est pas bloqué dans la vente pendant que le ticket est en vol ; le Deal peut rester dans le stage contracting indéfiniment. Mais Closed Won, le stage qui pilote bookings, commissions et forecasting de revenu, ne se déclenche que quand opérations a fini son travail. Le Pipeline de Deal reporte maintenant sur le débit commercial. Le pipeline de tickets reporte sur le débit opérationnel. La barrière garantit que les deux restent couplés.
Barrières de champs requis et couche de validation des données
L'architecture à deux pipelines ne tient que si le hand-off entre AE et opérations est propre. Le point de défaillance le plus commun est le moment où un AE crée un ticket : l'équipe opérations a besoin d'un set d'inputs défini, adresse du site, capacité, specs techniques, entité client pour KYC, sélection de template de contrat, et la plupart du temps ils ne l'obtiennent pas. Le correctif, ce sont des barrières de propriétés requises sur le stage de Deal qui déclenche la création de ticket.
Ce que je ferais , définissez les inputs dont l'équipe d'offre a besoin avant de commencer. Rendez ces propriétés requises pour bouger le Deal de qualified vers offering. Le workflow qui crée le ticket copie ces propriétés. Le job de l'AE au hand-off est de remplir le formulaire, pas de chasser l'équipe d'offre pour avoir le statut.
Les triggers de hand-off entre AE et RevOps
Le câblage mécanique dans HubSpot est direct. Un workflow Deal-based se déclenche sur changement de stage vers offering, crée un ticket sur le pipeline d'offre, met le pipeline de ticket à son premier stage, copie les propriétés Deal requises, et associe le ticket au Deal et au Contact. Un workflow ticket-based se déclenche quand le ticket atteint le stage compliance-cleared et met à jour une propriété Deal, quelque chose comme offer_status, qu'un dashboard côté AE lit. Quand le ticket se ferme, un workflow final flippe une propriété Deal qui permet à l'AE de bouger le Deal vers Closed Won.
Rien de ça n'est exotique, ce sont les mêmes briques de workflow que toute instance HubSpot a. La décision d'architecture est ce qui compte , le travail appartient à son propre pipeline, le Pipeline de l'AE est gaté plutôt que bloqué, et les deux systèmes coordonnent via un petit set de propriétés nommées.
Cas observé sur le terrain
Une PME énergie allemande avec une motion hardware-plus-onboarding est venue nous voir avec un seul Pipeline de Deal portant onze stages. Environ la moitié de ces stages étaient opérationnels , offer in progress, technical review, KYC, contract review, signature. Les forecasts AE étaient peu fiables parce que l'essentiel de l'âge des stages dans un trimestre donné était du temps de file en opérations. Le correctif a été un Pipeline de Deal avec stages sales possédés par l'AE et un pipeline de tickets séparé avec stages opérationnels possédés par l'équipe d'offre. Un workflow Deal-vers-ticket tournait sur transition de stage avec validation de champs requis ; la barrière Closed Won était une propriété Deal mise à jour quand le ticket se fermait. Après le changement, l'équipe d'offre avait sa propre file et ses SLAs, le forecast AE a commencé à se comporter comme un forecast, et la revue Pipeline hebdomadaire est passée de « où en est mon offre » à « quelle est la prochaine étape commerciale ».
Résolution , le playbook à deux pipelines
Si vous faites tourner une motion commerciale service-gated dans HubSpot aujourd'hui, voici l'ordre dans lequel je ferais le changement :
- Auditez votre Pipeline de Deal actuel. Pour chaque stage, demandez si l'AE possède l'action qui le fait avancer. Listez les stages qui échouent au test, c'est du travail opérationnel dans le mauvais Pipeline.
- Concevez le pipeline de tickets parallèle. Les stages reflètent ce que l'équipe opérations fait réellement, dans la langue qu'elle utilise réellement. Owners, SLAs et assignation de file sont définis par stage.
- Définissez les propriétés de hand-off Deal-vers-ticket. Le set d'inputs minimum dont l'équipe opérations a besoin avant de pouvoir commencer. Rendez-les required-to-advance sur le stage de Deal qui déclenche la création de ticket.
- Construisez les workflows. Un workflow crée le ticket sur transition de stage et copie les propriétés. Un deuxième workflow met à jour le Deal quand le ticket atteint un checkpoint significatif. Un troisième ferme la boucle quand le ticket se ferme.
- Gatez le stage Closed Won sur la fermeture du ticket. Le Deal ne peut bouger vers Closed Won que si le ticket associé est fermé. Imposez-le par règle de validation ou check de propriété requise.
- Reconstruisez les dashboards sur la nouvelle frontière. Forecast AE et rapports de conversion tournent sur le Pipeline de Deal. Débit opérationnel, conformité SLA et âge de file tournent sur le pipeline de tickets. Cessez de reporter les deux depuis le même graphique.
- Formez l'équipe AE sur le nouveau modèle. Le pushback le plus commun, et de loin, est que l'AE « ne peut pas voir ce qui se passe avec l'offre ». La réponse est un dashboard côté Deal alimenté par les propriétés du ticket, pas un retour à un Pipeline unique.
Faites ces sept choses et le changement prend quelques semaines ; le forecast commence à être honnête en un trimestre. Sautez l'étape une et vous concevrez un pipeline parallèle avec le même problème de frontière que celui que vous remplacez.
Là où Checkpoint intervient
La plupart des Pipelines HubSpot que nous redessinons chez Checkpoint ont cette pathologie , un Pipeline sales qui fait du travail opérationnel, un forecast qui ne se comporte pas comme tel, et une équipe qui a cessé de faire confiance aux données. Le correctif est rarement une nouvelle propriété ou un dashboard plus malin. C'est une décision architecturale sur quel travail appartient à quel pipeline, possédé par quelle fonction, gaté par quelle preuve. Cette décision siège à la couture entre RevOps et customer success operations. Si votre Pipeline porte du travail opérationnel qu'il ne peut pas forecaster, c'est la conversation à avoir.
Harmeet Obhrai