Primero diagnostica de dónde salen los duplicados
Un duplicado no justifica por sí solo un CRM nuevo. Separa los datos históricos sucios, la configuración nativa de coincidencias y una integración que repite escrituras. Pausa las fusiones automáticas inseguras, conserva una exportación y prueba con registros ficticios antes de tocar datos reales.
| Síntoma observado | Primera comprobación | Siguiente paso proporcionado |
|---|---|---|
| Quedan duplicados antiguos; no aparecen nuevos | Historial de importación y mapeo de campos | Limpieza reversible con registro de fusiones; conservar relaciones y preferencias. |
| Escribir el mismo correo crea otro contacto | Reglas nativas de duplicados del plan contratado | Configurar y probar el CRM existente antes de crear un conector. |
| Cada reintento de webhook crea un registro | ID del evento, idempotencia y logs de reintentos | Reparar la integración; repetir un evento sin duplicar sus efectos. |
| Dos personas comparten un buzón de empresa | Política de identidad e identificadores adicionales verificados | Revisión manual; el correo solo no basta. |
Dos filas parecidas no siempre representan a la misma persona. Y dos consultas de una misma persona no siempre son el mismo trabajo. Antes de automatizar la deduplicación de un CRM, separa ambas preguntas: ¿a qué contacto pertenece esta información? y ¿ya procesamos este envío? Confundirlas puede borrar una nueva oportunidad o generar dos tareas para una sola petición.
1. Separa identidad y repetición
Un identificador de envío permite reconocer el mismo evento cuando llega otra vez. Una referencia estable del sistema de origen puede ayudar a reconocer un contacto dentro de ese sistema. Son claves distintas y deben conservar su contexto. No uses el nombre como identificador único ni una marca de tiempo aislada como prueba de que un mensaje es nuevo.
Si un contacto vuelve a pedir otro servicio, conserva la nueva consulta aunque lo vincules a una ficha existente. Si el formulario reenvía exactamente la misma petición por un reintento, no crees otra tarea. Define durante cuánto tiempo se recordarán los identificadores y qué ocurrirá con repeticiones más antiguas.
2. Define coincidencias y excepciones
- Referencia estable y compatible del origen: candidata a vinculación, comprobando que pertenece al mismo ámbito.
- Correo coincidente: señal útil, pero revisa buzones compartidos y datos contradictorios antes de automatizar.
- Mismo nombre con distinto correo: revisión humana; no fusionar por parecido.
- Teléfono compartido, reciclado o incompleto: no usar como prueba suficiente de identidad.
Conserva el valor original y documenta cualquier normalización. Quitar espacios exteriores de un campo validado puede ser razonable; eliminar puntos o etiquetas «+» no es una regla universal. RFC 5321 exige preservar las mayúsculas de la parte local del buzón: no conviertas todos los correos a minúsculas suponiendo que siempre identifican la misma dirección. La política debe ajustarse al sistema y sus datos.
3. Decide qué preservar antes de fusionar
Una coincidencia no autoriza a sobrescribir toda la ficha. Decide por campo qué fuente tiene autoridad y qué hacer si ambas discrepan. Conserva responsable, historial y procedencia. Una restricción de contacto no debe desaparecer porque llegue un formulario nuevo; recibir una consulta tampoco equivale a consentir campañas. Los datos dudosos deben quedar visibles para una persona con permiso para resolverlos.
Ejemplo ficticio: Alex Example figura con alex@example.test y una responsable de cuenta. Una consulta nueva desde esa dirección puede vincularse manteniendo a la responsable. Otra desde alex.other@example.test con el mismo nombre pasa a revisión. No se elimina ninguna consulta ni se fusionan las fichas automáticamente. Quien revise debe poder ver la razón de la coincidencia y registrar su decisión.
4. Recupera fallos sin repetir efectos
Un tiempo de espera no demuestra que la escritura haya fallado: el destino puede haber guardado el contacto antes de perderse la respuesta. Consulta el estado usando una referencia estable o utiliza el mecanismo de idempotencia documentado por el proveedor. RFC 9110 explica la idempotencia de los métodos HTTP; no convierte cualquier creación mediante POST en una operación segura para repetir.
Acuerda límites de reintento, responsable de las excepciones y un estado pendiente visible. Registra el identificador, la operación y el resultado necesario para investigar, evitando copiar información personal innecesaria en los logs. La protección contra duplicados también debe cubrir dos procesos simultáneos; buscar y después crear, sin una garantía de unicidad o coordinación, puede producir una carrera.
5. Ensaya antes de usar datos reales
- Repetir el mismo envío: una sola tarea y resultado recuperable.
- Nueva petición de un contacto conocido: conservar la petición y el responsable.
- Nombre igual y correo distinto: revisión sin fusión automática.
- Respuesta perdida después de guardar: comprobar destino antes del reintento.
- Permiso insuficiente o caída del destino: excepción visible, sin afirmar éxito.
- Dos envíos simultáneos: comprobar la regla de unicidad acordada.
Prueba con datos inventados y revisa el resultado en el destino, no solo el mensaje del conector. Prepara una copia recuperable antes de cualquier fusión real y comprueba qué permite deshacer cada herramienta. Las reglas, los permisos y las pruebas importan más que activar una opción genérica de «eliminar duplicados».
Convierte la política en un recorrido
Nuestra demo local permite explorar consulta nueva, contacto conocido, ambigüedad y fallo con reintento. Su recuperación es simulada y no valida un proveedor real. Para plantear tu caso, describe origen, destino, responsable y una excepción con datos ficticios; podremos revisar el alcance de una solución.
Probar la demo de consultas y seguimiento
Reproduce la decisión con cinco entradas
Ejercicio sintético, no una integración activa con un proveedor. Usa un ID estable del evento para los reintentos y otro identificador para el contacto. Estos IDs pertenecen a una fuente y un espacio de trabajo. Un contacto existente puede enviar una consulta nueva: no dedupliques consultas distintas por correo.
event_id | contact_id | email | enquiry
evt-01 | C-7 | ana@example.test | quote A
evt-01 | C-7 | ana@example.test | quote A
evt-02 | C-7 | ana@example.test | quote B
evt-03 | unknown | shared@example.test | quote C
evt-04 | unknown | missing | quote D| Entrada | Decisión esperada | Efecto esperado |
|---|---|---|
| 1: evt-01 | Evento nuevo y contacto C-7 conocido | Una consulta A asociada a C-7. |
| 2: evt-01 repetido | Evento ya completado | Sin nueva consulta ni tarea; devolver el resultado registrado. |
| 3: evt-02 | Evento nuevo, mismo contacto | Conservar B separada de A; no descartarla. |
| 4: buzón compartido | Identidad ambigua | Cola de revisión; no fusionar personas automáticamente. |
| 5: identidad ausente | Datos insuficientes | Conservar la consulta para revisión; no adivinar ni perderla. |
Aceptación: tras las cinco entradas hay dos consultas asociadas a C-7 y dos casos para revisión. Reintentar evt-01 no añade nada. Si la escritura se completa pero se pierde su confirmación, concilia el resultado registrado antes de reintentar. En un conector real, el registro del evento y la escritura deben ser atómicos cuando sea posible, o usar la clave de idempotencia admitida por el proveedor y conciliación. Un intento fallido no debe marcarse como completado.
Límites antes de fusionar registros reales
Nunca deduzcas consentimiento comercial de una coincidencia. Conserva bajas, IDs originales, responsables, relaciones e historial de la fusión. No conviertas universalmente a minúsculas la parte local del correo ni elimines puntos o etiquetas con +; aplica solo reglas verificadas para tus proveedores. Este ejercicio comprueba una política, no una API ni una migración de producción.
Probar la demo local y sintética de consultas
Revisar una configuración o integración existente
Comparar integración con un CRM nuevo solo si los requisitos lo justifican
Preparar entrada, excepción y aceptación en un brief
Método y revisión
Revisado por Taldrivo el 19 de septiembre de 2026. Esta guía combina un ejemplo sintético trabajado, nuestro software y las fuentes indicadas. No acredita resultados de clientes, precios de un proveedor ni compatibilidad con un plan sin comprobar.