Clay und Make verbinden: Enrichment-Pipelines bauen

Warum Clay und Make zusammen

Die meisten Enrichment-Setups scheitern an einer Stelle: dem CSV-Export. Du ziehst eine Liste aus Clay, lädst sie runter, öffnest Excel, sortierst die Bounces raus, lädst sie in Instantly hoch. Pro Liste 20 bis 40 Minuten Handarbeit. Und der Datensatz ist alt, sobald er in der Sequenz landet.

Clay ist ein exzellentes Enrichment-Tool. Waterfall über mehrere Anbieter, Mail-Validierung, Firmen-Daten, ein KI-Agent für Freitext. Was Clay nicht gut kann, ist der Rest: sauber auf Trigger von außen reagieren, mehrere Ziele parallel bedienen, geplant laufen, Fehler abfangen. Genau da kommt Make ins Spiel. Make ist die Steuerzentrale, Clay der Enrichment-Motor.

„Clay macht das Anreichern, Make macht das Drumherum. Wer versucht, die ganze Automation in Clay zu pressen, baut sich Table-Formeln zusammen, die nach drei Monaten niemand mehr versteht."

Nach rund 40 Setups mit dieser Kombination ist das Muster immer gleich. Sobald du zwei Dinge willst, einen Trigger der nicht in Clay startet und ein Ziel das nicht Clay ist, brauchst du Make dazwischen. Ein neuer Deal im CRM, ein Reply in Instantly, ein Formular auf der Website: das sind externe Trigger. Und ein CRM-Feld zurückschreiben, einen Slack-Alert senden, drei Kontakte gleichzeitig in verschiedene Kampagnen legen: das sind mehrere Ziele. Beides ist Make-Terrain.

Der schöne Nebeneffekt: du zahlst zweimal getrennt und siehst genau, wo das Geld hingeht. Clay-Credits fürs Anreichern, Make-Operations fürs Orchestrieren. Die Make-Ops sind fast geschenkt, der Kostentreiber ist immer Clay. Dazu unten mehr.

Die 3 Verbindungswege

Bevor wir Pipelines bauen, drei Wege wie Clay und Make überhaupt miteinander reden. Jede Pipeline unten nutzt eine Kombination daraus. Wer die drei Richtungen verstanden hat, kann sich jede beliebige Pipeline selbst zusammenstecken.

Weg A: Clay pusht per Webhook

Du legst in Make ein Custom-Webhook-Modul an, kopierst die generierte URL und trägst sie in Clay in eine HTTP-API- oder Send-Webhook-Spalte ein. Sobald eine Zeile durch das Enrichment ist, schickt Clay den kompletten Datensatz als JSON an Make. Wichtig: setze in Clay einen Filter davor, zum Beispiel „Email is not empty", sonst pusht Clay auch halbfertige Zeilen und Make bekommt Datenmüll.

Weg B: Make schreibt per API in Clay

Der umgekehrte Weg. Make bekommt einen Trigger von außen und legt über die Clay-API eine neue Zeile in einer Webhook-Source-Table an. Clay startet das Enrichment automatisch. Weil Clay asynchron arbeitet, bekommst du das Ergebnis nicht im selben Make-Lauf zurück. Der saubere Weg ist Weg A als Rückkanal: Clay schickt die fertige Zeile an ein zweites Make-Szenario.

Weg C: Make ruft die Provider direkt

Nicht jede Aufgabe braucht Clay. Wenn ein einzelner Anbieter reicht und du keine Waterfall-Logik brauchst, ruft Make die Provider-API direkt per HTTP-Modul. Für Mail-Finding zum Beispiel Bettercontact oder Apollo. Das spart die Clay-Credits, kostet dich aber die Waterfall-Sicherheit. Faustregel: Single-Provider und simpel gehört zu Weg C, Multi-Provider und Match-Rate zählt gehört zu Clay.

Pipeline 1: Neue Leads bis Instantly

Die häufigste Pipeline und der beste Startpunkt. Ziel: eine frisch importierte Liste läuft ohne einen Klick durch Enrichment, Validierung und direkt in die Kampagne.

Der Ablauf Schritt für Schritt

Import: eine Apollo-Suche oder eine gekaufte Liste landet in einer Clay-Tabelle. Clay startet die Waterfall-Spalten: erst ein günstiger Provider, bei Miss der nächste, dann Mail-Validierung. Am Ende der Kette steht eine HTTP-Spalte mit deinem Make-Webhook (Weg A), aber nur mit Filter auf valide Mail. Make empfängt die Zeile, prüft die Confidence noch einmal, mappt die Felder auf die Instantly-Custom-Variables und ruft „Add Lead to Campaign".

Was du dir sparst: den CSV-Export, das manuelle Bounce-Sortieren, das Hochladen. Was du gewinnst: der Lead ist 2 bis 4 Minuten nach dem Import in der Sequenz. Bei 1.000 Leads pro Monat sind das rund 6 bis 10 Stunden Handarbeit weniger, und die Bounce-Rate bleibt sauber, weil die Validierung nie vergessen wird.

Ein Detail aus der Praxis: baue in Make einen Dedup-Check gegen deine Suppression-Liste, bevor du in Instantly schreibst. Sonst mailst du Kontakte doppelt an, die schon in einer anderen Kampagne laufen. Zwei zusätzliche Operations, spart dir peinliche Doppel-Mails.

Pipeline 2: CRM-Trigger mit Rückschreiben

Die Pipeline mit dem höchsten Aha-Effekt beim Kunden. Ein Datensatz im CRM füllt sich selbst mit Firmengröße, Tech-Stack, LinkedIn-URL und Mobile, sobald er angelegt wird. Kein SDR tippt mehr Pflichtfelder ab.

Warum das zwei Make-Szenarien braucht

Clay ist asynchron, das ist der Knackpunkt. Szenario 1 fängt den CRM-Trigger (neuer Deal oder Stage-Change) und schreibt per Clay-API eine Zeile in die Clay-Tabelle (Weg B). Dabei gibst du die CRM-Record-ID mit, damit du später weißt, wohin das Ergebnis zurück muss. Dann endet Szenario 1. Clay reichert an, das dauert Sekunden bis Minuten. Ist die Zeile fertig, schickt Clay sie per Webhook an Szenario 2 (Weg A). Szenario 2 nimmt die angereicherten Felder plus die mitgereichte Record-ID und schreibt alles zurück ins CRM.

Wer versucht, in einem einzigen Make-Lauf auf das Enrichment zu warten, baut sich eine Sleep-Schleife und verbrennt Operations für nichts. Der saubere Split in zwei Szenarien ist robuster und günstiger. Die Record-ID als roter Faden zwischen beiden ist der wichtigste Trick in der ganzen Pipeline.

Wann sich das rechnet

Ab dem Punkt, wo dein Sales-Team ins CRM tippt was Clay ohnehin weiß. Bei einem Team mit 200 neuen Datensätzen pro Monat und 3 Minuten manueller Recherche pro Datensatz sind das 10 Stunden, die verschwinden. Dazu die Datenqualität: automatisch angereichert ist konsistenter als handgetippt, und die Felder sind aktuell statt Monate alt.

Pipeline 3: Reply-Signal mit Re-Enrichment

Die Pipeline die aus einem Reply mehr macht. Wenn ein Interessent antwortet, ist das der wertvollste Moment im ganzen Funnel. Genau da verliert man Zeit mit LinkedIn-Recherche, bevor man antwortet. Diese Pipeline liefert den Kontext frei Haus.

Der Ablauf

Instantly feuert bei einem positiven Reply ein Webhook an Make. Make schickt den Kontakt zurück in Clay (Weg B), diesmal für ein tieferes Enrichment: aktuelle Rolle, Firmen-Signale wie frisches Funding oder Hiring, weitere Ansprechpartner im selben Account. Clay schickt das Ergebnis zurück (Weg A), und Make baut daraus ein kompaktes Slack-Briefing für den zuständigen SDR plus einen CRM-Eintrag. Der Rep sieht die Antwort und das Briefing zur gleichen Zeit.

Der Effekt ist unterschätzt. Statt 10 Minuten Recherche pro Reply geht der Rep sofort mit Kontext in die Antwort. Die erste Reaktion ist relevant, nicht generisch, und die Reply-zu-Meeting-Rate steigt spürbar. Wer viele Replies bekommt, spart hier mehr Zeit als in Pipeline 1.

„Ein Reply ist ein Timing-Signal. Wer im Moment der Antwort schon die aktuelle Rolle und die Firmen-News kennt, schreibt eine bessere zweite Mail als jeder, der erst googeln muss."

Operations und Clay-Credits: die Mathe

Jetzt zum Geld. Zwei Kostenblöcke, und der eine ist viel größer als der andere. Make-Operations kosten fast nichts, die Clay-Kosten sind der Treiber. Die folgenden Zahlen sind Richtwerte, Stand Juli 2026, und vor dem Kauf im Dashboard zu prüfen. Clay-Preise ändern sich häufiger als die Make-Tarife, zuletzt beim Pricing-Overhaul im März 2026.

Wichtig zu Clay seit diesem Overhaul: es gibt zwei Credit-Typen. Data Credits zahlst du für Enrichment-Daten aus dem Marketplace, Actions für Plattform-Operationen und Workflow-Schritte. Die reinen Datenkosten sind dabei deutlich gefallen. Der Free-Tier existiert weiter zum Testen. Die heutigen Pläne heißen Launch (rund 185 USD im Monat mit 2.500 Data Credits und 15.000 Actions) und Growth (rund 495 USD mit 40.000 Actions). Die alten Namen Starter, Explorer und Pro sind Legacy und laufen aus.

Make rechnet pro Modul eine Operation. Eine Pipeline mit 4 bis 7 Modulen verbraucht also 4 bis 7 Operations pro Datensatz. Bei 1.500 Datensätzen im Monat sind das rund 10.000 Ops, also der Pro-Plan für 16 USD. Der große Vorteil von Waterfall auf der Clay-Seite: du zahlst nur für Provider die auch drankommen. Findet der erste Anbieter die Mail, werden die späteren gar nicht mehr angefragt.

Die Zahlen zeigen das Grundmuster: der Make-Anteil ist zweistellig in USD, der Clay-Anteil dreistellig. Wer die Kosten drücken will, schraubt an den Clay Data Credits, nicht am Make-Plan. Das heißt konkret: früh filtern, bevor teures Enrichment läuft. Ein ICP-Filter direkt nach dem Import sortiert die 40 Prozent aus, die du ohnehin nicht anmailst, und die laufen dann gar nicht erst durch den Waterfall.

Zweiter Hebel: nicht jeden Kontakt maximal anreichern. Für Pipeline 1 reicht Work-Email plus Basis-Firmendaten, also wenige Data Credits pro Zeile. Das teure Deep-Enrichment mit Mobile und mehreren Fallbacks hebst du dir für Pipeline 3 auf, also nur für die Leads die schon geantwortet haben. Credits nach Interesse staffeln, nicht mit der Gießkanne verteilen.

Fehler-Handling und Rate-Limits

Der Teil, den die meisten weglassen und später teuer nachholen. Eine Pipeline ohne Fehler-Handling steht irgendwann still, und du merkst es erst wenn drei Tage lang keine Leads mehr durchkamen.

Clay ist asynchron, plane damit

Der wichtigste Punkt zuerst: warte nie im selben Make-Lauf auf ein Clay-Enrichment. Es dauert je nach Provider Sekunden bis Minuten. Immer per Webhook zurückschicken, nie mit einer Sleep-Schleife pollen. Wer pollt, verbrennt Operations und riskiert Timeouts.

Rate-Limits abfangen

Die Clay-API hat ein Rate-Limit. Wenn Make in einem Schwung 500 Zeilen pushen will, läufst du dagegen. Lösung: einen Iterator mit gedrosselter Rate oder eine kurze Sleep-Pause zwischen den Aufrufen. Instantly und die CRMs haben ebenfalls eigene Limits. Für die baust du in jedes External-Modul einen Error-Handler mit Auto-Retry, der bei einem 429-Fehler ein paar Sekunden wartet und es erneut versucht.

Der Standard-Error-Branch

Jedes Modul das eine externe API ruft, bekommt einen Error-Handler. Der macht zwei Dinge: er schickt einen Slack-Alert mit dem Fehler und der betroffenen Zeile, und er legt den Datensatz in eine Manual-Review-Liste, damit kein Lead lautlos verschwindet. Setup: 5 bis 10 Minuten pro Pipeline. Spart dir Tage Debugging, wenn ein API-Key abläuft oder ein Provider sein Schema ändert. Wer das nicht baut, betreibt eine Blackbox.

Ein letzter Punkt: sichere deine Make-Webhook-URLs ab. Ein Webhook das offen im Formular-Code steht, kann jeder mit Spam-Requests fluten und dir die Operations wegschießen. Ein Secret-Header plus ein Filter direkt nach dem Trigger reichen. Falls dir Make an irgendeiner Stelle zu eng wird, macht n8n dasselbe self-hosted, mit voller Kontrolle über Rate-Limits und Retries, dafür mit DevOps-Aufwand.

Clay-nativ vs Make dazwischen: wann was

Nicht jede Aufgabe braucht Make. Manchmal reicht Clay allein, und die zusätzliche Schicht macht das Setup nur komplizierter. Hier die Entscheidungs-Matrix.

Die einfache Regel: bleibt alles in Clay, bleib in Clay. Liste rein, anreichern, in eine Instantly- oder HubSpot-Spalte schreiben, fertig. Dafür brauchst du kein Make. Clay hat native Integrationen und kann eine fertige Zeile selbst in viele Ziele schreiben.

Make kommt in dem Moment dazwischen, wo einer von drei Fällen eintritt. Erstens: der Trigger startet nicht in Clay, sondern extern (CRM, Formular, Reply). Zweitens: du willst mehrere Ziele parallel bedienen oder verzweigte Logik mit einem Router. Drittens: du brauchst sauberes Scheduling und Fehler-Handling, das über Clays Table-Runs hinausgeht. Trifft keiner der drei zu, ist Make über-engineert.

Und n8n? Die Antwort ist einfach: gleiche Rolle wie Make, self-hosted. Wenn du ohnehin eine Infra-Kompetenz im Team hast, sensible Daten verarbeitest oder bei hohem Volumen die Pro-Ausführung-Kosten von Make drücken willst, ist n8n richtig. Für die meisten Sales-Teams ist Make der schnellere Weg, weil kein Server, keine Updates, kein Auth-Setup nötig sind und die Clay-, Instantly- und CRM-Module fertig bereitstehen.

Nach 40 Setups ist mein Rat: fang mit einer Pipeline an, Pipeline 1 aus diesem Artikel. Bau sie sauber mit Filter und Error-Handler, lass sie zwei Wochen laufen, dann kennst du deine echten Credit-Kosten und weißt, ob Pipeline 2 und 3 den Aufwand wert sind. Alles auf einmal zu bauen ist der schnellste Weg zu einem Setup, das niemand mehr wartet.

Häufige Fragen