Le deck arrive dans la huitième semaine. Soixante slides, quarante recommandations, une feuille de route colorée par trimestre. Le diagnostic est précis : des définitions d'étapes qui signifient différentes choses pour différents commerciaux, une règle de routage des leads que personne ne peut expliquer, une prévision basée sur des dates de clôture qui évoluent tous les vendredis. L’équipe de direction hoche la tête pendant la lecture et l’engagement se termine.
Six mois plus tard, le deck se trouve dans un dossier de lecteur partagé. Trois des quarante recommandations ont été mises en œuvre, les trois qui n'ont nécessité aucun temps. Les définitions d'étape ont été réécrites dans un document et n'ont jamais été appliquées dans le CRM. La règle de routage reste encore inexpliquée. La prévision bouge toujours tous les vendredis. Personne n’a rien fait de mal. Le pont était bon et il ne serait jamais expédié.
Il ne s’agit pas uniquement d’un problème RevOps ; c’est ce qui arrive à la plupart des projets qui quittent la salle sur papier. L'enquête 2025 des DSI et des responsables technologiques de Gartner, présentée en octobre 2024 et basée sur 3 186 DSI et responsables technologiques ainsi que 1 126 cadres non informatiques, a révélé que seulement 48 % des initiatives numériques atteignent ou dépassent leurs objectifs de résultats commerciaux. L'étude 2020 du BCG sur les transformations numériques, combinant 70 cas d'entreprises et une enquête auprès de 825 cadres supérieurs, a révélé que seulement 30 % d'entre elles ont atteint ou dépassé leur valeur cible et ont abouti à un changement durable.
L’écart se situe entre décider et faire. Dans une étude réalisée en 2013 par l'Economist Intelligence Unit et le Project Management Institute, 61 % des 587 cadres supérieurs ont déclaré que leur entreprise avait souvent du mal à combler le fossé entre la formulation de la stratégie et sa mise en œuvre quotidienne, et qu'en moyenne seulement 56 % de leurs initiatives stratégiques avaient été mises en œuvre avec succès au cours des trois années précédentes. Une décennie de meilleurs outils n’a pas comblé cet écart, car cet écart n’a jamais été une question d’outils.
Pour une équipe commerciale comprise entre $3M et $30M ARR, une recommandation non mise en œuvre n'est pas neutre. Il utilise un quart de l'attention des dirigeants et enseigne à l'équipe que le changement RevOps est un exercice documentaire.
Diagnostic : quatre raisons structurelles pour lesquelles les recommandations ne sont pas expédiées
Les explications habituelles sont personnelles : les consultants étaient trop théoriques, l'équipe trop occupée. Mais le schéma se répète avec de bons consultants et des équipes engagées. Quatre raisons structurelles l’expliquent mieux.
Le livrable est le deck, donc personne n'est propriétaire de la mise en œuvre
Si la remise est un document, l'engagement est terminé lorsque le document est accepté, que quelque chose change ou non dans le CRM. La mise en œuvre devient le travail du client, et dans cette bande ARR, le client est généralement une équipe RevOps composée d'une ou deux personnes déjà à pleine capacité. Dans la même enquête Gartner, un groupe de dirigeants très performants dans lesquels les dirigeants d'entreprise sont également responsables de la livraison ont atteint un taux de réussite de 71 % sur les initiatives numériques, contre 48 % dans l'ensemble (Gartner, 2024). Le succès suit celui qui détient le résultat, et non celui qui a rédigé le plan.
Les recommandations ne sont jamais testées par rapport à votre propre historique
"Introduire des critères de sortie d'étape" semble approprié dans chaque entreprise. Que cela soit correct dans le vôtre dépend de choses que personne n'a vérifiées : combien de contrats remportés l'année dernière n'auraient pas répondu aux nouveaux critères, quels représentants travaillent déjà de cette façon, de quels champs dépendrait la règle et à quelle fréquence ils sont vides. Une recommandation qui n’a pas été appliquée à vos transactions passées est une hypothèse. Lorsque l’équipe essaie de la mettre en œuvre et que les vingt premières transactions enfreignent la règle pour des raisons que le deck n’avait pas anticipées, la recommandation meurt tranquillement.
Les consultants partent avant l'adoption
La majeure partie de la valeur de tout programme de changement est gagnée ou perdue une fois le plan approuvé. L'enquête McKinsey de 2021 auprès de 1 034 personnes ayant participé à des transformations a révélé que les transformations réussies captent environ 67 % de leurs avantages financiers potentiels, tandis que toutes les autres en captent environ 37 %. Parmi la valeur perdue, environ 55 % l’ont été pendant et après la mise en œuvre, et environ 20 % ont été perdus une fois les initiatives entièrement exécutées (McKinsey, 2021). Un engagement de recommandations se termine exactement là où commence la majeure partie de la perte : au moment où quelqu'un doit faire en sorte que le changement soit maintenu un mardi après-midi de la onzième semaine.
Les recommandations sont rédigées sous forme de comportement et non de système
« Les représentants doivent mettre à jour les prochaines étapes et les dates de clôture chaque semaine » est une demande adressée à douze personnes. Une règle qui signale un accord périmé et l’achemine vers la bonne personne constitue un changement dans un seul système. Les demandes de comportement entrent en concurrence avec le temps de vente, et le temps de vente est déjà rare : le rapport sur l'état des ventes 2024 de Salesforce, une enquête menée auprès de 5 500 professionnels de la vente, a révélé que les commerciaux consacrent 70 % de leur temps à des tâches non liées à la vente (Salesforce, 2024). Chaque recommandation qui ajoute une étape manuelle perd cette concurrence par défaut. Ceux qui survivent sont ceux que quelqu’un a transformés en logiciels.
Le framework : le test Ships-or-Slides
L’alternative à un ensemble de recommandations n’est pas « l’absence de diagnostic ». Un diagnostic est nécessaire ; le diagnostiquer avant de créer un playbook expose ce cas en détail. L’alternative est un diagnostic qui aboutit à un système unique, construit et testé sur vos données, plutôt qu’à une liste de quarante choses à faire. Le test Ships-or-Slides comprend cinq questions que vous pouvez poser pour tout engagement RevOps, dont celle que vous êtes sur le point d'acheter. Un jeu de cartes y répond au futur ; un système y répond dans le présent.
| Question | À quoi répond un jeu de recommandations | À quoi répond un système fonctionnel |
|---|---|---|
| Qu'est-ce qui se passe lundi ? | Une feuille de route pour ce qui devrait fonctionner à terme | Une règle, un workflow ou un agent spécifique se trouve dans votre pile |
| À qui appartient la construction ? | "Votre équipe", après la passation de pouvoir | Les personnes qui ont rédigé la spécification, jusqu'à ce qu'elle réussisse son test |
| A-t-il été testé sur notre histoire ? | Basé sur les meilleures pratiques et entretiens | Exécutez vos propres cas passés, avec des résultats écrits au cas par cas |
| Qu'est-ce que la barre de passe ? | Accord lors de la réunion de lecture | Un seuil de précision déclaré qu'il doit franchir avant d'être mis en ligne |
| Comment saurons-nous que cela a fonctionné ? | Une liste de métriques suggérées | Un chiffre avant et après sur la fuite spécifique pour laquelle elle a été conçue |
Les conseils sont utiles quand on a la capacité de le construire soi-même. La plupart des équipes commerciales de la bande $3M à $30M ne le font pas, c'est pourquoi leurs decks s'empilent. La solution n’est pas non plus d’embaucher un partenaire de mise en œuvre après l’entreprise de stratégie : séparer le diagnostic de la construction recrée le transfert une étape plus tard. Les mêmes personnes doivent diagnostiquer, spécifier, construire et prouver, ce qui est l'idée centrale de ingénierie déployée vers l'avant appliqué à une équipe commerciale.
Un exemple concret
Exemple illustratif, avec des nombres ronds inventés : une entreprise $15M ARR possède un jeu de cartes provenant d'un engagement précédent. La recommandation quatorze se lit comme suit : « appliquer les critères de sortie d’étape et l’hygiène des dates de clôture hebdomadaires pour améliorer l’exactitude des prévisions ». C’est sur la feuille de route depuis les trois quarts. La version Ships-or-Slides commence par extraire 20 transactions conclues au cours des deux derniers trimestres et pose une question précise : une règle d'hygiène aurait-elle signalé les transactions qui ont échoué, sans signaler celles qui ont été clôturées à temps ? La première version signale trop de transactions saines, car un champ obligatoire est vide dans la plupart des enregistrements. La règle passe donc aux données d'activité. La deuxième version identifie les bons accords dans 18 des 20 cas, ce qui franchit la barre des 85 pour cent d'accords ; après avoir confirmé qu'aucune action dangereuse n'a été détectée, il est mis en ligne en tant que Pipeline Hygiene Sentinel qui publie des offres périmées à chaque propriétaire et à son manager tous les lundis. La recommandation quatorze est désormais un système avec un propriétaire et un enregistrement de test. Vos chiffres seront différents ; la séquence ne le sera pas.
Implémentation : transformer un deck bloqué en un logiciel en cours d'exécution
Si vous possédez déjà un deck, conservez-le. Ces six étapes le transforment en file d'attente de construction.
Triez les recommandations en trois piles
Étiquetez chaque recommandation comme une décision (la direction doit choisir quelque chose), un comportement (les gens doivent agir différemment) ou un système (une règle, un flux de travail ou un modèle pourrait le faire sur des données). De nombreux comportements se révèlent être des systèmes écrits sous forme de requêtes. Vérifiez : chaque recommandation comporte exactement une étiquette.
Prenez les décisions en premier
Les systèmes ne peuvent pas être construits sur des définitions indécises. Si le deck dit « s'aligner sur une définition de prospect qualifié », c'est une décision, et cela bloque tout en aval. Gartner a constaté que 49 % des directeurs commerciaux déclarent que leur définition de prospect qualifié diffère considérablement de celle du marketing (Gartner, 2025). Vérifiez : chaque décision a une date et un décideur nommé, et le résultat est écrit là où l'équipe de construction peut le lire.
Prix ce que vaut chaque recommandation de système
Pour chaque élément de la pile système, estimez le coût annuel de l’écart qu’il comble, en dollars, avec un niveau de confiance indiqué. Les transactions qui échouent, les leads qui échouent et les renouvellements qui expirent ont tous un prix. Vérifiez : la pile du système est classée en fonction du coût annuel estimé, et non en fonction de la force avec laquelle elle a été argumentée dans le relevé.
Notez à quoi ressemble le correct, puis extrayez l'historique
Prenez l'élément principal et définissez-le comme un test : compte tenu de ces entrées, le système devrait effectuer cet appel. Ensuite, identifiez une vingtaine de cas réels pour lesquels vous connaissez déjà la bonne réponse. Vérifiez : une définition écrite du correct et un ensemble de cas passés existent avant que quiconque ne construise quoi que ce soit.
Construisez-le dans votre pile et testez-le avant sa mise en ligne
Intégrez les outils que vous utilisez déjà, puis exécutez le système sur les cas historiques. Nous soumettons chaque système à la même barre : testé sur une vingtaine de cas antérieurs du client, avec au moins 85 % d'accord et aucune action dangereuse non détectée, sinon il n'est pas expédié. Vérifiez : les résultats sont enregistrés au cas par cas et le système a effacé la barre avant de toucher aux données en direct.
Remettez-le en marche, avec un propriétaire, puis mesurez à nouveau
Nommez un propriétaire exploitant de votre côté qui signe le test et surveille le résultat. Après un cycle complet, réévaluez la fuite. Prenez ensuite l’élément suivant de la pile classée. Vérifiez : un système est actif avec un propriétaire nommé et un chiffre avant et après, et le suivant a été choisi parmi de nouveaux numéros.
Workflow : à quoi ressemble une construction de système à côté d'un ensemble de recommandations
La différence entre les deux modèles apparaît dans ce que produit chaque étape. Un flux de travail suggéré pour un engagement de construction :
Ce qui se produit: un examen en lecture seule des données du CRM, de l'automatisation du marketing, des produits et du support, identifie les fuites de revenus et évalue chaque fuite en dollars. Rien dans vos systèmes n’est modifié.
Equivalent du deck : la phase de découverte, qui se termine généralement par une présentation.
Propriétaire: le CRO ou le fondateur le parraine ; RevOps fournit un accès et un contexte.
Ce qui se produit: la plus grande fuite dont les entrées sont prêtes devient un système, avec une définition écrite de ce qui est correct et un ensemble de cas passés sur lesquels le tester.
Equivalent du deck : la feuille de route, qui répertorie de nombreuses initiatives et n’en précise aucune.
Propriétaire: la direction des revenus accepte le choix ; le propriétaire exploitant accepte la définition de correct.
Ce qui se produit: le système est construit à l'intérieur de la pile existante et exécuté sur les cas historiques jusqu'à ce qu'il franchisse la barre ou qu'il ne soit pas expédié.
Equivalent du deck : aucun. C’est l’étape que la plupart des programmes de recommandations n’atteignent jamais.
Propriétaire: les ingénieurs qui l'ont diagnostiqué et spécifié, donc rien n'est perdu dans la traduction.
Ce qui se produit: le système fonctionne en production, son résultat est rapporté par rapport à la fuite pour laquelle il a été construit et le système suivant est choisi parmi les chiffres mis à jour.
Equivalent du deck : une mission de suivi demandant pourquoi rien n’a été mis en œuvre.
Propriétaire: le propriétaire exploitant rend compte des résultats ; RevOps maintient la liste classée à jour.
Le récit du conseil d'administration
Les conseils d’administration qui ont déjà financé un engagement RevOps se demanderont ce qui est différent cette fois-ci. Trois affirmations y répondent.
Nous avons payé pour le diagnostic et les conseils. Le diagnostic était solide, mais le livrable était un document, et notre équipe n'avait pas la capacité de transformer quarante recommandations en systèmes fonctionnels tout en gérant l'entreprise. La plupart d’entre eux n’ont jamais été mis en œuvre.
Nous payons pour un système fonctionnel à la fois, choisi parce qu’il colmate notre fuite la plus coûteuse. Chacun est construit à l'intérieur de nos outils existants et testé sur nos propres transactions passées avant d'être mis en ligne, par rapport à une barre de passage convenue à l'avance.
Chaque système a un propriétaire nommé dans notre équipe et un chiffre avant et après la fuite pour laquelle il a été construit. Nous publierons ce chiffre chaque trimestre. Si un système ne réussit pas son test, il n’est pas expédié, et nous vous le dirons également.
Cross-domain : où le logiciel bat les diapositives en premier
Le test Ships-or-Slides s'applique à l'ensemble du moteur de revenus, mais Sales Operations C'est là que l'écart entre la recommandation et la réalité est généralement le plus grand, car les recommandations commerciales sont celles qui sont le plus souvent rédigées sous forme de demandes de comportement. Les conseils d'hygiène et de prévision demandent aux commerciaux de changer leurs habitudes ; le Pipeline Hygiene Sentinel et le Forecast Assistant faites le même travail sans demander. Une prévision fondée sur un pipeline propre est la preuve la plus visible pour un conseil d’administration que quelque chose a changé.
La même logique s’applique aux autres domaines. « Répondre plus rapidement aux leads entrants » devient Speed-to-Lead. "Corriger le transfert de SDR à AE" devient le Handoff Orchestrator. "Prendre de l'avance sur le taux de désabonnement" devient la devise Churn Signal Watchtower. Voir tout systèmes en un seul endroit.
Les preuves plus larges vont dans le même sens. L'étude commerciale 2026 de Gartner indique que les organisations commerciales les plus efficaces ne se contentent pas d'intégrer l'IA aux méthodes de travail existantes, mais de repenser les flux de travail des vendeurs (Gartner, 2026). Le MIT NANDA a constaté que les solutions d'IA achetées ou construites avec des partenaires spécialisés avaient un taux de réussite environ deux fois supérieur aux versions internes (MIT NANDA, 2025). Ce n’est pas non plus un argument en faveur de davantage d’outils. Les deux plaident en faveur d’une personne responsable du fonctionnement du système dans votre environnement. Si vous souhaitez voir en quoi un modèle limité dans le temps et axé sur la construction diffère d'un travail de conseil ouvert, ce que le modèle déployé vers l'avant de Palantir a du bon et du mauvais pour les équipes commerciales couvre les compromis, et comment nous travaillons montre le processus étape par étape.
Sources : Gartner, Enquête 2025 auprès des DSI et des dirigeants technologiques (communiqué de presse du 22 octobre 2024 ; 3 186 DSI et cadres technologiques, 1 126 cadres non informatiques). BCG, "Si l'échec n'est pas une option, pourquoi le succès est-il si rare ?" (octobre 2020 ; 70 cas d’entreprises, 825 cadres supérieurs). Unité de renseignement des économistes et Institut de gestion de projets, "Pourquoi les bonnes stratégies échouent" (2013 ; 587 cadres supérieurs). McKinsey & Company, "Perdre dès le premier jour : pourquoi même les transformations réussies échouent" (Décembre 2021 ; 1 034 répondants). Salesforce, État des ventes, 6e édition (juillet 2024 ; 5 500 commerciaux). Gartner, Enquête auprès des OSC (communiqué de presse 21 mai 2025 ; 243 CSO et hauts responsables commerciaux). Gartner, recherche sur l'IA des ventes (communiqué de presse 20 mai 2026 ; 227 OSC). AVEC NANDA, « La fracture GenAI : état de l'IA dans les entreprises 2025 », copie du rapport hébergée par Valtao, 2025. La scène d'ouverture est un composite générique, le test Ships-or-Slides est le cadre de VANDFORT et l'exemple travaillé utilise des figures illustratives, pas des données client.
