Arquitectura de integración CRM: definir quién manda en cada dato

Mantenga datos de clientes coherentes con identidad estable, propiedad de campos, conflictos explícitos y conciliación operativa.

Los problemas CRM suelen empezar cuando dos sistemas creen ser dueños del mismo campo. Ventas corrige un nombre y un evento antiguo vuelve a sobrescribirlo. Antes de elegir automatización, defina significado y propiedad de los datos. Una integración fiable respeta ese acuerdo en lugar de tratar toda actualización como un reemplazo igualmente autorizado.

Separar identidad y atributos

Seleccione IDs internos y CRM estables y guarde su correspondencia. El correo puede cambiar, compartirse o aparecer repetido. Defina relaciones entre personas, empresas, cuentas y suscripciones. En el primer importado, aísle coincidencias dudosas en vez de fusionar por igualdad de texto. Conserve la razón de la asociación para corregirla después. Incluso un importado único debe poder repetirse con datos reparados sin crear nuevos duplicados.

Crear una matriz de propiedad

Para cada campo, anote sistema de referencia, editores y dirección. Las notas comerciales pueden ser del CRM y el estado de suscripción de facturación. Un campo compartido exige una regla de conflicto. Incluya null, eliminación, consentimiento y correcciones históricas. Quitar puede significar archivar, borrar o impedir contacto. Son efectos comerciales distintos que no debe decidir accidentalmente el transporte de mensajes.

Diseñar para interrupciones

• Use identidad de operación y versión de origen cuando exista, evitando ciclos de devolución.
• Guarde fallos con repetición segura y operador responsable.
• Concilie cantidades y estados relevantes fuera del flujo habitual de eventos.
• Limite acceso y datos personales en logs, exportaciones y adjuntos de diagnóstico.

Empezar con datos acotados

Pruebe duplicados, cambios de dirección y contactos archivados. Compare sistemas después de cambios normales y una caída. Antes de sincronizar producción, acuerde corte, relleno histórico y aceptación. Observe conflictos sin resolver, no solo peticiones exitosas. El panel debe explicar qué cliente está desalineado, qué estado corresponde y quién puede corregir. Fije también un plazo de atención y marque registros incompletos. Un fallo técnicamente registrado sigue siendo peligroso si ventas utiliza esa información como verificada cada día.

• Backend e integraciones →
• Checklist de integración API antes del desarrollo →
• Versionado de API: un plan para cambios incompatibles →