Si ventas revisa una y otra vez los mismos contactos, deduplicar puede liberar trabajo. Pero reducir filas no demuestra que la limpieza sea correcta: una fusión equivocada puede mezclar responsables, oportunidades e historial de dos clientes. Mi punto de partida es acordar qué significa «el mismo lead» para esa operación.
Esta guía se centra en la identidad y calidad de los registros antes de entregarlos. El recorrido completo, desde la extracción hasta la escritura en destino, está en la guía de pipeline de datos desde scraping hasta CRM.
Duplicado, spam e incompleto son decisiones distintas
Un duplicado representa una entidad ya conocida. Un registro fuera del segmento puede ser válido, aunque no sirva para tu operación. Un teléfono ausente significa información incompleta; no demuestra que el negocio sea falso. Una dirección genérica de correo tampoco convierte por sí sola un contacto en spam.
Separo la decisión de identidad de la de calidad: «misma empresa» y «pendiente de verificar» pueden coexistir. Cada descarte necesita una razón comprobable. Mantengo los casos dudosos en revisión y acuerdo qué evidencia conservar, durante cuánto tiempo y quién puede consultarla.
Define la entidad antes de comparar nombres
Empresa, establecimiento, persona y oportunidad comercial necesitan identidades distintas. Dos sucursales pueden compartir dominio y centralita. Un intermediario puede publicar anuncios de varios negocios. La coincidencia sirve para encontrar candidatos, pero no basta para fusionarlos.
Conservo el valor original y una versión normalizada para comparar. El país del teléfono debe conocerse; los campos vacíos no cuentan como coincidencias. Normalizar espacios o formatos no permite eliminar partes significativas de un correo, una dirección o un nombre. Registro la fuente, su identificador, la captura y la versión de la regla.
Qué fusionar, qué separar y qué revisar
Ejemplo hipotético: un importador recibe fichas de establecimientos de varias fuentes autorizadas. Estas decisiones propuestas deben probarse con una muestra etiquetada por operaciones; no son umbrales universales.
| Situación | Decisión propuesta | Comprobación |
|---|---|---|
| Misma fuente e ID estable | Actualizar la ficha de origen existente. | Confirmar que el proveedor no recicla IDs; esto no resuelve por sí solo la identidad entre fuentes. |
| Mismo dominio, distintas sucursales | Mantener establecimientos separados. | Relacionarlos con su empresa matriz solo si existe evidencia. |
| Mismo teléfono, nombres distintos | Enviar a revisión. | Descartar centralita compartida, intermediario o número reasignado. |
| Nombre parecido, dirección incompleta | No fusionar automáticamente. | Buscar evidencia adicional o mantener el caso sin resolver. |
| Identidad confirmada, datos contradictorios | Resolver los campos antes de aplicar cambios. | Conservar la corrección validada y documentar la propuesta entrante. |
Un score ordena candidatos; no es una probabilidad demostrada ni una autorización de fusión. Si A se parece a B y B a C, no asumo que A, B y C sean una sola entidad. Las contradicciones de todo el grupo deben revisarse. Salesforce explica la diferencia entre duplicados y falsos positivos; la regla concreta depende del modelo de datos del negocio.
Qué información conserva una fusión
Antes de modificar el CRM, preparo una vista previa: registros afectados, entidad resultante, valores que cambian y asociaciones que se moverían. Acordamos quién tiene autoridad sobre cada campo. Una importación más reciente no debe sustituir sin revisión un teléfono verificado por ventas ni cambiar el responsable de una oportunidad.
Guardo la decisión, regla aplicada, responsable y correspondencia entre IDs anteriores y actuales dentro de la política de conservación acordada. Eso facilita investigar un error, pero no garantiza poder deshacerlo. HubSpot documenta que sus registros fusionados no se pueden separar mediante una operación de deshacer. Comprueba las consecuencias en el CRM concreto antes de activar fusiones automáticas; un CSV previo no restaura necesariamente asociaciones, actividades o efectos externos.
La revisión humana necesita una salida
La cola debe mostrar los valores originales, las diferencias y el motivo de la propuesta. El revisor puede confirmar identidad, mantener entidades separadas o pedir más información. «Sin resolver» no equivale a aprobado. Si no hay capacidad para revisar, el flujo debe retener los casos pendientes.
Conservo también las decisiones de «no fusionar» para no proponer el mismo par en cada importación, salvo que cambie evidencia relevante. Asigno un responsable y vigilo la antigüedad de la cola. La decisión de identidad no autoriza por sí misma un envío comercial.
Cómo aceptar un piloto de deduplicación
Primero ejecuto las reglas sin escribir cambios y comparo sus propuestas con una muestra revisada por el equipo. Reservo ejemplos para evaluar que no se hayan usado al ajustar las reglas. Estas son pruebas propuestas para el ejemplo anterior:
- Repetición: importar de nuevo una ficha conserva su identidad y no crea otra entidad.
- Sucursales: dos establecimientos con dominio compartido permanecen separados.
- Campos vacíos: dos teléfonos ausentes no producen una coincidencia.
- Contradicción: un teléfono compartido con direcciones incompatibles llega a revisión.
- Corrección humana: una nueva captura conserva el dato verificado y muestra el conflicto.
- Fusión equivocada: el equipo puede identificar los cambios y ensayar la recuperación disponible, documentando lo que no puede restaurar.
Mido falsos positivos entre las propuestas revisadas, duplicados conocidos que se escaparon y esfuerzo de revisión por fuente. Los umbrales se acuerdan según el daño de una fusión errónea y la capacidad del equipo. Una muestra sin errores no demuestra precisión perfecta en toda la base.
La calidad debe mantenerse después de la limpieza
Un cambio de fuente o parser puede alterar nombres, IDs o direcciones y disparar coincidencias falsas. Versiono reglas y reviso una muestra cuando cambian las entradas. La guía de mantenimiento de scrapers cubre esa capa de extracción.
El caso Adslyfy muestra estados y evidencia operativa en monitorización de anuncios. Sirve como referencia de trazabilidad; no es un caso de deduplicación de CRM ni acredita una tasa de acierto.
Una identidad correcta todavía puede generar trabajo repetido si falla una entrega. Comprueba por separado los reintentos y resultados inciertos con las pruebas de aceptación del pipeline CRM.
Qué contratar y qué debe incluir la propuesta
Si las funciones de tu CRM cubren la entidad, reglas y revisión necesarias, empieza por configurarlas y probarlas. El desarrollo a medida tiene sentido cuando debes resolver identidades entre fuentes, aplicar políticas propias o integrar una cola de revisión. Ese trabajo encaja en mis servicios de integración de APIs y CRM.
Pide el modelo de entidades, reglas versionadas, muestra de evaluación, vista previa de cambios, límites de recuperación y responsable del mantenimiento. Separa construcción, revisión humana y operación al comparar presupuestos de software. Si falta una dirección técnica común entre equipos y proveedores, puede encajar el apoyo de CTO externo.
El siguiente paso: revisar tus casos difíciles
Para valorar el alcance, cuéntame dónde aparecen los duplicados y prepara ejemplos sintéticos o anonimizados de un duplicado real, dos registros parecidos que deban seguir separados y una corrección manual. Puedo revisar contigo las reglas, los sistemas implicados y qué debería demostrar una primera entrega.