Clientes duplicados: qué comparar antes de fusionar

Para revisar clientes duplicados, compara primero identidad y función de cada ficha; después decide si hace falta fusionar. Un registro en ventas y otro en facturación pueden ser correctos. Lo que falta quizá sea una correspondencia fiable entre ambos.

El problema aparece cuando administración encuentra dos historiales parecidos y alguien propone quedarse con «el más completo». Una ficha puede contener el contacto actual; la otra, las referencias usadas por una integración. Elegir por cantidad de campos rellenos no resuelve ese conflicto. Esta guía entrega una matriz y un registro de decisiones para revisar el caso antes de modificarlo.

Una ficha por herramienta puede ser lo correcto

Distingue la misma entidad representada en dos sistemas de dos registros redundantes dentro de uno. El primer caso puede necesitar un mapa de correspondencias; el segundo, una investigación sobre el origen del duplicado. Ninguno autoriza a borrar una fila por su nombre.

Define también qué representa cada registro: organización, persona de contacto, sede o cuenta comercial. Una persona que trabaja en una empresa no es un duplicado de esa empresa. Dos sedes tampoco deben unirse si tu operación necesita tratarlas por separado.

Esta revisión encaja en la preparación de una migración, pero también sirve sin cambiar de herramienta. Su resultado puede ser conservar dos fichas y explicar su relación.

Conserva el origen antes de normalizar

Trabaja sobre una copia de lectura. Para cada fila guarda sistema, espacio de trabajo, tipo de registro, identificador original y fecha de extracción. CRM / W1 / account / A17 identifica algo distinto de BILL / W1 / account / A17: repetir el número no demuestra que sea el mismo cliente.

Mantén los valores originales y crea columnas auxiliares para comparar espacios, mayúsculas o variantes conocidas del nombre. No elimines sufijos, departamentos o referencias que puedan distinguir entidades. Un campo vacío significa «sin dato», no «coincide con otro vacío».

Anota de dónde procede cada señal. Un código común tiene más valor si conoces quién lo asignó y comprobaste su correspondencia. Un código copiado en una importación errónea puede propagar el mismo error a las dos fichas. La fecha de última edición tampoco convierte automáticamente un valor en correcto.

Una matriz con tres resultados y cuatro casos

El siguiente ejemplo es enteramente ficticio. Todos los registros pertenecen al espacio W1; los códigos ORG y EV son referencias de ejercicio, no identificadores fiscales ni datos de clientes. Las evidencias descritas se suponen disponibles solo para mostrar el razonamiento.

No asignes porcentajes de confianza inventados. «Probable» abre una revisión: no es una fusión aprobada. «Ambiguo» conserva el bloqueo y explica qué falta. Incluso cuando confirmes identidad, queda por decidir si hace falta modificar algo.

La ausencia de pedidos en una ficha tampoco prueba que sobre: puede ser un alta reciente o representar otra función. Clasifica con evidencia, no con el número de campos vacíos.

El mapa de alias no ejecuta una fusión

Supongamos que el responsable resuelve el primer caso: A17 y B62 representan a ORG-07, pero ambas herramientas necesitan su ficha. La decisión es conservarlas y registrar su correspondencia. En una hoja independiente, ENTITY-F07 puede ser tu referencia de trabajo:

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

Estas columnas son una plantilla propia, no un formato de importación de Frihet ni una orden para un conector. entity_key agrupa identidades revisadas; source_id conserva la referencia original. Un alias no modifica las herramientas por existir en una hoja.

No aplanes personas, empresas y sedes bajo la misma clave. Y no combines por transitividad sin revisar: si A se parece a B y B se parece a C, aún no has demostrado que A y C sean lo mismo.

Registra una decisión que otra persona pueda revisar

Copia esta ficha por cada par. Conserva la propuesta anterior cuando cambie la decisión, con una nueva versión que la sustituya.

Revisión: R-01 / versión 1
Referencias completas: CRM/W1/account/A17; BILL/W1/account/B62
Evidencia: EV-01; correspondencia ORG-07 comprobada por el responsable
Conflicto: contacto responsable distinto; valor vigente confirmado en EV-05
Decisión: conservar ambas fichas y registrar correspondencia ENTITY-F07
Responsable de revisión: ROLE-OPS
Acción en las herramientas: ninguna
Pendiente: revisar cómo usa esa correspondencia el conector
Sustituye a: ninguna revisión anterior

Los códigos son ficticios. En uso real, referencia evidencia accesible a quien debe revisarla y evita copiar datos personales innecesarios en la hoja. Si más tarde se autoriza una modificación, registra aparte ejecutor, momento, referencias anteriores y resultado observado. «Aprobado», «ejecutado» y «verificado» son estados distintos.

Este historial es revisable, no una garantía de reversión. Rectificar una decisión escrita no reconstruye automáticamente los datos ya modificados.

Qué comprobar en el proveedor antes de fusionar

El comportamiento depende del producto y del tipo de registro. HubSpot documenta que una fusión no puede deshacerse y que los identificadores, propiedades y asociaciones siguen reglas específicas. No presupongas que siempre sobrevive intacto el ID que marcaste como principal.

Shopify también advierte que la operación no es reversible y excluye ciertos perfiles, como los que tienen o han tenido contratos de suscripción. Estos ejemplos no describen el comportamiento de Frihet ni de tu otro proveedor.

Antes de cualquier acción irreversible, deja respondidas estas preguntas:

• ¿Está soportada esta combinación de tipos y tienes los permisos adecuados?
• ¿Qué valores se conservan, cuáles se descartan y qué ID tendrá el resultado?
• ¿Qué sucede con historial, relaciones y referencias externas?
• ¿Qué hará la sincronización: reconocer el cambio, recrear una ficha o fallar?
• ¿Qué recuperación existe realmente y qué no cubre tu copia?

Lee el alcance de las integraciones y comprueba el contrato del conector utilizado. Una función de lectura no demuestra que sepa propagar fusiones.

Cierra el caso comprobando también su origen

Si se autoriza una fusión, acuerda primero cómo limitar sus efectos sobre los sistemas conectados. Ensaya con datos sintéticos en un entorno de prueba compatible; si no existe, conserva el bloqueo hasta resolver las incógnitas con el proveedor. Una exportación aislada no demuestra que puedas restaurarlo todo.

Después de una modificación autorizada, compara campos y referencias con lo previsto y revisa la siguiente sincronización antes de ampliar el lote. Si el resultado es incierto, investiga antes de repetir la acción.

En la gestión de clientes de Frihet está disponible la exportación de la lista como CSV. Puede servir de entrada a una revisión; no presupone importación de esta plantilla ni fusión automática de clientes.

Cierra anotando por qué apareció el duplicado: alta manual, importación o regla del conector, si hay evidencia. Si todavía no lo sabes, deja un responsable y una comprobación pendiente. Dos fichas conservadas con una relación clara son un resultado válido; una lista más corta sin historial explicable no lo es.

Fuentes consultadas el 14 de septiembre de 2026. Revisa la documentación vigente de tu proveedor antes de operar.