Bundle buyer signals into a daily AE digest with Claude

Un Claude Skill qui extrait les signaux d’intention, les événements d’engagement et les données d’usage produit pour un compte nommé, et les compresse en un unique digest quotidien qu’un AE peut lire et exploiter en moins de cinq minutes. Il remplace le rituel matinal consistant à naviguer entre Common Room, Gong et un dashboard de product analytics pour assembler un tableau qui aurait dû l’être depuis longtemps. Le bundle est disponible à apps/web/public/artifacts/signal-bundler-account-execs-claude-skill/ et contient SKILL.md ainsi que deux templates de référence que l’utilisateur adapte avant la première utilisation.

Quand utiliser

Utilisez ce skill lorsqu’un AE gère simultanément plus de six ou sept comptes nommés et que la charge cognitive liée à la surveillance de plusieurs canaux de signaux — récapitulatifs Gong, fils d’activité Common Room, alertes d’usage produit — est devenue le goulot d’étranglement avant le standup matinal. Le skill n’est pas conçu pour les comptes où l’AE n’a eu aucun contact préalable ; le bundling de signaux requiert une base de référence sur l’identité du comité d’achat et l’allure d’une activité « normale » pour ce compte. Effectuez au moins un appel de découverte avant d’invoquer le skill sur un compte.

Le skill est également l’outil adapté lorsque votre équipe dispose des signaux mais n’en a pas une vue partagée. Common Room capture l’activité communautaire et web ; Gong capture l’intelligence conversationnelle ; le product analytics capture le comportement in-app. Si ces trois flux de données ne sont visibles que dans trois onglets séparés, les AEs ignorent deux d’entre eux ou construisent un modèle mental inférieur à ce qu’une simple synthèse leur donnerait.

Concrètement, invoquez-le depuis :

• Une tâche planifiée Claude qui s’exécute chaque matin par AE, itère sur la liste des comptes nommés de l’AE, et envoie chaque brief par Slack ou email avant le standup.
• Une invocation manuelle dans Claude Code lorsque l’AE a un appel de QBR ou de renouvellement ce jour-là et souhaite une vue consolidée des 14 derniers jours d’activité avant l’appel.
• Une colonne AI Clay sur une table de comptes, déclenchée lorsqu’un webhook « compte actif » de Common Room s’est déclenché dans les 24 dernières heures — afin que seuls les comptes avec des signaux récents génèrent un brief ce jour-là.

Quand NE PAS utiliser

Ignorez ce skill lorsque :

• L’AE couvre moins de cinq comptes. En dessous de ce seuil, l’AE maintient généralement de toute façon le tableau complet des signaux en tête, et le coût de configuration (calibration de la taxonomie, câblage de la tâche planifiée) ne vaut pas la peine.
• Les feeds de signaux ne sont pas connectés. Si Common Room n’exporte pas de données d’activité structurées et que les transcriptions Gong ne sont pas disponibles dans un format parseable, le skill n’a rien à synthétiser. Faites d’abord le travail d’intégration ; le skill n’est pas un scraper.
• Vous souhaitez que le skill rédige la mise à jour CRM. Le digest est destiné à la mémoire de travail de l’AE. Il ne se substitue pas à l’enregistrement des activités dans Salesforce. Câblez une étape distincte de writeback CRM en aval du brief, ou formez les AEs à coller manuellement le champ « Recommended first move » dans le journal d’activité.
• Le compte appartient à un secteur réglementé avec des exigences strictes de résidence des données. Faire transiter des signaux d’engagement client par l’API Claude signifie que ces signaux traversent l’infrastructure Anthropic. Vérifiez vos accords de traitement des données avant de connecter des données comportementales client externes à un appel LLM.

Configuration

La configuration prend entre 30 et 60 minutes une fois que Common Room et Gong exportent des données structurées. La configuration de ces exports est la dépendance la plus longue.

1. Installer le Skill. Copiez apps/web/public/artifacts/signal-bundler-account-execs-claude-skill/SKILL.md et le dossier references/ dans votre répertoire .claude/skills/signal-bundler/, ou uploadez-le comme Skill dans claude.ai. Les champs name et description du frontmatter sont le déclencheur sur les prompts pertinents.
2. Configurer la taxonomie de signaux. Ouvrez references/1-signal-taxonomy.md. Remplacez les lignes de type d’événement par défaut par les types d’événements réels que Common Room et Gong produisent dans votre instance — les noms d’événements Common Room varient selon les canaux que vous avez connectés. Définissez urgency_tier pour chacun. Si votre produit émet des événements personnalisés (noms d’activation de feature, seuils d’usage), ajoutez des lignes pour eux.
3. Configurer le template de digest. Ouvrez references/2-digest-template.md. Mettez à jour les noms de champs Salesforce dans la section CRM-writeback si vous souhaitez renvoyer le brief vers l’enregistrement de compte. Mettez à jour les notes de blocs Slack pour correspondre au nommage de vos canaux.
4. Connecter les sources d’entrée. Common Room : utilisez l’API d’export d’activité de compte ou l’intégration Zapier pour pousser des fenêtres d’activité de 48 heures vers une table de staging. Gong : utilisez l’API Gong (/v2/calls) pour extraire les résumés et extraits de transcriptions pour un compte donné. Événements produit : exportez depuis votre warehouse (Snowflake, BigQuery, Redshift) ou depuis Amplitude/Mixpanel via leurs APIs d’export, avec périmètre sur les emails utilisateurs du compte.
5. Tester sur trois comptes. Exécutez le skill manuellement sur trois comptes avec une activité récente connue. Vérifiez que : les niveaux d’urgence dans la table de signaux correspondent à l’intuition de votre équipe sur ce qui était important ; le narratif nomme les bons acteurs ; le « Recommended first move » est quelque chose qu’un AE ferait réellement, pas un générique « relancer le compte ». Ajustez la taxonomie si les niveaux semblent incorrects.
6. Planifier ou automatiser. Configurez une tâche planifiée (tâche planifiée Claude Code, cron job ou flow n8n) qui exécute le skill par AE à une heure cohérente chaque matin. Chaque exécution doit couvrir la liste complète des comptes de l’AE et livrer un brief par compte.

Ce que fait réellement le skill

Le skill exécute quatre étapes dans un ordre fixe.

Étape 1 — normalisation et dédoublonnage des signaux. Tous les événements entrants de Common Room, Gong et du product analytics sont mappés vers un schéma partagé : {source, actor, event_type, urgency_tier, timestamp, raw_excerpt}. Les événements qui apparaissent dans plusieurs sources (un appel Gong qui a aussi généré un événement « meeting » Common Room) sont dédoublonnés sur (actor, event_type, timestamp_hour). Pourquoi normaliser avant de synthétiser : si le modèle reçoit des schémas hétérogènes, il pondère implicitement la source la plus verbeuse — une transcription Gong a plus de tokens qu’une ligne d’événement Common Room — plutôt que de pondérer par urgence réelle du signal.

Étape 2 — classification de l’urgence par lookup taxonomique. Chaque événement normalisé est comparé à references/1-signal-taxonomy.md pour attribuer un niveau d’urgence (hot / warm / cold). Les événements absents de la taxonomie reçoivent warm par défaut. Les premières occurrences d’événements de niveau hot — événements que l’acteur n’a pas produits dans les 7 derniers jours — sont signalées comme particulièrement significatives. Pourquoi basé sur une taxonomie plutôt que le jugement libre du LLM : des niveaux d’urgence cohérents entre les comptes sont ce qui rend le brief comparable d’un jour à l’autre. Si le modèle re-dérive l’urgence depuis zéro à chaque exécution, un AE ne peut pas développer l’intuition qu’un brief « 3 hot » signifie quelque chose de matériellement différent d’un brief « 0 hot ».

Étape 3 — synthèse narrative. Avec les signaux classifiés, le modèle les regroupe par thème (intérêt produit, mention d’un concurrent, changement de stakeholder, pic ou baisse d’engagement) et rédige une section « What happened » de 3-5 phrases nommant des acteurs et événements spécifiques par ordre d’urgence. Il identifie le signal le plus actionnable et rédige un « Recommended first move » en une seule phrase. Si account_snapshot est fourni avec l’étape actuelle du deal, il signale explicitement les signaux qui contredisent l’étape — un champion mentionnant un concurrent alors que le deal est en « Proposal Sent » est affiché explicitement, pas enfoui.

Étape 4 — assemblage de l’output. Le digest est rendu avec references/2-digest-template.md : en-tête de compte, comptage de signaux par niveau, narratif, action recommandée, table de signaux (limitée à 10 lignes) et un footer de fraîcheur des données. La limite de la table évite l’anti-pattern du « mur d’événements » ; les AEs peuvent accéder au feed complet depuis Common Room quand ils en ont besoin.

Réalité des coûts

Le coût en tokens par compte dépend du nombre d’événements dans la fenêtre et de la longueur des transcriptions Gong. Pour une fenêtre typique de 48 heures avec 10-15 événements Common Room et 1-2 résumés d’appel Gong (pas de transcriptions complètes), attendez environ 2 000-3 500 tokens d’entrée et 400-600 tokens de sortie par compte. Aux tarifs de Claude Sonnet 4.x (environ $3 par million de tokens d’entrée et $15 par million de tokens de sortie début 2026), cela représente environ $0,012-0,02 par brief de compte.

Un AE avec 15 comptes nommés dépense environ $0,18-0,30 par jour en tokens Claude, soit $4-7 par mois. Une équipe de 20 AEs couvrant chacun 15 comptes dépense $80-140 par mois en tokens Claude — un arrondi face à la rémunération AE économisée sur l’agrégation matinale des signaux.

Les coûts hors tokens sont plus importants. Configurer de manière fiable les exports Common Room et Gong prend une demi-journée de temps RevOps. La session de calibration de la taxonomie avec l’équipe AE prend 60-90 minutes. Ensuite, le skill est pratiquement autonome jusqu’à ce que le vocabulaire de signaux change (un nouveau feature produit crée de nouveaux types d’événements, ou Common Room ajoute une nouvelle intégration de canal).

La longueur des transcriptions Gong est la principale variable de tokens. Si vous passez des transcriptions verbatim complètes plutôt que des résumés d’appel générés par Gong, les tokens d’entrée par compte peuvent atteindre 8 000-15 000 pour une semaine chargée en appels. Utilisez l’output de résumé natif de Gong plutôt que les transcriptions brutes, sauf si vous avez une raison spécifique d’avoir besoin du texte verbatim.

Métrique de succès

La métrique qui indique que le digest fonctionne : temps de l’AE jusqu’au premier contact significatif sur les comptes à signal hot. Avant le skill, un signal hot (revisite de la page de tarification, changement de poste du champion) restait inaperçu jusqu’à ce que l’AE ouvre Common Room par hasard. Après le skill, ce signal devrait produire une action de l’AE dans la même journée ouvrable. Suivez-le : marquez le « Recommended first move » avec une date dans le CRM lorsque l’AE enregistre l’activité, et comparez l’écart avec le timestamp du signal. Si l’écart médian ne tombe pas sous 8 heures pour les comptes à signal hot après 30 jours, le brief n’est pas lu — examinez si le canal de livraison (Slack vs email) est le problème.

Métrique secondaire : taux de couverture AE — quelle fraction des comptes nommés avec un signal hot dans les 48 dernières heures a reçu un contact AE dans la même fenêtre. Un taux de couverture supérieur à 80% indique que le digest accomplit sa mission.

Modes d’échec

• Mauvaise calibration de la taxonomie. La première taxonomie que vous écrirez sera incorrecte sur au moins deux ou trois lignes. Un événement « repo starred » semble warm en théorie, mais en pratique est toujours cold sauf si l’acteur est un stakeholder nommé. Si les AEs vous disent constamment « le brief a signalé X mais je n’agirais jamais là-dessus », le niveau taxonomique pour X doit être abaissé. Guard : après les deux premières semaines d’utilisation en production, effectuez une rétrospective : pour chaque action qu’un AE a prise sur la base d’une recommandation de digest, le signal qui l’a motivée était-il noté hot ou warm ? Si plus de 30% des signaux sur lesquels on a agi étaient cold, la taxonomie est trop agressive et va générer du bruit qui entraînera les AEs à ignorer le brief.
• Lacunes dans le comité d’achat. Common Room capture l’activité de n’importe qui dans le domaine du compte — développeurs juniors, stagiaires marketing, quelqu’un utilisant son email professionnel pour un projet personnel. Si le skill ne filtre pas par acteurs du comité d’achat, le brief se remplit de bruit provenant de non-décideurs et l’AE perd confiance en lui. Guard : passez account_snapshot avec une liste de contacts nommés depuis Salesforce (contacts du comité d’achat uniquement). Le skill étiquette chaque acteur de signal comme on-committee, unknown ou not-on-committee et rétrograde automatiquement les signaux hors comité d’un niveau d’urgence. Examinez les acteurs « unknown » chaque semaine — certains seront de nouveaux stakeholders à ajouter à l’opportunité.
• Obsolescence des transcriptions Gong amplifiant de vieux signaux. Le lookback Gong par défaut du skill est de 14 jours. Pour les comptes où le dernier appel remonte à 12 jours, le brief décrit les signaux de cet appel comme s’ils étaient récents. Un AE qui agit sur un signal « concurrent mentionné » vieux de 12 jours peut entrer dans un appel où la dynamique du deal a déjà évolué. Guard : le skill ajoute « Last call : N days ago » en tête de la section Gong et rétrograde tous les signaux dérivés de Gong à warm (pas hot) lorsque l’appel le plus récent date de plus de 7 jours. L’AE voit clairement l’ancienneté avant de décider d’agir.
• Pics de volume de signaux provenant de crawlers automatisés. Certaines intégrations Common Room captent l’activité de bots (monitoring automatisé, pipelines CI) comme « événements utilisateur ». Un pipeline de déploiement qui touche GitHub 40 fois par jour va inonder la table de signaux avec des événements repo_push notés warm et enterrer le vrai signal. Guard : ajoutez une liste d’exclusion bot_user_patterns au fichier de taxonomie (une liste de patterns d’email ou de noms d’acteur correspondant à des bots connus et comptes automatisés). Les événements de ces acteurs sont supprimés à l’étape de normalisation et non inclus dans le comptage.

vs alternatives

vs revue matinale manuelle sur trois onglets. Le statu quo pour la plupart des AEs : ouvrir Common Room, scanner le feed du compte, passer à Gong, trouver l’appel le plus récent, passer au dashboard produit, essayer de se rappeler quelle est la baseline d’usage du compte. Pour 5 comptes, cela prend 15-20 minutes et la synthèse n’est pas meilleure que la mémoire de l’AE. Pour 15 comptes, ce n’est pas faisable et la plupart des comptes ne sont pas surveillés. Le skill effectue la synthèse cross-sources de manière cohérente chaque jour ; le jugement de l’AE va dans la taxonomie et la décision de suivi, pas dans l’agrégation.

vs la vue Deals intégrée de Gong. L’onglet Deals de Gong affiche l’activité d’appels, les prochaines étapes et les signaux de risque de deal — mais uniquement pour les comptes avec des appels Gong actifs. Il n’affiche pas l’activité communautaire Common Room ni l’usage produit. Si vos AEs couvrent des comptes qui ne sont pas encore dans un cycle d’appels actif (comptes high-fit en début de pipeline), la vue intégrée de Gong est essentiellement vide. Ce skill extrait des signaux des trois sources pour tout compte nommé, quelle que soit la fréquence des appels.

vs une plateforme d’intelligence commerciale dédiée (par exemple, le scoring d’engagement de compte de 6sense ou les données d’intention + engagement de Demandbase). Ces plateformes disposent de taxonomies de signaux préconstruites, de données d’intention plus riches issues de leurs réseaux propriétaires et d’intégrations CRM natives qui poussent automatiquement les scores. La contrepartie : elles coûtent entre $30 000 et $100 000+ par an pour une équipe mid-market et leurs taxonomies sont opaques — vous ne pouvez pas inspecter ni modifier pourquoi un compte donné est évalué comme il l’est. Ce skill coûte quelques dollars par mois en tokens Claude, est totalement transparent et la taxonomie vous appartient à posséder et calibrer. Choisissez une plateforme si le volume de signaux est très élevé ou si vous avez besoin de données d’intention hors de votre propre produit et communauté ; choisissez ce skill si vous souhaitez un contrôle éditorial sur les signaux qui comptent et ne pouvez pas justifier une dépense au niveau plateforme.