Ein Kunde, sechs Systeme: die selbstsichere Fehlzuordnung

Ich habe sechs Orte verbunden, an denen ein B2B-Unternehmen Kundenkontext hält: Chat, Tickets, Wiki, CRM, Postfächer und Meeting-Notizen. Die erste Version durchsuchte alle sechs und lieferte belegte Antworten. Nützlich, und sie nahm die eigentliche Arbeit nicht weg. Jemand musste weiterhin bemerken, dass ein Ticket, ein CRM-Konto und eine Meeting-Notiz denselben Kunden meinten, entscheiden, welche Quelle aktuell war, und die Änderung an die Personen kopieren, die sie brauchten.

Das stellte sich als Zuordnungsproblem heraus, mehr als als Suchproblem, und das Zuordnungsproblem hat einen Ausfallmodus, den keine Warteschlange fängt.

Die Fälle sind gewöhnlich

Die schwierigen Fälle sind nicht exotisch:

• eine Firma wird umbenannt;
• eine Mutter und eine Tochter teilen sich Kontakte;
• Leute benutzen einen Produktnamen als Kundennamen;
• das CRM sagt aktiv, während das neueste Ticket blockiert sagt;
• dieselbe Entscheidung taucht im Chat und in den Meeting-Notizen in unterschiedlicher Formulierung auf.

Die Suche kann all das zurückgeben. Sie kann nicht sagen, was zusammengehört oder wer es wissen sollte.

Die selbstsichere Fehlzuordnung

Schema-Drift war nie das, was wehtat. Was wehtat, war der Agent, der sicher war, zu welchem Kunden ein Datensatz gehört. Jedes Feld validiert, der Fingerprint passt, und das Update landet mit voller Sicherheit auf dem falschen Konto. Dafür gibt es kein 429 und keine Dead-Letter-Queue. Es geht leise an das falsche Team.

Mehrdeutige Fälle können geprüft werden. Die selbstsichere Fehlzuordnung ist die teure, gerade weil nichts in der Pipeline nach einem zweiten Blick fragt. Was sie gestoppt hat, war, die kanonische Entität vor dem Schreibpfad aufzulösen statt nach der Suche: Jeder Datensatz fällt unter ein Kundenregister, bevor irgendetwas vorgeschlagen wird, und der Vorschlag nennt den Kunden, unter dem er abgelegt wurde.

Welche Quelle bei welchem Feld gewinnt

Aktualität als Standard hat mich schnell in Schwierigkeiten gebracht, deshalb gilt Autorität jetzt pro Feld. Die Regel, bei der ich gelandet bin: Das System, in dem ein Feld verfasst wird, schlägt jedes System, das es spiegelt. Ein Ticket wird vom Kunden geschrieben, also gewinnt es beim Zustand des Anliegens. Die CRM-Phase wird von der Person geschrieben, die das Konto verantwortet, also gewinnt sie beim kommerziellen Zustand. Wenn das CRM aktiv sagt und das Ticket blockiert, ist das kein Widerspruch. Es sind zwei verschiedene Felder, und sie als eines zu modellieren war der Fehler.

Fakten mit Anfang und Ende

Fakten werden mit einem Gültig-ab und, wenn es so weit ist, einem Ungültig-ab festgehalten. Wenn ein neuer Fakt das Gegenteil eines bestehenden aussagt, wird der ältere invalidiert. Das deckt direkte Widersprüche ab und sonst nichts, und die Lücke ist exakt: Eine Scope-Änderung lässt Subjekt, Prädikat und Typ unverändert, also feuert nichts. „Der Preis ist X" wird falsch, wenn X den Umfang ändert, nicht den Wert.

Was diesen Fall rettet, ist, dass Quelle und zitierte Textstelle am Fakt bleiben. Die Drift ist im Zitat sichtbar, auch wenn das Tripel unverändert aussieht. Das ist ein menschlicher Fang, kein automatischer, und es ist der Grund, warum die Textstelle mit jedem Datensatz reist, statt wegzusammengefasst zu werden.

Eine Korrektur muss etwas beibringen

Heute wird eine Korrektur als Alias an die kanonische Entität zurückgeschrieben, sodass genau dieses Paar nie wieder bricht. Das repariert einen Vorfall und bringt dem Matcher nichts bei. Die Bewertung darunter bleibt so naiv wie am ersten Tag, während sich die Aliase stapeln.

Die bessere Version behandelt Korrekturen als beschriftete Daten: der ursprüngliche Kontext und der korrigierte Kunde als positives Beispiel, der fälschlich gewählte Kunde als hartes Negativbeispiel, und der Matcher in Chargen neu kalibriert. Dort bin ich noch nicht, weil harte Negativbeispiele aus einem kleinen Team dünn sind und in Richtung dessen verzerrt, was dem Team zufällig aufgefallen ist. Also werden Korrekturen als beschriftete Menge gehalten, bis genug da sind, um dagegen zu kalibrieren, und die Aliase tragen die Last bis dahin.

Stille ist kein Verfall

Eine Quelle, die verstummt, ist keine Quelle, die falsch geworden ist. Stille heißt meistens, dass niemand sie angefasst hat. Ich halte lieber einen alten Fakt mit sichtbarem Datum als einen sicheren, der auf einem Timer verblasst. Was eine stille Quelle tun sollte, ist die Obergrenze senken: Ein Fakt aus einer Quelle, die aufgehört hat sich zu aktualisieren, kann nicht ewig volle Sicherheit behalten, er sollte nur nicht nach Zeitplan fallen. Das nächste Stück ist die Neubestätigung beim Lesen: Wenn ein Fakt benutzt wird, wird die Quelle geprüft, und das Datum am Fakt wandert oder der Fakt wird markiert.

Was das für die Kontrolle bedeutet

Zuordnung ist ein Kontextproblem mit einer Kontrollfolge. Eine falsche Zuordnung leitet einen Schreibzugriff an den falschen Kunden, und der einzige Ort, an dem vor diesem Schreibzugriff noch eine Person hinschaut, ist die Freigabekarte. Also nennt die Karte den aufgelösten Kunden, zitiert die Textstelle und zeigt den vorherigen Wert. Die selbstsichere Fehlzuordnung wird an dem einen Schritt sichtbar, in dem ohnehin eine Person steckt, und genau dafür steht sie dort.