Vier Systeme, ein Bildschirm — Kundendaten im Service-Center korrigieren

Ausgangslage

Eine schreibgeschützte „Kundenansicht“ zeigte Anruferdaten bereits im Arbeitsbereich der Servicemitarbeitenden an. Ihre Nachschlage-Logik war allerdings über mehrere quellspezifische Abfragen verstreut, und sie konnte ausschließlich anzeigen — nie schreiben. Es gab keine Stelle, an der sich ein Kontakt anlegen, suchen, korrigieren oder entdoppeln ließ.

Was der Projektordner nicht sagt: was Mitarbeitende tatsächlich taten, wenn Anruferdaten falsch oder unvollständig waren — in Salesforce korrigieren, eine eigene Liste führen oder ignorieren. Eine Messung des Vorher-Zustands existiert nirgends.

Ansatz

Eine Flask-Anwendung mit einem eigenen Kontakt-Schema und einem zentralen Auflösungs-Endpunkt. Zu einer Rufnummer normalisiert sie zunächst auf das internationale E.164-Format und prüft die eigene Tabelle über drei Rufnummernfelder. Findet sie nichts, fragt sie die vier Vorsysteme parallel ab und liefert den ersten Treffer in fester Reihenfolge: SAP, dann Salesforce, dann HubSpot, dann das interne Adressbuch.

Interessant wird es, wenn ein gepflegter Kontakt doch gefunden wird. Die Anwendung gibt dann nicht ihren eigenen Datensatz zurück. Sie holt die aktuellen Datensätze der verknüpften Vorsysteme und legt die gepflegten Werte feldweise darüber: Ein gepflegter Wert gewinnt, ein leeres gepflegtes Feld fällt auf die Quelle durch. Jedes Feld der Antwort trägt eine Markierung, woher sein Wert stammt — die Oberfläche kann „aus Salesforce“ von „von einem Mitarbeitenden korrigiert“ unterscheiden.

Das Schreiben folgt einem bewussten Ablauf: erst suchen, dann anlegen. Bevor jemand einen Kontakt anlegen darf, sucht die Anwendung in allen Quellen nach etwas Verknüpfbarem; ein freistehender Kontakt ist nur erlaubt, wenn nichts passt. Jede Feldänderung schreibt eine eigene Prüfzeile, und Aktualisierungen laufen über eine Versionsspalte, damit zwei Mitarbeitende sich nicht still gegenseitig überschreiben.

Der Punkt, an dem es anders hätte laufen können

Die gepflegten Kontakte sind ein Overlay, keine neue Stammdatenbank.

Ein gepflegter Kontakt speichert ausschließlich die Felder, die tatsächlich jemand geändert hat. Alle anderen bleiben leer und werden bei jedem Lesen live aus dem Quellsystem aufgelöst. Im Datenbankschema ist das daran sichtbar, dass alle Identitätsspalten optional sind — mit einer Prüfregel, die eine vollständige Identität nur für Kontakte ohne jede Verknüpfung erzwingt.

Es hätte anders laufen können: die Quelldatensätze in die neue Datenbank kopieren und Mitarbeitende einen lokalen Stamm pflegen lassen. Das hätte das Lesen trivial gemacht und die Abhängigkeit von vier Live-Systemen zur Gesprächszeit beseitigt.

Verworfen wurde es, weil es die neue Anwendung in Konkurrenz zu SAP und Salesforce darüber setzt, wem die Wahrheit gehört. Der stattdessen gezahlte Preis ist real: Jeder Lesevorgang muss zu den Live-Quellen ausfächern und zusammenführen, und die Herkunft je Feld muss durch den gesamten Stapel getragen werden.

Ergebnis

Rund 5.700 Zeilen in etwa 31 Dateien, 18 Endpunkte, vier angebundene Vorsysteme, sechs Tabellen im neuen Schema. Die ältere Kundenansicht wurde nicht neu geschrieben — sie bekam einen 165-Zeilen-Adapter, der den neuen Auflöser aufruft und die Antwort in die Form zurückflacht, die ihre Vorlagen ohnehin erwarten. Umschaltbar über eine Umgebungsvariable; Rückfall ist das Entfernen dieser Variable.

Bewusst nicht automatisiert: Ob ein Anrufer ein bestehender oder ein neuer Kontakt ist, welcher Datensatz verknüpft wird und ob eine Dublettenwarnung übergangen wird, entscheidet der Mensch. Das System prüft und warnt — es führt nie still zusammen. Telefon- und E-Mail-Kollisionen blockieren hart, Namensähnlichkeit erzeugt eine übergehbare Warnung.

Offen benannt: Es gibt keine automatisierte Testsuite; der einzige definierte Test ist ein manueller Abgleich über 100 Rufnummern vor dem Scharfschalten. Dubletten werden verhindert, nicht repariert — das Zusammenführen zweier bestehender Kontakte ist ausdrücklich nicht Teil der ersten Ausbaustufe. Und der Salesforce-Export existiert noch nicht; geplant ist er einseitig und zunächst als Trockenlauf.