Inside Clay Workflows : l’histoire de notre nouveau bâtiment primitif

Jusqu’à présent, Clay fonctionnait avec des tableaux. Chaque séquence que vous créiez, que ce soit pour enrichir une longue liste de comptes ou qualifier des formulaires de demande de démo, était rangée en lignes et colonnes. Ce design a bien servi : il gérait des tâches ponctuelles rapides comme des moteurs complets de routage Inbound. Mais les tableaux imposaient aussi un compromis qui s’est aggravé avec la croissance de nos clients : ils mêlaient données et logique sur la même surface. Les contacts et les entreprises que vous enrichissiez partageaient la même grille que les formules conditionnelles qui décidaient quoi exécuter et quand, si bien que tout était aplati. Une séquence ne pouvait voir que ce qui était dans cette grille, ce qui signifiait qu’un agent qui notait les comptes n’avait aucune visibilité sur l’appel Gong de la semaine dernière ou les données d’usage de votre entrepôt, à moins que quelqu’un n’ait pensé à les faire entrer dans une colonne.

Ça a changé la semaine dernière quand nous avons lancé Workflows en bêta ouverte pour tous les clients, tous plans confondus. C’est le plus grand changement dans la façon dont les clients construisent sur Clay depuis la table d’origine. Un workflow est un graphe visuel d’étapes connectées. Un déclencheur le lance, chaque enregistrement progresse dans les branches, une à la fois, et les résultats sont renvoyés dans votre couche de données Audience, la couche de données de Clay où toutes vos données first‑party et tier‑party sont réunies.

Notre PDG Kareem Amin pense que Workflows est l’avenir des systèmes GTM, et il expose son argumentaire dans le full livestream. Continuez la lecture pour découvrir les coulisses de la création de Workflows : pourquoi nous avons retiré l’orchestration des tables, le produit que nous avons failli développer à la place, et une démonstration de deux Workflows réels, dont un que notre équipe Growth utilise pour l’Inbound.

Les objectifs des flux de travail

Les équipes GTM utilisent Clay depuis des années pour piloter leurs actions go‑to‑market, toujours avec des tableaux. Mais à mesure que les clients ont imaginé des stratégies plus sophistiquées (et ingénieuses), nous avons dû choisir : investir davantage dans les tableaux ou créer une nouvelle interface réellement conçue pour l’orchestration.

Nous avions trois objectifs qui, finalement, nous ont guidés vers les Workflows :

Une approche visuelle avant tout pour construire

Le premier objectif de notre liste était de rendre l’orchestration traçable et adaptée aux équipes. Dans un tableau, vous voyez toutes les sorties. Mais la logique qui les génère est cachée dans des conditions « run‑if » et des formules réparties sur des dizaines de Colonne. Quand un imprévu survient, il faut décortiquer le tableau. C’est encore pire si vous n’avez pas créé ce tableau vous‑même. Nous avons entendu des utilisateurs qui ont hérité d’un tableau d’un collègue parti : ils n’avaient aucune stratégie de maintenance, si ce n’est « espérons que ça ne casse jamais ».

Les workflows placent la logique au premier plan. Le canevas de construction affiche chaque branche, de sorte que quiconque ouvre un workflow peut suivre le parcours des enregistrements. Chaque exécution consigne ce qui s’est passé à chaque étape, pas seulement le résultat final, ce qui vous permet de retracer le chemin exact d’un **Compte** ou d’un contact. Chaque modification du workflow est versionnée. Une fois que vous avez créé quelque chose, vous pouvez le diagnostiquer et le corriger sans deviner comment un enregistrement a été traité. Nous avons également conçu le canevas pour un second lecteur, afin qu’il soit lisible tant pour les personnes que pour les agents de codage qui travaillent à leurs côtés.

Une utilisation simple, quel que soit l’échelle

Ensuite, nous avions besoin de workflows capables de soutenir n’importe quel GTM Play qu’une équipe pourrait imaginer, ce qui impliquait de supprimer les limites intégrées des tables. Les anciennes restrictions existaient pour que les tables puissent trier et filtrer tout à l’écran, mais un workflow n’a pas besoin de cette contrainte. Les workflows n’ont aucune limite de lignes, aucune limite de colonnes, aucune restriction de taille de cellule et aucun plafond sur le nombre d’enregistrements qu’un GTM Play peut toucher. Vous pouvez créer des arbres de décision à embranchements aussi grands que nécessaire.

Il y avait aussi une limite logique dans les tables : les formules ne pouvaient aller que jusqu’à un certain point. Avec les nœuds de code, tu peux exécuter Python dans une séquence, ce qui ouvre des possibilités comme le scoring personnalisé des comptes, des règles de routage avec de nombreuses conditions, et des connexions à des outils hors de la bibliothèque d’Intégration de Clay.

Et comme Workflows repose sur Audience, un play dispose de tout votre contexte GTM, pas seulement de quelques champs. Tout ce qui se trouve dans Audience — enregistrements CRM, utilisation du produit, appels Gong, conversations Slack — est accessible à un workflow. Les plays peuvent s’exécuter sur des segments d’audience dynamiques et se déclencher dès qu’un enregistrement les rejoint.

Des builds plus rapides pour votre équipe

Le dernier point était la vitesse, car beaucoup d’entre vous nous ont dit que créer dans une UI peut être très lent. Workflows a été conçu pour que les agents puissent construire pour vous à partir du langage naturel, soit en mode headless via le Clay CLI depuis n’importe quel agent de code, soit de façon conversationnelle dans Clay grâce à Sculptor. Si vous avez utilisé le CLI lors de son alpha le mois dernier, vous utilisiez déjà déjà Workflows sans le savoir, puisqu’il alimente tout ce que le CLI crée.

C’est là que le choix visuel fait toute la différence. Les agents manipulent plus aisément des graphes que des grilles, et quand un agent crée quelque chose pour vous, le graphe est bien plus simple à vérifier. On s’attend à ce que les utilisateurs construisent rapidement en ligne de commande, puis passent en revue le résultat dans l’interface.

Les deux débats qui ont façonné les workflows

Ce que nous avons lancé cette semaine n’est pas le produit que nous avions prévu. Deux décisions majeures ont évolué en cours de route : le degré de contrôle donné aux agents, et la conservation ou non de la vue tableau.

Le produit uniquement destiné aux agents que nous avons presque construit

Le plan initial n’était pas du tout un outil de workflow. La prochaine interface d’orchestration dans Clay devait être centrée sur l’agent et entièrement déclarative. Vous décrivez le résultat souhaité, par exemple « réserver des réunions avec des Compte du marché », et un agent détermine les étapes et exécute le scénario complet. Petite anecdote interne : le nom de code était « Terracotta », parce que l’idée était d’avoir une armée d’agents dans Clay.

Mais nous continuions à rencontrer le même problème en avançant vers cette vision. Dans la plupart des cas d’usage GTM, vous savez déjà ce que should doit se produire et vous avez besoin que cela se passe de la même façon à chaque fois. Confier chaque étape à un agent cède le contrôle du processus, et transforme tout le déroulement en boîte noire. Les équipes doivent pouvoir auditer ce qui a été exécuté, surtout les plus grandes, et un produit entièrement piloté par un agent rendrait cela presque impossible. Cela nous ferait aussi ressembler à tous les autres outils d’agents du marché. De plus, c’est plus cher, car un modèle de langage est plus lent et plus coûteux qu’une étape que vous avez définie à l’avance. Savoir exactement ce que vous voulez voir se produire devrait signifier le faire à moindre coût avec des résultats constants.

Cette prise de conscience a tout changé. Aujourd’hui, les Workflows sont déterministes par défaut, et le raisonnement n’est ajouté que quand c’est nécessaire. A Claygent nœud introduit le jugement dans le flux de recherche ou de classification, gérant les parties qui demandent de l’interprétation tandis que le reste du processus reste fixe et reproductible. Le travail centré sur l’agent n’a pas disparu non plus, il arrive dans les Workflows sous forme d’Agents de compte (plus d’infos dans les semaines à venir).

Le revirement d’observabilité

Le deuxième renversement concernait la vue tableau elle-même. Les gens aiment voir toutes leurs données présentées en grille, mais notre plan initial pour les workflows n’incluait pas cette vue. Comme les résultats des workflows sont automatiquement stockés dans l’Audience, on pensait que la grille était superflue.

Nous avions mal compris l’utilité de la grille : le stockage ne représentait que la moitié. L’autre moitié, c’est l’observabilité, car parcourir une vingtaine d’enregistrements de sortie est la façon dont les équipes vérifient qu’un play fonctionne correctement. Quand il faut examiner un enregistrement en détail, on peut le suivre dans le workflow. Vous voyez le chemin emprunté par le **Prospect**, comment chaque branche a été choisie et la logique derrière les décisions de l’agent. Les premiers clients nous ont toutefois indiqué qu’ils souhaitaient toujours une vue d’ensemble. Nous avons donc réintégré le snapshot de données à travers les enregistrements dans les Workflows. Vous disposez maintenant des deux types d’observabilité : la trace granulaire d’un enregistrement individuel et la vue tabulaire sur de nombreux enregistrements. La CLI a ensuite poussé l’auditabilité encore plus loin que prévu. Il suffit d’insérer un lien vers n’importe quelle table ou workflow, de demander ce qu’il fait, et vous obtenez une explication claire de ce qui se passe. Cela aide énormément quand on reprend un play d’un collègue qui vient de partir.

Voyez les workflows se mettre en place

Regardez le livestream complet pour voir notre démonstration des Workflows. Nous avons créé un scénario de zéro avec cette fonctionnalité et ouvert un autre déjà en production chez Clay.

Cas d’utilisation #1 : d’une invite à un Inbound fonctionnel

La première démo a commencé avec une simple consigne d’une page décrivant une qualification de Lead Inbound, et, cinq minutes plus tard, elle livrait déjà un workflow exécutable dans Clay. Tout a été créé par un agent de codage, le plugin agent étant installé.

1. Le prompt détaillait un processus en cinq étapes pour qualifier et acheminer automatiquement les leads entrants selon leur niveau d’engagement et leur adéquation avec le profil client idéal de Clay : recevoir le Lead, vérifier s’ils ont visité le site plus de cinq fois au cours des trente derniers jours, Enrichir et noter l’entreprise, router selon le Score et le secteur, puis notifier le commercial ou disqualifier.
2. Le prompt a été envoyé à l'agent de codage, qui a ouvert le plugin Clay et a commencé à planifier la construction.
3. L’agent a lu le schéma d’Audience dans l’espace de travail, il savait donc sur quels champs faire correspondre les comptes et quelle logique de routage appliquer. En plus, il a repéré les Intégrations d’Enrichissement mentionnées dans l’invite.
4. Le workflow est maintenant dans Clay ! Il comprend un segment d’Audience qui alimente un déclencheur, une vérification d’engagement, l’enrichissement et le scoring, puis le routage avec une alerte Slack pour les comptes à fort potentiel.

Le processus de notation était un Claygent qui qualifiait chaque Lead selon les critères exacts de la consigne. L’alerte Slack provenait d’un nœud de code, qui formatait les coordonnées, la file d’attente suggérée et le raisonnement en un message que le commercial peut exploiter d’un seul coup d’œil. Les nœuds de code sont gratuits et déterministes, et ils remplacent largement les formules des tableaux. Chaque enrichissement et chaque Action issus des tableaux fonctionnent dans un workflow, tout comme les fonctions déjà créées par votre équipe.

Cas d’utilisation #2 : remplacer la table de 81 colonnes qui pilotait notre motion Inbound

La deuxième démo venait de notre propre équipe Growth. Quand quelqu’un crée un espace de travail Clay via MCP, que ce soit depuis Claude, ChatGPT ou Cursor, ce Lead était auparavant Score et acheminé via une table de 81 colonnes, ce qui demandait des heures de travail chaque jour pour la maintenir.

Le même processus s’exécute maintenant comme un workflow :

1. Un déclencheur repère chaque nouvel espace de travail créé via MCP.
2. Le workflow répartit chaque Lead sur un parcours orienté produit ou orienté vente selon nos critères internes.
3. Les Lead issus du produit sont dirigés vers Inflection, notre outil d’automatisation marketing, qui les inscrit dans des campagnes goutte orientées vers les cohortes Clay et de nouveaux cas d’usage.
4. Les Lead générés par les ventes sont vérifiés dans Salesforce, ce qui permet de reconnaître un contact existant et de créer un nouveau contact sans doublons.
5. Les règles de routage déterminent la propriété, vérifient les périodes de refroidissement des comptes, puis assignent le bon représentant.
6. Un nœud de code crée les e‑mails de prospection, et le workflow vérifie que le contact est joignable et n’est pas déjà dans une séquence active.
7. Les contacts qualifiés arrivent dans un flux Gong pour la prospection, et une campagne Salesforce suit l’attribution du marketing jusqu’à la vente.

Notre équipe Growth apprécie particulièrement ce qui se passe quand quelque chose se casse. Les nœuds en fin de workflow vérifient si une erreur s’est produite en amont, et les échecs sont publiés sur un canal Slack avec leurs explications. Un·e agent consulte ce canal chaque jour, corrige le workflow, puis recherche le même schéma de défaillance dans nos autres scénarios. Ainsi, notre moteur inbound s’auto‑entretenit au lieu d’attendre qu’un·e humain·e le remarque.

En plus, la vue des exécutions est entièrement recherchable : chaque entrée et sortie de nœud est indexée, donc taper le nom d’un contact fait apparaître son exécution, et le chemin mis en évidence indique les branches empruntées.

Les workflows sont à vous de faire évoluer.

Les flux de travail sont maintenant en bêta ouverte, sans frais supplémentaires au‑delà des **crédits** et des **actions** déjà consommés par le travail sous‑jacent. À plus long terme, nous ne cherchons pas à facturer chaque étape que vous exécutez. En interne, nous nous demandons simplement si **Clay** vous a apporté plus de clients et rendu vos équipes plus productives. Nos tarifs doivent refléter ces résultats, pas le nombre d’utilisations.

Les clients des forfaits Launch, Growth et Enterprise conservent un accès à vie, tandis que les anciens forfaits Starter, Explorer et Pro y ont accès jusqu’à la fin de l’année.

Il existe plusieurs façons d’y accéder, selon votre manière de construire.

• Partez d’un agent de codage. Prenez le plugin d’agent et collez les instructions de configuration dans Claude Code, Cursor ou Codex, puis décrivez le scénario que vous souhaitez.
• Commencez à l’intérieur de Clay. Ouvrez Open Workflows et discutez avec Sculptor, qui se développe à côté de la toile du produit.
• Convertir une table que vous maîtrisez déjà. L’option d’importation de table vous permet de reconstruire une table existante en tant que workflow, afin de voir le produit fonctionner sur des données en temps réel.
• Apprenez au fil de votre progression.Clay University propose toute la documentation et les vidéos nécessaires pour créer, déboguer et déployer des workflows.}

Pour voir les builds de ce post en action, visionnez l’enregistrement complet du livestream.