Généralement, quand un revenue leader nous demande de réparer la prévision, la prévision n'est pas le problème. Les étapes de Pipeline en dessous ont cessé de signifier la même chose pour les commerciaux qui font avancer les Deals. Discovery, c'est le premier appel d'un commercial et le mutual action plan signé d'un autre. Closed Won, c'est contrat signé dans une équipe et kickoff planifié dans l'autre. Les maths de conversion sont correctes et opérationnellement inutiles, les chiffres tiennent contre des définitions que personne ne partage.
Pourquoi cela compte maintenant
La pression sur les définitions d'étapes a empiré, pas amélioré, depuis que l'IA est apparue dans le funnel. L'article de Sinha, Shastri, Lorimer et Mantrala paru en septembre dans Harvard Business Review sur les équipes de vente qui croissent aux côtés de l'IA faisait ce constat , les équipes qui prennent de l'avance sont celles qui traitent l'IA comme une couche de coaching et d'orchestration au-dessus d'un process commercial déjà propre, pas comme un substitut. C'est l'asymétrie. Si vos définitions d'étapes sont serrées, l'outillage agentique accélère un système qui marche déjà. Si elles sont lâches, l'IA automatise gaiement la dérive, routant les Deals sur un signal d'étape qui veut déjà dire trois choses différentes.
Le diagnostic , « Closed Won » veut dire trois choses différentes pour trois commerciaux
Faites un petit test sur votre propre instance. Sortez les dernières dizaines de Deals passés d'une étape comme proposal-sent à une étape comme negotiation, et demandez à chaque commercial ce que signifiait la transition. Vous obtiendrez , le pricing a été envoyé ; le pricing a été envoyé et accusé réception ; le pricing a été envoyé, accusé réception, et procurement est engagé ; le pricing a été envoyé et le champion a verbalement dit oui. Quatre réalités opérationnelles, une seule valeur d'étape, un seul modèle de prévision qui les traite comme équivalentes.
Ce n'est pas un problème de discipline du commercial. C'est un problème de définition. Les commerciaux font ce que les gens font toujours quand un système leur donne des inputs ambigus, ils remplissent l'ambiguïté avec leur propre définition de travail, et l'équipe optimise autour de l'écart. C'est pour ça que les pipeline reviews finissent par ressembler à des dépositions. Le manager ne révise pas vraiment le Deal ; il rétro-ingénière ce que le commercial entendait par l'étape.
Le modèle de critères d'entrée/sortie en une page
Le correctif est petit et sans gloire. Chaque étape du Pipeline obtient quatre lignes sur une seule page partagée :
- Définition en une phrase. Ce que cette étape est, dans une langue qu'un nouveau commercial peut lire au troisième jour et appliquer immédiatement. Si vous ne pouvez pas l'écrire en une phrase, l'étape fait deux jobs et doit être scindée.
- Critères d'entrée. La chose spécifique et vérifiable qui doit être vraie sur l'enregistrement Deal pour entrer dans l'étape. « Le champion a confirmé qu'un budget existe pour cet exercice fiscal, capté dans la propriété Budget Confirmed. »
- Critères de sortie. La chose spécifique et vérifiable qui doit être vraie pour que le Deal quitte l'étape vers l'avant. Différente de l'entrée, c'est tout l'enjeu.
- Owner. Le rôle responsable de la transition. Parfois l'AE ; parfois le SE ; parfois le deal desk. Nommer l'owner, c'est ce qui fait de l'étape une étape de process plutôt qu'un libellé.
C'est tout le modèle. Il tient sur une page. Le coût n'est pas dans l'écriture. Le coût est dans le désaccord qui surface pendant que vous l'écrivez, et c'est pour cela que le modèle ne fonctionne qu'en atelier, pas comme un doc remis à une seule personne pour rédaction solitaire.
Le faire vivre sur un Deal , ce qui se passe à chaque bord d'étape
Par exemple : une équipe B2B SaaS avec laquelle j'ai travaillé récemment avait un Pipeline en six étapes. L'étape médiane: appelons-la l'étape d'évaluation: n'avait aucun critère d'entrée, et un critère de sortie qui correspondait quasi mot pour mot au critère d'entrée de l'étape suivante. Fonctionnellement, l'étape était un parking. Les Deals y vivaient en moyenne environ trois semaines de plus que dans toute autre étape, et l'équipe avait silencieusement accepté ça comme le fonctionnement du milieu de Pipeline. Quand nous avons mené l'atelier de réécriture, deux choses ont surgi en 20 minutes. Les AE ont réalisé qu'ils utilisaient cette étape pour signifier que le Deal était bloqué et qu'ils ne voulaient pas le perdre dans la prévision. Le CRO a réalisé que l'étape existait parce que quelqu'un, cinq ans plus tôt, voulait un endroit pour suivre les POCs et personne n'y était revenu depuis. La décision était simple une fois que les deux choses étaient sur la même page , scindez. Les POCs ont eu leur propre étape avec leurs propres entrées et sorties ; la version parking de l'étape médiane a été supprimée.
C'est pour cela que l'atelier compte. L'artefact final, c'est la page unique. Le travail, c'est la mise au jour.
Les étapes que vous ne pouvez pas définir
Certaines étapes survivent à la réécriture proprement. D'autres non. Le pattern, après avoir mené ça sur assez d'instances HubSpot pour ne plus les compter , environ un tiers des étapes ont besoin d'un resserrement de définition mais restent ; environ un tiers doit être scindé en deux étapes parce qu'elles font deux jobs opérationnels différents ; le reste est fusionné ou supprimé. Si vous ne pouvez pas écrire une définition en une phrase dans la salle, l'étape n'est pas une étape. C'est un flag, et il devrait vivre comme une propriété sur l'enregistrement Deal, pas comme une position dans le Pipeline.
Étapes opérationnelles vs. de reporting
D'un côté, vos commerciaux ont besoin d'étapes qui correspondent à ce qu'ils font réellement chaque jour: la forme de l'action, le prochain appel, l'artefact requis pour avancer. De l'autre, votre CFO a besoin d'étapes qui s'agrègent proprement en un modèle de prévision tenant à l'échelle board. Ces deux besoins n'ont pas toujours la même forme. La façon dont je le résous généralement : garder les étapes de Pipeline opérationnelles (orientées commercial, avec une forme d'action, quatre à six étapes) et utiliser une propriété forecast category séparée, commit, most-likely, best-case, pipeline, que le manager pilote. Le commercial fait avancer l'étape Deal ; le manager assigne la forecast category. Champs différents, owners différents, pas de bagarre sur ce qu'une seule colonne doit signifier.
Cas observé sur le terrain
Une équipe B2B SaaS DACH en Series B est venue nous voir pour de l'aide en prévision. Le problème énoncé par le CRO était que la prévision pondérée manquait sa cible avec une marge significative chaque trimestre. Le vrai problème, mis au jour dès la première séance de travail, c'était que le Pipeline en huit étapes avait trois étapes aux critères de sortie qui se chevauchaient et une étape que l'équipe SDR utilisait comme parking pour des Leads non qualifiés. Nous avons mené la réécriture comme un atelier de deux heures avec les leads AE, le lead SDR, le CRO et le lead RevOps dans la salle. Le résultat : Pipeline ramené de huit étapes à cinq ; une étape promue en propriété ; une étape scindée parce que les POCs et les pilotes payants étaient des motions différents. Le modèle de prévision reconstruit contre la nouvelle architecture est tombé dans les dix pour cent du réel le trimestre suivant, pas parce que les maths sont devenues plus malines, mais parce que les inputs ont enfin voulu dire quelque chose.
Résolution , un playbook pour la réécriture
Si vous êtes sur le point de mener ça sur votre propre instance, l'ordre compte :
- Bloquez deux heures et mettez les bonnes personnes dans la salle. Leads AE, le lead SDR ou BDR si votre haut de funnel est partagé, le CRO, et celui qui pilote RevOps. Pas de spectateurs. Le désaccord est le travail.
- Parcourez le Pipeline actuel étape par étape et lisez les définitions existantes à voix haute. S'il n'y a pas de définition écrite, demandez à chaque commercial dans la salle d'en écrire une en 60 secondes et comparez. Les écarts sont le diagnostic.
- Pour chaque étape, remplissez les quatre lignes. Définition, entrée, sortie, owner. Si la salle ne peut pas s'accorder sur une définition en une phrase en trois minutes, l'étape fait deux jobs. Scindez-la.
- Signalez toute étape où les critères d'entrée et de sortie coïncident. Ce n'est pas une étape ; c'est une propriété de Deal qui se fait passer pour une étape. Promouvez-la en propriété et retirez-la du Pipeline.
- Tranchez opérationnel vs. reporting maintenant, pas plus tard. Les étapes de Pipeline restent orientées commercial et de forme action. La forecast category devient un champ séparé piloté par le manager.
- Configurez les changements dans HubSpot avant que quelqu'un ne quitte la salle. Noms d'étapes, critères d'entrée/sortie capturés en propriétés requises ou gates de workflow, assignations d'owner. Si vous reportez la configuration, l'accord se délite en une semaine.
- Re-baselinez la prévision contre la nouvelle architecture. Les anciens taux de conversion ne se transposent pas. Menez les deux pipeline reviews suivantes contre les nouvelles étapes avant de refaire confiance au modèle.
Là où Checkpoint intervient
Les réécritures d'étapes de Pipeline sont l'une des séances de travail les plus fréquentes que nous menons dans nos missions RevOps chez Checkpoint, généralement le premier mois, presque toujours avant tout travail de prévision ou de reporting. Si votre prévision manque, si vos maths de conversion semblent peu fiables, ou si vos commerciaux se disputent sur le sens d'une étape en pipeline review, c'est l'atelier à mener avant de passer un trimestre de plus à modéliser sur des définitions que personne ne partage.
Noah Charak