Integrations in detail Rufnummernvergleich
Why the last nine digits decide everything
Three spellings, one number:
- 05251/2020505
- +49 5251 2020505
- +49 (0)5251 2020505
A human sees at once that this is the same line three times. A character comparison sees three different values. This is where most caller recognition fails — not at the interface, not at the phone system, but at one line of comparison logic.
What the comparison has to throw away
Between the number the network reports and the number in the customer record lie five kinds of difference:
- The country code — sometimes +49, sometimes 0049, sometimes absent.
- The leading zero of the area code, which disappears internationally.
- Separators: slash, hyphen, dot, space.
- Brackets around the zero — the worst, because they are both at once.
- The extension, sometimes appended, sometimes set off with a hyphen.
Throw all of that away and compare the last nine digits, and you hit the same person — without anyone having had to clean a database first.
Why nine and not eight
Eight would be more convenient. Eight would find more. Eight is wrong.
For +49 5251 2020505 the last eight digits are `12020505`. The cut lands in the middle of the area code. You then hit anyone who happens to carry the same trailing digits — somewhere in the country, in another town, with no relation to the caller.
And that stranger’s name is what appears when the phone rings. A wrong caller is worse than none — nobody double-checks a fact the system states confidently.
How differently vendors handle it
Checking more than forty systems reveals a wide range — from exemplary to unusable.
The strictest case
A Spanish accounting package writes about its phone filter, verbatim, that the value “must be an exact match, including special characters like '+', '#', and '-'”.
That is unambiguous — and harsh. A number held there as “+34 871 590159” will not be found by “+34871590159”. The space counts.
For systems like that the portal sends several spellings in sequence. With a system that does substring search those variants would be a safety net; here they are the function itself.
The exemplary case
Two systems solved the problem for us before we asked.
A German estate agency package holds a field of normalised phone numbers and states that you can search by a “fully or partially” normalised number. Normalised means the system tidies the spellings itself before comparing. Partially means a fragment is enough.
A French CRM describes its phone filter as a search for a contained string — across landline and mobile at once, in a single parameter.
With both, our list of variants is in theory unnecessary. We send it anyway: the engine does not decide per system what to leave out.
What we therefore write to vendors
Every enquiry we send to a software house carries the same paragraph:
It is the cheapest improvement a vendor can make — and the only one that helps every one of their customers at the same time.
Frequently asked questions
Why does my CRM not find the caller?
Usually because it compares what is written rather than what is meant. The caller arrives as “+49 5251 2020505”, the CRM holds “05251/2020505”. To a character comparison those are two different values.
How should the comparison work?
Reduce both sides to digits only and compare over the last nine. That drops the country code, the leading zero, brackets, slashes and spaces — and the same number stays the same number.
Why nine and not eight?
Because eight digits cut into the middle of a German area code. You then hit whoever happens to share the same trailing digits — and the wrong name is on screen while the phone rings.
Do I have to clean up my numbers first?
No. That is precisely the point: the comparison should tolerate the spellings, not the database avoid them. Anyone who has to normalise their data first has moved the problem to the wrong place.