CRM-Schnittstelle: der zweite Test zählt

Warum meldet die Integration „fertig“, obwohl Doppeleinträge entstehen?

Eine Integration kann fehlerfrei laufen und trotzdem falsche Ergebnisse produzieren. Der grüne Haken bestätigt nur, dass zwei Systeme miteinander sprechen. Ob eine Firma beim zweiten Kontakt wiedergefunden oder neu angelegt wird, sagt er nicht. Genau dort entstehen die Doppeleinträge, die zwei Wochen später in der Kampagne auffallen und Vertrauen kosten.

Der Ablauf ist in fast jedem Projekt derselbe. Das Team verbindet das Anreicherungswerkzeug mit dem CRM und das CRM mit dem Versandwerkzeug. Dann klickt es auf Testen, bekommt drei grüne Zeilen und meldet die Integration als fertig. Geprüft wurde dabei nur, ob die Schnittstelle erreichbar ist: Die Adresse stimmt, die Zugangsdaten stimmen, die Gegenstelle antwortet. Das ist eine Verbindungsprüfung, kein Durchlauf mit echten Daten.

Unsere These: Eine Schnittstelle gilt erst dann als getestet, wenn wir am Zielsystem nachgelesen haben, was dort wirklich steht. Eine gespeicherte Einstellung ist eine Absicht. Eine zurückgelesene Nummer ist ein Ergebnis. Wir bauen diese Ketten in der Pipeline Generation regelmässig. Und dieser Unterschied ist der häufigste Grund, warum eine Kampagne in Woche zwei auffällt statt in Woche null.

Teuer ist der Schaden auch deshalb, weil er leise ist. Kein Werkzeug meldet einen Fehler, wenn es eine Firma zum zweiten Mal anlegt. Für das anlegende System ist das ein korrekter Vorgang. Sichtbar wird es erst, wenn zwei Sequenzen auf dieselbe Person laufen oder ein Bestandskunde eine Kaltakquise-Mail bekommt.

Was muss feststehen, bevor du irgendetwas baust?

In den meisten Projekten kann niemand sagen, welches System eine Firma anlegen darf. Also legen am Ende zwei Systeme an, und beide halten sich für zuständig. Die Folgen trägt der Vertrieb: doppelte Einträge, unklare Zuständigkeiten und Zeit, die in Aufräumarbeit statt in Gespräche fliesst. Entscheide die Zuständigkeit deshalb vorher, statt sie nachträglich herzuleiten.

Zeichne vor dem ersten Klick den Weg, Station für Station: Wo kommen die Daten her, welches System nimmt sie an, wo landen sie? Zu jeder Station gehört eine benannte Verantwortung. Wer sucht? Wer legt an? Wer aktualisiert? Wer schreibt das Ergebnis zurück? Solange eine dieser vier Fragen offen ist, baust du nicht.

Wir arbeiten dafür mit drei getrennten Arbeitsflächen statt einer breiten Tabelle. Die erste führt die Organisation. Dort stehen ihre Identität und der Abgleich, dazu das Anlegen unter Bedingung und die Nummer, die das Zielsystem zurückgibt. Die zweite führt die Person, ihre Zuordnung zur Organisation und denselben Abgleich. Die dritte führt die Übergabe selbst, also die freigegebene Person, die Aktion im Zielsystem und den Freigabestand.

Unsere These: Eine vierte Fläche entsteht nur, wenn sie einen eigenen Schritt hat. Eine Fläche, die nur wiederholt, was die anderen schon führen, macht den Aufbau breiter und den Fehler schwerer auffindbar. Das gilt genauso für Länder- und Rollenvarianten. Eine Variante, die nur einen Feldwert ändert, ist keine eigene Prüfung. Eine Variante, die den Weg, die Berechtigung oder den Abgleich ändert, schon.

In der Praxis heisst das bei uns meist: Clay liefert die angereicherten Daten zu Organisationen und Personen. HubSpot ist das Zielsystem, in dem Firmen und Kontakte leben, und Lemlist steht am Ende als Versandwerkzeug. Die Werkzeuge sind austauschbar. Die vier Fragen sind es nicht.

Deep Dive Guide · 17 Seiten · kostenlos

Vom Signal zur Sales Pipeline

Ob dein Markt Volumen trägt, welche drei bis fünf Signale zählen und an welcher Stelle die Kette bricht. Dazu die Prüfungen vor dem ersten Versand.

Guide ansehen →

Anlegen oder nachschlagen: welcher Schreibweg gilt pro Objekt?

Viele Aufbauten haben zwei Schreibwege gleichzeitig scharf geschaltet, weil sich niemand getraut hat, einen abzuschalten. Das Ergebnis ist kein Fehler, sondern ein Wettlauf. Und Wettläufe erzeugen genau die Doppeleinträge, die du vermeiden willst. Pro Objekt bleibt deshalb genau ein Weg aktiv. Die Bedingung dafür ist nachprüfbar und keine Geschmacksfrage.

Es gibt zwei mögliche Wege. Der erste heisst anlegen oder aktualisieren in einem Schritt (Upsert). Er ist erlaubt, wenn im Zielsystem ein geprüfter eindeutiger Schlüssel vorliegt (External ID). Geprüft heisst hier vier Dinge. Das Feld ist über die Schnittstelle erreichbar, und es ist in jedem Datensatz eindeutig. Seine Schreibweise ist vereinheitlicht, und das verbindende Werkzeug kann darauf zugreifen. Der zweite Weg heisst nachschlagen und erst nach eindeutigem Nicht-Treffer anlegen. Er gilt immer dann, wenn der Schlüssel ungeprüft, mehrdeutig oder nicht erreichbar ist.

Die dritte Zeile wird am häufigsten übersehen. Anhalten fühlt sich nach Ausfall an, ist aber ein Ergebnis: Das System sagt dir, dass es die Lage nicht sicher auflösen kann, und überlässt die Entscheidung einem Menschen. Automatisch anzulegen wäre an dieser Stelle keine Lösung, sondern eine geratene Antwort.

Eine Verwechslung kostet regelmässig einen Anlauf. Ein interner Schlüssel, mit dem ein Team seine eigenen Doppeleinträge erkennt, ist noch kein eindeutiger Schlüssel im Sinne der Schnittstelle. Das wird er erst, wenn die vier genannten Bedingungen einzeln bestätigt sind.

Womit testest du?

Ist kein Testdatensatz vorbereitet, wird am ersten echten Interessenten getestet, und der erste Fehler geht nach draussen. Das ist der einzige Fehler in dieser ganzen Kette, den du nicht intern korrigieren kannst. Ein vorbereiteter Datensatz kostet zehn Minuten und nimmt genau dieses Risiko heraus.

Du brauchst eine einzige, klar als Test erkennbare Organisation und eine erreichbare eigene Adresse. Die Organisation trägt die Felder, die das Zielsystem zwingend verlangt, und die Merkmale, über die abgeglichen wird. Dazu kommt jedes Feld einer Sperrliste (DNC), das im Weg vorkommt. Und eine leere Stelle für die Nummern, die das Zielsystem später zurückgibt. Mehr braucht der erste Durchlauf nicht.

Unsere These: Der Test gehört ins eigene Haus, und er bleibt nach der Abnahme liegen. Wer den Testdatensatz aufräumt, verliert die Möglichkeit, nach dem nächsten Umbau in fünf Minuten nachzuweisen, dass die Kette noch hält. Aufgeräumt werden nur Zwischentabellen und Felder, die niemand mehr liest.

Während des Tests bleiben alle schreibenden Schritte auf manuell. Der Versand geht ausschliesslich an benannte eigene Empfänger. Echte Zielgruppen und automatische Zeitpläne bleiben ausserhalb des Testwegs. Sonst läuft eine Kampagne an, während du noch prüfst.

Warum entscheidet erst der zweite Durchlauf?

Nach einem erfolgreichen Durchlauf gilt die Sache in vielen Teams als bewiesen. Doppeleinträge entstehen aber nicht beim ersten Kontakt, sondern beim zweiten. Und die zweite Berührung ist der Normalfall: Dieselbe Firma taucht in der nächsten Liste wieder auf. Wer nur einmal testet, hat die eigentliche Frage gar nicht gestellt.

Im ersten Durchlauf geht ein einziger Datensatz den ganzen Weg. Danach schaust du nicht ins Werkzeug, sondern liest im Zielsystem nach. Steht dort eine Organisation, und steht dort eine Person? Ist die Person der richtigen Organisation zugeordnet, und hängt das Ereignis an der richtigen Person? Passen Besitzer und Absender, Kanal und Zeitstempel zur Vereinbarung? Halte die zurückgegebenen Nummern und den Zeitstempel fest.

Im zweiten Durchlauf geht derselbe Datensatz denselben Weg noch einmal. Erst dieser Lauf beantwortet die Frage, die dich als Entscheider eigentlich interessiert.

Der zweite Durchlauf bekommt eine neue Lauf-Nummer, behält aber die Ereignis-Nummern des ersten. Nur so lässt sich eine Doppelung überhaupt erkennen. Fünf grüne Zeilen sind das erste belastbare Ergebnis des ganzen Projekts. Vier grüne und eine rote sind ein Befund, der dich jetzt zwanzig Minuten kostet statt später eine Kampagne.

Dass diese Kette trägt, wenn sie sauber gebaut ist, zeigt eine eigene Case Study: node.energy: „5x Mehr Demos mit AI-Powered Outbound durch Clay & HubSpot“. Es ist dieselbe Übergabe zwischen Anreicherung, CRM und Versand, nur eben nachweislich geprüft, bevor die erste Kampagne lief.

Was muss passieren, wenn etwas schiefgeht?

Fehlerfälle werden meist erst besprochen, wenn sie in der laufenden Kampagne auftreten, und dann unter Zeitdruck. Vorher festgelegt kosten sie eine halbe Stunde. Hinterher kosten sie eine gestoppte Kampagne und eine Erklärung an den Kunden. Prüf deshalb vorab genau die Fälle, die im echten Weg deines Unternehmens vorkommen.

Eine Antwort des Empfängers gehört in dieselbe Logik. Soll eine Antwort weitere automatische Berührungen stoppen, ist das eine Prüfzeile und keine Einstellung, auf die du dich einfach verlässt. Im Versandwerkzeug, bei uns meist Lemlist, löst du sie im Testlauf einmal echt aus und liest dann im CRM nach.

Abnahmebereit ist eine Schnittstelle, wenn fünf Dinge zutreffen. Ein zweiter Mensch erkennt den Weg an den Namen der Flächen. Pro Objekt existiert genau ein aktiver Weg. Alle schreibenden Schritte stehen auf manuell. Der Testdatensatz ist intern und markiert. Und beide Durchläufe liegen mit Rücklesung am Zielsystem vor. Erst danach ersetzt du die Platzhalter durch die echten Aktionen und trennst die Testfreigabe von der Produktionsfreigabe.

Unsere These: Anhalten ist ein Ergebnis, kein Ausfall. Ein System, das bei Mehrdeutigkeit stoppt, kostet einen Handgriff. Ein System, das rät, kostet eine Bereinigung und das Vertrauen des Empfängers, der die Mail nie hätte bekommen dürfen. Wie schnell so eine geprüfte Kette produktiv wird, zeigt eine zweite eigene Case Study: knk: „24/7 AI-Automatisierte Sales Pipeline in <6 Monaten“.