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, dass zwei Systeme miteinander sprechen. Er sagt nichts darüber, ob eine Firma beim zweiten Kontakt wiedergefunden statt neu angelegt wird. Genau dort entstehen die Doppeleinträge, die zwei Wochen später in der Kampagne sichtbar werden und Vertrauen kosten.

Der Ablauf ist in fast jedem Projekt derselbe. Das Team verbindet das Anreicherungswerkzeug mit dem CRM, verbindet das CRM mit dem Versandwerkzeug, klickt auf Testen, bekommt drei grüne Zeilen und meldet die Integration als fertig. Was dabei geprüft wurde, ist die Erreichbarkeit der Schnittstelle: Adresse stimmt, 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.

Der Schaden ist auch deshalb teuer, 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 irgendetwas gebaut wird?

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 Folge trägt der Vertrieb: doppelte Einträge, unklare Zuständigkeit, Zeit, die in Aufräumarbeit statt in Gespräche geht. Die Zuständigkeit wird deshalb vorher entschieden, nicht nachträglich hergeleitet.

Vor dem ersten Klick wird der Weg gezeichnet, Station für Station: wo die Daten herkommen, welches System sie annimmt, wo sie landen. 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, wird nicht gebaut.

Wir arbeiten dafür mit drei getrennten Arbeitsflächen statt einer breiten Tabelle. Die erste führt die Organisation: Identität, Abgleich, 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 besitzt. 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 Organisations- und Personendaten, 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 der 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 tragen zwei Schreibwege gleichzeitig scharf, weil sich niemand getraut hat, einen abzuschalten. Das Ergebnis ist kein Fehler, sondern ein Wettlauf, und Wettläufe erzeugen genau die Doppeleinträge, die vermieden werden sollten. 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 ein geprüfter eindeutiger Schlüssel im Zielsystem vorliegt (External ID). Geprüft heisst hier: das Feld ist über die Schnittstelle erreichbar, es ist wirklich 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, 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. Er wird es erst, wenn die vier genannten Bedingungen einzeln bestätigt sind.

Womit wird getestet?

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

Gebraucht wird eine einzige, klar als Test erkennbare Organisation und eine erreichbare eigene Adresse. Die Organisation trägt die Felder, die das Zielsystem zwingend verlangt, dazu die Merkmale, über die abgeglichen wird, und jedes Feld einer Sperrliste (DNC), das im Weg vorkommt. Dazu kommt 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, gibt die Möglichkeit auf, nach dem nächsten Umbau in fünf Minuten nachzuweisen, dass die Kette noch hält. Was aufgeräumt wird, sind 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 noch geprüft wird.

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 Frage gar nicht gestellt, um die es geht.

Im ersten Durchlauf geht ein einziger Datensatz den ganzen Weg. Danach wird nicht im Werkzeug geschaut, sondern im Zielsystem nachgelesen. Steht dort eine Organisation, steht dort eine Person, ist die Person der richtigen Organisation zugeordnet, hängt das Ereignis an der richtigen Person, stimmen Besitzer, Absender, Kanal und Zeitstempel mit der Vereinbarung überein. Die zurückgegebenen Nummern und der Zeitstempel werden festgehalten.

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

Der zweite Durchlauf bekommt eine neue Lauf-Nummer, behält aber die Ereignis-Nummern des ersten, damit sich Doppelung überhaupt erkennen lässt. Fünf grüne Zeilen sind das erste belastbare Ergebnis des ganzen Projekts. Vier grüne und eine rote sind ein Befund, der 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". 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 meistens erst besprochen, wenn sie in der laufenden Kampagne auftreten, und dann unter Zeitdruck. Vorher festgelegt kosten sie eine halbe Stunde. Nachher kosten sie eine gestoppte Kampagne und eine Erklärung an den Kunden. Geprüft werden nur die Fälle, die im echten Weg dieses Unternehmens auch wirklich vorkommen.

Eine Antwort des Empfängers gehört in dieselbe Logik. Wenn eine Antwort weitere automatische Berührungen stoppen soll, ist das eine Prüfzeile und keine Einstellung, die man annimmt. Im Versandwerkzeug, bei uns meist Lemlist, wird sie im Testlauf einmal echt ausgelöst und im CRM nachgelesen.

Abnahmebereit ist eine Schnittstelle, wenn ein zweiter Mensch den Weg an den Namen der Flächen erkennt, wenn pro Objekt genau ein aktiver Weg existiert, wenn alle schreibenden Schritte auf manuell stehen, wenn der Testdatensatz intern und markiert ist, und wenn beide Durchläufe mit Rücklesung am Zielsystem vorliegen. Erst danach werden Platzhalter durch die echten Aktionen ersetzt und die Testfreigabe von der Produktionsfreigabe getrennt.

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 einen Vertrauensverlust beim Empfänger, der die Mail nicht 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".