Tu CRM compró tu plataforma de engagement: qué decidir primero

Si tu CRM y tu plataforma de engagement ahora pertenecen al mismo proveedor, la decisión que tienes enfrente es de modelo de datos, no de contrato: define si los dos sistemas deben compartir un modelo de identidad y un modelo de eventos antes de decidir si renuevas, fusionas o migras. El anuncio de Salesforce sobre su adquisición de Braze no resuelve nada de esto. Dice qué pretende construir el proveedor, no qué pasa con tus registros de cliente cuando dos sistemas que no coinciden sobre quién es una persona terminan bajo el mismo techo.

Qué dice el anuncio — y qué no dice

El 20 de octubre de 2026, Salesforce anunció un acuerdo definitivo para adquirir Braze por aproximadamente 5.660 millones de dólares en valor de empresa, a 47,50 dólares por acción en efectivo. La compañía indicó que la operación se espera cierre en su año fiscal 2028, sujeto a la aprobación de accionistas y de los reguladores, y que las capacidades de engagement en tiempo real y de decisión con IA de Braze complementarán Data 360, Customer 360, Agentforce y Marketing Cloud.

Eso es una declaración de estrategia, no una arquitectura. La cobertura de Digiday del 26 de octubre enmarca el trato como una "encrucijada de ecosistema" para los marketers, con el vendor lock-in y la ejecución diferenciada por IA como preguntas abiertas. El análisis de MarTech es más directo: Salesforce dice que Braze complementará Marketing Cloud y se conectará con Data 360 —"esa es la intención de la empresa, todavía no un resultado demostrado ante clientes".

Es decir: el roadmap que te permitiría planificar una consolidación todavía no existe en público. Lo que sí existe es tu stack actual: un CRM que posee contactos, negocios y etapas del ciclo, y una plataforma de engagement que posee comportamiento, recorridos y entrega por canal. Cuando el equipo comercial del proveedor te pregunta si quieres consolidarte en un solo contrato este trimestre, la respuesta honesta es que no te están haciendo una pregunta de compra. Te están haciendo una pregunta de modelo de datos disfrazada de compra.

Las cuatro preguntas que deciden consolidar o mantener la costura

Respóndelas en orden. Cada respuesta nombra un responsable, y los responsables dicen si la consolidación es segura.

Cuatro respuestas limpias que apuntan a un responsable por pregunta: consolida, y secuencialo bien (más abajo). Respuestas mixtas: mantén la costura de forma deliberada, con una integración documentada entre los dos, y revisa cuando el proveedor publique una arquitectura real. Que sean mixtas no es un fallo, es un diagnóstico. Una fusión forzada con identidad sin resolver produce registros duplicados, audiencias infladas y reportes en los que nadie confía — el mismo problema que hace los datos sucios tan caros mucho antes de que exista ninguna adquisición.

La documentación de ambos describe la misma costura

Los documentos de las dos compañías son más útiles que el comunicado, porque muestran dónde vive realmente la costura.

La documentación de resolución de identidad de Salesforce trabaja con reglas (rulesets): las reglas de coincidencia deciden qué perfiles se unifican (coincidencia exacta, normalizada sobre correo, teléfono y dirección, o difusa sobre nombre), y las reglas de reconciliación deciden qué valor gana en un campo que solo admite uno —Última actualización, Más frecuente o Secuencia de fuente. La documentación es explícita: la reconciliación no borra ni modifica los datos de origen, los perfiles unificados se generan en un ciclo diario después de publicar, y la línea que conviene interiorizar es que es más fácil corregir un flujo de datos antes de la ingesta que después.

La documentación de Braze describe el mismo problema desde el lado de los eventos. La ingesta por /users/track es asíncrona: una respuesta exitosa significa que la petición fue recibida y encolada, no que el perfil se haya actualizado. Los perfiles anónimos se crean a partir de tokens de dispositivo y se fusionan en un perfil identificado cuando el usuario se identifica —con la ventaja para los campos que ya existen en el perfil identificado—. La documentación de comportamiento de fusión también detalla lo que no se transfiere, incluido el historial previo a la fusión en superficies alimentadas por su almacén de datos, y los perfiles duplicados que nunca se fusionan no pueden recibir mensajes.

Puestas una al lado de la otra, las dos documentaciones cuentan lo mismo: quien posee la reconciliación de identidad y la ingesta de eventos posee el registro del cliente. El contrato que firmas decide quién te factura. No decide qué versión de una persona es la verdadera.

Secuencia de migración: identidad, eventos, reportes, apagado

Si consolidas, el orden no es negociable. La salida de cada etapa es la entrada de la siguiente.

Los equipos que invierten la etapa 1 y la etapa 2 terminan con datos de eventos limpios pegados a las personas equivocadas. Los que se saltan la etapa 3 terminan discutiendo de números en vez de clientes. La secuencia es el marco; la herramienta concreta es lo de menos.

Qué se rompe primero

En producción, los mismos cuatro fallos aparecen antes de que algo se vea corrupto:

• Audiencias construidas sobre perfiles que aún no terminaron de ingerir. Como la ingesta va en cola, una segmentación hecha justo después de una carga puede estar incompleta sin aviso.
• Los valores por defecto de reconciliación. Última actualización significa que gana el sistema más ruidoso, no el más verídico. Si tu CRM se enriquece cada noche y la plataforma de engagement se actualiza en tiempo real, el tiempo real gana cada campo en disputa.
• El historial de anónimo a identificado. Los campos ya presentes en el perfil identificado no se sobrescriben, así que el comportamiento inicial registrado bajo un token de dispositivo puede no aparecer donde lo esperas.
• Cambios de reglas en ciclo diario. Una corrección a las reglas de coincidencia no es inmediata; los equipos leen perfiles unificados obsoletos y concluyen que el arreglo no funcionó.
• Perfiles duplicados que nunca se fusionan. Quedan fuera de los envíos, lo que aparece semanas después como pérdida de entregabilidad inexplicable, no como un error.

Ninguno de estos necesita una adquisición para ocurrir. La adquisición simplemente los pone a todos frente al mismo equipo en el mismo trimestre — por eso los carriles de excepción y la higiene de datos disciplinada pertenecen al plan antes de la migración, no después.

Nuestra postura: consolida el modelo, ve lento con los contratos

Consolida primero el modelo de identidad y de eventos, y deja que la decisión comercial salga de ahí. Una clave documentada, un responsable del comportamiento, un responsable de la siguiente acción, un número que el negocio cita — cuando eso es cierto, pasar a un solo contrato es contabilidad. Invierte el orden y obtendrás un stack fusionado con dos registros de cliente sin resolver y una renovación que firmaste para conseguirlo.

Mantener la costura también es un resultado legítimo. Si la identidad no se puede acordar, una integración deliberada con un responsable por sistema gana a una migración que adivina — sobre todo mientras el roadmap del producto fusionado sigue siendo un comunicado. Lo que no haríamos es que la fecha de cierre del proveedor se convierta en tu fecha límite de migración. La operación se cierra cuando lo digan reguladores y accionistas; tu modelo de datos debería estar listo mucho antes de que alguien te pida firmar.

Si tienes un CRM más una plataforma de engagement por separado y un proveedor preguntándote por cuál te quedas, nuestro trabajo de implementación de CRM empieza exactamente por estas cuatro preguntas — antes de cualquier herramienta, contrato o importación. Y si estás comparando plataformas antes de decidir, la comparativa de WhatsApp y CRM para Latinoamérica cubre el lado del canal.