Fehlende Adressdaten in CRM-Leads automatisch recherchieren

Ausgangslage

Im Projekt dokumentiert: In den CRM-Leads fehlen regelmäßig PLZ und Ort. Dadurch können die Leads „nicht bearbeitet und nicht an den zuständigen Ansprechpartner weitergeleitet werden“. Als Auslöser wird ein konkreter Fall genannt — im Formular war „Deutschland“ ausgewählt, die Firma sitzt tatsächlich in der Schweiz.

Bemerkenswert ist, was bereits existierte: Die Routing-Logik war da, ihr fehlte nur der Input. Ein Dubletten-Werkzeug war ebenfalls installiert, kann aber nur vorhandene Adressen prüfen und normieren — keine fehlenden finden.

Was die Mitarbeitenden vorher konkret taten — manuell nachrecherchieren, zurückfragen oder die Leads liegen lassen — steht nirgends im Projekt und wird hier nicht erfunden.

Ansatz

Ein Python-Programm liest die unvollständigen Leads: keine PLZ, oder ein Platzhalter statt Firmenname, nicht konvertiert, Zeitfenster wählbar. Aus Website- oder E-Mail-Feld wird die Domain bestimmt. Bekannte Wettbewerber-Domains und Freemail-Adressen werden vorab aussortiert — sie kosten damit keinen einzigen API-Aufruf.

Für den Rest greifen drei Quellen in fester Reihenfolge: erstens das eigene CRM (existiert zur selben Domain bereits ein Account, Kontakt oder Lead mit Adresse?), zweitens die Impressumsseite der Firma, die das Programm selbst abruft und von einem Sprachmodell auslesen lässt, drittens — nur wenn die Seite blockiert oder nicht erreichbar ist — eine Websuche. Der Abruf ist bewusst zurückhaltend: eigener User-Agent, maximal drei Seiten pro Firma, Pause zwischen den Anfragen.

Anschließend prüft normaler Code alles nach: PLZ-Format gegen die Regel des jeweiligen Landes, PLZ↔Ort gegen freie Referenzdaten, USt-IdNr. gegen das Länderformat. Widerspricht das Rechercheergebnis dem Formular — der Fall „Deutschland vs. Schweiz“ —, wird die Zeile markiert und landet auf einem eigenen Blatt, statt still korrigiert zu werden.

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

Phase 1 schreibt bewusst nichts zurück.

Das System hätte die gefundenen Adressen direkt in die Leads schreiben können. Es liefert stattdessen eine Excel-Liste zur manuellen Freigabe. Die Begründung steht ausformuliert im Projekt: erst die Trefferquote belegen, dann automatisieren.

Der Preis ist real — kein unmittelbarer Zeitgewinn, ein zusätzlicher manueller Schritt. Der Gegenwert ist es auch: kein Risiko für die CRM-Daten und, praktisch relevanter, kein Änderungsbedarf im CRM. Ein Lesezugriff genügt. Das Projekt konnte ohne Freigabeschleife starten, statt auf die Administration zu warten.

Technisch gespiegelt wird dieselbe Haltung in der Regel kein Beleg, kein Wert: Das Modell darf ausschließlich wiedergeben, was wörtlich auf der Seite steht; jeder Wert braucht Quell-URL und Zitat, sonst wird er verworfen. Lieber eine Lücke als eine plausible Erfindung.

Ergebnis

Neun Module, rund 1.780 Zeilen, drei aufrufbare Programme — Feld-Analyse, Datenprofil, Anreicherung. Der Excel-Report hat drei Blätter mit rund 30 Spalten. Alle Quelldateien tragen dasselbe Datum: ein Arbeitstag von der Idee bis zu drei Testläufen gegen eine echte Organisation.

Parallel wird der Anfragetext, der ohnehin am Lead hängt, in die Picklisten des Systems einsortiert und als Nicht-Lead markiert, wenn es sich um Bewerbung, Agenturangebot oder Spam handelt. Die erlaubten Werte werden zur Laufzeit aus dem CRM gelesen, nicht im Code hinterlegt — ändert jemand eine Pickliste, folgt die Klassifizierung automatisch.

Bewusst begrenzt: Widersprüche werden nicht gelöst, sondern vorgelegt. Freemail-Adressen und Leads ohne Website sind nicht anreicherbar und werden als solche ausgewiesen, nicht geraten. PLZ↔Ort wird nur für vier Länder gegengeprüft, so weit die Referenzdaten reichen; die USt-IdNr. nur auf Format, nicht gegen das EU-Register.

Und ein Satz, der im Projekt selbst steht: Die eigentliche Ursache bleibt bestehen — dass die PLZ im Web-Formular kein Pflichtfeld ist. Das Werkzeug behandelt die Altfälle, nicht den Auslöser.