Anbindungen im Einzelnen Rufnummernvergleich
Warum die letzten neun Stellen entscheiden
Drei Schreibweisen, eine Nummer:
- 05251/2020505
- +49 5251 2020505
- +49 (0)5251 2020505
Ein Mensch sieht sofort, dass das dreimal derselbe Anschluss ist. Ein Zeichenvergleich sieht drei verschiedene Werte. Und genau hier scheitern die meisten Anrufererkennungen – nicht an der Schnittstelle, nicht an der Telefonanlage, sondern an einer Zeile Vergleichslogik.
Was der Vergleich wegwerfen muss
Zwischen der Nummer, die das Telefonnetz meldet, und der Nummer im Kundendatensatz liegen fünf Sorten Unterschied:
- Die Ländervorwahl – einmal +49, einmal 0049, einmal gar nicht.
- Die führende Null der Ortsvorwahl, die international entfällt.
- Trennzeichen: Schrägstrich, Bindestrich, Punkt, Leerzeichen.
- Klammern um die Null – die schlimmste, weil sie beides zugleich ist.
- Die Durchwahl, mal angehängt, mal mit Bindestrich abgesetzt.
Wer all das wegwirft und die letzten neun Ziffern vergleicht, trifft dieselbe Person – ohne dass jemand vorher eine Datenbank aufräumen musste.
Warum neun und nicht acht
Acht wäre bequemer. Acht fände mehr. Acht ist falsch.
Bei +49 5251 2020505 sind die letzten acht Stellen `12020505`. Der Schnitt fällt mitten in die Ortsvorwahl. Getroffen wird dann jeder, der zufällig dieselbe Ziffernfolge am Ende trägt – irgendwo in Deutschland, in einer anderen Stadt, ohne jeden Bezug zum Anrufer.
Und dieser fremde Name steht dann beim Klingeln auf dem Bildschirm. Ein falscher Anrufer ist schlimmer als gar keiner – niemand prüft eine Angabe nach, die das System selbstsicher anzeigt.
Wie unterschiedlich die Hersteller damit umgehen
Beim Prüfen von über vierzig Systemen zeigt sich eine große Spannweite – von vorbildlich bis unbrauchbar.
Der strengste Fall
Eine spanische Buchhaltungssoftware schreibt zu ihrem Telefonfilter wörtlich, der Wert müsse „zeichengenau übereinstimmen, einschließlich Sonderzeichen wie '+', '#' und '-'".
Das ist unmissverständlich – und hart. Eine Nummer, die dort als „+34 871 590159" gepflegt ist, wird von „+34871590159" nicht gefunden. Das Leerzeichen zählt mit.
Für solche Systeme schickt das Portal mehrere Schreibweisen nacheinander. Bei einem System mit Teilzeichenkettensuche wären diese Varianten eine Absicherung; hier sind sie die Funktion.
Der vorbildliche Fall
Zwei Systeme haben das Problem für uns gelöst, bevor wir gefragt haben.
Eine deutsche Maklersoftware führt ein Feld mit normalisierten Rufnummern und schreibt dazu, man könne damit nach einer „vollständig oder teilweise" normalisierten Nummer suchen. Normalisiert heißt: Das System räumt die Schreibweisen selbst auf, bevor verglichen wird. Teilweise heißt: Ein Stück genügt.
Ein französisches CRM beschreibt seinen Telefonfilter als Suche nach einer enthaltenen Zeichenfolge – über Festnetz und Mobil zugleich, in einem einzigen Parameter.
Bei beiden wäre unsere Variantenliste theoretisch überflüssig. Wir schicken sie trotzdem: Der Motor entscheidet nicht je System, was er weglässt.
Was wir Herstellern deshalb schreiben
In jeder Anfrage an ein Softwarehaus steht derselbe Absatz:
Es ist die billigste Verbesserung, die ein Hersteller vornehmen kann – und die einzige, die jedem seiner Kunden gleichzeitig nützt.
Häufige Fragen
Warum findet mein CRM den Anrufer nicht?
Meistens, weil verglichen wird, was dasteht, statt was gemeint ist. Der Anrufer meldet sich als „+49 5251 2020505", im CRM steht „05251/2020505". Für einen Zeichenvergleich sind das zwei verschiedene Werte.
Wie sollte richtig verglichen werden?
Beide Seiten auf reine Ziffern reduzieren und über die letzten neun Stellen vergleichen. Damit fallen Ländervorwahl, führende Null, Klammern, Schrägstriche und Leerzeichen weg – und dieselbe Nummer bleibt dieselbe Nummer.
Warum neun und nicht acht?
Weil acht Stellen bei einer deutschen Nummer mitten in die Ortsvorwahl schneiden. Getroffen wird dann, wer zufällig dieselbe Ziffernfolge am Ende hat – und der falsche Name steht beim Klingeln auf dem Bildschirm.
Muss ich meine Rufnummern vorher aufräumen?
Nein. Genau das ist der Sinn: Der Vergleich soll die Schreibweisen aushalten, nicht der Bestand sie ablegen. Wer erst seine Datenbank normalisieren muss, hat das Problem an die falsche Stelle geschoben.