Integrations in detail Telefonfelder im CRM
The first phone field is almost always the wrong one
In almost every customer record the landline comes first. There are historical reasons for that and nobody is to blame — the form was built when landlines were the rule.
People still call from their mobiles.
Why this figure triggered a decision
It is the reason one of the most widespread ERP packages is not queried directly here, although it can filter.
Its documentation states explicitly that an OR cannot span two different fields. So a number search there could query the landline or the mobile. Never both.
With 98.6 per cent behind it, that is no longer a trade-off. A search that misses precisely the mobile numbers would be technically flawless and practically worthless — and it would not report its failure, it would simply say “contact not found”.
So a nightly sync runs there instead. In our own table no field restriction applies, and the spelling is normalised on storage. The price is stated openly — the answer is only as fresh as the last run.
Three kinds of system
After more than forty interfaces checked, they fall into three groups.
One: those that force a choice
They allow exactly one condition per query, or they combine several with AND — which never finds anything across two number fields, because the same number is not in both.
For those systems the description file names the landline field, with a sentence below explaining why. Not because it is the better choice, but because a choice has to be made.
Two: those that allow OR across fields
Here we ask for everything at once. One vendor in the Microsoft world holds four number columns on a contact — business, home, a third one and the mobile — and its filter language explicitly allows `and`, `or` and `not`. So we query all four in one request.
Fax is deliberately left out. Nobody calls from a fax machine, and every extra condition costs time while the phone rings.
Three: those where the question does not arise
The pleasant group. A French CRM describes its phone filter as searching landline and mobile at once — one parameter, both fields. A German estate agency package keeps a list of all normalised numbers of an address, explicitly “including main, mobile, etc.”.
With these systems the question about the first field is moot. They answered it for their customers before anyone asked.
What this means for a vendor
Every enquiry we send to a software house therefore carries a sentence that sounds banal at first:
It is not banal. It decides whether caller recognition works in daily use or only in the demo.
Frequently asked questions
Why is searching the first phone field not enough?
Because the first field usually holds the landline and people call from mobiles. At one site we measured 98.6 per cent of resolved callers as mobile numbers.
What if my CRM can only search one field?
Then the number search is practically worthless — flawless in theory and blind in daily use. For such systems the portal runs a nightly sync instead of a direct query, because no field restriction applies in our own table.
How do I tell whether my system can do both?
By its filter language. If it allows an OR across two different fields, one query is enough. If the documentation says OR only works within one field, you have to choose — and every choice is wrong.
Does that include fax numbers?
No, and it is the one case where we deliberately leave a field out: nobody calls from a fax machine. Every extra condition costs time while the phone is ringing.