Der Kunde ist archiviert, und seit Mai steht er zweimal im CRM

Zwei Datensätze für denselben Kunden

Ein Großhändler für Laborbedarf hat im Februar einen Kunden archiviert. Die Praxis hatte zwei Jahre nichts bestellt, der Vertrieb hat aufgeräumt, der Datensatz wanderte ins Archiv. Im Mai kam über das Bestellportal wieder eine Bestellung, mit derselben Kundennummer auf dem Beleg.

Die Automatisierung sucht bei jeder Bestellung den passenden Kunden im CRM und hängt die Bestellung an. Findet sie keinen, legt sie einen an. Sie hat keinen gefunden.

Seitdem gibt es diesen Kunden zweimal. Einmal archiviert, mit sechs Jahren Historie, dem ausgehandelten Rabatt von acht Prozent und einem Zahlungsziel von 30 Tagen. Und einmal frisch angelegt, ohne alles davon. Die Bestellung ist zum Listenpreis rausgegangen, per Vorkasse, an einen Kunden, den man seit sechs Jahren kennt.

Aufgefallen ist es, als der Kunde angerufen hat.

Gelöscht wird fast nirgends

Kaum ein Geschäftssystem löscht Datensätze wirklich. Was in der Oberfläche wie Löschen aussieht, setzt in der Datenbank ein Feld: deleted_at, archived, status = inaktiv. Die Zeile bleibt liegen und verschwindet nur aus den Listen.

Das ist auch richtig so. Rechnungen verweisen auf Kunden, Bestellungen auf Artikel, und ein hart gelöschter Kunde macht aus jeder alten Rechnung eine Karteileiche. Dazu kommen Aufbewahrungsfristen, die ein echtes Löschen ohnehin verbieten.

Archivieren selbst ist unproblematisch. Zum Problem wird es, weil dieser Zustand für Automatisierungen unsichtbar bleibt, solange niemand ausdrücklich danach fragt.

Drei Systeme, drei Bedeutungen von archiviert

Wir sehen bei Kunden regelmäßig drei Verhaltensweisen nebeneinander, oft im selben Workflow.

Das erste System blendet archivierte Datensätze aus der Suche aus, liefert sie aber, wenn man sie direkt über die ID abruft. Die Suche sagt, es gibt ihn nicht. Der direkte Abruf sagt, es gibt ihn. Beides ist dieselbe API.

Das zweite liefert alles, archiviert oder nicht, und stellt den Zustand in ein Feld unter vierzig anderen. Wer beim Bauen des Mappings nicht danach gesucht hat, hat ihn nicht.

Das dritte antwortet auf archivierte Datensätze mit 404. Die Automatisierung folgt dem Fehlerpfad, und der endet in den meisten No-Code-Workflows bei "dann eben anlegen".

Dasselbe Wort bedeutet damit in drei Systemen drei verschiedene Dinge, und der Workflow läuft quer durch alle drei.

Vier Muster, die immer wiederkommen

Am häufigsten entsteht ein Duplikat. Die Suche nach einem bestehenden Datensatz sieht das Archiv nicht und legt neu an. Was dem neuen Datensatz fehlt, sind genau die Felder, die über Jahre gepflegt wurden: Konditionen, Ansprechpartner, Lieferadressen, Sperrvermerke. Er sieht sauber aus, deshalb fällt er niemandem auf.

Dann gibt es die Wiederauferstehung. Ein nächtlicher Abgleich schreibt in beide Richtungen. Im CRM ist der Kontakt archiviert, im Shop noch aktiv. Der Abgleich sieht zwei unterschiedliche Stände und schreibt den aus dem Shop zurück. Am Montag archiviert jemand den Kontakt, am Dienstag steht er wieder da. Bei einem Logistikkunden ging das vier Wochen so, bis jemand die Änderungshistorie aufgemacht hat. Das Protokoll meldete in jeder dieser Nächte "1 Datensatz aktualisiert", also grün.

Der dritte Fall trifft den Postausgang. Das Mailtool holt Kontakte über die API und bekommt die archivierten mit. Der Kunde, der um Löschung gebeten hat, steht im CRM im Archiv und im Verteiler weiter drin. Beim nächsten Newsletter bekommt er Post. War der Grund für das Archivieren ein Widerspruch gegen Werbung, hält der Empfänger den Verstoß in Form der Mail selbst in der Hand.

Der vierte betrifft keine Kunden, sondern Artikel. Eine Bestellung verweist auf einen archivierten Artikel oder eine abgelaufene Preisliste. Die Automatisierung holt Bezeichnung und Preis, bekommt nichts zurück und schreibt eine leere Bezeichnung und 0,00 in die Position. Die Rechnung geht raus. Auffallen kann das erst in der Buchhaltung, und dort auch nur, wenn jemand die Summe gegen den Auftrag prüft.

Warum keine Testphase das findet

Testdaten sind neu und aktiv. Niemand archiviert einen Testdatensatz und lässt danach den Workflow laufen. Archiviert wird später, im Betrieb, von einem Menschen im Vertrieb, der aufräumt, und zwar Monate nach dem Livegang.

Dazwischen liegt der Zeitraum, in dem alle Beteiligten die Automatisierung für stabil halten. Wenn der erste archivierte Datensatz durchläuft, ist der Workflow längst niemandes Baustelle mehr.

Dazu kommt, dass keiner der vier Fälle einen Fehler wirft. Ein Duplikat ist ein erfolgreich angelegter Datensatz. Eine Wiederauferstehung ist ein erfolgreiches Update. Eine Mail an einen archivierten Kontakt ist eine erfolgreich zugestellte Mail. Das Monitoring bleibt grün, unabhängig davon, wie viel danebengeht.

Was wir stattdessen bauen

Die Suche sucht auch im Archiv. Jeder Schritt, der prüft, ob ein Datensatz schon existiert, fragt ausdrücklich mit Archiv ab, statt sich auf die Voreinstellung der API zu verlassen. Findet er einen archivierten Treffer, legt er nichts an. Der Workflow entscheidet an dieser Stelle bewusst, ob reaktiviert wird oder ob der Fall als Aufgabe an einen Menschen geht. Beides ist besser als ein zweiter Datensatz.

Der Zustand wird mitgeführt. Das Archivkennzeichen gehört ins Mapping, in jedes Zielsystem, das den Datensatz bekommt. Fehlt dort ein Feld dafür, legen wir eins an. Ein Datensatz, dem die Information "archiviert" fehlt, zwingt jeden nachgelagerten Schritt zum Raten.

Eine Richtung gewinnt. Für jedes Objekt, das zwischen zwei Systemen abgeglichen wird, legen wir fest, welches System über den Zustand entscheidet. Die andere Seite folgt und schreibt nie zurück. Ohne diese Regel ist das Ping-Pong nur eine Frage der Zeit.

Geprüft wird unmittelbar vor dem Versand. Jeder Schritt, der etwas rausschickt, prüft den Zustand direkt davor. Bei einem Lauf über 4.000 Kontakte liegen zwischen dem Auslesen der Liste und der letzten Mail schnell zwei Stunden. Wer in dieser Zeit archiviert wird, bekommt trotzdem Post, solange die Prüfung am Anfang des Laufs steht.

Und 404 ist keine Erlaubnis zum Anlegen. Der Fehlerpfad muss unterscheiden zwischen "existiert nicht" und "existiert, aber nicht für diese Abfrage". Praktisch heißt das: eine zweite Abfrage mit Archiv, bevor der Zweig zum Anlegen greift.

Wo der Schalter in der Praxis sitzt

In Make und n8n steckt das Problem selten in der Logik, sondern im Modul davor. Die fertigen Suchmodule der Konnektoren bilden meist die Standardsuche der API ab, und die blendet Archiviertes aus. Ob es überhaupt einen Schalter dafür gibt, steht nicht im Modul, sondern in der API-Dokumentation des Zielsystems. Bei manchen Anbietern ist es ein zusätzlicher Parameter an der Listenabfrage, bei anderen ein eigener Endpunkt für archivierte Objekte, bei wieder anderen ein Filter auf ein Statusfeld, dessen Namen man kennen muss.

Bietet das fertige Modul den Schalter nicht an, ersetzen wir es durch einen HTTP-Aufruf. Das ist unbequem, weil Authentifizierung und Fehlerbehandlung dann an uns hängen. Verglichen mit einer Suche, die systematisch die Hälfte des Bestands nicht sieht, ist es trotzdem der billigere Weg.

Einen Nebeneffekt sollte man einplanen. Eine Suche mit Archiv findet mehr, auch mehr Altlasten. Bei dem Großhändler hat der erste Lauf mit Archiv 340 Treffer gebracht, wo vorher keine waren. Ein Teil davon waren echte Wiederaufnahmen, ein Teil Karteileichen aus einer Migration von 2019. Diese Sortierung übernimmt kein Workflow, die macht jemand aus dem Vertrieb an zwei Nachmittagen.

Die Prüfung für den eigenen Bestand

Nehmen Sie einen archivierten Datensatz aus Ihrem führenden System und schicken Sie einen Vorgang durch, der ihn betrifft. Was dann passiert, beantwortet die Frage schneller als jede Analyse. Machen Sie es in der Testumgebung.

Zählen Sie im Zielsystem, wie oft dieselbe Kundennummer oder dieselbe Mailadresse vorkommt. Jedes Paar ist ein Kandidat.

Sehen Sie in der Änderungshistorie der letzten dreißig Tage nach, welche Datensätze reaktiviert wurden, ohne dass ein Mensch die Änderung ausgelöst hat. Steht dort ein Systemkonto, haben Sie ein Ping-Pong.

Vergleichen Sie den Verteiler Ihres Mailtools gegen die archivierten Kontakte im CRM. Die Schnittmenge sollte leer sein.

Was bei dem Großhändler herauskam

Wir haben 12.400 Kundendatensätze verglichen. 84 Kundennummern gab es doppelt, in 61 Fällen war eine der beiden Seiten archiviert. Bei elf davon war in den letzten zwölf Monaten eine Bestellung auf den falschen Datensatz gelaufen, ohne Rabatt.

Die 61 Paare haben zwei Personen aus dem Vertrieb von Hand zusammengeführt. Hängen an einem Duplikat Belege, entscheidet die Zusammenführung darüber, an welcher Rechnung später welcher Kunde hängt. Das ist keine Aufgabe für eine Regel, die 61 Fälle über einen Kamm schert.

An der Automatisierung selbst waren es zwei Änderungen. Die Kundensuche fragt jetzt mit Archiv ab, und archivierte Treffer landen in einer Aufgabe statt in einem neuen Datensatz. Ein halber Tag Arbeit gegen ein Problem, das sich sonst mit jedem aufgeräumten Datensatz weiter aufbaut.