Un Claude Skill qui audite quelles opportunités Salesforce satisfont genuinement les critères de sortie de l’étape dans laquelle elles viennent d’entrer. Pour chaque opp qui a progressé dans la semaine précédente, le Skill vérifie les règles déterministes (champs requis, activités enregistrées, rôles des parties prenantes), puis cross-référence les affirmations qualitatives du rep contre les transcripts d’appels Gong. La sortie est une queue de coaching pour la revue hebdomadaire RevOps, pas une porte d’application qui fait reculer automatiquement les deals.
Le bundle d’artefacts se trouve dans apps/web/public/artifacts/stage-progression-validator-skill/ et contient SKILL.md plus trois templates de référence : references/1-stage-criteria-template.md (le rubrique d’étapes de l’équipe), references/2-methodology-mapping-template.md (comment MEDDPICC, MEDDIC, SPICED, BANT ou un framework personnalisé se mappe sur vos champs Salesforce et vos patterns de phrases Gong), et references/3-sample-output-format.md (le Markdown exact que le Skill émet).
Quand l’utiliser
Exécutez ceci sur la cadence de votre réunion de forecast. Le pattern canonique est un batch dimanche soir indexé sur week_ending, avec le rapport tombant dans un canal Slack avant le point du lundi matin des managers. Le mode opp unique est aussi valide — un réviseur du deal-desk peut exécuter le Skill contre un Opportunity.Id avant une réunion d’approbation tarifaire, ou un manager peut l’exécuter contre un seul deal avant un 1:1 pour ancrer la conversation dans les gaps spécifiques plutôt que dans un vague sentiment de « ça semble bloqué ».
La vérification des affirmations qualitatives est la partie qui se rentabilise. Salesforce applique déjà des règles de validation de champs requis ; ce qu’il ne peut pas faire, c’est remarquer que le rep a affirmé « l’acheteur a accepté les critères de succès » et qu’aucun appel Gong des 45 derniers jours n’a réellement capturé cette conversation. Le Skill est conscient de la méthodologie dans sa recherche — pour l’acheteur économique de MEDDPICC, il cherche le nom de l’acheteur dans les douze tokens suivant un langage de décision (« approuver », « signer », « décideur budgétaire ») plutôt qu’une simple mention du nom. C’est cette distinction qui sépare un flag utile d’un faux positif que les reps apprennent à ignorer.
Quand NE PAS l’utiliser
- Auto-rollback. Ne câblez pas la sortie du Skill dans une mise à jour Salesforce qui rétrograde les deals sur un verdict
fail. Le verdict est un input parmi plusieurs ; le manager possède la décision de rétrogradation avec tout le contexte que le Skill ne peut pas voir (réunions hors Gong, engagements de couloir, particularités d’approvisionnement côté client). - Gestion de la performance. Un seul
failsur un seul deal est du bruit. Le signal est les patterns sur des semaines — le rep dont le taux defailmonte de 5 % à 30 % sur un trimestre tandis que ses pairs restent stables. Utiliser un verdict ponctuel dans un PIP effondre la confiance du rep et le Skill cesse de fonctionner. - Inputs de comp. L’étape pilote le forecast, pilote parfois les accélérateurs. Si la sortie du validateur alimente les calculs de comp, vous avez créé une incitation directe pour les reps à jouer les inputs — refuser l’enregistrement Gong, omettre les notes, stocker les données dans des tableurs en dehors du système. Gardez la sortie du validateur dans le canal de coaching et hors du pipeline de comp.
- Étapes sans rubrique documenté. Si
references/1-stage-criteria-template.mdn’a pas d’entrée pour l’étape en cours de validation, le Skill émetneeds_methodologyplutôt que de deviner. Ne « réglez » pas le Skill pour scorer ces étapes avec une valeur par défaut — corrigez le rubrique à la place. - Équipes qui ne stockent rien de structuré. Une équipe qui exécute MEDDPICC dans des slides et non dans Salesforce échouera à chaque vérification qualitative. Exécutez le Skill en mode dry-run pendant deux semaines ; si plus de 40 % des opps atterrissent dans
needs_methodologyou scorent en dessous de 0,2 sur les vérifications qualitatives de façon généralisée, le doc de mapping de méthodologie est fictif. Corrigez le doc ou instrumentez les champs manquants avant de le déployer.
Setup
- Documentez les étapes. Ouvrez
references/1-stage-criteria-template.mdet remplacez le contenu template par le vrai rubrique de votre équipe, étape par étape. Chaque étape a trois buckets de règles :field_rules(un champ Salesforce doit avoir une valeur non-défaut),activity_rules(une activité enregistrée d’un type spécifié doit exister dans une fenêtre de récence), etstakeholder_rules(OpportunityContactRoledoit inclure un contact avec un rôle correspondant à un regex). Marquez les champs commeevidence_required: gongquand vous voulez une vérification croisée avec les transcripts Gong sur l’affirmation qualitative. - Mappez la méthodologie. Éditez
references/2-methodology-mapping-template.mdpour correspondre au framework de votre équipe. Le fichier est livré avec des exemples travaillés pour MEDDPICC, MEDDIC et SPICED — copiez celui qui correspond, puis ajustez les noms de champs Salesforce vers les noms API réels de votre org. La colonne des patterns de phrases est ce qui dit au Skill ce qui compte comme preuve Gong ; ne laissez pas la valeur par défaut du template sauf si vos champs correspondent genuinement aux mappings d’exemple. - Installez le Skill. Déposez le bundle dans
~/.claude/skills/stage-progression-validator/. DéfinissezSFDC_TOKEN(lecture seule surOpportunity,OpportunityFieldHistory,Task,Event,OpportunityContactRole) etGONG_API_KEY(avec portéescalls/extensiveetdeals). La lecture seule est la bonne portée ; le Skill ne doit pas écrire dans Salesforce. - Planifiez le run hebdomadaire. Un cron simple convient —
claude run stage-progression-validator week_ending=$(date -d 'sunday' +%F)le dimanche à 22h00. Pipez la sortie vers votre canal Slack ou un email de digest hebdomadaire. - Associez-le à un rituel de coaching. La queue de verdicts est inutile si personne ne l’ouvre. Créneau fixe de 30 minutes le lundi, le manager parcourt les lignes
failetneeds_manager_reviewavec chaque rep. Après huit semaines, le volume dans ces buckets devrait baisser — c’est la métrique de succès.
Ce que le skill fait réellement
Pour chaque progression dans la fenêtre, le Skill calcule deux scores. Le score déterministe est la fraction des règles de méthodologie satisfaites — cinq règles, trois passent, le score est 0,6. C’est rubrique structuré plutôt que langage naturel libre-forme par conception : les critères en forme libre forcent le modèle à interpréter les cas limites de façon incohérente entre les runs et les reps ne peuvent pas prédire ce qui déclenchera un fail, ce qui tue la confiance dont l’outil dépend.
Le score qualitatif est la fraction des affirmations evidence_required: gong qui trouvent des preuves de transcript de soutien dans la fenêtre pertinente. La correspondance de phrases est consciente de la méthodologie. Pour l’acheteur économique de MEDDPICC, le Skill cherche le nom de l’acheteur dans les douze tokens suivant un langage de décision. Pour l’événement critique de SPICED, il cherche un langage d’urgence borné par une date avec des verbes de conséquence (« manquer », « glisser », « risquer ») à proximité. Une vérification naïve « toute mention du nom de l’acheteur compte » produit trop de faux-pass — le rep mentionnant l’acheteur en passant dans un appel avec une autre partie prenante n’est pas une preuve d’engagement de l’acheteur.
Les deux scores se combinent en l’un des cinq verdicts : pass (les deux à 1,0), flag (un bucket fort, l’autre faible), fail (les deux en dessous du seuil de limite, 0,6 par défaut), needs_manager_review (la bande limite entre flag et fail — ni clairement mauvais ni clairement bon), ou needs_methodology (le rubrique n’a pas d’entrée pour cette étape). Le bucket needs_manager_review existe parce que forcer chaque deal limite dans un binaire flag versus fail produit du bruit que les reps apprennent à rejeter ; les lignes limites vont dans une queue séparée que le manager résout manuellement, ce qui préserve le signal dans les autres buckets.
Coûts réels
Claude Sonnet 4 aux tarifs actuels coûte environ 15-25 centimes par opportunité validée, dominé par la lecture des transcripts Gong (une fenêtre de 30 jours typique couvre 4-8 appels par deal actif à 5-15 000 tokens chacun, plus quelques centaines de tokens de rubrique de méthodologie chargés depuis les références). Un batch hebdomadaire de 50 deals coûte environ 7-12 $ en dépense API.
Le temps économisé est l’argument en faveur du Skill. Un responsable RevOps effectuant cet audit à la main dépense 20-30 minutes par deal — tirer l’historique d’étapes, ouvrir chaque appel Gong, scanner le nom de l’acheteur et la conversation sur les critères de succès. Sur 50 deals, c’est deux jours complets d’audit à la main par semaine, ce qui est pourquoi presque aucune équipe ne le fait réellement. Le Skill réduit cela à une passe de revue de rapport de 4-6 minutes sur le digest, avec une inspection plus approfondie uniquement sur les lignes dans les buckets fail et needs_manager_review — typiquement 5-10 deals sur 50, soit 30-60 minutes de revue ciblée. Net : 12-15 heures RevOps par semaine récupérées, pour moins de 15 $ en coût API.
Métrique de succès
Suivez deux métriques sur un ramp de huit semaines. D’abord, le taux de fail — la part des progressions hebdomadaires qui atterrissent dans fail. Un ramp sain le voit baisser d’une référence (souvent 25-40 % lors du premier run) à moins de 10 % à mesure que les reps internalisent ce que le rubrique requiert avant d’avancer un deal. Si cela ne baisse pas, soit le rubrique est trop strict (les reps ne peuvent physiquement pas le satisfaire sans des conversations acheteur que le deal n’est pas prêt pour) soit la boucle de coaching ne se produit pas. Ensuite, l’ancienneté médiane de l’étape juste avant la porte la plus stricte. Si celle-ci augmente — les reps garent des deals une étape en dessous de leur réalité pour esquiver la porte — le rubrique est faux, pas les reps. Ajustez le rubrique vers le bas avant de continuer à exécuter le Skill.
Comparaison avec les alternatives
- Règles de validation Salesforce — elles appliquent la présence de champ au niveau enregistrement (vous ne pouvez pas sauvegarder une opp en étape 4 sans
Economic_Buyer__crempli). Elles ne peuvent pas faire la vérification qualitative : un rep peut taper n’importe quel nom dans le champ, les règles de validation passent, le Skill détecte qu’aucun appel Gong ne soutient l’affirmation. Les règles de validation sont aussi un instrument contondant parce qu’elles rejettent la sauvegarde ; le Skill produit un verdict gradué avec lequel le manager travaille. - Clari, Gong Forecast et outils de forecasting IA similaires — ils font la validation d’étapes comme partie d’une surface produit bien plus grande (forecast, revue de deal, analytique de conversation, coaching). Comptez 50-150 $ par rep par mois contre ce Skill à environ 10-15 $ par semaine en coût API. Choisissez la plateforme si vous avez aussi besoin de ses couches de forecasting et d’analytique de conversation ; choisissez ce Skill si votre gap est spécifiquement l’audit de progression d’étapes et que vous avez déjà Salesforce et Gong.
- Revues manuelles du deal-desk — un responsable RevOps humain lisant chaque progression. Le bon outil pour les équipes enterprise à ACV élevé où les deals sont peu nombreux et conséquents. Mauvais outil pour le SMB ou le mid-market à volume où le coût d’audit (12-15 heures par semaine) signifie que cela ne se produit pas du tout et que les mauvaises progressions atterrissent dans le forecast.
- Ne rien faire — la référence réelle dans la plupart des équipes. La précision du forecast dans la plupart des SaaS B2B se situe quelque part entre médiocre et embarrassante précisément parce que les étapes sur lesquelles le forecast est construit ne sont pas validées. Le coût de ne rien faire se manifeste dans la réaction du DFG à un mauvais trimestre, ce qui est un pire moment pour découvrir que les données d’input n’étaient pas fiables.
Points de vigilance
- Une validation trop stricte pousse les reps à jouer les étapes. Garde-fou : instrumentez l’ancienneté médiane de l’étape juste avant la porte la plus stricte. Si elle s’envole après le déploiement du Skill, le rubrique est faux ; ajustez-le vers le bas avant de continuer.
- Inadéquation de méthodologie entre les slides et Salesforce. Garde-fou : dry-run pendant deux semaines. Si
needs_methodologyplus les scores qualitatifs bas couvrent plus de 40 % des opps, corrigez le doc de mapping de méthodologie ou l’instrumentation de champ sous-jacente avant de traiter tout verdict comme actionnable. - Dérive du validateur par rapport aux vrais critères de sortie. Les leaders commerciaux redéfinissent silencieusement les significations d’étapes dans les QBRs ; le fichier rubrique n’est pas mis à jour. Garde-fou : le rubrique porte un champ
last_reviewed; le Skill préfixe un avertissement à chaque rapport quand la date est antérieure de plus de 90 jours. - Les gaps de couverture d’enregistrement Gong ressemblent à de la malhonnêteté des reps. Garde-fou : le fichier de mapping de méthodologie déclare un
recording_coverage_floorpar étape. Les deals en dessous du plancher atterrissent dansneeds_manager_reviewavec le gap de couverture exposé explicitement, pas dansfail. - Le rep conteste un verdict
fail. Garde-fou : le rapport inclut les manques de règle déterministe verbatim et les patterns de phrases non correspondants. La conversation s’ancre dans le gap spécifique, que le rep peut corriger en mettant à jour le champ et en re-exécutant, ou contester avec des preuves hors-Gong que le manager accepte.
Stack
- Salesforce — historique d’étapes, champs de deal, rôles de contacts, activités enregistrées
- Gong — transcripts de conversations enregistrées, listes d’appels au niveau deal
- Claude (Sonnet 4) — correspondance de phrases consciente de la méthodologie contre les transcripts, synthèse du verdict
- Cron / planificateur de votre choix — le déclencheur hebdomadaire
- Slack ou email — le canal digest où le rapport atterrit avant le point manager