Un prompt réutilisable qui transforme l’export hebdomadaire de comptes de Gainsight en un digest prêt pour le CSM : les comptes qui ont bougé cette semaine, ceux qui ont franchi une bande de risque et une liste priorisée des trois à toucher lundi. Le CSM colle un CSV (ou l’input à trois blocs du prompt) dans Claude et reçoit en retour un digest organisé par movers, risques et actions recommandées — chaque action nommant le compte, le trigger et l’étape suivante. Aucune integration à construire, aucun workflow n8n à maintenir : c’est un prompt que vous collez dans Claude.ai ou Claude Code, et le bundle d’artifact dans apps/web/public/artifacts/customer-health-digest-prompt/ inclut le texte du prompt plus le manifeste de colonnes que le prompt attend.

C’est la version d’entrée de gamme du workflow composite health score en n8n. Celui-là construit et réécrit un score défendable sur un planning nocturne ; celui-ci lit le score que vous avez déjà et le transforme en une liste de tâches du lundi matin. Commencez ici. Passez au flow n8n quand vous cessez de faire confiance au chiffre lui-même.

Quand l’utiliser

Utilisez-le quand vous (ou le pod CS que vous dirigez) avez déjà un health score dans Gainsight auquel vous faites globalement confiance, et que l’écart n’est pas le score — c’est que personne ne le lit avant le début de la semaine. Le mode d’échec le plus courant qu’il corrige : un CSM avec 40-80 comptes ouvre Gainsight le lundi, voit un mur de pills colorées et priorise selon le compte qui a envoyé un email en dernier plutôt que selon le compte qui a bougé. Le digest remplace « scruter le dashboard et espérer » par une liste priorisée de trois comptes et la raison pour laquelle chacun y figure.

Il convient à un book de CSM d’environ 30-120 comptes. En dessous de 30, vous pouvez lire chaque compte vous-même et le digest économise peu. Au-dessus de ~150, un export par CSM devient assez long pour que vous vouliez le batching et l’alerting du flow n8n plutôt qu’un collage manuel. Il convient aussi à un lead CS Ops qui veut un format de digest cohérent dans toute l’équipe pour que le standup CS du lundi tourne sur le même artifact pour chaque book.

Quand NE PAS l’utiliser

Ne l’utilisez pas comme le health score lui-même. Le prompt résume un score ; il n’en calcule pas un. Si votre score Gainsight n’est pas digne de confiance — les CSM l’ignorent déjà et tirent l’usage brut — un digest d’un chiffre auquel personne ne croit n’est qu’une façon plus rapide de faire remonter du bruit. Corrigez d’abord le score (c’est le travail du workflow n8n), puis faites-en le digest.

Ne le pointez pas vers un export sans colonne de delta semaine-sur-semaine. Tout le digest repose sur le mouvement — « ce qui a changé depuis la semaine dernière » — donc l’export a besoin à la fois du score actuel et du score de la période précédente (ou d’un delta précalculé). Sans le delta, le prompt classera par score absolu, ce qui enterre le compte tombé de 80 à 55 (encore « jaune », mais en chute libre) sous le compte qui est un rouge stable depuis un an. Le manifeste de colonnes dans le bundle liste la colonne de delta comme requise pour exactement cette raison.

Ne l’utilisez pas pour envoyer quoi que ce soit au client. La sortie est un digest interne du CSM. Il nomme les risques sans détour (« usage d’ACME en baisse de 41 % semaine-sur-semaine, dépendance à un seul utilisateur ») dans un langage que vous ne mettriez jamais devant le compte. C’est un artifact de préparation du lundi, pas un brouillon de communication client.

Ne lui donnez pas plus de ~150 lignes de comptes en un seul collage. Au-delà, le modèle commence à compresser le milieu de la liste et le classement se dégrade. Divisez un grand book en deux collages, ou passez au flow n8n avec batching.

Setup

Environ 20-30 minutes, presque entièrement passées à faire correspondre les colonnes de l’export Gainsight au manifeste une fois.

Construisez l’export. Dans Gainsight, créez (ou réutilisez) un rapport sur l’objet Company avec ces colonnes : nom du compte, ID du compte, health score actuel, health score de la semaine précédente (ou le delta directement), ARR, date de renewal, owner CSM, et vos deux ou trois sub-scores si vous en avez (usage, sentiment, activité). Exportez en CSV. Le column-manifest.md du bundle liste les noms de colonne exacts que le prompt lit et lesquels sont requis ou optionnels.
Déposez le prompt. Copiez le corps du prompt depuis apps/web/public/artifacts/customer-health-digest-prompt/prompt.md dans un Project Claude.ai (ou une session Claude Code). Il est structuré selon la forme en cinq parties : rôle, format d’input, tâche, choses-à-éviter, format d’output. Ne le paraphrasez pas — la section choses-à-éviter est ce qui empêche le modèle d’inventer une raison de churn que les données ne soutiennent pas.
Collez vos données. Collez le CSV sous le prompt. Si vos noms de colonne diffèrent du manifeste, renommez-les dans le rapport ou ajoutez une note de mapping d’une ligne en haut de votre collage (« traiter Score_Prev comme le score de la semaine précédente »). Le prompt tolère une note de mapping ; il ne tolère pas un delta manquant.
Fixez les seuils une fois. Le bloc de tâche du prompt a trois nombres ajustables : les coupures de bande (par défaut vert à 75 ou plus, jaune à 50 ou plus, rouge en dessous de 50 — écrit « en dessous de 50 » délibérément, jamais le glyphe littéral inférieur-à, pour qu’il soit sûr à coller), le delta qui compte comme un « mover » (par défaut 5 points), et combien de comptes mettre dans la liste d’actions recommandées (par défaut 3). Éditez-les selon la calibration de votre équipe avant la première utilisation, puis laissez-les stables pour que les digests semaine-sur-semaine soient comparables.
Lancez-le chaque semaine. Même prompt, export frais, chaque lundi (ou vendredi pour la semaine suivante). Comme le prompt est déterministe en structure, deux CSM le lançant sur leurs propres books produisent la même forme de digest, ce qui est le point pour un lead CS Ops standardisant le standup.

Ce que le prompt fait réellement

Le prompt fait quatre choses dans l’ordre, et l’ordre est le design. D’abord il classe chaque compte dans une bande à partir du score actuel en utilisant vos coupures, donc le digest s’ouvre sur une ligne de décompte (« 12 vert, 9 jaune, 4 rouge »). Ensuite il calcule les movers : tout compte dont le delta semaine-sur-semaine dépasse le seuil de mover, trié par delta absolu, donc les plus grands swings — à la hausse ou à la baisse — remontent en premier. Nommer les movers à la hausse importe autant que ceux à la baisse ; un compte qui a bondi de 20 points est un signal d’expansion, pas seulement un non-problème.

Troisièmement il marque les franchissements de bande séparément des movers bruts, parce que franchir du jaune au rouge est un événement différent de chuter de cinq points à l’intérieur du vert. Un franchissement de bande est la ligne qui déclenche un play ; une oscillation à l’intérieur d’une bande ne le fait généralement pas. Les garder dans des sections séparées empêche un CSM de traiter chaque baisse de cinq points comme une urgence.

Quatrièmement — la partie qui en fait une liste de tâches plutôt qu’un rapport — il produit une liste priorisée d’actions recommandées. Chaque entrée nomme le compte, le seul signal contributeur le plus fort (tiré des sub-scores s’ils sont présents, par ex. « usage en baisse de 41 % », « aucun contact CSM depuis 38 jours »), et une étape suivante concrète (« planifier un check-in », « impliquer l’AE sur le renewal dans 22 jours »). Le classement pondère d’abord les franchissements de bande vers le rouge, puis les gros movers à la baisse, puis la proximité du renewal. Le bloc choses-à-éviter interdit au modèle d’inventer une cause que les colonnes ne montrent pas : si seul le composite a bougé et qu’aucun sub-score ne l’explique, l’entrée se lit « composite en baisse de 11, aucun driver unique dans les données — tirer le compte manuellement » plutôt qu’une raison fabulée.

Le format d’output est fixe : une ligne de décompte, une table de Movers, une table de Franchissements de bande et une liste numérotée d’Actions recommandées plafonnée à votre N. Cette forme fixe est ce qui permet à un lead CS Ops de comparer le digest de cette semaine à celui de la semaine dernière et ce qui permet au standup du lundi de tourner dessus sans reformatage.

Réalité des coûts

Un book typique de 60-100 comptes est un seul collage d’environ 3 000-6 000 tokens d’input (le CSV) plus le prompt de ~600 tokens, et le digest en retour fait 400-900 tokens d’output. Sur Claude Sonnet aux prix actuels, c’est bien en dessous d’un centime par lancement — disons 0,02-0,04 $ par CSM par semaine, ou quelques dollars par an pour une équipe de 10 CSM. Aucun coût d’infrastructure : pas d’exécuteur n8n, pas de credentials à faire tourner, pas de vue de warehouse à maintenir. Le seul coût récurrent, ce sont les deux minutes qu’un CSM passe à tirer l’export et à le coller, ce qui est bien moins que les 15-30 minutes à fixer le dashboard que cela remplace.

L’arbitrage honnête face au flow n8n : ce prompt ne peut rien réécrire, ne peut pas tourner sur un planning sans surveillance et ne peut pas alerter Slack. C’est un collage avec humain-dans-la-boucle. C’est une feature à cette échelle (le CSM lit chaque digest) et un goulot d’étranglement au-delà de ~150 comptes (le collage devient ingérable). Le coût de passer au niveau supérieur, c’est les ~2 heures de setup n8n ; le coût de rester, c’est le collage hebdomadaire de deux minutes.

À quoi ressemble le succès

Surveillez trois nombres le premier mois. Premièrement, la latence digest-vers-action : la part des comptes dans la liste d’actions recommandées qui ont reçu un contact CSM journalisé dans les 48 heures du digest. Visez au-dessus de 70 % à la semaine trois ; en dessous, le digest est lu et ignoré, ce qui signifie généralement que le classement ne correspond pas à l’intuition du CSM et que les seuils ont besoin d’ajustement. Deuxièmement, le taux de capture des franchissements de bande : parmi les comptes qui ont churné ou escaladé dans le trimestre, combien sont apparus dans un franchissement de bande vers le rouge dans le digest au moins 30 jours avant. C’est le test d’indicateur avancé — si le digest ne les a jamais signalés tôt, le problème est le score sous-jacent, pas le digest. Troisièmement, le temps de standup : un lead CS Ops devrait voir le standup CS du lundi raccourcir une fois que tout le monde arrive avec le même format de digest ; sinon, le digest n’est pas réellement utilisé pour mener la réunion.

Face aux alternatives

Face à la lecture directe du dashboard Gainsight. Le dashboard montre l’état actuel ; il ne classe pas, ne met pas le mouvement au premier plan et ne produit pas de liste de tâches. Un CSM discipliné peut répliquer le digest manuellement en triant sur la colonne de delta et en lisant vers le bas — et pour un book de 30 comptes, c’est vraiment plus rapide que de coller dans Claude. Le prompt gagne sa place à 60 comptes ou plus où le tri-et-lecture manuel prend 20 minutes et se dégrade dès le mercredi.

Face aux CTA et au Cockpit propres à Gainsight. Gainsight peut déclencher un Call To Action quand un score franchit un seuil, ce qui chevauche la section franchissement de bande ici. Utilisez les CTA pour les événements qui doivent déclencher un workflow que quelqu’un lise un digest ou non (un franchissement vers le rouge sur un compte top-20). Utilisez ce digest pour le triage hebdomadaire que les CTA ne vous donnent pas : le jugement priorisé « touchez ces trois en premier » sur tout le book. Ils sont complémentaires — les CTA sont les interruptions dures, le digest est la lecture hebdomadaire.

Face au flow composite health score en n8n. Ce flow est le bon outil quand le score lui-même a besoin d’être reconstruit, quand vous voulez du write-back nocturne et des alertes Slack, ou quand le book est assez grand pour que le collage manuel ne passe pas à l’échelle. Ce prompt est le bon outil quand le score va bien et que l’écart est purement « le transformer en plan du lundi ». La plupart des équipes devraient commencer avec ce prompt et ne construire le flow qu’une fois qu’elles ont la preuve que le score doit changer, pas seulement être résumé.

À surveiller

Pas de colonne de delta, digest inutile. Sans un delta semaine-sur-semaine, le prompt ne peut pas calculer les movers et retombe silencieusement sur un classement par score absolu, ce qui fait remonter les rouges chroniques et enterre ceux qui viennent de chuter. Garde-fou : le column-manifest.md du bundle marque le delta (ou le score de la semaine précédente) comme requis, et le bloc format-d’input du prompt ordonne au modèle de s’arrêter avec « colonne de delta manquante — impossible de calculer les movers » plutôt que de se dégrader en classement par score absolu.
Causes de churn inventées. Sommé d’expliquer une baisse de score, un modèle fabriquera volontiers une raison qui sonne plausible que les colonnes ne soutiennent pas. Garde-fou : le bloc choses-à-éviter interdit toute affirmation causale non traçable à un sub-score nommé, et force la sortie littérale « aucun driver unique dans les données — tirer le compte manuellement » quand seul le composite a bougé. Un CSM agissant sur une cause fabriquée est pire qu’un à qui on a dit d’aller regarder.
Export périmé lu comme à jour. Un CSM colle le CSV de la semaine dernière par accident et agit sur un mouvement déjà résolu. Garde-fou : le prompt exige une ligne « date-de » en haut du collage et la reprend dans l’en-tête du digest, donc un export périmé est visible d’un coup d’œil plutôt que d’être traité à l’aveugle.
Collage trop long compressant le milieu. Au-delà de ~150 lignes, le modèle compresse les comptes du milieu de la liste et le classement se dégrade en silence. Garde-fou : le bloc format-d’input plafonne le nombre de lignes et ordonne au modèle de refuser et de demander une division plutôt que de résumer silencieusement une liste tronquée.
Dérive des seuils entre semaines. Si un CSM édite les coupures de bande ou le seuil de mover entre les lancements, le digest de cette semaine n’est pas comparable à celui de la semaine dernière et le cadrage « ce qui a bougé » se casse. Garde-fou : les seuils vivent dans le bloc de tâche du prompt, pas dans les données collées, précisément pour qu’ils restent fixes d’un lancement à l’autre ; le manifeste de colonnes note que les seuils doivent être fixés une fois au setup et versionnés avec le prompt.

Stack

Claude — lit l’export, classe les movers et les franchissements de bande, écrit la liste d’actions recommandées (Sonnet suffit largement ; la tâche est du résumé structuré, pas du raisonnement profond)
Gainsight — source de l’export hebdomadaire de comptes (score actuel, score de la semaine précédente ou delta, ARR, date de renewal, sub-scores)
N’importe quelle source CSV — le prompt lit des colonnes, pas Gainsight spécifiquement ; repointez le manifeste vers un export Catalyst, Vitally ou ChurnZero et il fonctionne pareil

Modifier cette page sur GitHub