.avif)
Quand un·e représentant·e de Clay recherche un compte inactif, rédige un e‑mail à froid, envoie un cadeau à un·e prospect ou score une société de capital‑investissement, on n’ouvre pas Clay pour le faire. On ouvre Claude ou ChatGPT connectés au MCP de Clay.
Clay continue de faire le travail en coulisses : l’enrichissement, le scoring, les recherches de données, l’orchestration. Les équipes commerciales n’ont jamais à quitter l’outil d’IA dans lequel elles évoluent déjà.
Le risque (et le gain) de mettre l’IA à la portée de tous
Le risque de la vente assistée par l’IA, c’est que chaque commercial l’utilise à sa façon. L’un passe une heure à créer des prompts au lieu de décrocher le téléphone. Un autre envoie un e‑mail avec une affirmation juridique jamais validée. Un troisième conçoit un workflow qui impressionne, mais qu’on ne peut ni reproduire ni mesurer. Ce qui ressemble à un gain de productivité n’est en réalité qu’une incohérence à grande échelle. Faites‑nous confiance, on est passés par là.
Le modèle d’exploitation qui fonctionne le mieux est une construction centralisée pour un usage décentralisé. Nos équipes ops et GTM Engineering conçoivent la logique, créent les fonctions dans Clay et en définissent le comportement. Les commerciaux n’ont pas besoin d’écrire des prompts compliqués. Ils tapent une phrase dans l’outil qu’ils utilisent déjà — Claude ou ChatGPT — et Clay MCP la dirige vers la fonction adéquate. Le traitement se fait en arrière‑plan, sur l’infrastructure maîtrisée par l’équipe.
Les commerciaux passent plus de temps à discuter avec des humains, pas avec l’IA. Le résultat reste toujours conforme à la marque, juridiquement sûr et aligné sur le message. Quand le play s’améliore, l’équipe ops met à jour la fonction une fois, et chaque commercial exécute automatiquement la version améliorée.
Voici quatre actions que nous exécutons ainsi.
Clay Play 1 : Réactiver un compte mort sans quitter le chat
Michaela Pandorf, ClayDR
Quand une transaction devient obscure, le pire, c’est de faire de l’Outbound à l’aveugle. Michaela a mis au point une compétence de Prospect qui donne aux commerciaux l’historique complet du Compte dès le départ.
Elle confie à Claude un compte à étudier. La fonctionnalité effectue une recherche structurée via Clay Audiences et MCP, puis classe le compte : chaud, froid ou réchauffage en statut fermé‑perdu, et partage un brief avec le commercial. Par exemple, un compte est arrivé l’an dernier grâce à une publicité LinkedIn, a discuté des tarifs, a perdu son CMO, puis s’est tus avant d’être classé comme fermé‑perdu. Clay le tague comme compte de réchauffage, confirme qu’aucune opportunité ouverte ne bloque la prise de contact, et signale que quelqu’un s’en occupe déjà.
Ensuite, elle demande la meilleure façon de revenir. Claude indique l’ancienne annonce LinkedIn comme introduction et rédige le premier mail à partir d’un Template créé par un·e collègue. Les champions d’origine ne sont plus là, alors elle utilise Clay pour en dénicher de nouveaux, en les croisant avec le CRM via Audiences afin de ne faire apparaître que les personnes qui n’y sont pas déjà. Neuf contacts nouveaux, aucun doublon.
La dernière étape : renvoyer ces contacts dans le CRM avec des e‑mail et des numéros de téléphone enrichis. Et tout ça, sans quitter le chat.
Clay Play 2 : Rédiger un e‑mail à froid à partir du contexte réel d’un compte
Luca Prando, GTM Ops
La plupart des rédactions d’emails IA gaspillent votre meilleur atout. Vous demandez « un e‑mail », et le modèle invente le contexte à partir de rien, alors que tout ce que vous savez sur le contact se trouve dans votre CRM. Le générateur Outbound de Luca ne prend qu’une seule entrée : une adresse e‑mail. Il fonctionne uniquement sur les contacts déjà présents dans le CRM, délibérément, pour s’appuyer sur un contexte de première main que vous avez vérifié, et non sur des suppositions tierces.
Claude active la fonction via Clay MCP, trouve le contact dans Salesforce et lance des requêtes Snowflake sur le contact et le compte : résumé de l’engagement, Score d’engagement produit, Score Signal, adéquation du compte et cas d’usage des clients similaires. Il lit aussi la persona et l’ancienneté, de sorte qu’un·e manager RevOps et un·e VP des ventes obtiennent des points de vue différents.
Ensuite, il rédige trois versions :
- Le premier s’ouvre avec une observation pertinente tirée du contexte du Compte et de son activité.
- Le second récupère une vraie étude de cas Clay, avec un Claygent qui parcourt notre page d’études de cas pour identifier le client le plus proche selon des mouvements GTM similaires, des points de douleur ou l’impact recherché.
- Le dernier s’appuie sur une actualité récente de l’entreprise, comme une nouvelle levée de fonds, un investissement majeur ou un communiqué public. L’e‑mail apparaît opportun et montre que nous avons fait nos recherches.
Les trois atterrissent dans le rédacteur d’e‑mail sous forme de brouillons étiquetés. Le commercial les modifie directement, demande à Claude de les rendre plus détendus, puis les envoie.
L’équipe GTM Ops possède la fonction. Les commerciaux ne font que la déclencher. Quand la logique de messagerie change, elle se met automatiquement à jour pour tous les commerciaux.
Clay Play 3 : lancer une campagne de cadeaux en un seul prompt
Emily Chen, Responsable Growth
Offrir peut être très efficace, mais si la logistique n’est pas gérée, c’est un coût perdu énorme. Il faut le bon Compte, le bon cadeau, la bonne adresse et le bon message à chaque fois. Emily a résumé tout ça en une phrase.
Un représentant ouvre Claude et tape : envoyer un cadeau aux comptes où j’ai un Pipeline ouvert. Claude renvoie les comptes correspondants. Le représentant approuve ceux qu’il veut. La fonction s’occupe du reste.
Il rédige une note adaptée au cadeau et au destinataire, trouve l’adresse la plus pertinente (en triangulant le bureau où la personne travaille le plus souvent), récupère le cadeau chez les fournisseurs approuvés, puis l’expédie via Sendoso, auquel Clay se connecte nativement. Dès que l’envoi est lancé, le commercial reçoit une notification Slack.
Les représentants n’ont plus besoin de mettre à jour les CSV ni de demander maladroitement l’adresse postale des Prospects. La campagne se lance sans que personne n’intervienne en plein milieu, et l’équipe suit les dépenses de cadeaux ainsi que leur impact sur le Pipeline.
Clay Play 4 : Constituer un portefeuille de capital‑investissement avant la réunion
Bruno Radice, GTM Ops
Notre équipe partenariats mène une démarche de capital‑investissement. Trouver des fonds de private equity, c’est simple. Identifier ceux qui correspondent vraiment à une rencontre, c’est le vrai défi.
La recherche est le goulot d’étranglement. Avant la réunion, on se contente souvent de Google et de quelques requêtes d’IA, ce qui est lent et irrégulier. Les données essentielles – propriété du capital‑investissement, sièges au conseil, qui a soutenu qui – sont enfouies dans les recoins du web, voire pas du tout publiques.
Alors, Bruno a créé deux fonctions que Claude déclenche via Clay MCP, s’appuyant sur PitchBook pour récupérer les données que l’internet ne fournit pas : sociétés du portefeuille, sièges au conseil, investisseurs, partenaire de l’opération. Si l’entreprise n’est pas encore dans Salesforce, le flux Enrichir l’entreprise d’abord. Ensuite, il Score le portefeuille en appliquant des modèles aux comptes Salesforce pour estimer la valeur potentielle du contrat, afin que l’équipe identifie les sociétés du portefeuille à cibler.
Un·e commercial·e demande à Claude d’évaluer une entreprise avant la réunion de demain. Claude renvoie le Score, récupère le détail du portefeuille sur demande et le présente sous forme de visuels et d’un document Notion. Le·la commercial·e arrive avec une vraie couche de données, pas une pile d’onglets de navigateur.
Construisez une fois, utilisez‑le partout
Quatre cas d’utilisation différents pour les commerciaux, quatre approches différentes, mais la même structure sous‑jacent : les ops et GTME construisent la fonction, les commerciaux l’activent et obtiennent des résultats prévisibles à chaque fois. Le résultat ? Les commerciaux gagnent du temps pour créer des relations avec leurs prospects au lieu de devoir dépanner un workflow.
La cohérence, c’est le deuxième pilier, et c’est plus difficile à reproduire qu’on le croit. Les e‑mails sont envoyés en phase avec le message, les cadeaux respectent la liste des fournisseurs approuvés, et l’Outbound suit les meilleures pratiques de conformité. Quand chaque·e représentant·e construit son propre workflow Claude à partir de zéro, rien de tout cela n’est garanti et rien n’est auditable.
Quand un workflow doit être affiné, il n’y a qu’un seul endroit à consulter. Quand ça fonctionne, vous le mettez à jour une fois, et chaque commercial utilise la version améliorée dès le lendemain, sans besoin de re‑formation.
Envie de voir les workflows complets ? Regardez le livestream où l’équipe GTM de Clay vous montre la construction de bout en bout.
FAQ
Pourquoi passer ces scénarios par Claude ou ChatGPT plutôt que directement dans Clay ? Parce que c’est là que les commerciaux travaillent déjà. Clay MCP relie Clay aux deux outils, de sorte qu’un commercial saisit sa requête dans l’interface qu’il préfère et la fonction correspondante s’exécute en arrière‑plan. Il obtient les données et la logique de Clay sans devoir apprendre une nouvelle interface. Le vrai atout, c’est la gouvernance : les équipes ops définissent ce que chaque fonction peut faire, quelles données elle touche et comment le résultat est présenté. Les commerciaux avancent rapidement, les garde‑fous étant déjà en place.
Comment la bonne fonction est‑elle appelée depuis une invite simple ? Clay MCP lit l’intention dans l’invite et la dirige vers la fonction correspondante. Un commercial qui écrit « écrire un e‑mail contextualisé pour [contact] » ne sélectionne pas la fonction dans un menu. MCP reconnaît la demande et exécute la fonction appropriée sur le dossier du contact.
Qu’est‑ce qui empêche les commerciaux de casser un workflow ou de consommer tous les Crédits ? Les ops décident quelles fonctions sont exposées, définissent les budgets de Crédits par commercial ou équipe, et suivent chaque appel. Les commerciaux exécutent une logique validée sans toucher à l’infrastructure, ils avancent vite et les ops maintiennent les garde‑fous. Une fonction peut être testée avant d’être déployée à l’échelle de l’entreprise.
Pourquoi le générateur d’emails ne fonctionne-t-il que sur les contacts déjà présents dans le CRM ? L’idée, c’est d’écrire à partir de données vérifiées, pas d’hypothèses. Les Signal de première main – résumé d’engagement, usage du produit, adéquation du Compte – sont dans Salesforce et Snowflake, et ils sont bien plus fiables que du contenu scrappé à froid. Si le contact n’est pas dans le CRM, il n’y a aucune donnée de première main pour ancrer l’email.
Les équipes en dehors de Clay peuvent-elles créer les mêmes scénarios ? Oui. Tout fonctionne avec les mêmes primitives que chaque client de Clay possède : Data Marketplace, Claygent, Audience, Functions et MCP. Les scénarios sont propres à notre méthode de vente, mais leur construction est accessible aux clients de Clay.
.png)
.avif)
.avif)
.avif)
