Une Claude Skill qui transforme un seul compte Gainsight en une narration de QBR et un outline diapositive par diapositive : un titre exécutif, une histoire d’usage-et-résultats reliée aux objectifs du success plan du compte, une table des risques ouverts et un ensemble priorisé de plays d’expansion. Le CSM obtient un brouillon structuré en Markdown — un bloc par diapositive, dans l’ordre où le deck se déroule — qu’il édite et dépose dans le template de deck de l’équipe, au lieu de fixer un outline vide. Le bundle de l’artifact inclut SKILL.md plus trois fichiers de référence que l’équipe CSM adapte une fois et réutilise sur chaque compte.

C’est le cousin narration-et-outline de la skill de préparation de QBR, qui tire aussi Salesforce et Gong. Si vous vivez dans Gainsight et voulez l’histoire du deck directement depuis l’enregistrement de compte, le scorecard et le success plan de votre CSP, commencez ici.

Quand l’utiliser

Vous êtes un CSM préparant un QBR pour un compte nommé spécifique, Gainsight est votre système d’enregistrement pour le health, l’usage et les objectifs du success plan, et vous voulez une narration peuplée et un outline de diapositives que vous pouvez éditer plutôt qu’un deck vide. La Skill est conçue pour le cas où l’histoire du QBR doit tresser quatre choses ensemble — où le compte se situe par rapport aux engagements du trimestre dernier, ce que disent les données d’usage et de résultats, quels risques sont ouverts, et où se trouve l’expansion crédible — et l’amener dans un ordre de diapositives qu’un humain peut affiner.

Elle produit l’output le plus utile quand le scorecard Gainsight est configuré (pas seulement le health pill par défaut), que le success plan a des objectifs avec dates cibles et statut, et que les mesures d’usage sont peuplées par rapport à un vrai baseline. Pour les comptes qui atteignent cette barre, le brouillon atterrit proche du prêt-pour-deck. Pour ceux qui ne l’atteignent pas, la Skill signale le gap par son nom plutôt que d’écrire un brouillon confiant par-dessus des données manquantes.

Quand NE PAS l’utiliser

N’utilisez pas cette Skill pour auto-envoyer un deck de QBR. Elle rédige une narration et un outline ; elle ne rend pas les diapositives et ne remplace pas la lecture que le CSM fait de la relation. Chaque deck reçoit une passe humaine et une validation de l’équipe de compte sur le framing avant que le client ne le voie.

Ne la pointez pas vers un compte avec moins de 30 jours de données d’usage dans Gainsight, un scorecard vide ou jamais configuré, ou un success plan sans objectifs enregistrés. La Skill est conçue pour signaler et refuser plutôt que combler avec des généralités — mais seulement si vous honorez le refus. Écraser le flag INSUFFICIENT_DATA produit un brouillon qui se lit bien et induit le client en erreur.

Ne l’utilisez pas comme modèle de probabilité de renewal ou de churn. La table des risques est du framing de QBR — de quoi parler dans la salle — pas un score de rétention calibré. Si vous avez besoin d’un nombre de health défendable avec une explication de ce-qui-a-changé, construisez plutôt le score de health composite dans n8n et lisez la table des risques de cette Skill comme un commentaire, pas comme un signal.

Ne l’utilisez pas pour des reviews internes ou de board. Les passes de narration et de ton supposent une audience client externe et un cadre de renewal-ou-expansion.

Setup

Environ 45 à 90 minutes la première fois, presque entièrement consacrées à mapper l’ordre des diapositives de votre deck au vocabulaire d’outline de la Skill et à déposer de vrais échantillons de voix. Après le premier compte, les exécutions prennent quelques minutes.

Installez la Skill. Déposez le bundle de apps/web/public/artifacts/qbr-deck-builder-skill/ dans ~/.claude/skills/qbr-deck-builder/. Elle expose une seule commande, build_qbr_deck(account_id, quarter), plus des helpers internes pour les pulls Gainsight, le parsing du success plan et le pipeline Claude à deux passes.
Branchez la credential Gainsight. Configurez GAINSIGHT_API_KEY et GAINSIGHT_DOMAIN avec un accès en lecture à Company, Scorecard, Success Plan / CTA, et les objets d’usage/adoption que votre org peuple. La Skill lit seulement ; elle n’écrit jamais en retour dans Gainsight. Si vos données d’usage vivent dans un objet d’adoption séparé, configurez GAINSIGHT_USAGE_OBJECT avec son nom d’API — la Skill valide les noms de champs contre references/1-deck-outline-map.md et refuse de remplir la diapositive d’usage s’ils dérivent.
Mappez l’outline de votre deck. Ouvrez references/1-deck-outline-map.md et remplacez le manifeste de diapositives par l’ordre et les titres de diapositives réels de votre équipe. L’outline par défaut est titre-exécutif, où-nous-en-étions, usage-et-résultats, risques-ouverts, plays-d’expansion, demandes-et-prochaines-étapes — réordonnez ou renommez pour correspondre au deck que vous présentez réellement.
Fixez la forme du success-plan. Ouvrez references/2-success-plan-format.md et soit adoptez le schema verbatim, soit décrivez comment votre équipe enregistre les objectifs dans Gainsight (type de CTA, le champ qui porte la date cible, le picklist qui porte le statut). La Skill a besoin d’une forme stable pour parser objectif par objectif ; une forme mal ajustée est la cause la plus fréquente d’une histoire de résultats vide.
Déposez des échantillons de voix. Remplacez le placeholder dans references/3-sample-deck.md par trois à cinq narrations de QBR antérieures anonymisées de votre équipe CSM pour que la passe de ton ait du vrai matériel à imiter. Sans échantillons, la Skill écrit dans un registre neutre et signale TONE_REVIEW_NEEDED.
Exécutez pour un compte. build_qbr_deck(account_id="1P01...XYZ", quarter="Q2-2026", last_deck_path="..."). La Skill écrit un fichier Markdown avec un bloc fenced par diapositive, plus un résumé exécutif d’un paragraphe en fichier séparé. Lisez-le de haut en bas, éditez et collez dans le deck.

Ce que la Skill fait réellement

La Skill tire quatre choses de Gainsight en un batch : l’enregistrement Company (ARR, date de renewal, segment, étape de lifecycle), le scorecard actuel (chaque mesure, son score et sa tendance par rapport à la période précédente), le success plan actif (chaque objectif avec date cible et statut) et le rollup d’usage par rapport au baseline du compte. Si un pull retourne vide, la Skill enregistre unavailable pour cet input et le file vers un flag INSUFFICIENT_DATA sur la diapositive affectée plutôt que d’inventer du contenu. Gainsight est ici la source unique à dessein — une credential, un enregistrement de compte, une définition de scorecard — pour que le brouillon soit reproductible et que la lignée des données soit évidente pour le CSM qui l’édite.

Elle exécute ensuite deux passes Claude, pas une. La passe un est la synthèse : Claude lit les quatre inputs plus le deck de QBR précédent et construit un scratchpad interne — les wins reliés aux objectifs du success plan, les gaps, l’histoire d’usage-et-résultats par rapport au baseline, les risques ouverts priorisés rouge/jaune/vert, et les plays d’expansion priorisés par signal (tendance d’usage, force du scorecard, marge de contrat) et confiance (haute, moyenne, basse). La synthèse est sa propre passe parce que la passe suivante a besoin d’une image cohérente ; plier synthèse et écriture de diapositives en une seule passe fait que les diapositives surpondèrent l’input que Claude a lu en dernier, et la priorisation d’expansion dégénère en liste plutôt qu’en priorisation.

La passe deux est narration-et-outline. Claude lit les échantillons de voix de references/3-sample-deck.md et réécrit le scratchpad dans la voix de l’équipe — neutre, fondée sur les données, sans superlatifs — puis le mappe sur l’ordre de diapositives de references/1-deck-outline-map.md, un bloc fenced par diapositive. Garder le mapping d’outline dans la seconde passe signifie que réordonner ou renommer des diapositives ne réexécute que cette passe ; le scratchpad de synthèse est réutilisé. Le résumé exécutif est généré en dernier à partir de la narration terminée pour qu’il ne contredise jamais les diapositives en dessous.

L’output est un seul fichier Markdown — un bloc fenced par diapositive, dans l’ordre du deck, chaque bloc en-tête avec le titre de diapositive de votre map — plus un résumé exécutif séparé d’un paragraphe. Le CSM édite toujours avant que le deck ne soit construit. La Skill est un moteur de brouillon, pas un publisher.

Réalité des coûts

Une exécution complète coûte environ 12 000 à 22 000 tokens d’input et 3 000 à 6 000 tokens d’output sur Claude Sonnet — disons 5 à 12 centimes par QBR aux prix actuels de Sonnet. C’est moins cher que la skill de prep avec Salesforce-plus-Gong parce qu’il n’y a pas de transcriptions d’appels dans l’input ; les pulls Gainsight sont des enregistrements structurés, pas des transcriptions de 60 minutes. Le temps d’horloge est d’une à trois minutes par compte, dominé par le batch d’API Gainsight en passe zéro ; les deux passes Claude ajoutent 30 à 60 secondes.

Un CSM construisant une narration de QBR à partir de zéro passe typiquement 60 à 120 minutes par compte à tirer le scorecard, reconstruire les engagements du trimestre dernier et rédiger le texte des diapositives. La Skill ramène cela à 20 à 40 minutes d’édition, donc l’économie est d’environ une heure par QBR. Un book de 25 comptes à un QBR par trimestre représente environ 25 heures économisées par trimestre par CSM — contre une dépense Anthropic sous les 3 $ par trimestre pour ce book.

Métrique de succès

Suivez le temps entre « outline généré » et « deck envoyé en revue interne » par QBR ; la Skill devrait ramener la médiane sous 45 minutes dans le premier trimestre d’usage. Surveillez le taux de brouillons portant les flags INSUFFICIENT_DATA, SUCCESS_PLAN_STALE ou TONE_REVIEW_NEEDED — ce sont des indicateurs avancés de problèmes d’hygiène upstream (scorecards laissés sur les défauts, success plans non maintenus, pas d’échantillons de voix) que la Skill fait remonter par conception ; un trimestre sain les fait tendre à la baisse. Suivez aussi la part de narration générée qui survit à la passe d’édition du CSM : visez 70 % ou plus. En dessous, les données Gainsight ont besoin de travail ; au-dessus de 90 %, le CSM sous-édite probablement un brouillon qui ne devrait jamais sortir sans édition.

Versus les alternatives

Versus le QBR / Success Snapshot natif de Gainsight. Gainsight livre des exports templatisés de QBR et de Success Snapshot qui auto-peuplent les mesures du scorecard, les charts d’usage et le NPS dans une mise en page de diapositives. Si vous voulez des champs rendus dans un deck, c’est moins de setup et le défaut évident — c’est le produit que vous payez déjà. Le gap qu’il laisse est la narration : il fait remonter les mesures, il n’écrit pas l’histoire qui relie l’usage de ce trimestre aux engagements du trimestre dernier, et il ne priorise pas les plays d’expansion en prose. Cette Skill écrit cette histoire à partir des mêmes données Gainsight. Utilisez l’export natif pour les diapositives à charts et cette Skill pour les diapositives de narration ; elles sont complémentaires, pas concurrentes.

Versus la skill de prep de QBR avec Salesforce-plus-Gong. Cette skill ajoute l’historique de compte Salesforce et les thèmes d’appels Gong au mélange et est le bon choix quand la couleur dérivée des appels (citations d’exécutifs, mentions de concurrents) est porteuse dans vos QBR et que vous avez la couverture Gong pour la soutenir. Elle coûte plus par exécution et nécessite trois credentials. Cette Skill est le bon choix quand Gainsight est votre source de vérité, que vous n’avez pas ou ne voulez pas brancher Gong, et que le scorecard plus le success plan portent l’histoire. Exécutez celle adossée à Gong pour les comptes stratégiques au riche historique d’appels ; exécutez celle-ci pour la long tail que vous pilotez depuis le CSP.

Versus l’écrire à la main. La préparation manuelle produit le meilleur QBR pour un compte de top-tier parce que le CSM porte un contexte qu’aucun enregistrement ne détient — la conversation budgétaire hors registre, le champion qui part en silence. Le coût est l’heure et plus par compte, qui ne passe pas à l’échelle sur un book de 25 comptes. Utilisez la préparation manuelle pour la poignée de comptes où le contexte de la relation est le deck ; utilisez la Skill pour le reste, et même sur les comptes top-tier partez du brouillon de la Skill et éditez plus fort.

Points de vigilance

Scorecard par défaut, histoire confiante. Un compte dont le scorecard n’a jamais été configuré au-delà du health pill par défaut produit des mesures qui ne signifient rien, et une narration construite dessus se lit plausible et ne dit rien. Garde : la Skill vérifie si le scorecard a plus que l’unique mesure par défaut peuplée ; sinon, elle écrit la diapositive usage-et-résultats comme INSUFFICIENT_DATA: scorecard non configuré plutôt que de narrer du bruit.
Success plan périmé. Un success plan non touché depuis plus de 60 jours rend une histoire de progrès qui sonne confiante mais est dépassée. Garde : la Skill lit la date de dernière modification de chaque objectif ; si l’édition la plus récente du plan est plus vieille que 60 jours, elle préfixe SUCCESS_PLAN_STALE à la diapositive où-nous-en-étions pour que le CSM doive confirmer que les objectifs tiennent toujours avant de les présenter.
Mauvais deck précédent. Si last_deck_path pointe vers le deck d’un autre compte ou d’un autre trimestre, le framing « engagements d’alors versus réalité d’aujourd’hui » casse silencieusement et la narration rend compte par rapport aux mauvaises promesses. Garde : la passe de synthèse extrait le nom de compte et le trimestre de la première diapositive du deck précédent et s’arrête avec une erreur de mismatch si l’un ou l’autre est en désaccord avec les inputs.
Mismatch de ton avec le client. La voix par défaut est celle de l’équipe CSM, qui peut ne pas correspondre à la façon dont un acheteur enterprise s’attend à être adressé versus un startup. Garde : quand les échantillons de voix dans references/3-sample-deck.md incluent des decks que le client a réellement reçus, la passe de ton les pondère au-dessus des docs internes ; sans échantillons elle écrit en registre neutre et signale TONE_REVIEW_NEEDED sur le résumé exécutif.
Plays d’expansion qui devancent les données. Sommé de prioriser l’expansion, un modèle fabriquera un upsell plausible même quand aucun signal d’usage ou de contrat ne le soutient. Garde : la priorisation d’expansion est contrainte aux plays adossés à un signal nommé (une mesure d’usage en tendance haussière, une marge de scorecard, des seats de contrat sous l’entitlement) ; un play sans signal est abandonné, pas rétrogradé, et si aucun ne qualifie la diapositive le dit plutôt que de combler.

Stack

Gainsight — enregistrement Company, scorecard, success plan et rollup d’usage ; source en lecture seule pour tout le brouillon
Claude — pipeline à deux passes : synthèse (wins, risques, expansion, histoire d’usage) puis narration plus mapping d’outline de diapositives (Sonnet recommandé pour le coût ; Opus seulement si le voice match importe plus que le budget)
Votre outil de deck — Google Slides ou PowerPoint ; le CSM colle le Markdown diapositive par diapositive dans le template de l’équipe après édition

Modifier cette page sur GitHub