Consulta del operador original para CRM: adición de campos de operador original y tipo de línea

Una guía de diseño de campos y flujo de trabajo para equipos de operaciones de CRM que deseen añadir el operador original, el operador subyacente, el tipo de número y la región de asignación a los registros de contacto mediante comprobaciones síncronas y tareas de archivo.

Una consulta del operador original para CRM añade contexto de asignación a cada contacto: el operador al que se asignó originalmente el rango de numeración, el operador subyacente cuando una marca opera bajo otra red, el tipo de número (como móvil o línea fija) y la región y ciudad de asignación. La configuración práctica consta de tres partes: crear campos personalizados con nombres claros, ejecutar comprobaciones síncronas a medida que llegan nuevos registros y procesar la base de datos existente una vez mediante una tarea de archivo. Los valores vacíos deben almacenarse como no disponible, y cada campo debe tratarse como contexto para la agrupación y revisión, no como prueba de que se puede contactar a un contacto.

Diseño de los campos del CRM antes de realizar cualquier consulta del operador

La mayoría de las guías sobre este tema pasan directamente a llamar a una API y dejan el diseño de los campos al azar. Los nombres de los campos determinan cómo leerán los datos sus colegas años después, así que defínalos primero.

Utilice las palabras "original" y "asignación" en las etiquetas para que nadie interprete el operador como la red actual ni la región como el lugar donde vive el contacto. En HubSpot, los tipos de campo de propiedad como texto de una línea, selección desplegable y selector de fecha cubren todas estas necesidades; Salesforce ofrece lo equivalente a través de campos personalizados.

Preparación de los campos telefónicos para la consulta

Una consulta es tan buena como su entrada. Antes de la primera ejecución, compruebe cómo se almacenan los números de teléfono en el CRM:

1. Elija un campo de origen. Los contactos suelen tener campos de Teléfono, Móvil y un campo de texto libre "otro". Decida cuál alimenta la consulta o cree un registro de consulta por cada campo.
2. Normalice a E.164. Elimine espacios y puntuación, elimine los prefijos nacionales y añada un signo más y el código de país, por ejemplo +447700900123. El formato está definido en ITU-T Recommendation E.164.
3. Almacene el valor normalizado por separado de la entrada original, para que los usuarios de ventas sigan viendo lo que escribió el contacto.
4. Elimine duplicados a nivel de número, de modo que un número compartido por varios contactos se compruebe una vez y se escriba en cada uno.
5. Anote el país de cada número a partir de su código de país. Las comprobaciones síncronas no lo necesitan, pero las tareas de archivo sí.

Los registros que no se puedan normalizar deben mantener el estado "no comprobado" con un motivo, en lugar de enviarse y ser rechazados.

Nuevos registros: comprobaciones síncronas dentro del flujo de trabajo del CRM

Los nuevos contactos llegan de uno en uno a través de formularios, importaciones o integraciones, por lo que una comprobación síncrona es lo más adecuado. Patrones típicos:

• Webhook de flujo de trabajo o middleware. Cuando se crea un registro o cambia su campo de teléfono, su servidor de integración llama a POST /api/v1/check para un número y escribe el resultado en los campos del CRM.
• Micro-lotes programados. Cada pocos minutos, recopile nuevos registros y envíe de 1 a 100 números E.164 a POST /api/v1/batch-check. Los resultados se devuelven en el orden de entrada, así que asígnelos a los registros por posición o por el número que envió.
• Revisión manual. Un usuario de operaciones puede pegar hasta 500 números en el área de lotes en tiempo real del panel para una comprobación rápida.

Mantenga la X-API-Key en su servidor de integración; nunca la coloque en un script del lado del cliente del CRM o en una extensión del navegador. La API pública documenta un número reducido de espacios compartidos en vuelo y una solicitud múltiple por cuenta a la vez, por lo que debe poner en cola las consultas en lugar de lanzar una por registro durante una importación grande.

Base de datos existente: una tarea de archivo por país

Para el catálogo anterior, exporte los números normalizados y procéselos como tareas de archivo en lugar de miles de llamadas síncronas.

1. Agrupe por código de país. Una tarea de archivo utiliza un país seleccionado y las filas fuera de él se excluyen, así que cree una exportación por país.
2. Escriba un número por línea en un TXT o CSV de una columna, como dígitos simples con el código de país.
3. Envíe cada archivo en el panel o con POST /api/v1/bulk-tasks, enviando el país antes del archivo en solicitudes multipart.
4. Consulte GET /api/v1/bulk-tasks/{id} no más de una vez cada 30 segundos.
5. Descargue el CSV de cada tarea completada e impórtelo en el CRM, haciendo coincidir el identificador de dígitos simples con su campo normalizado.

El preprocesamiento elimina filas no válidas, duplicados y números sin código de país, y esas filas excluidas no se cobran. Se aplican límites por producto en cuanto al tamaño de la lista y del archivo, así que consulte la documentación de la API antes de decidir cómo dividir una exportación grande. Los países cuyos números solo se admiten para comprobaciones síncronas, como China continental, Hong Kong y Macao, deben pasar por la ruta síncrona.

Escritura correcta de resultados vacíos e indeterminados

Tres resultados parecen similares en una hoja de cálculo pero significan cosas diferentes en un CRM:

En una solicitud múltiple síncrona, una fila sin un resultado normal pertenece al grupo de no disponible, no a una lista de números incorrectos. Nunca sobrescriba valores anteriores correctos con espacios en blanco de un intento indeterminado posterior. Las consultas fallidas o indeterminadas no generan cargos, por lo que un reintento limitado, por ejemplo, unos pocos intentos a lo largo de un día, es razonable.

Uso de los nuevos campos en segmentos e informes

Con los campos ya configurados, los equipos de CRM suelen crear:

• Segmentos por tipo de número, para que los contactos de línea fija vayan a secuencias basadas en llamadas y los rangos móviles vayan a canales que requieran un número móvil.
• Grupos de operadores para comparar informes de entrega de proveedores de mensajería, teniendo en cuenta que los números portados permanecen dentro del grupo de operador original.
• Colas de revisión para registros con un estado de completado-vacío o indeterminado antes de realizar contactos de alto valor.
• Paneles de calidad de datos que muestran la proporción de registros comprobados, completados y no disponibles por país.

Estos campos sirven de apoyo para la agrupación y la toma de decisiones de revisión. No establecen que un contacto sea alcanzable, que el número pertenezca a la persona nombrada o que el contacto haya aceptado ser contactado, por lo que las comprobaciones de consentimiento y propiedad permanecen en sus propios campos y procesos.

Preguntas frecuentes

¿Con qué frecuencia deben los equipos de CRM volver a ejecutar las consultas de operador en los registros existentes?

El operador asignado originalmente describe el rango de numeración y no cambia cuando se porta un número, por lo que una actualización completa frecuente aporta poco. Vuelva a comprobar un registro cuando cambie su número de teléfono, cuando el estado almacenado sea indeterminado o cuando la fecha de consulta sea lo suficientemente antigua como para que su equipo desee un contexto actualizado para una campaña específica. Un campo de fecha de consulta facilita este filtrado, y comprobar solo los registros cambiados o indeterminados mantiene el volumen bajo.

¿Debe el CRM sobrescribir el operador original cuando un contacto dice que cambió de red?

No. El campo de operador original describe el operador al que se asignó el rango por primera vez, lo cual permanece igual después de una portabilidad. Si la red que utiliza un contacto hoy es importante para su equipo, regístrela en un campo separado con su propia fuente y fecha, como una nota del contacto. Mantener los dos valores separados evita que los informes mezclen el contexto de asignación con la información declarada por el propio usuario.

¿Cómo pueden los equipos conectar un asistente de IA a los mismos datos de consulta?

El endpoint oficial de MCP permite que un asistente de IA ejecute comprobaciones síncronas de 1 a 100 números y lea el saldo, utilizando la misma cuenta y límites que la API REST. No ofrece una herramienta de tareas de archivo, por lo que una actualización de toda la base de datos debe seguir realizándose a través del panel o la API de carga masiva. Los asistentes son útiles para comprobaciones ad-hoc durante la revisión de registros, con resultados escritos por una persona o una integración.

Más información

Elija la información del producto que se ajuste al siguiente paso de su flujo de trabajo.

• Ver la documentación del producto →
• Hablar con el equipo →