Qué identificador debe unir los sistemas
Un identificador estable permite reconocer el mismo registro aunque cambien su nombre o algunos atributos.
Define por separado cuenta, persona y oportunidad. Un dominio puede ayudar a reconocer una empresa, pero no resuelve todos los casos de filiales o marcas. Una dirección de email puede cambiar; conserva la relación con el identificador del sistema cuando exista. Documenta cómo se revisan coincidencias dudosas.
| Campo | Sistema que decide | Regla de actualización |
|---|---|---|
| ID de cuenta/contacto | Registro maestro acordado | No sustituir por nombre aproximado |
| Contexto de investigación | Fuente de prospección | Añadir procedencia y fecha |
| Estado comercial | Equipo/CRM según acuerdo | No degradar por un evento de campaña |
| Exclusión | Proceso compartido | Propagar antes de nuevas acciones |
| Responsable | Regla comercial acordada | Resolver conflictos, no duplicar asignación |
Este mapa es un ejemplo de diseño, no una especificación de API. Los nombres y capacidades concretas dependen de las herramientas utilizadas y deben comprobarse en su documentación vigente.
Si hay valores repetidos, antiguos o contradictorios, prepara la auditoría de calidad del CRM.
La identidad resuelta permite definir qué cambios de estado se pueden sincronizar.
Cómo separar estado comercial y estado de campaña
El estado comercial refleja la relación; el de campaña controla acciones. Un cambio en uno no debe sobrescribir al otro sin una regla.
Una respuesta puede detener la secuencia sin convertirse en oportunidad. Una oportunidad cerrada puede seguir perteneciendo a una cuenta existente. HubSpot distingue etapas de ciclo de vida; utiliza esa separación como referencia y define el significado local antes de activar sincronizaciones. HubSpot: etapas del ciclo de vida ↗
Los criterios del pipeline comercial ayudan a decidir qué eventos sí justifican avanzar una oportunidad.
Una transición necesita también reglas para eventos repetidos y resultados parciales.
Tres fallos de integración y su recuperación
La recuperación debe evitar repetir efectos y conservar la evidencia de lo que ya ocurrió.
Los fallos de ejemplo se convierten en pruebas antes de activar.
Checklist de pruebas antes de activar la sincronización
Prueba identidades, conflictos y paradas, además de un registro válido.
- Registro nuevo con campos mínimos: se crea una sola vez.
- Registro existente: se actualizan solo campos autorizados.
- Evento duplicado: no repite efectos.
- Respuesta recibida: pausa y asignación coherentes.
- Exclusión: no se reactiva por una actualización posterior.
- Fallo parcial: queda visible y puede recuperarse sin duplicar.
- Dato conflictivo: conserva fuente, fecha y responsable de revisión.
Para preparar los atributos de entrada, revisa el enriquecimiento con procedencia y validación.
Las pruebas y sus resultados deben quedar documentados para quien mantenga la integración.
Qué documentar para que el equipo pueda mantenerla
Documenta campos, identidades, reglas de prioridad, excepciones y cómo detener o recuperar el flujo.
La documentación debe permitir que alguien distinto al creador diagnostique un registro que no avanzó. Incluye ejemplos sintéticos y una explicación de qué no se sincroniza. Evita guardar secretos o datos personales innecesarios en capturas de formación.
La metodología de implementación define cómo comprobar esa transferencia.
Después de activar, revisa las métricas de actividad y oportunidades aceptadas para distinguir errores de integración y resultados comerciales.
El servicio outbound B2B conecta estas reglas con la operación de campañas.
En resumen
Una integración fiable conserva identidad y significado, no solo mueve datos. Define quién decide cada campo y prueba cómo se recupera un error antes de activar volumen.