Las integraciones en detalle Telefonfelder im CRM
El primer campo de teléfono casi siempre es el equivocado
En casi todas las fichas de cliente el fijo va primero. Hay razones históricas para ello y no es culpa de nadie: el formulario se hizo cuando el fijo era la norma.
Aun así, se llama desde el móvil.
Por qué esta cifra provocó una decisión
Es la razón por la que uno de los ERP más extendidos no se consulta aquí de forma directa, aunque sabe filtrar.
Su documentación dice expresamente que un OR no puede abarcar dos campos distintos. Así que allí una búsqueda podría consultar el fijo o el móvil. Nunca los dos.
Con un 98,6 por ciento detrás, eso ya no es una ponderación. Una búsqueda que se pierde justo los móviles sería técnicamente impecable y prácticamente inútil, y no anunciaría su fracaso: diría simplemente «contacto no encontrado».
Por eso allí funciona una sincronización nocturna. En nuestra tabla no rige restricción de campo y la grafía se unifica al guardar. El precio se dice abiertamente: la información es tan reciente como la última ejecución.
Tres tipos de sistema
Tras revisar más de cuarenta interfaces, se dividen en tres grupos.
Primero: los que obligan a elegir
Permiten exactamente una condición por consulta, o combinan varias con AND — lo que con dos campos de teléfono no encuentra nunca nada, porque el mismo número no está en ambos.
Para esos sistemas el archivo de descripción indica el campo del fijo, con una frase debajo que explica por qué. No porque sea la mejor opción, sino porque hay que elegir una.
Segundo: los que permiten OR entre campos
Aquí lo preguntamos todo de una vez. Un fabricante del entorno Microsoft mantiene cuatro columnas de teléfono en el contacto — trabajo, particular, una tercera y el móvil — y su lenguaje de filtros permite expresamente `and`, `or` y `not`. Así que consultamos las cuatro en una sola petición.
El fax queda fuera a propósito. Nadie llama desde un fax, y cada condición adicional cuesta tiempo mientras suena el teléfono.
Tercero: aquellos en los que la pregunta no se plantea
El grupo agradable. Un CRM francés describe su filtro de teléfono como una búsqueda en fijo y móvil a la vez: un parámetro, ambos campos. Un programa alemán para inmobiliarias mantiene una lista de todos los números normalizados de una dirección, expresamente «incluidos el principal, el móvil, etc.».
En estos sistemas la pregunta por el primer campo carece de sentido. La respondieron para sus clientes antes de que nadie preguntara.
Qué significa esto para un fabricante
En cada consulta que enviamos a una empresa de software va por eso una frase que al principio suena trivial:
No es trivial. Decide si una identificación de llamadas funciona en el día a día o solo en la demostración.
Preguntas frecuentes
¿Por qué no basta con buscar en el primer campo de teléfono?
Porque en el primer campo suele estar el fijo y la gente llama desde el móvil. En una sede medimos que el 98,6 por ciento de las llamadas identificadas eran números móviles.
¿Y si mi CRM solo puede buscar en un campo?
Entonces la búsqueda por número es prácticamente inútil: impecable en teoría y ciega en el día a día. Para esos sistemas el portal ejecuta una sincronización nocturna en lugar de una consulta directa, porque en nuestra propia tabla no rige ninguna restricción de campo.
¿Cómo sé si mi sistema puede con ambos?
Por su lenguaje de filtros. Si permite un OR entre dos campos distintos, basta una consulta. Si la documentación dice que el OR solo vale dentro de un campo, hay que elegir — y cualquier elección es equivocada.
¿Vale también para los números de fax?
No, y es el único caso en el que dejamos fuera un campo a propósito: nadie llama desde un fax. Cada condición adicional cuesta tiempo mientras suena el teléfono.