Make.com CRM-Syncs: HubSpot, Pipedrive, Salesforce

Warum CRM-Syncs kaputtgehen

Ein CRM-Sync ist in Make in zwanzig Minuten gebaut. Webhook rein, Suchmodul, Update-Modul, fertig. Genau deshalb sind so viele davon kaputt. Nicht laut kaputt, sondern leise: Dubletten, die niemand zählt, überschriebene Felder, die erst im Quartalsreport auffallen, und ein Ops-Verbrauch, der jeden Monat wächst, ohne dass mehr Datensätze durchlaufen.

Drei Fehler kommen dabei immer wieder vor, und alle drei entstehen in den ersten zwanzig Minuten.

Fehler 1: Matching über die E-Mail-Adresse

Der naheliegende Weg, und der mit der kürzesten Haltbarkeit. Die E-Mail-Adresse ist im B2B kein stabiler Schlüssel. Leute wechseln die Firma, Unternehmen stellen von vorname.nachname auf Kürzel um, derselbe Mensch existiert mit info-Adresse und persönlicher Adresse. Jedes Mal entsteht eine Dublette, und jede Dublette zerlegt die Historie, an der dein Rep später erkennen soll, ob dieser Kontakt schon angeschrieben wurde.

Fehler 2: Kein führendes System je Feld

Wer synchronisiert, ohne vorher festzulegen, welches System bei welchem Feld gewinnt, baut einen Zufallsgenerator. Die Telefonnummer aus dem Enrichment überschreibt die, die der Rep im Gespräch notiert hat. Der Status aus der Kampagne überschreibt den, den der Vertrieb gesetzt hat. Das lässt sich nicht durch bessere Technik lösen, nur durch eine Entscheidung vorher: Feld für Feld, wer führt.

Fehler 3: Zwei Wege ohne Loop-Schutz

Der teuerste. Make schreibt ins CRM, das CRM feuert daraufhin sein Update-Webhook, Make nimmt das als Änderung und schreibt zurück, das CRM feuert erneut. Das läuft, bis das Ops-Kontingent leer ist oder jemand das Szenario anhält.

„Ein Zwei-Wege-Sync ohne Loop-Schutz ist kein Sync mit einem Bug. Er ist eine Schleife, die zufällig auch Daten überträgt."

Alle drei Probleme haben eine gemeinsame Ursache: der Sync wurde als Technik-Aufgabe behandelt, obwohl er zuerst eine Datenmodell-Aufgabe ist. Deshalb geht es unten erst um Richtungen und Schlüssel und danach um Module.

Die 3 Sync-Richtungen

Drei Richtungen, und die Reihenfolge ist keine Geschmacksfrage. Jede baut auf der vorherigen auf, und jede lässt sich einzeln in Betrieb nehmen, bevor die nächste dazukommt.

Richtung A: Outbound zum CRM

Der Sync, mit dem man anfängt, weil er nichts kaputtmachen kann. Er legt an und ergänzt, er überschreibt nichts, was ein Mensch gepflegt hat. Ein Reply kommt rein, der Kontakt landet im CRM mit Quelle, Verlauf und einer Aufgabe für den zuständigen Rep. Wenn sonst nichts läuft, läuft wenigstens das.

Richtung B: CRM zum Outbound

Jetzt ist das CRM die Quelle der Zielgruppe. Ein Stage-Change oder eine Listen-Zugehörigkeit löst aus, Make prüft die Suppression und legt in der Sequenz an. Der Gewinn ist nicht die Automatisierung, sondern die Aktualität: niemand arbeitet mehr mit einem CSV-Export von vor drei Wochen, und wer im CRM auf „kein Interesse“ gesetzt wird, fällt sofort aus der Kampagne.

Richtung C: beide Wege

Erst wenn A und B einzeln seit Wochen stabil laufen. Beide gleichzeitig zu bauen heißt, zwei Systeme gleichzeitig zu debuggen, und du weißt bei jedem falschen Feld nicht, aus welcher Richtung es kam. Die Details zum Loop-Schutz stehen weiter unten in Abschnitt 5.

Sync 1: Reply landet im CRM

Der erste Sync, konkret. Ziel: eine Antwort im Sending-Tool erzeugt innerhalb von Sekunden einen vollständigen CRM-Eintrag mit Kontext.

Der Ablauf

Das Sending-Tool, etwa Instantly, schickt bei einer Antwort ein Webhook an Make. Make normalisiert zuerst die Adresse, also Kleinschreibung und Leerzeichen weg, und sucht dann im CRM. Existiert der Kontakt, wird er aktualisiert. Existiert er nicht, wird er angelegt, und zwar mit gesetzter Quelle, damit später nachvollziehbar ist, woher der Deal kam.

Danach zwei Schritte, die oft fehlen und den Unterschied machen. Erstens: den Mail-Verlauf als Notiz an den Datensatz hängen, nicht nur ein Flag setzen. Der Rep muss lesen können, was der Kontakt geschrieben hat, ohne ins Postfach zu wechseln. Zweitens: eine Aufgabe mit Fälligkeit erzeugen und dem richtigen Besitzer zuweisen. Ein Kontakt ohne Aufgabe wird nicht bearbeitet, er wird gespeichert.

Die Zuweisung

Bei mehreren Reps brauchst du eine Regel, und zwar eine, die im Modul steht und nicht im Kopf. Round Robin ist einfach, aber selten richtig. Besser sind Kriterien, die zur Sache passen: Region, Branche, Firmengröße oder schlicht der Absender der Kampagne. Der Kontakt gehört dem, aus dessen Postfach die Mail kam. Das ist für den Empfänger die einzige nachvollziehbare Variante.

Ein Detail aus der Praxis: baue eine Verzweigung für negative Antworten. Ein „bitte nehmen Sie mich raus“ darf keine Aufgabe erzeugen, sondern muss auf die Suppression-Liste und den Kontakt im CRM entsprechend markieren. Wer das nicht trennt, produziert Aufgaben, die der Rep wegklickt, und schreibt denselben Kontakt in drei Monaten wieder an.

Sync 2: CRM speist die Kampagne

Die Gegenrichtung. Ab hier ist das CRM die Quelle der Wahrheit für Zielgruppen, und Listen-Exporte hören auf.

Der Trigger

Am robustesten ist ein Trigger auf ein dediziertes Feld, nicht auf den allgemeinen Deal-Stage. Ein Feld wie „Outbound-Freigabe“ mit einem definierten Wert ist eindeutig, während ein Stage-Change aus zwanzig Gründen passieren kann. Der Nebeneffekt ist wichtig: der Vertrieb steuert die Kampagne über ein Feld, das er versteht, statt über eine Automatisierungsregel, die ihm niemand erklärt hat.

Die Prüfkette vor dem Anlegen

Bevor irgendetwas in einer Sequenz landet, laufen drei Prüfungen. Erstens Suppression: steht die Domain oder die Adresse auf der Sperrliste? Ganze Domains, nicht nur einzelne Adressen, sonst schreibst du den Kollegen dessen an, der gerade abgesagt hat. Zweitens: läuft der Kontakt schon in einer anderen Kampagne? Drittens: sind die Pflichtfelder für die Personalisierung gefüllt? Fehlt eins, geht der Kontakt in eine Review-Liste statt in die Sequenz.

Fehlen Daten, ist der übliche Weg ein Zwischenschritt über Clay: Make legt die Zeile an, Clay reichert asynchron an und meldet die fertige Zeile per Webhook zurück. Wie diese Kopplung im Detail funktioniert, steht in unserem Beitrag zur Clay-Make-Integration.

Und zurück

Sobald der Kontakt in der Sequenz liegt, schreibt Make die Kampagnen-ID und das Startdatum ins CRM zurück. Zwei Felder, eine Operation, und plötzlich sieht jeder im Team im Datensatz, dass dieser Kontakt gerade angeschrieben wird. Ohne diesen Rückweg ruft der Rep jemanden an, der heute Morgen Mail drei bekommen hat.

Sync 3: Zwei Wege ohne Endlosschleife

Jetzt der Teil, um den es eigentlich geht. Ein Zwei-Wege-Sync ist technisch nur A plus B, aber er hat ein Problem, das A und B einzeln nicht haben.

Warum die Schleife entsteht

CRMs unterscheiden nicht, wer ein Feld geändert hat. Ein Update ist ein Update, egal ob ein Mensch getippt oder eine API geschrieben hat. Also feuert das Webhook auch dann, wenn dein eigener Sync gerade geschrieben hat. Make nimmt das als neue Änderung, verarbeitet sie und schreibt in die Gegenrichtung, was dort dasselbe auslöst.

Loop-Schutz 1: das Signatur-Feld

Die zuverlässige Variante. Du legst im CRM ein technisches Feld an, zum Beispiel „sync_source“, das für Nutzer ausgeblendet ist. Jedes Mal wenn Make schreibt, setzt es dieses Feld auf einen festen Wert plus Zeitstempel. Direkt nach dem Trigger prüft Make dieses Feld: steht dort die eigene Signatur mit einem Zeitstempel aus den letzten Sekunden, wird der Durchlauf beendet. Kostet eine Operation, verhindert die Schleife vollständig.

Loop-Schutz 2: der Zeitstempel-Vergleich

Die einfachere Variante, wenn du kein zusätzliches Feld anlegen darfst. Make vergleicht den Änderungszeitpunkt des Datensatzes mit dem Zeitpunkt des letzten eigenen Schreibvorgangs, den es in einem Datastore führt. Liegt die Änderung innerhalb eines kurzen Fensters, wird sie verworfen. Das ist weniger präzise als die Signatur, weil eine echte Nutzeränderung im selben Fenster mit verschluckt wird, reicht aber für die meisten Setups.

Das führende System festlegen

Loop-Schutz löst die Technik, nicht die Fachlichkeit. Du brauchst zusätzlich eine Liste, Feld für Feld, welches System gewinnt. Als Faustregel aus unseren Setups: alles, was ein Mensch eintippt, führt das CRM. Alles, was aus Enrichment oder Kampagne kommt, führt das Outbound- System, und es schreibt in eigene Felder statt in die des Vertriebs. Eine angereicherte Telefonnummer gehört nicht in „Telefon“, sondern in „Telefon (angereichert)“. Klingt kleinlich, verhindert aber genau den Streit, der solche Projekte kippt.

Matching, Dedup und Record-IDs

Der Abschnitt, der über die Halbwertszeit deines Syncs entscheidet. Es geht um eine einzige Frage: woran erkennt Make, dass zwei Datensätze dieselbe Person meinen?

Die Record-ID mitführen

Beim allerersten Abgleich matchst du über die normalisierte E-Mail-Adresse, es geht nicht anders. Aber in genau diesem Durchlauf schreibst du die CRM-Record-ID in ein Feld deines Outbound-Systems zurück. Ab dem zweiten Mal matchst du nur noch darüber. Der Effekt ist doppelt: das Matching bleibt korrekt, wenn sich die Adresse ändert, und du sparst bei jedem Durchlauf das Suchmodul, weil du direkt aktualisieren kannst.

„Die E-Mail ist ein Attribut, kein Schlüssel. Sie ändert sich, sobald jemand die Firma wechselt oder die IT die Namenskonvention umstellt. Die Record-ID ändert sich nie."

Normalisieren, bevor du vergleichst

Wenn du doch über die Adresse matchen musst, dann sauber. Kleinschreibung, Leerzeichen entfernen, und bei Gmail-Adressen die Punkte und alles ab einem Plus ignorieren. Auf Firmenseite dasselbe für die Domain: www weg, Protokoll weg, Groß- und Kleinschreibung vereinheitlichen. Zwei Zeilen Text-Transformation in Make, und ein großer Teil der Dubletten entsteht gar nicht erst.

Firmen sind schwieriger als Personen

Bei Unternehmen gibt es keine eindeutige Adresse, und der Firmenname ist als Schlüssel unbrauchbar. „Müller GmbH“, „Mueller GmbH“ und „Müller GmbH & Co. KG“ sind für einen String-Vergleich drei Firmen. Der praktikable Schlüssel ist die Domain der Website, weil sie eindeutig ist und sich selten ändert. Wenn dein CRM ein Domain-Feld auf der Company hat, ist das dein Match-Key. Hat es keins, leg eins an, bevor du den Sync baust.

Was du tun solltest, bevor der Sync live geht

Einmal die bestehenden Dubletten aufräumen. Ein Sync auf einem Datenstand mit dreihundert doppelten Kontakten multipliziert das Problem, statt es zu lösen, weil er ab sofort beide Kopien pflegt. Das ist ein unangenehmer Nachmittag, aber es ist der einzige Zeitpunkt, an dem es billig ist.

Operations, Rate-Limits, Kosten

Make rechnet pro ausgeführtem Modul eine Operation. Der Trigger zählt mit, jede Suche zählt, jeder Router-Pfad, der tatsächlich läuft, zählt. Daraus ergibt sich eine unbequeme Wahrheit: der teuerste Teil eines Syncs ist nicht das Schreiben, sondern das Suchen davor.

Der Vergleich zwischen den letzten beiden Zeilen ist der Punkt. Derselbe Zwei-Wege-Sync verbraucht rund ein Drittel weniger Operations, sobald die Record-ID mitgeführt wird und die Suchmodule entfallen. Das ist kein Optimierungs-Detail, das ist der Unterschied zwischen zwei Tarifstufen.

Rate-Limits sauber abfangen

Jedes Modul, das eine CRM-API ruft, bekommt einen Error-Handler mit Auto-Retry. Bei einem 429er wartet Make und versucht es erneut, statt den Durchlauf abzubrechen und den Datensatz zu verlieren. Wichtig ist der Unterschied im Charakter der Limits: HubSpot und Pipedrive drosseln über kurze Zeitfenster, das merkst du sofort und es erholt sich von selbst. Salesforce arbeitet mit einem Tageskontingent über die gesamte Organisation. Das ist tückischer, weil dein Sync sich das Kontingent mit jeder anderen Integration teilt und der Anschlag erst nachmittags kommt.

Bulk statt einzeln

Wenn du regelmäßig größere Mengen synchronisierst, nutze die Batch-Endpunkte statt einer Schleife über Einzelaufrufe. Hundert Kontakte einzeln zu schreiben kostet hundert Operations und läuft ins Rate-Limit. Derselbe Vorgang als Batch kostet einen Bruchteil davon. Der Aufwand ist ein Array-Aggregator mehr im Szenario.

Falls dir Make an dieser Stelle zu teuer wird, macht n8n dasselbe self-hosted, mit Fixkosten statt Verbrauchspreis. Der Tausch ist immer derselbe: du sparst pro Ausführung und zahlst mit DevOps-Aufwand.

HubSpot vs Pipedrive vs Salesforce

Die drei CRMs verhalten sich in Make deutlich unterschiedlich, und das liegt weniger an den Modulen als am Datenmodell dahinter.

HubSpot

Gute Module, saubere Webhooks, aber du musst die Associations planen. Ein Deal, der an keinem Kontakt hängt, ist in HubSpot technisch erlaubt und fachlich wertlos. Wer den Sync baut, ohne die Verknüpfungen mitzuschreiben, produziert einen Berg unverbundener Objekte, den später niemand mehr zuordnen kann. Zweiter Punkt: Custom Properties heißen in der API anders als im Interface. Die interne Bezeichnung einmal notieren, bevor du mappst.

Pipedrive

Der schnellste Weg zu einem laufenden Sync. Flaches Modell, wenige Objekttypen, verständliche Felder. Die einzige verlässliche Stolperstelle sind Custom Fields, die über kryptische API-Keys statt über Klarnamen angesprochen werden. Einmal auslesen, in eine Notiz schreiben, fertig. Wenn du zwischen den dreien freie Wahl hast und ein schlankes Sales-Team bist, ist das die pragmatische Antwort. Wer noch schlanker unterwegs ist, kommt auch mit Close weit, das ist ohnehin auf Outbound zugeschnitten.

Salesforce

Der aufwendigste, und meistens keine freie Entscheidung, sondern eine Vorgabe. Rechne mit Vorlauf: Objekt-Modell, Validierungsregeln, Pflichtfelder und Berechtigungen sind pro Instanz anders. Der klassische Fehlschlag ist ein Update, das an einem Pflichtfeld scheitert, das mit deinem Sync nichts zu tun hat. Vor dem Bauen die Validierungsregeln des Zielobjekts durchgehen und mit dem Salesforce-Admin klären, welche davon für einen Integrations-User ausgesetzt werden.

Der Rat zum Schluss, unabhängig vom System: bau Richtung A, lass sie zwei Wochen laufen, schau dir an was im CRM ankommt. Dann Richtung B. Den Zwei-Wege-Sync erst, wenn beide einzeln unauffällig sind und du das führende System je Feld schriftlich hast. Alles auf einmal ist der schnellste Weg zu einem Sync, den nach drei Monaten niemand mehr anfassen will.

Häufige Fragen