1. Contexto Del Proyecto
El cliente era un equipo de ventas que había usado su CRM durante mucho tiempo sin una disciplina estricta de datos. El sistema debía guardar compradores, contactos, empresas, pedidos e historial de comunicación, pero con el tiempo se convirtió en una base en la que los managers ya no podían confiar del todo
El problema no era el CRM en sí. El problema era cómo se usaban los campos: un nombre podía estar en el campo empresa, una empresa en el campo nombre, una nota en el contacto, registros especiales aparecían en formatos aleatorios y un mismo comprador podía existir en muchas tarjetas
Mi rol fue devolver orden sin hacer un cleanup masivo y peligroso. Tenía que extraer el estado real de la base, diseñar reglas de normalización, mostrar un dry-run, separar cambios seguros de manual review y dar al equipo un canon claro para trabajar con CRM en adelante
2. Situación Inicial
•El CRM estaba contaminado por input manual: durante años los managers pusieron valores en campos incorrectos, mezclando compradores, empresas, notas, registros de prueba y tarjetas basura
•Los compradores estaban duplicados: el mismo contacto podía existir en muchas tarjetas por distintas formas de escribir nombre, teléfono, empresa o canal de entrada
•Los nombres eran inconsistentes: empresas, organizaciones, fundaciones, instituciones y otros tipos de registros estaban escritos con distinto case, comillas, espacios, abreviaturas y errores
•Las notas vivían en campos equivocados: el campo de nombre podía contener comentarios de managers, fuente de solicitud o fragmentos de descripción del pedido
•La automatización ciega era peligrosa: un script simple podía borrar historial útil, fusionar personas distintas o romper vínculos con pedidos
3. Alcance
•Exportar datos del CRM vía API y construir un audit snapshot local
•Detectar buyer duplicates, tarjetas vacías, test records, unknown clients y registros sin suficiente evidencia de contacto
•Crear reglas que distingan persona, empresa, tipo especial de organización y nota operativa
•Definir un naming canon: case, comillas, abreviaturas, espacios y estructura contact plus company
•Preparar un dry-run antes de cualquier escritura en CRM live
•Separar safe automation de manual review para que registros dudosos no cambien sin decisión humana
•Dar al equipo un estándar claro para introducir datos después del cleanup
4. Solución
CRM Audit & Data Snapshot
•Se extrajeron compradores, tarjetas, contactos, empresas, teléfonos, pedidos y campos de sistema vía API
•Los datos se guardaron en artifacts locales JSON/CSV para repetir el análisis sin live requests constantes y riesgosos
•Se crearon checks para exact duplicates, fuzzy duplicates, phone duplicates, empty cards, missing contacts, weird names, all-caps names, transliteration y spam-like records
•El análisis no dependía de un solo criterio. Teléfono, nombre, empresa, número de pedidos y calidad del campo se evaluaban juntos
Canon For Buyers, Contacts & Companies
•Se diseñó un canon único para buyer profile: quién es el comprador, quién es contact person, qué pertenece a company y qué debe ser nota
•Para empresas y organizaciones se definieron reglas de abreviaturas, formato, comillas y mayúsculas/minúsculas
•Se normalizaron las reglas de comillas: dónde el nombre debe tenerlas y dónde solo crean ruido
•Los formatos organizativos especiales se trataron aparte, porque un espacio o case incorrecto podía romper búsqueda y agrupación
•Para notas escritas por managers en el campo nombre, se prepararon reglas para moverlas al contexto correcto sin perder contenido
Duplicate Consolidation & Safe Merge Plan
•El live API audit cubrió 6,662 buyer records, 6,305 pipeline cards, 690 companies y 6 CRM pipelines
•A nivel de pipeline cards se detectaron 372 duplicate phone groups, cubriendo 1,043 cards
•El duplicate cluster más grande tenía 28 tarjetas para una sola contact key
•La auditoría también encontró 1,533 cards without contact phone, 2,808 cards without contact name, 77 buyer records con legal/company markers dentro del campo name y 163 all-caps company records
•Esto confirmó el problema central: la base no estaba simplemente “un poco sucia”; no tenía disciplina de campos ni un modelo estable de buyer/contact/company
Manual Review Instead Of Blind Automation
•Los registros dudosos no se cambiaban automáticamente. Pasaban a una manual review list con una razón clara
•Registros sin teléfono, sin pedidos o con nombres sospechosamente cortos se separaban aparte
•Para nombres ambiguos de empresas, se generaba un proposed-change report: valor anterior, valor nuevo y lógica del cambio
•El equipo recibió una tabla transparente de decisiones, no un resultado vago de “hemos limpiado algo”
Execution & Guardrails
•Los scripts se organizaron como pasos repetibles: audit, dry-run, report, review, safe update y verification
•Las escrituras en CRM eran updates precisos, no sobrescrituras masivas sin control
•Después de los cambios se verificaban lost names, remaining duplicates, buyer links, company links, shipping names y registros que podían haber sido afectados por error
•La lógica no era “borrar basura”, sino “preservar historia comercial y quitar el caos que bloquea ventas”
5. Resultado
•El CRM dejó de ser una pila de tarjetas llenadas al azar y recibió un modelo claro de buyer profile
•El equipo vio la escala real de duplicación, basura y caos manual dentro de la base
•Se creó un canon de CRM data entry: dónde va el contacto, dónde la empresa, dónde la nota y cómo no crear duplicados nuevos
•Duplicados y registros vacíos recibieron un plan seguro con dry-run y manual review
•Los managers recibieron no solo una base más limpia, sino un estándar que evita que el mismo caos vuelva en un mes
•El negocio obtuvo una base más limpia para segmentación, repeat sales, reporting y marketing selections
6. Resultado Técnico
Este caso trató de data discipline. No puedes escalar operaciones CRM si los managers usan el sistema como una libreta libre. Primero cada campo necesita significado, cada comprador necesita un perfil estable y cada cambio debe ser verificable
El resultado no fue un solo cleanup script, sino un data-cleanup pipeline controlado: audit, classification, canonical rules, dry-run, manual review, safe update y verification. Esa es la diferencia entre CRM hygiene seria y una edición masiva peligrosa de una base viva
