Limpieza de Datos para Migración de CRM: Deduplicación, Normalización, Enriquecimiento

Una migración de CRM es la mejor oportunidad que tendrá para corregir la calidad de sus datos. La mayoría de los equipos la desperdician porque tratan la limpieza como una tarea post-migración, algo que manejarán después del go-live cuando las cosas se calmen. Las cosas nunca se calman. El backlog post-migración nunca se limpia. Y seis meses después, los representantes trabajan desde un sistema nuevo que tiene los mismos datos malos que el anterior, más los nuevos errores introducidos durante la importación.

La responsable de RevOps de una empresa ejecutó una migración de 8.000 contactos de HubSpot a un nuevo CRM. Encontró 2.400 contactos duplicados después de la importación. Una sesión de deduplicación de 3 horas antes de la exportación lo habría evitado. En cambio, la limpieza tomó tres semanas y requirió una reimportación parcial. (Si está migrando específicamente desde HubSpot, cambiar de HubSpot a Rework detalla las diferencias del modelo de datos que hacen que este paso de limpieza sea aún más importante.)

Esta guía le proporciona la secuencia de limpieza que previene ese resultado. Trabaje estos pasos en orden en su sistema de origen. No exporte un solo registro hasta haber terminado.

Paso 1: Estrategia de Deduplicación

La deduplicación tiene dos fases: identificar duplicados y decidir qué hacer con ellos. No fusione nada hasta tener una regla de decisión clara para cada tipo de coincidencia.

Jerarquía de reglas de coincidencia:

  1. Coincidencia exacta de email: Dos registros con el mismo email son casi con certeza la misma persona. Se puede fusionar automáticamente. El registro con más campos completos (más campos no vacíos) gana.
  2. Coincidencia difusa de nombre + apellido + empresa: Dos registros donde el nombre es similar (John Smith vs. Jonathan Smith) y el nombre de la empresa es igual o similar. Poner en cola para revisión manual — no fusionar automáticamente.
  3. Coincidencia de teléfono: El mismo número de teléfono en dos registros diferentes. Menor confianza que el email — los teléfonos fijos de empresa aparecen en muchos contactos. Solo revisión manual.
  4. Coincidencia de dominio de empresa en el mismo contacto: Dos registros para "Sarah Jones" y "S. Jones" en el mismo dominio de email. Confianza media. Revisión manual.

Tabla de Lógica de Decisión para Deduplicación

Tipo de coincidencia Confianza Acción
Coincidencia exacta de email Alta Fusión automática — mantener registro con más datos
Coincidencia difusa nombre + empresa (>85% similitud) Media Poner en cola para revisión manual
Coincidencia exacta de teléfono, misma empresa Media Poner en cola para revisión manual
Solo nombre (sin empresa, sin email) Baja Marcar, no fusionar automáticamente
Solo coincidencia de dominio de email Baja Omitir — demasiados falsos positivos

Umbral de fusión automática: Configure la fusión automática solo para coincidencias exactas de email. Cualquier cosa por debajo de eso requiere revisión humana. Una fusión automática agresiva que combina incorrectamente a dos personas diferentes en la misma empresa corrompe el historial de oportunidades y los datos de relaciones de maneras difíciles de resolver.

Paso 2: Herramientas para la Deduplicación

La elección de herramienta depende de su sistema de origen y del tamaño del conjunto de datos.

HubSpot (nativo): Contactos > Acciones > Administrar Duplicados. HubSpot presenta pares para revisión con una comparación lado a lado. Maneja la fusión de forma nativa — usted elige el registro ganador y conserva todo el historial de asociaciones. Límite: procesa un par a la vez, lo que es manejable hasta unos 5.000 contactos pero lento más allá de eso.

Salesforce (nativo): Configuración > Gestión de Duplicados. Defina una Regla de Duplicados (campo de coincidencia: Email, tipo de coincidencia: Exacta) y ejecútela como informe. Use la herramienta de Fusión de Contactos para fusiones individuales. Para deduplicación masiva en Salesforce, las herramientas nativas son limitadas — para conjuntos de datos de más de 10.000 contactos, una herramienta de terceros es más rápida. La guía de Salesforce Data Loader vale la pena leerla antes de cualquier operación masiva para entender cómo la herramienta maneja la resolución de conflictos.

Pipedrive (soporte nativo limitado): Pipedrive marca posibles duplicados en la vista de contactos pero no tiene una herramienta de deduplicación masiva. Exporte a CSV, ejecute la deduplicación en una hoja de cálculo o herramienta de terceros, luego reimporte el archivo limpio.

Herramientas de terceros para conjuntos de datos grandes:

  • Dedupely (dedupely.com): Diseñado específicamente para HubSpot y Salesforce. Maneja la fusión masiva con automatización basada en reglas. Bueno para 10.000+ registros.
  • Dedupe.io: Funciona con exportaciones CSV de cualquier CRM. Cargue su archivo, configure las reglas de coincidencia, descargue el archivo deduplicado. $0,01–0,02 por registro para lotes grandes.
  • Cloudingo (cloudingo.com): Específico para Salesforce. Mejor interfaz que las herramientas nativas para reglas de fusión complejas.

Antes de ejecutar cualquier herramienta de deduplicación: exporte una copia de seguridad completa. Descargue cada objeto como CSV. Guárdelo en un lugar accesible. No puede deshacer de forma fiable una fusión masiva, y querrá el estado previo a la fusión si algo sale mal.

Paso 3: Normalización de Números de Teléfono

Los campos de teléfono son los datos más desordenados en cualquier CRM. Encontrará: +1 (555) 234-5678, 555-234-5678, 5552345678, +15552345678, 555.234.5678 x102 y (555) 234-5678. El mismo número, siete formatos diferentes.

Estándar objetivo: Formato E.164. Este es el estándar internacional: + seguido del código de país seguido del número de abonado, sin espacios ni caracteres de formato. Número de EE. UU. en E.164: +15552345678.

Pasos de normalización:

  1. Elimine todos los caracteres no numéricos: quite (, ), -, ., espacios
  2. Si el número tiene 10 dígitos y su base está en EE. UU., anteponga +1
  3. Si el número comienza con 1 y tiene 11 dígitos, anteponga +
  4. Compruebe extensiones en el campo de teléfono principal — cualquier cosa después de "x", "ext" o "Ext" — extráigala a un campo de extensión separado

Expresión regular para limpieza básica de teléfonos (funciona en Google Sheets mediante REGEXREPLACE):

Eliminar caracteres no numéricos: =REGEXREPLACE(A2,"[^0-9+]","")

Comprobar número de 10 dígitos de EE. UU.: =IF(LEN(REGEXREPLACE(A2,"[^0-9]",""))=10, "+1"&REGEXREPLACE(A2,"[^0-9]",""), A2)

Para conjuntos de datos grandes, un script de Python que use la biblioteca phonenumbers manejará los números internacionales de forma más fiable que las expresiones regulares. Pero para la mayoría de los equipos de Sales Ops que trabajan en una hoja de cálculo, el enfoque con expresiones regulares cubre el 90% de los casos.

Direcciones de email de rol en el campo de teléfono: Algunos registros tienen cosas como "ver info@empresa.com" en el campo de teléfono. Márquelos para revisión manual — no se pueden normalizar programáticamente.

Paso 4: Validación de Email

Antes de la migración, la validación masiva de emails elimina los contactos que tendrán rebote duro en la primera campaña de alcance en el nuevo sistema. Los registros de email no válidos no valen la pena migrar.

Herramientas de validación masiva:

  • ZeroBounce: Cargue un CSV, obtenga un estado por email (válido, no válido, catch-all, trampa de spam, abuso). Alrededor de $0,008 por email para lotes grandes. Tiene un nivel gratuito para pruebas.
  • NeverBounce: Precios y capacidades similares. Buena API si desea integrarlo en un script.
  • Hunter.io Email Verifier: Más lento pero útil para verificar dominios específicos.

La investigación Global de Calidad de Datos de Experian encuentra consistentemente que la mala calidad de datos cuesta a las organizaciones un promedio del 15-25% de los ingresos, lo que pone el caso de negocio para la validación previa a la migración en términos concretos.

Qué hacer con cada resultado de validación:

Estado Acción
Válido Migrar
No válido (historial de rebote duro) Eliminar de la migración, archivar
Catch-all (el dominio acepta todo) Migrar con etiqueta "no verificado"
Trampa de spam Eliminar, no migrar
Abuso (historial frecuente de quejas) Eliminar de la migración
Direcciones de rol (info@, ventas@, admin@) Marcar — migrar solo si no hay email de contacto individual

No elimine contactos no válidos sin verificar si tienen oportunidades asociadas. Un contacto con un email no válido podría tener una oportunidad activa vinculada. Migre el registro (sin el email incorrecto), limpie el email manualmente y continúe.

Paso 5: Normalización de la Etapa del Ciclo de Vida

Este campo causa más confusión post-migración que casi cualquier otra cosa. Los sistemas de origen acumulan etapas del ciclo de vida con el tiempo a medida que cambian las definiciones de procesos. Para cuando esté migrando, podría tener 9 valores de etapa distintos que necesiten mapearse a 4 en el destino.

Comience exportando todos los valores distintos de la etapa del ciclo de vida de su sistema de origen. En Salesforce: SELECT Status, COUNT(Id) FROM Lead GROUP BY Status. En HubSpot: exporte contactos y haga una tabla dinámica de la columna de etapa del ciclo de vida en Excel. En Pipedrive: exporte contactos/leads y use un COUNTIF. Antes de finalizar el mapeo de valores, revise las definiciones de etapa del ciclo de vida de leads de su destino — las decisiones de mapeo que tome aquí impulsarán el enrutamiento, la automatización y los informes en el nuevo sistema.

Luego construya su mapeo:

Plantilla de Mapeo de Etapas del Ciclo de Vida

Valor en sistema de origen Cantidad Valor en sistema de destino Notas
New Lead 1.240 Lead Mapeo directo
Open Lead 890 Lead Combinar con el anterior
Marketing Qualified Lead 430 MQL Mapeo directo
Product Qualified Lead 180 MQL Mapear a MQL a menos que el destino tenga PQL
Sales Accepted Lead 220 SQL Mapeo directo
Sales Qualified Lead 310 SQL Combinar con el anterior
Demo Scheduled 145 SQL Mantener como SQL, agregar nota de actividad
Negotiation 88 SQL Tratar como SQL de etapa tardía
Customer 2.100 Customer Mapeo directo
Churned 340 Customer (inactive) Etiquetar como inactivo
Evangelist 45 Customer Mapear a cliente, agregar etiqueta
Disqualified 670 Disqualified Mapeo directo

Documente este mapeo y obtenga la aprobación del liderazgo de ventas antes de la importación. La definición de etapa del ciclo de vida afecta el enrutamiento, los informes y las cuotas — no es una decisión unilateral de operaciones.

Paso 6: Normalización de Campos de Fecha

Los campos de fecha fallan silenciosamente. Se importan sin error, pero los valores son incorrectos, lo que significa que sus informes basados en fechas y las reglas de automatización se rompen de maneras que no detectará hasta que un representante note que sus tareas de seguimiento tienen fechas incorrectas.

Estándar objetivo: ISO 8601, con formato AAAA-MM-DD (por ejemplo, 2025-06-15). Este formato es inequívoco entre locales y es aceptado por todas las herramientas de importación de CRM.

Problemas comunes:

  • MM/DD/AAAA vs DD/MM/AAAA: Una fecha de cierre de "06/07/2024" es el 7 de junio en formato de EE. UU. y el 6 de julio en formato UK/UE. Si su equipo tiene representantes internacionales que ingresaron fechas, tendrá ambos en la misma columna.
  • Cadenas de texto: Entradas como "Q3 2024", "Fin de año", "Por confirmar" en campos de fecha. Estas no se pueden normalizar programáticamente — revisión manual o importación en blanco.
  • Desplazamientos de zona horaria: Algunos sistemas exportan fechas como ISO 8601 con zona horaria (2025-06-15T00:00:00-05:00). Elimine el desplazamiento de zona horaria y convierta a UTC antes de importar, a menos que el sistema de destino maneje la conversión de zona horaria automáticamente.
  • Marcas de tiempo Unix: Algunas herramientas de exportación generan marcas de tiempo en milisegundos desde el epoch. Convierta con una fórmula: =TEXT(A2/86400000+"1/1/1970","AAAA-MM-DD") en Excel.

Para fechas "desconocidas": Si una fecha de cierre está vacía, déjela vacía — no llene una fecha predeterminada. Vacío es honesto; una fecha incorrecta es engañosa.

Paso 7: Decisiones de Enriquecimiento

La migración es el momento en que el enriquecimiento tiene más sentido. Ya está tocando cada registro, los datos están en un estado limpio (post-deduplicación, post-normalización), y el CRM de destino está comenzando de cero.

Cuándo enriquecer antes de la migración:

  • Su tasa de completitud del nombre de empresa está por debajo del 70% (consulte gestión de datos de leads para ver los puntos de referencia de completitud por tipo de campo)
  • Tiene contactos sin cargo ni asociación de empresa
  • Está migrando a un CRM con objetos de datos a nivel de empresa (como Cuentas de Salesforce o Empresas de HubSpot) que necesitan firmografía precisa para configurar asociaciones

Opciones de enriquecimiento gratuitas:

  • Clearbit Reveal (ahora Breeze Intelligence en HubSpot): Enriquece automáticamente los datos de empresa desde el dominio de email. Nivel gratuito limitado pero útil para el enriquecimiento masivo de los dominios más comunes.
  • Apollo.io: Tiene un nivel gratuito con 50 enriquecimientos por mes. Bueno para verificar registros específicos.
  • Búsqueda manual en LinkedIn: Lento, pero fiable para cuentas clave donde los datos realmente importan.

Cuándo omitir el enriquecimiento antes de la migración:

  • Su mapeo de campos no incluye los campos que enriquecería (enriquecer cargos que no va a migrar de todas formas es esfuerzo desperdiciado)
  • Su cronograma es ajustado — el enriquecimiento agrega 2–5 días
  • El CRM de destino tiene una integración de enriquecimiento nativa que se ejecutará automáticamente después de la importación

Una verificación importante: confirme que los campos enriquecidos sobrevivirán el mapeo de campos de la migración. No tiene sentido enriquecer "Número de Empleados" si ese campo no tiene un destino mapeado en el nuevo sistema.

Paso 8: QA del Conjunto de Datos Limpiado

Después de la deduplicación, normalización, validación y (opcionalmente) enriquecimiento, debe verificar que el proceso de limpieza en sí no introdujo errores.

Lista de Verificación de QA Post-Limpieza

Verificación Antes de limpiar Después de limpiar Estado
Recuento total de contactos [línea base] Debería ser menor (dedup)
Estimación de duplicados (email) [% línea base] <1%
Campo email: direcciones válidas [% línea base] >90%
Campo teléfono: formato E.164 [% línea base] >85%
Etapa del ciclo de vida: valores nulos [recuento línea base] <2%
Campos de fecha: formato ISO 8601 [% línea base] >95%
Campo de país: estandarizado [% línea base] >95%
Completitud del nombre de empresa [% línea base] [% objetivo]

Pase por esta lista en una muestra de 500 filas primero. Exporte 500 registros aleatorios, límpielos usando su proceso y verifique la salida contra la lista. Si la muestra pasa, aplique el mismo proceso a todo el conjunto de datos. Esto limita el radio de impacto si un script de limpieza tiene un error.

Verificación de cordura del recuento de registros: Su recuento de contactos post-limpieza debería ser menor que su recuento pre-limpieza (la deduplicación eliminó registros) pero no dramáticamente menor. Si comenzó con 10.000 contactos y terminó con 4.000, o tuvo un problema de duplicación extremo o el script de limpieza eliminó registros que no debería. Investigue antes de continuar.

Errores Comunes

Ejecutar deduplicación sin hacer copia de seguridad primero. Una fusión masiva es irreversible en la mayoría de los sistemas. Los 10 minutos que toma exportar un CSV de copia de seguridad valen la pena cada vez.

Umbrales de fusión automática agresivos que destruyen contactos legítimamente separados. Dos personas llamadas "Michael Chen" en la misma empresa no son la misma persona. La fusión automática por nombre + empresa sin verificar email o teléfono primero crea un registro corrupto que es doloroso de desenredar.

Enriquecer datos que no sobrevivirán el mapeo de campos. Si su documento de mapeo de campos no incluye "URL de LinkedIn" como campo de destino, enriquecer URLs de LinkedIn es esfuerzo desperdiciado. Confirme qué campos se están migrando antes de decidir qué enriquecer. La guía de campos personalizados es útil aquí — cubre cómo decidir qué campos personalizados merecen un equivalente de destino y cuáles deben quedarse atrás.

Normalizar números de teléfono sin verificar extensiones. Un script de normalización que elimina todos los caracteres no numéricos convertirá "+1 (555) 234-5678 x102" en "+15552345678102" — un número de 13 dígitos que parece válido pero no lo es. Maneje las extensiones antes de la normalización.

Limpiar todo el conjunto de datos sin probar primero en una muestra. Todo script de limpieza tiene casos extremos. Pruebe en 500 registros, verifique la salida y solo entonces ejecútelo en 50.000.

Qué Hacer Después

No intente limpiar todo a la vez. Esta semana, exporte una muestra de 500 filas, aplique los pasos de limpieza de esta guía y pase por la lista de verificación de QA. Verifique que la salida se vea correcta. Luego — y solo entonces — ejecute el mismo proceso en su conjunto de datos completo. Si está migrando a Rework y desea entender cómo está estructurado el modelo de datos en el lado receptor, cambiar de Salesforce a Rework cubre las diferencias de objetos y campos que afectan qué decisiones de limpieza importan más.

El orden importa:

  1. Deduplicación primero (para no normalizar registros que está a punto de fusionar)
  2. Validación de email segundo (eliminar registros no válidos antes del enriquecimiento)
  3. Normalización tercero (teléfono, país, fechas, etapa del ciclo de vida)
  4. Enriquecimiento último (opcional, agregar solo a registros limpios)
  5. QA del conjunto de datos limpiado completo contra la lista de verificación antes de exportar

Una vez que su conjunto de datos limpiado pase el QA, estará listo para construir el documento de mapeo de campos. Ese proceso se cubre en la siguiente guía.

Más Información