Comment bâtir une équipe GTM sur Claude Code que vous pouvez gérer seul

Une équipe GTM ressemble à une opération d'envoi. La majeure partie de son vrai travail est du jugement : quelle entreprise mérite un message cette semaine, que dire pour prouver que vous l'avez remarquée, quel absent relancer, ce qui a réellement fait avancer le pipeline.

L'envoi a toujours été la partie la moins chère. Le jugement est ce pour quoi vous aviez besoin d'une équipe, et c'est exactement ce qu'une seule personne + Claude Code peut désormais gérer de bout en bout.

Alors arrêtez de penser en effectifs et commencez à penser en tâches.

Une équipe GTM est une liste de tâches, et la plupart ont la même forme : lire un tas de données, prendre une décision, écrire quelque chose, faire un suivi, et se souvenir de ce qui s'est passé.

Branchez chaque tâche à un agent, donnez-leur une mémoire partagée, et mettez-les sur un planning. Les gens ont une UX, les logiciels ont une API, un agent a une ligne de commande, donc toute l'équipe tourne à partir d'une seule ligne cron à huit heures du matin. Chaque matin, elle fait un rapport, et votre travail se transforme en édition plutôt qu'en opération.

Ci-dessous, la construction, siège par siège, avec le prompt que je colle dans Claude Code pour chacun.

L'effectif : cinq sièges

Décider qui mérite un message

La partie difficile de l'outbound n'a jamais été l'envoi. C'était le jugement en amont : parmi toutes les entreprises du marché, laquelle mérite d'être contactée cette semaine, et que dire pour prouver que vous l'avez remarquée.

Ce jugement est le premier siège.

Il surveille quatre types de mouvements, les quatre qu'une décennie de données de marché continue de réduire :

• Un poste s'ouvre, ou est republié.
• Une entreprise engage un concurrent, ou publie quelque chose sur le problème que vous résolvez.
• Une entreprise lance, se développe, ou modifie sa stack.
• De l'argent circule via un tour de table ou une acquisition.

Il note chaque mouvement par rapport à qui correspond réellement et à tout ce que vous savez déjà sur ce compte, puis il rédige à partir du déclencheur lui-même.

La règle qu'il ne viole jamais est de citer ce qui a bougé. « J'ai vu que vous avez republié le poste de Head of RevOps, deuxième recrutement ops ce trimestre. » Jamais « Bonjour {{firstName}}. » Si le message avait pu être envoyé inchangé le mois dernier, le déclencheur a été ignoré et le compte attend.

1Écrire team/prospector.py : run(memory, source, delivery, icp, sequences, weights, offline, dry_run).
2Détecter les nouveaux signaux dans les quatre catégories (job, social, company, funding) et les écrire dans la mémoire
3partagée. Regrouper par compte. Pour chaque compte, l'évaluer par rapport à l'ICP et à l'historique complet avec
4prompts/judge.md (Claude, température 0), avec un repli sur une heuristique pondérée par catégorie qui ignore les signaux faibles
5ou hors ICP. Pour ceux qui passent la barre, rédiger à partir du déclencheur le plus fort avec prompts/draft.md,
6transmettre le brouillon à delivery (dry-run par défaut), et enregistrer le contact. Renvoyer les lignes de standup classées.

Préparer chaque appel avant qu'il ne commence

Avant un premier appel, quelqu'un passait vingt minutes à construire une fiche : de quoi parle cette entreprise, qu'est-ce qui a bougé, que lui avez-vous déjà envoyé, où le dernier fil s'est refroidi.

Confiez cela au deuxième agent.

Il rédige la fiche pour chaque appel programmé à partir de la même mémoire que le prospector utilise. Au moment où l'appel commence, la page est déjà là, avec le déclencheur qui les a amenés, l'historique, et la seule chose sur laquelle ouvrir.

Personne ne prépare à 23h pour un appel à 9h, et personne n'arrive à froid.

1Écrire team/researcher.py : run(memory, calendar, icp, offline).
2Pour chaque appel du calendrier d'aujourd'hui, extraire l'historique complet du compte depuis la mémoire partagée et rédiger une
3fiche d'une page avec prompts/brief.md : ce qui a bougé, ce que nous avons déjà envoyé et comment cela a été reçu, et la meilleure
4chose pour ouvrir l'appel. Appuyez chaque ligne sur l'historique, n'inventez jamais. En l'absence de clé API, revenir à un
5modèle simple construit à partir du dernier signal. Renvoyer une ligne de standup par appel.

Laisser la séquence faire le suivi

Un signal est la ligne de départ. La séquence est ce qui convertit, et c'est la partie où les gens sont les moins bons, car le suivi dépend qu'un humain se souvienne de faire le suivi. On oublie, on hésite, on le fait une fois et on arrête.

Alors l'envoi et le suivi tournent dans Overloop AI sous forme de séquences qui se déclenchent toutes seunes une fois que l'agent les a transmises. L'agent décide qui et rédige le premier contact. Overloop prend le relais selon un calendrier, par email et LinkedIn, de sorte que la cadence ne dépend jamais de la mémoire de personne.

1Écrire team/sequencer.py : run(memory, delivery, sequences, offline, dry_run, min_age_days, max_age_days).
2Demander à la mémoire partagée les comptes dont le dernier contact date de quelques jours et qui n'ont ni réponse ni réunion
3au planning. Rédiger un léger suivi qui ajoute un angle vraiment nouveau, l'envoyer dans la séquence follow_up,
4et enregistrer le contact. Ne pas toucher aux contacts récents en respectant la fenêtre d'âge minimum. Renvoyer une
5ligne de standup par compte.

Récupérer les absents

Un absent est un lead qualifié qui a eu un conflit de calendrier. Ils s'échappent du pipeline pour une seule raison : la récupération manuelle n'a jamais lieu.

Donc le même moteur exécute une séquence de récupération pour chaque absence. Quatre contacts sur une semaine, deux canaux, aucun reproche dans aucun :

• Une heure après l'absence : un lien de reprogrammation en deux clics.
• Le lendemain : la même offre sur LinkedIn.
• Jour trois : une chose utile liée à leur secteur, sans demande.
• Jour sept : un simple dernier appel.

Cela enlève l'émotion du suivi, et cela récupère environ un tiers des absents qui disparaissaient auparavant. Personne n'a à se souvenir d'en envoyer un seul.

1Écrire team/recoverer.py : run(memory, calendar, delivery, sequences, offline, dry_run).
2Pour chaque absent récent du calendrier, l'inscrire dans la séquence no_show_recovery définie dans
3config/sequences.yaml (quatre contacts sur une semaine, deux canaux, aucun reproche dans aucune étape), enregistrer le contact,
4et renvoyer une ligne de standup. La cadence vit dans config, pas dans le code.

Faire en sorte que le rapport hebdomadaire s'ajuste tout seul

Chaque vendredi, quelqu'un compile le rétro : ce qui a été envoyé, ce qui a réservé, ce qui est bloqué, où en est le pipeline. Le dernier agent le construit à partir de la même mémoire, chaque semaine, sans qu'on le lui demande.

Puis il fait ce qu'un rapport humain ne fait jamais.

Il note ses propres actions : les signaux qui continuent de réserver des réunions reçoivent plus de poids, les copies qui continuent d'échouer sont coupées. La shortlist du mois prochain est ordonnée par ce à quoi le marché a réellement répondu, et non par ce que vous avez supposé important en janvier. Le rapport cesse d'être un enregistrement de la semaine dernière et devient ce qui ajuste la suivante.

1Écrire team/reporter.py : run(memory, weights, days, offline).
2Lire les statistiques de la semaine depuis la mémoire partagée. Commencer par le nombre de réunions. Repondérer les quatre catégories
3de signaux par taux de réussite, en comptant une réunion plus qu'une réponse, avec un plancher pour qu'aucune catégorie ne tombe à zéro.
4Renvoyer les lignes de standup et les nouveaux poids pour la prochaine exécution. prompts/report.md rédige la version
5prose quand une clé est définie.

Les deux prompts qui tournent chaque matin

Chaque prompt de construction ci-dessus tourne une fois. Ces deux-là tournent sur chaque compte, chaque jour, donc ce sont ceux à conserver et à ajuster. Le jugement et la voix vivent ici, dans des fichiers simples, pas enfouis dans du code.

Le prospector juge sur celui-ci :

1RÔLE  Vous êtes la couche de jugement du prospector. Pour un compte, décidez si un signal d'achat mérite
2d'être actionné maintenant, et comment.
3ENTRÉE  { icp, new_signals: [{bucket, summary}], history, days_since_last_touch }
4SCORING  80-100 bon ajustement ICP et signal à haute intention (financement, ou deux regroupés) ; 50-79 bon ajustement,
5un signal solide ; 20-49 ajustement faible ou un seul signal à faible intention ; 0-19 hors ICP ou bruit
6RÈGLES  Moins de 7 jours depuis le dernier contact, préférez nurture ou skip, jamais first_touch. Si le signal est
7faible ou hors ICP, notez-le bas et ignorez ; dire non fait partie du travail. why_now doit citer le
8déclencheur réel, en termes qu'un représentant pourrait dire à l'acheteur.
9SORTIE (JSON uniquement)  { "score": 0-100, "why_now": "...", "play": "first_touch|follow_up|nurture|skip", "rationale": "..." }

Et il écrit sur celui-ci :

1RÔLE  Vous rédigez le message d'ouverture. Le signal est la raison pour laquelle vous contactez, et le message doit
2prouver que vous l'avez remarqué.
3ENTRÉE  { trigger, bucket, why_now, play, guardrails: {goal, must, never} }
4RÈGLES  Ouvrez la première phrase sur le déclencheur, jamais "Bonjour {{firstName}}". Reliez le déclencheur à un
5problème que vous résolvez, en une seule phrase. Terminez par une demande à faible friction. Phrases simples, longueurs variées,
6pas d'urgence factice, pas de tirets cadratins, pas de mots à la mode. Si le message aurait pu être envoyé inchangé le mois dernier, vous
7avez ignoré le déclencheur ; recommencez.
8SORTIE (JSON uniquement)  { "subject": "6-9 mots", "body": "3-5 phrases" }

Ce qui fait de cinq agents une équipe

Cinq agents, une mémoire partagée

Cinq scripts qui tiennent chacun leurs propres notes ne sont pas une équipe. Ce qui les transforme en une équipe est une seule mémoire partagée : un enregistrement par compte que chaque siège lit et écrit.

Le prospector enregistre un contact lundi. Le séquenceur le lit jeudi, voit aucune réponse, et envoie l'étape suivante. Le reporter le compte vendredi et repondère les catégories. Même enregistrement, une source de vérité. Construisez ce stock en premier, gardez ses noms de méthodes stables, et chaque siège s'appuie dessus au lieu de deviner.

Comment une seule personne le gère

Le standup matinal

Vous n'opérez pas ceci. Vous l'éditez, ce qui est un travail plus petit et très différent.

L'équipe tourne sur cron avant que vous soyez réveillé. Au moment où vous vous asseyez, le standup vous attend dans Slack : qui contacter aujourd'hui et pourquoi, une fiche pour chaque appel sur votre calendrier, les absents relancés, les chiffres de la semaine dernière repondérés par ce qui a réellement réservé. Deux minutes : approuvez, éditez, ou annulez.

Pas de liste à construire, pas de lignes d'objet à deviner, pas de réunion le lundi pour décider qui appeler. Toute l'équipe tourne pour environ 400 $ par mois en tokens, le coût opérationnel total du département. Ce qui reste est éditorial : avoir du goût sur ce que l'équipe met devant vous, et dire non à la plupart.

Là où les humains gagnent encore

Là où les humains restent

Cela ne gère pas l'intégralité du go-to-market, et les parties qu'il ignore sont les plus importantes. Les agents décident qui contacter et écrivent la première ligne. Ils ne concluent pas, et ils ne construisent pas la relation qui fait qu'un acheteur vous choisit un an plus tard, quand le budget arrive enfin.

Quand une réponse revient avec une vraie question, une hésitation, un discret « nous ne sommes pas sûrs que ce soit pour nous », c'est une conversation humaine, et elle doit le rester. Le système est très bon pour vous faire entrer dans la pièce. Il n'a rien à dire une fois que vous y êtes.

Donc les personnes que vous auriez dépensées sur le travail de routine vont là où elles ont toujours eu plus de valeur : l'appel, la confiance, la conclusion. L'équipe rachète les heures qui disparaissaient à décider qui méritait un appel, et les consacre aux conversations qui décident des deals.

Prenez l'équipe

J'ai emballé le tout dans un dépôt que vous pouvez cloner et exécuter : les cinq sièges, la mémoire partagée sur laquelle ils tournent, les prompts qui portent le jugement et la voix, et le standup qui les relie.

1gtm-team/
2  team/     prospector · researcher · sequencer · recoverer · reporter
3  core/     memory · models · adapters · llm
4  prompts/  judge · draft · brief · report
5  config/   icp · sequences · signals · team
6  run.py    the morning standup

C'est une version fonctionnelle, pas la stack interne que nous faisons tourner chez Sortlist. Le siège prospector est le gtm-brain du dernier article. Voici l'équipe autour de lui.

Commentez TEAM et je vous l'enverrai. Suivez-moi pour que le DM passe.

Si vous préférez le faire tourner pour vous plutôt que de le câbler vous-même, c'est MAX : la même idée avec les coutures cachées. Un agent avec qui vous parlez, qui surveille les signaux, exécute les séquences par email et LinkedIn, et vous remet le standup, soutenu par dix ans de données d'appariement acheteur-vendeur que vous ne pouvez pas tirer d'une API publique. Visitez : yourmax.ai