CheckNumber.AI · 7 min read
Cómo hacer coincidir los resultados de verificación masiva de teléfonos con los registros del CRM
Cree un mapa local de origen a número, gestione números compartidos y reconcilie los resultados de verificación exportados con los registros correctos del CRM.
Para hacer coincidir los resultados de la verificación masiva de teléfonos con los registros del CRM, asigne identificadores de registro estables antes de preparar la carga y mantenga un mapa local desde cada número normalizado hacia cada registro de origen. Una los resultados exportados utilizando el número verificado y dicho mapa en lugar de la posición de la fila. Revise los casos sin coincidencia y los casos de muchos a uno antes de modificar los campos del CRM.
El problema de la coincidencia comienza antes de la carga
Una exportación de verificación telefónica responde a una pregunta sobre los números enviados; un CRM almacena personas, organizaciones, permisos e historial. Esos objetos están relacionados, pero no son la misma tabla. Un registro de CRM puede tener múltiples valores de teléfono y un número puede aparecer en múltiples registros. La normalización o la deduplicación también pueden cambiar el recuento y el orden de las filas enviadas. Si el equipo planea pegar las filas devueltas sobre la exportación original del CRM según la posición de la hoja de cálculo, incluso una verificación limpia podría actualizar el contacto equivocado.
Cree una clave de registro interna estable antes de transformar nada. Si el CRM tiene un identificador de registro duradero, expórtelo junto con los campos de teléfono. Si el origen carece de uno, asigne una clave temporal en una tabla de preparación local protegida y conserve la exportación original. Incluya la identidad del campo de teléfono cuando un registro tenga varios números. La tabla de preparación es propiedad del equipo; no es una afirmación de que CheckNumber.AI acepte identificadores personalizados en cada producto o los devuelva en un esquema particular.
Construir un mapa de número a registro
Para cada valor de teléfono, mantenga el identificador de registro de origen, el nombre del campo de origen, el texto original, el número normalizado, el contexto del país y el estado de preparación. Cree una tabla de búsqueda separada codificada por el número normalizado que enumere todos los identificadores de registro de origen y campos correspondientes. Un número verificado único puede relacionarse con varias personas, como la centralita de una empresa. No fusione esos contactos simplemente porque comparten el número. Por el contrario, una persona con un móvil y una línea de oficina necesita dos posibles resultados a nivel de número.
Prepare la entrada masiva utilizando la guía actual del producto. El flujo de trabajo de lista de teléfonos de CheckNumber.AI documentado utiliza CSV o TXT y un número por línea con código de país, con un país por archivo. Se debe consultar la documentación de la API para conocer el flujo de trabajo admitido actualmente y los límites aplicables al realizar la integración mediante programación. Este artículo evita deliberadamente asumir una carga útil de solicitud, un nombre de campo de resultado o un sobre de respuesta que no haya sido verificado para el verificador seleccionado. Mantenga el archivo de carga, el mapa local, el producto seleccionado y la fecha de verificación asociados con un identificador de lote interno.
Normalizar la clave de unión de forma consistente
El número enviado para su verificación y el número utilizado para buscar un resultado deben representarse de forma consistente. Por ejemplo, la puntuación de visualización opcional y el signo más inicial opcional no deberían crear identidades locales separadas cuando el número con código de país subyacente es el mismo. Utilice una rutina de normalización para la carga preparada y para la importación de resultados, y conserve los valores sin procesar junto con las claves normalizadas. Pruebe un ciclo de ida y vuelta de muestra antes de procesar toda la exportación.
Nunca dependa del orden de las filas de resultados. Un servicio puede devolver filas en un orden diferente y un equipo puede deduplicar intencionalmente la entrada. En su lugar, lea el resultado a nivel de número, derive su clave normalizada y realice la unión a través del mapa local. Si un resultado no puede coincidir exactamente con la clave prevista, reténgalo para su revisión. Si varias filas de resultados se asignan a una clave pero no coinciden, investigue en lugar de elegir la última fila. Si un resultado se asigna a muchos registros del CRM, distribuya la señal con cuidado mientras conserva cada registro como una entidad distinta.
Aplicar una señal específica del producto con el significado correcto
Diferentes productos de CheckNumber.AI proporcionan diferentes señales. Una verificación de validez telefónica, una señal de actividad y una verificación de registro en plataforma no deben almacenarse como si fueran un valor booleano universal. Registre qué verificador nombrado produjo cada resultado y la fecha en que se obtuvo. Una señal de registro específica de la plataforma puede informar la planificación del canal en el momento de la verificación; no verifica la identidad, la propiedad, el consentimiento, la accesibilidad futura ni la entrega de mensajes. Una señal de actividad puede respaldar la priorización, pero no puede prometer una respuesta.
Decida cómo representará el CRM un resultado de revisión antes de volver a escribir los valores. Un equipo puede utilizar un estado interno como revisión necesaria o verificado en fecha, pero esas son etiquetas de CRM sugeridas, no campos de salida del producto. No sobrescriba un registro de consentimiento, una preferencia de contacto verificada o un campo de teléfono confirmado por una persona simplemente porque una verificación devolvió un resultado incierto. Mantenga el resultado exportado sin procesar y la interpretación local por separado para que los revisores posteriores puedan ver lo que devolvió el servicio frente a lo que decidió el equipo.
Reconciliar excepciones y hacer que las actualizaciones sean reversibles
Realice recuentos en cada etapa: valores de teléfono de origen, valores excluidos o ambiguos, números únicos cargados, filas devueltas, claves de resultados coincidentes, claves sin coincidencia y registros del CRM propuestos para actualización. Estos recuentos diferirán por razones legítimas. La prueba importante es que cada diferencia pueda explicarse mediante un mapa documentado o una decisión de revisión. Muestree números compartidos, múltiples campos de teléfono, divisiones por país y valores faltantes.
Antes de una actualización masiva del CRM, genere un archivo de cambios propuestos que contenga el identificador de registro, el campo de teléfono, el estado interno anterior, el nuevo estado interno, el lote de origen y la decisión del revisor. Mantenga los datos de origen protegidos y siga la política de retención de la organización. Utilice un proceso de actualización reversible para que un error de asignación pueda corregirse. Los equipos pueden revisar el producto Number Checker para obtener una señal adecuada a nivel de número y, a continuación, implementar la reconciliación del CRM como su propio flujo de trabajo de datos controlado. El valor de la verificación depende de realizar esa asociación final correctamente, no de la rapidez con la que se puedan pegar las filas.
Para cada actualización propuesta, haga que un revisor confirme que el identificador de origen todavía existe, que el campo de teléfono previsto no ha cambiado desde la exportación y que el lote pertenece al mismo país y producto. Si el registro del CRM cambió mientras tanto, pause la actualización y vuelva a evaluar la asignación.
Preguntas frecuentes
¿Cómo pueden los equipos unir resultados cuando las filas de carga fueron deduplicadas?
Mantenga un mapa desde cada número normalizado único hacia todos los identificadores de registro de origen y campos de teléfono. Una el resultado a nivel de número con la clave y, a continuación, expándalo a los registros asignados.
¿Se puede utilizar el orden de las filas de resultados como clave de CRM?
No. Utilice identificadores de origen estables y claves de números normalizados. El orden de las filas puede cambiar durante la preparación, la deduplicación o la exportación.
¿Qué debería suceder cuando varios contactos comparten un número?
Conserve cada registro de contacto. La misma señal a nivel de número puede estar asociada con varios registros, pero no prueba que representen a una sola persona.
¿Cómo se debe manejar un resultado sin coincidencia?
Reténgalo para su revisión, compare los números sin procesar y normalizados, y verifique el mapa del lote. No actualice un registro de CRM a partir de una coincidencia incierta.
