ooligo
claude-skill

Rapport hebdomadaire de revue de pipeline HubSpot avec Claude

Difficulty
intermédiaire
Setup time
30min
For
revops
RevOps

Stack

Un Claude Skill qui prend deux instantanés du pipeline HubSpot — celui du lundi courant et celui du lundi précédent — les découpe par segment, et rédige le brief d’une page que le VP commercial lit avant la revue de pipeline du lundi. Chaque métrique porte un mot indiquant la direction du mouvement. Chaque affirmation est directe — il y a une passe de suppression des hésitations. La sortie est publiée en tête de #pipeline-review à six heures le lundi matin et le fil de direction se dispute déjà la bonne chose au moment où l’appel commence.

Quand utiliser ce skill

Vous êtes un responsable RevOps ou un directeur des opérations commerciales et votre VP commercial tient une revue de pipeline le lundi. Vous avez un pipeline HubSpot que vous pouvez extraire via l’API des deals. Vous voulez que le brief de référence soit en tête du fil le lundi matin, qu’il soit rédigé et non omis, et vous ne voulez pas le rédiger vous-même chaque semaine.

Le skill suppose que l’équipe est consciente des segments — Enterprise / Mid-Market / SMB, ou toute tranche équivalente — et que le VP veut voir les deltas au niveau des segments, pas seulement un chiffre de pipeline agrégé. Il suppose que vous avez un instantané du pipeline de la semaine précédente sauvegardé quelque part d’accessible. La première exécution produit un brief de base ; la deuxième exécution et au-delà produit une vraie histoire semaine-sur-semaine.

Le bundle se trouve dans apps/web/public/artifacts/weekly-pipeline-report-skill/. Le corps du skill est SKILL.md ; les modèles que le skill lit à chaque exécution sont references/1-report-format-template.md, references/2-segment-mapping.md et references/3-hedge-words-blocklist.md.

Quand NE PAS utiliser ce skill

N’utilisez pas ce skill pour les présentations au conseil. Le brief est opérationnel — il utilise les deltas de la semaine précédente et des hypothèses vieilles d’une semaine sur ce qui est réel dans le pipeline. Les rapports au conseil nécessitent des chiffres réconciliés et audités provenant du système financier, pas d’un fichier Markdown du lundi matin.

Ne l’utilisez pas pour les rapports destinés aux clients. Le brief nomme des deals, des propriétaires et des risques dans un langage qui convient à un canal Slack interne et qui est dangereux à partager en externe. Il n’y a pas de passe d’anonymisation ; en construire une est hors scope.

Ne laissez personne citer le chiffre de titre comme la prévision réelle. Le brief résume la composition et le mouvement du pipeline ; ce n’est pas un modèle de prévision. La prévision vient de l’appel de prévision du vendredi, détenu par le VP commercial et le responsable RevOps. Le pied du brief porte ce disclaimer à chaque exécution — le disclaimer est dans references/1-report-format-template.md et le supprimer annule la protection.

Si votre équipe ne segmente pas son pipeline, ne commencez pas par adopter ce skill — commencez par écrire references/2-segment-mapping.md pour l’équipe. Le brief fonctionne sans segments uniquement comme une exécution de base agrégée uniquement, qui est moins utile que les mêmes données dans le tableau de bord propre de HubSpot.

Configuration

  1. Déposez le bundle dans votre dossier Skills. Copiez apps/web/public/artifacts/weekly-pipeline-report-skill/ dans votre projet Claude sous .claude/skills/weekly-pipeline-report/. Claude Code (ou Claude.ai avec un MCP monté en projet) le découvre au prochain lancement.
  2. Remplacez les trois fichiers de référence. references/1-report-format-template.md est la disposition littérale que suit le brief — modifiez-le pour changer la forme du rapport, ne modifiez pas SKILL.md. references/2-segment-mapping.md déclare vos règles de segment ; les espaces réservés sont livrés avec Enterprise/Mid-Market/SMB et vous voudrez presque certainement les changer. references/3-hedge-words-blocklist.md est une liste de départ ; étendez-la dès qu’une hésitation passe en production.
  3. Configurez l’extracteur d’instantanés. Le skill consomme deux fichiers d’instantanés ; il n’appelle pas lui-même l’API HubSpot. Mettez en place un petit extracteur (cron job, flux n8n, GitHub Action planifié) qui frappe /crm/v3/objects/deals avec les colonnes que le skill attend (deal_id, deal_name, owner_id, stage, amount, close_date, last_modified, plus ce que vos règles de segment référencent) et écrit un fichier CSV ou JSON par lundi dans un répertoire connu. L’extracteur est la partie de cette stack qui est spécifique à HubSpot.
  4. Exécutez le skill le lundi à 06h00. Invoquez avec deux chemins (pipeline_snapshot, previous_snapshot) et le fichier de segments. Redirigez la sortie vers #pipeline-review ou vers la liste de distribution de la direction. La première exécution définit comparison_mode = none et émet un brief de base plutôt que de fabriquer des deltas nuls.
  5. Révisez la passe de suppression des hésitations chaque semaine. Lisez le brief qui est arrivé. Si une hésitation a glissé (« semble suggérer », « a l’air de pouvoir »), ajoutez-la à references/3-hedge-words-blocklist.md afin que la passe de la semaine suivante la détecte. La liste est faite pour évoluer.

Ce que le skill fait réellement

La méthode est dans SKILL.md étape par étape. Les choix techniques que vous devez connaître avant d’adopter ce skill :

Conscient des segments, pas agrégé. Un « pipeline en hausse de 4 pour cent » plat cache le cas où l’Enterprise est en baisse de 12 et le SMB en hausse de 30 — des histoires opposées qui demandent des réponses opposées. Le brief découpe chaque métrique par segment et remonte vers un titre seulement après. Si un deal ne peut être assigné à un segment, il va dans un compartiment non-segmenté visible ; jamais silencieusement supprimé.

Mot de direction du mouvement sur chaque métrique. Pas seulement le titre. Le VP parcourt la page en un seul passage — si seul le chiffre supérieur porte un mot de direction, le reste se lit comme des données et l’œil l’ignore. Chaque cellule du tableau de segments, chaque puce dans la liste de titre, est en hausse +Z% ou en baisse -Z% ou stable.

Top deals qui font bouger le chiffre, pas top deals par taille. Cette section concerne le mouvement depuis lundi dernier — transitions d’étape, nouveaux ajouts, changements de périmètre, dates de clôture décalées. Un deal statique de 500k$ qui n’a rien fait cette semaine ne figure pas dans la section. Les deals qui font bouger le chiffre cette semaine sont ceux sur lesquels le VP doit interroger.

Les top risques sont les deals qui glissent silencieusement. Les risques bruyants (email du DSI, « nous avons perdu ») sont escaladés par d’autres canaux. Le brief fait remonter les deals qui semblent bons dans la vue conseil mais qui ont été décalés deux fois, ont régressé d’une étape, ont vu leur montant réduit de plus de 25 pour cent, ou sont restés dormants pendant 14+ jours tout en étant encore signalés comme devant se clôturer ce trimestre.

Un pattern, une demande. Le brief nomme un seul plus grand pattern et une seule demande. Pas cinq patterns et une liste de recommandations à cinq puces. Le brief se lit en trois minutes ; une demande est un point de vue, cinq est une liste, et la différence est de savoir si le VP entre dans la salle avec une position ou avec un sondage.

Passe de suppression des hésitations à la fin. Le modèle rédige le brief, puis le relit par rapport à references/3-hedge-words-blocklist.md et réécrit toute phrase contenant un terme bloqué. Les hésitations s’infiltrent parce que le modèle est poli sur des données incertaines ; le brief est plus utile quand il énonce le pattern observé de façon directe et que le lecteur repousse plutôt que quand chaque affirmation est pré-hésitée. La passe est mécanique et refuse de livrer un brief qui viole la liste.

Réalité des coûts

Le coût en tokens par brief hebdomadaire est faible. Un pipeline de 1 000 deals se sérialise en environ 80 à 120k tokens d’entrée une fois les deux instantanés et les références chargés. La sortie est d’environ 600 à 900 tokens — le brief fait une page exprès. Aux tarifs Claude Sonnet, le coût par exécution est dans la fourchette des centimes. Aux tarifs Opus, les deux chiffres faibles. Sur une année de lundis, c’est un arrondi par rapport au coût de n’importe quel autre poste d’outils de pipeline.

Le temps économisé par responsable RevOps est le chiffre plus important. Le brief du lundi représente typiquement 30 à 60 minutes de travail manuel — extraire le rapport, analyser les deltas à vue d’œil, rédiger le récit, le publier sur Slack. Rédigé par le skill, le cycle descend sous 5 minutes (lire le brouillon, accepter ou réécrire le paragraphe de pattern, publier). Sur 50 lundis par an, c’est environ 25 heures récupérées, ce qui est du temps réel même si la valeur en dollars est difficile à chiffrer.

Le coût caché est l’extracteur d’instantanés. Mettre en place le cron job qui écrit deux CSV cohérents représente environ une demi-journée de travail ponctuel. Si votre équipe n’a pas déjà un pipeline d’extraction, comptez ce travail avant de prétendre que le skill est « gratuit à adopter ».

Indicateur de succès

La métrique qui compte est de savoir si le brief du lundi est lu et référencé lors de la revue de pipeline. Deux indicateurs avancés qui fonctionnent en pratique :

  • Le VP a-t-il cité le paragraphe de pattern du brief lors de la réunion ? Suivez cela qualitativement pendant les six premières semaines. Si le VP nomme le pattern lors de la revue, le brief fait son travail. Si le VP lit depuis les tableaux de bord HubSpot en ignorant le fil Slack, le brief ne passe pas et le paragraphe de pattern a besoin de travail.
  • Temps jusqu’à la première question lors de la revue de pipeline. Avant le skill, les dirigeants passaient les 10 premières minutes à s’orienter sur ce qui avait changé. Après, ils devraient entrer en train de débattre déjà du pattern nommé par le brief. Si le temps d’orientation n’a pas diminué, soit le brief n’est pas lu, soit le pattern ne nomme pas la bonne chose.

La métrique retardée — précision du pipeline ou précision de la prévision — ne se déplace pas à cause de ce skill. Le brief ne change pas ce qui est dans le pipeline ; il change ce dont l’équipe parle le lundi matin.

Comparaison avec les alternatives

Les tableaux de bord intégrés de HubSpot. HubSpot Sales Hub a un tableau de bord des deals qui affiche le pipeline par étape et propriétaire, avec des deltas semaine-sur-semaine si vous construisez le rapport soigneusement. Il ne produit pas de récit — il n’y a pas de top-3-en-mouvement, pas de top-3-risques, pas de paragraphe de pattern, pas de demande recommandée. Une équipe peut fonctionner avec uniquement des tableaux de bord et beaucoup le font. Le brief gagne sa place quand la direction veut que le récit soit pré-rédigé plutôt que construit en direct lors de la réunion.

Clari weekly briefings. Clari (ou Gong Forecast, ou BoostUp) livre un outil de prévision avec des capacités de résumé hebdomadaire. Les briefings sont crédibles et la couche de données sous-jacente est plus fiable qu’un extracteur fait maison. Le compromis : la licence par siège de Clari est dans la fourchette des quatre chiffres par rep par an, les briefings suivent la forme opinionnée de Clari plutôt que celle de votre VP, et vous ne contrôlez pas la formulation. Le skill est la bonne réponse quand le budget exclut un Clari et que votre équipe utilise déjà HubSpot.

Résumé manuel rédigé par RevOps. Le statu quo pour la plupart des équipes. La qualité est élevée quand le responsable RevOps a le temps de le rédiger, faible quand il ne l’a pas. Le brief est cohérent semaine après semaine — même forme, mêmes métriques, même structure pattern-et-demande — ce qui facilite la lecture pour le VP. Un responsable RevOps senior peut surpasser le skill n’importe quel lundi donné ; le skill gagne sur la cohérence et en rendant 25 heures par an à ce responsable pour un travail à plus fort effet de levier.

Points de vigilance

  • Données confiantes mais obsolètes. L’instantané HubSpot n’est aussi frais que la dernière exécution de l’extracteur. Si last_modified sur le fichier d’instantané est vieux de plus de 24 heures, le brief ajoute un avertissement d’une ligne en préfixe (« L’instantané est vieux de N heures — les chiffres peuvent ne pas refléter l’activité de fin de semaine du vendredi »). Protection : la vérification de fraîcheur s’exécute avant tout calcul ; le skill refuse de livrer le brief sans elle.
  • Langage d’hésitation qui s’infiltre malgré la suppression. La passe de suppression des hésitations utilise une liste fixe ; les nouvelles formulations d’hésitation inventées par le modèle passeront. Protection : la liste dans references/3-hedge-words-blocklist.md est faite pour être étendue chaque semaine. Le premier mois d’utilisation du skill fera remonter 5 à 10 nouvelles formulations d’hésitation ; ajoutez-les au fur et à mesure.
  • Lecteurs aval qui citent cela comme la prévision. Le brief met en titre un chiffre de pipeline ouvert, qu’un lecteur occasionnel arrondira à « la prévision ». Protection : le pied du brief se lit toujours « Résumé opérationnel, pas une prévision. La prévision appartient à <nom du VP> et est produite lors de l’appel du vendredi. » La ligne est dans references/1-report-format-template.md et la supprimer annule la protection. Ne la supprimez pas.
  • Les réassignations de propriétaires cassent le calcul SAS. Si un deal a changé de propriétaire en cours de semaine, les deltas de l’ancien et du nouveau propriétaire se déclenchent tous les deux — double comptage du mouvement. Protection : le skill émet une note de bas de page « deals réassignés cette semaine : N » et exclut les deals réassignés de la section top-deals-en-mouvement, de sorte que le mouvement n’est attribué à aucun des deux propriétaires. Choisissez un côté (suivre-le-deal ou suivre-le-propriétaire) et documentez-le dans le playbook de votre équipe.
  • Étapes HubSpot personnalisées non présentes dans le fichier de segments. Si votre équipe a renommé des étapes par défaut, les règles de mapping de segments qui référencent des noms d’étapes se cassent silencieusement. Protection : le validateur d’instantané confirme que chaque valeur stage distincte dans l’instantané est référencée par au moins une règle de segment, et fait remonter les étapes non correspondantes dans le pied du rapport. Si une nouvelle étape apparaît là, mettez à jour references/2-segment-mapping.md.

Stack

  • HubSpot — source de vérité du pipeline et entrée de l’extracteur d’instantanés
  • Claude Skill — rédige le brief à partir des deux instantanés et des références
  • Extracteur d’instantanés (cron / n8n / GitHub Action) — écrit le CSV hebdomadaire consommé par le skill ; la partie de la stack spécifique à HubSpot
  • Slack — canal de distribution du brief rendu

Files in this artifact

Download all (.zip)