Comment nous avons construit la fonction GTM Engineering de Clay

La plupart des entreprises voient les opérations GTM comme une fonction de soutien : quelqu’un qui nettoie les données Salesforce, configure des séquences, voire crée un ou deux tableaux de bord. Chez Clay, on a choisi une autre voie dès le départ.

Chez Clay, GTM Engineering est au cœur de notre approche go‑to‑market. L’équipe rend compte directement à notre cofondateur Varun, aux côtés de la première ligne de direction sous les fondateurs. Elle fonctionne comme une équipe d’ingénierie produit, avec des sprints, du contrôle de version et des notes de version. Elle a aussi automatisé une grande partie de notre processus commercial tout en maintenant les systèmes qui alimentent à la fois nos offres en libre‑service et nos ventes dirigées.

Merci d’avoir lu The GTM Engineer de Clay ! Abonnez‑vous gratuitement pour recevoir les nouveaux articles et soutenir mon travail.

Voici comment nous l’avons structuré, pourquoi cela fonctionne, et ce que nous avons retenu en construisant une infrastructure GTM à grande échelle.

En bref :

• Clay divise GTM Engineering en deux équipes : des ingénieurs déployés sur le terrain qui travaillent avec les clients, et des ingénieurs internes qui conçoivent et maintiennent toute l’infrastructure GTM.
• L’équipe interne travaille en sprints de deux semaines, avec contrôle de version et notes de version, et considère les Clay Tables et les workflows Clay comme du code.
• GTM Engineering rend compte directement à un co‑fondateur, pas à un VP des ventes ou du RevOps, ce qui donne à l’équipe l’autorité de prendre des décisions architecturales sans les contraintes politiques du service.
• Le premier recrutement GTM d’une entreprise devrait être un ingénieur GTM, avant même le premier AE, en commençant par bâtir une liste d’or claire des Comptes cibles.

Deux types d’ingénieurs GTM

Nous avons scindé GTM Engineering en deux équipes distinctes :

• Ingénieurs GTM déployés sur le terrain travaillent directement avec les client·e·s. Ils aident les Prospect·e·s à évaluer Clay, à définir les implémentations et à créer leurs cas d’usage spécifiques. Beaucoup viennent des équipes ops ou growth avant de rejoindre Clay.
• Internal GTM Engineers construisent et maintiennent toutes nos opérations internes. L’équipe travaille sous la direction d’Osman Sheikhnureldin et gère tout, de l’automatisation des deals à la génération des QBR, en passant par les flux de travail des partenariats. Elle soutient nos équipes expérience client, marketing, growth et partenariats. C’est l’équipe à laquelle on pense quand on parle d’« ops ».

Les deux équipes peuvent échanger leurs rôles si nécessaire. La différence principale réside dans le tempérament. Les personnes à l’aise avec l’ingénierie se tournent naturellement vers l’infrastructure interne. Celles qui préfèrent les podcasts et les échanges avec les clients sont déployées en première ligne.

La stack technique GTM Engineering

Notre équipe interne utilise quatre outils principaux : Clay, Snowflake, Salesforce et Gong. Slack complète la pile en tant qu’interface que nos GTME utilisent au quotidien.

Nous avons créé une application Slack que les GTME utilisent au quotidien. Elle leur permet de lancer des campagnes, de consulter les Signal, d’obtenir des recherches avant l’appel, d’accéder aux notes de réunion après l’appel et d’envoyer des relances, le tout sans ouvrir un autre onglet. L’équipe interne GTM Engineering assure la maintenance de l’application grâce aux flux de travail humains de Clay déployés sur notre instance Slack.

La simplicité, c’est ce qui compte. La plupart des entreprises se retrouvent avec plus de 15 outils dans leur stack GTM. Nous l’avons simplifiée, ce qui réduit le travail d’intégration et diminue les points de défaillance.

La philosophie : flexibilité dans les standards

Nous laissons les GTME choisir les outils de réunion qui leur conviennent. Certains utilisent Gong et Granola en même temps. D’autres se servent d’Attention pour leurs notes personnelles. Le paysage des outils de réunion évolue rapidement, et les préférences changent avec le temps. Imposer une façon de travailler finit par laisser des avantages de côté.

Nous avons bien une exigence ferme : les données doivent circuler vers Clay.

Par exemple, Gong fonctionne toujours parce qu’il s’intègre à notre infrastructure d’automatisation. Mais si quelqu’un veut ajouter Granola à son propre flux de prise de notes, c’est tout à fait acceptable, tant que la transcription et les informations clés arrivent là où notre équipe interne d’ingénierie GTM Engineering peut les transformer dans Clay. Les gens ont ainsi la liberté d’expérimenter.

Si vous vous limitez aux outils de base, vous profiterez d’une expérience optimale. Mais comme nous sommes Clay, vous pouvez aussi explorer de nouveaux outils qui vous attirent.

Fonctionner comme une équipe d’ingénierie

L’équipe interne GTM Engineering travaille en sprints de deux semaines. Les autres équipes de Clay soumettent des tickets — par exemple pour des demandes d’automatisation, des corrections de qualité de données ou de nouveaux besoins de workflow. L’équipe trie ces tickets, les regroupe en versions et les déploie deux fois par mois, avec des notes de version complètes.

Ils utilisent le contrôle de version pour leur travail. Les Clay Tables et les workflows de Clay sont traités comme du code. Ils tiennent à jour la documentation. Lorsqu’ils évaluent de nouveaux fournisseurs (nous examinons actuellement des outils d’accompagnement commercial IA), ils réalisent l’évaluation technique et assurent l’intégration.

Cette structure résout un problème que rencontrent la plupart des équipes ops : la file sans fin de demandes ponctuelles. En regroupant le travail en sprints, l’équipe peut se concentrer sur des projets d’infrastructure plus ambitieux tout en traitant les requêtes quotidiennes. En publiant les notes de version, le reste de l’entreprise sait ce qui est déployé et quand.

Ce que les ingénieurs GTM construisent réellement

L’automatisation que nous avons déployée se classe dans plusieurs catégories :

• génération de contenu : Notre équipe stratégie croissance (post‑vente) reçoit automatiquement des decks de passation dès qu’une affaire se conclut. On extrait les données de consommation de crédits depuis Snowflake, les enregistrements d’appels de Gong et les informations de **Compte** depuis Salesforce. Tout ça est transformé en une présentation Google Slides qui se publie avant l’appel de lancement. On fait la même chose pour les QBR maintenant. Le deck se construit à partir des données d’usage et de l’historique des conversations. L’équipe croissance se contente d’arriver et de présenter.
  
• Automatisation de suivi : Après les appels de découverte, le système rédige les e‑mails de suivi à partir de la transcription. Nous avons largement résolu ce problème à ce stade.
  
• Flux de travail basés sur le Signal : Les GTME externes reçoivent des notifications sur Slack quand les comptes franchissent certains déclencheurs : habitudes d’utilisation du produit, signaux d’intention, étapes clés du contrat. L’application Slack met en avant ces moments et incite à l’Action appropriée.
  
• Opérations de pipeline : Tout le quotidien du routage des leads, de l’enrichissement des données, de l’attribution des territoires. Mais comme l’équipe travaille en sprints, avec des priorités claires, ces tâches ne freinent pas l’automatisation à forte valeur.

La prochaine frontière est plus ardue. Passer d’un bon e‑mail de relance à un excellent, et le faire de façon constante sur plusieurs mois de processus de vente tout en construisant un deck complet au fur et à mesure, c’est un problème du 90ᵉ‑95ᵉ percentile. Il en va de même pour extraire des informations de multiples appels et les transformer en propositions, fiches d’une page ou brouillons d’études de cas qui sonnent vraiment comme le travail d’un humain qui comprend le business du client. On travaille sur tout ça dès maintenant.

Pourquoi cette structure fonctionne pour Clay

Clay est à peu près partagé à parts égales entre le libre‑service et l’approche commerciale. Cette répartition engendre de la complexité.

Du côté libre-service, tout fonctionne grâce à une automatisation pure. Aucun humain n’intervient sur ces accords tant qu’ils ne sont pas prêts à s’étendre. Du côté des ventes, on adopte une approche d’entreprise classique, avec des GTMEs déployés sur le terrain, des appels de découverte et Multi-threading.

Une grande partie de l’activité en haut de l’entonnoir de notre business orienté ventes se déroule en réalité dans notre base de clients en libre‑service. Un·e utilisateur·trice commence à utiliser Clay de façon autonome, en retire de la valeur, puis le fait adopter par son entreprise. L’équipe interne d’ingénierie GTM possède les systèmes qui identifient ces opportunités d’expansion et les orientent correctement.

Cela signifie qu’ils ne peuvent pas se contenter de soutenir uniquement l’équipe commerciale ou l’équipe growth. Ils doivent assurer l’infrastructure des deux mouvements et créer le lien entre elles.

En ce moment, faire passer les clients de l’auto‑service à une approche dirigée par les ventes n’est pas aussi fluide qu’on le voudrait. C’est une priorité majeure pour l’entreprise. Le fait qu’une même équipe gère les systèmes des deux côtés simplifie l’amélioration de cette transition.

Applicabilité au‑delà de la tech

Les gens pensent que Clay ne sert que les entreprises technologiques qui adoptent le PLG, mais imaginez ceci : Waste Management utilise Clay. C’est complètement hors de notre univers habituel de SaaS et d’acheteurs tech. Pourtant, le cas d’usage était solide comme le roc. La flexibilité de la plateforme permet à l’ingénierie GTM, en tant que discipline, d’intervenir dans différents secteurs et modèles de vente. Vous n’êtes pas cantonné à un seul type de mouvement ou à un seul type d’acheteur.

L'organisation du reporting

L’ingénierie GTM Engineering interne relève de Varun, notre co‑fondateur et responsable des opérations. Elle travaille aux côtés des cadres qui dirigent les grandes fonctions, sans être reléguée sous un VP des ventes ou enfermée dans une organisation rev ops.

C’est important pour la priorisation. Si l’équipe qui construit votre infrastructure GTM a un accès direct à la direction fondatrice, elle peut prendre des décisions d’architecture sans être bloquée par la politique des départements.

Nous n’avons pas de structure CRO traditionnelle chez Clay. Aucun leader unique ne supervise les ventes, le marketing, le post‑vente et les opérations. La responsabilité des revenus est répartie. L’équipe growth gère le self‑serve. L’équipe commerciale s’occupe du sales‑led. GTM Engineering soutient les deux.

Cette structure fonctionne à notre taille actuelle (environ 100 M $ de chiffre d’affaires). Quand on passera à quelques centaines de millions, on devra probablement regrouper sous un CRO ou adopter un modèle à plusieurs CRO comme chez Stripe. Mais la fonction GTM Engineering restera proche du sommet de l’organigramme, quel que soit le réaménagement.

RevOps vs GTM Engineering

Nous avons toujours une fonction RevOps, mais elle est partagée entre GTM Engineering et la finance.

La finance gère les prévisions, fixe les objectifs du Pipeline et pilote la planification des ventes d’un trimestre à l’autre. Elle collabore avec GTM Engineering pour aligner les chiffres et définir des objectifs à l’échelle de l’entreprise.

Tout ce qui concerne les systèmes, la qualité des données ou l’automatisation relève de GTM Engineering. Découpage des territoires, déploiement des séquences, création de tableaux de bord, évaluation des outils.

C’est une structure matricielle. Les objectifs de **Pipeline** sont définis par la finance, mais réalisés grâce à la collaboration de la croissance, du marketing et de **GTM Engineering**. L’équipe interne de **GTM Engineering** assure l’exécution. Cette organisation fonctionne parce que chaque équipe sait ce qu’elle doit faire. La finance se concentre sur les chiffres attendus. **GTM Engineering** se charge de l’infrastructure qui les rend possibles.

Outils au‑delà de la stack de base

L’équipe interne utilise Clay, Snowflake, Salesforce, Gong et Slack pour la plupart de son travail. Mais nous avons intégré quelques outils d’IA qui se sont avérés utiles.

• Dust agit comme une couche d’agent au‑dessus des informations de notre entreprise : Notion, Gong, Salesforce, tout Slack. Les équipes s’en servent pour poser des questions sur les processus internes, les conversations passées et le contexte client. La fonctionnalité la plus utilisée est la recherche Slack avec des renvois à d’autres discussions. Nous commençons à transférer les requêtes Dust récurrentes dans les workflows Clay. Dès que nous identifions des motifs dans les demandes, nous automatiserons ces questions précises. Il reste toutefois un grand nombre de questions ponctuelles où Dust fait toute la différence.
  ‍
  
• Crosby gère nos redlines contractuels. Elle assure la première passe de chaque négociation juridique. Dans bien des cas, les accords se concluent sans jamais passer par notre service juridique. Nous sommes passés de jours à quelques heures pour répondre aux redlines. L’équipe Crosby a fait un travail remarquable pour rendre les LLM fiables sur le langage juridique noir‑et‑blanc. Pas d’hallucinations, pas de clauses inventées. Atteindre ce niveau de fiabilité sur des documents juridiques est plus difficile qu’on le croit.
  ‍
  
• Granola and Gong fonctionnent tous les deux pendant les appels, selon les préférences des membres de l’équipe. Gong est la référence dans l’entreprise (il alimente toutes nos automatisations). Certains ajoutent Granola pour prendre des notes personnelles. Nous laissons les équipes choisir ce qui leur convient, tant que les données aboutissent dans Clay où l’équipe interne GTM Engineering les transforme.

Le défi du séquençage

Nous testons le (outil de) séquençage natif de Clay pour des messages à faible volume mais à fort impact. Il n’est pas encore prêt à gérer plus de 50 000 e‑mails par mois, mais pour les messages qui comptent (prospection stratégique, initiatives d’expansion, développement de partenariats), avoir tout le processus intégré dans Clay élimine beaucoup de friction.

Pour les Outbound, nous utilisons Gong Engage. Leur nouvelle API a changé notre façon de concevoir les séquences.

La nouvelle API Gong Engage vous permet de personnaliser chaque message et chaque ligne d’objet d’une séquence à plusieurs étapes, le tout en un seul appel API. Vous pouvez créer une séquence entièrement sur‑mesure pour chaque contact. Ce n’est pas une simple adaptation de Template avec des variables — c’est vraiment du sur‑mesure.

Pour les ingénieurs GTM, c’est une vraie avancée. Vous pouvez puiser des données où que ce soit, créer des messages ultra‑personnalisés avec les LLM, et lancer des séquences multi‑touch sans être limité par des Template. Chez Clay, on utilise cette API en interne, et elle est disponible comme Action dans Clay pour les clients qui conçoivent leurs propres workflows.

Là où les deals se concrétisent

Un truc qui ne figure pas dans Salesforce, c’est que la plupart de nos ventes aux dirigeants se passent sur iMessage.

Notre processus de vente vise à identifier l’acheteur décisionnaire et à récupérer son numéro de téléphone. Ensuite, un membre de la direction (moi‑même, notre Lead Becca Lindquist, ou nos cofondateurs Kareem et Varun) lui envoie un SMS directement. Nous planifions les appels, négocions les conditions et concluons les accords par texto. L’un de nos plus gros contrats cette année s’est déroulé entièrement via les messages privés Slack. Il n’est pas non plus synchronisé avec Salesforce.

Cela crée un fossé entre notre infrastructure d’automatisation et le lieu où le travail se déroule réellement. Nos systèmes tournent autour de l’email, de Salesforce et de Gong, mais les vraies conversations se passent sur iMessage, WhatsApp et les DM Slack.

Nous n’avons pas encore résolu ce problème. C’est manuel : j’ajoute les contacts à mon téléphone, je copie leurs numéros et j’envoie les messages depuis iMessage sur mon ordinateur. Rien ne se synchronise avec nos systèmes.

La même chose se produit avec Slack. Slack est un produit Salesforce, mais les conversations en DM sur Slack n’apparaissent pas dans les enregistrements Salesforce. Il faut encore travailler sur l’infrastructure, et celui ou celle qui résoudra le problème du canal DM débloquera un avantage réel.

Quand faire appel à un ingénieur GTM

Si on repartait de zéro aujourd’hui, la première embauche GTM serait un ingénieur GTM. Avant le premier AE. Sans doute avant de constituer une équipe rev ops complète. (Et si vous êtes curieux, nous avons un guide complet sur comment pour embaucher un ingénieur GTM ici.)

Vous les associeriez à un AE fondateur et à un ingénieur solutions ou à un ancien client qui connaît le domaine. Ensuite, vous feriez appel à une agence Outbound pour gérer le volume. Cette équipe pourrait vraiment faire la différence en détectant le premier Signal et en posant les bases de l’échelle.

Le premier projet de cet·te ingénieur GTM : créer la liste d’or.

Voici la sélection de comptes qui vous ferait vibrer si vous obteniez une introduction magique demain. Chaque compte dispose des bons contacts, d’informations à jour et d’une raison claire expliquant pourquoi il a été retenu.

La plupart des entreprises n’ont pas ça. Elles commencent à vendre, accumulent une liste de Compte désordonnée, puis, six mois plus tard, quand il faut découper les territoires, elles se rendent compte qu’elles ne savent pas vraiment comment structurer leur marché. Résultat : Compte en double, segmentation floue et territoires qui n’ont aucun sens.

Commencer avec une architecture de compte claire simplifie tout quand vous passez à l’échelle. Vous connaissez vos segments. Vous connaissez votre profil client idéal. Vous pouvez créer des territoires de façon logique, car vous maîtrisez la forme de votre marché.

L’aspect itératif de GTM Engineering est le plus précieux au départ. Vous pouvez tester de nouvelles approches chaque jour, sans vous battre contre la dette technique ou l’inertie organisationnelle. Plus tard, la fonction reste cruciale, mais vous travaillez autour des contraintes plutôt que de partir d’un terrain vierge.

Et ensuite ?

Nous avons présenté plusieurs nouveaux produits lors de notre conférence Sculpt : Sculptor, le (outil de) séquençage natif, Audience. La plupart de ces fonctionnalités sont encore en cours de déploiement chez les clients, ce qui signifie que l’équipe interne d’ingénierie GTM travaille activement à créer les flux de travail qui exploiteront ces nouvelles capacités.

La génération de contenu est la nouvelle frontière. L’écart entre un simple suivi et une proposition qui synthétise des mois de conversations, c’est là où nous intervenons.

Nous surveillons de près l’espace des interfaces de vente. Le modèle où les GTME externes sautent d’un onglet Chrome à l’autre touche à sa fin. Ce qui le remplacera sera probablement une vue unique que les agents et les équipes opérationnelles pourront piloter en arrière‑plan. Nous construisons cet avenir, même si nous ne savons pas encore à quoi ressemblera l’interface finale.

GTM Engineering travaille chez Clay parce que nous le traitons comme de l’ingénierie. Une responsabilité claire, des livraisons en sprint, le contrôle de version, des notes de version. L’équipe dispose de l’espace nécessaire pour construire une vraie infrastructure plutôt que de courir après les urgences.

La structure de reporting leur donne le pouvoir de prendre des décisions architecturales. La stack technologique reste suffisamment simple pour qu’ils comprennent l’ensemble du système. Et le travail qu’ils font (générer des decks, automatiser les suivis, router le Signal) impacte directement le chiffre d’affaires, de façon mesurable par tous.

Vous n’avez pas besoin d’être une entreprise de plateforme de données pour appliquer ce guide. Vous devez croire que l’infrastructure GTM mérite la même rigueur que l’ingénierie produit. Et il faut recruter des personnes qui savent construire, pas seulement administrer.

Commencez tôt. Gardez la pile serrée. Offrez à l’équipe de vraies pratiques d’ingénierie. Placez‑les près du sommet de l’organigramme.

C’est comme ça qu’on construit une infrastructure GTM qui s’adapte.

FAQ

Où GTM Engineering devrait‑elle faire rapport dans l’organisation ?

Chez Clay, GTM Engineering interne rend compte directement à un co‑fondateur, aux côtés des autres fonctions exécutives, et non sous un VP des ventes ou dans une organisation RevOps. Cette proximité avec la direction permet à l’équipe de prendre des décisions architecturales sans être bloquée par la politique départementale.

Qu’est‑ce que GTM Engineering ?

GTM Engineering consiste à concevoir et à entretenir les systèmes, les automatisations et l’infrastructure de données qui alimentent les actions de GTM. Chez Clay, cela englobe tout, de l’automatisation des deals et des flux de travail basés sur les Signal à la création de decks QBR et à la gestion du Pipeline, le tout avec la même rigueur que l’ingénierie produit.

Comment GTM Engineering se connecte à RevOps ?

Chez Clay, les responsabilités RevOps sont partagées entre GTM Engineering et la finance. La finance gère les prévisions et les objectifs de Pipeline. GTM Engineering s’occupe des systèmes, de la qualité des données, de l’automatisation, de l’évaluation des outils et de l’infrastructure d’exécution. Les deux équipes ont des champs d’action bien définnés et collaborent pour s’aligner sur les chiffres et la livraison.

Quand faut‑il embaucher son premier ingénieur GTM ?

Avant votre premier AE, le premier ingénieur GTM doit créer une architecture de compte claire (la « golden list »), définir la segmentation ICP et poser les bases de l’infrastructure avant que le volume de ventes ne rende les corrections plus difficiles. L’aspect itératif de la GTM Engineering est le plus précieux lorsqu’on part d’une feuille blanche, pas lorsqu’on doit contourner des contraintes déjà en place.

‍