CRM + Ecommerce: un solo cliente, no dos

Problema

Una tienda online y un CRM describen a la misma persona sin saberlo. En el ecommerce está lo que compró, cuánto gastó y qué dejó en el carrito. En el CRM están las conversaciones, el ciclo de vida y las campañas. Ninguno de los dos sabe lo del otro.

El resultado se nota rápido: marketing manda una promoción de bienvenida a alguien que lleva ocho pedidos, y el equipo comercial abre dos pestañas para responder una pregunta sencilla.

Contexto

La salida rápida suele ser un export mensual de pedidos que alguien sube al CRM a mano. Funciona un mes. Al segundo, el archivo llega tarde, alguien pisa datos y nadie se fía del histórico.

Objetivo

Que el CRM sea la vista del cliente —incluida su actividad de compra— sin convertir al ecommerce en un satélite del CRM ni al revés. Cada sistema sigue mandando en lo suyo.

Arquitectura

Una capa intermedia se sienta entre la tienda y HubSpot:

• La tienda emite webhooks en los momentos que importan: pedido creado, pedido pagado, pedido cancelado, carrito abandonado.
• El middleware normaliza el evento a un modelo común, así el mismo código sirve para WooCommerce o Magento cambiando solo un adaptador.
• Se resuelve la identidad del cliente por email y, si existe, por un id externo de la tienda, para no crear duplicados cuando alguien compra como invitado.
• Los datos de compra se escriben en HubSpot como propiedades y objetos: total gastado, número de pedidos, fecha del último pedido, productos favoritos.

Carritos abandonados, sin ser pesado

El carrito abandonado es el caso donde una integración se nota o molesta. El flujo que tiene sentido:

1. La tienda avisa cuando un carrito lleva un tiempo sin cerrarse, no al instante.
2. El middleware comprueba en el CRM si esa persona ya compró después de abandonar. Si compró, el evento se descarta.
3. Solo si sigue abierto se dispara el workflow, respetando consentimiento y frecuencia: nunca dos avisos en la misma semana.

Ese segundo paso es el que evita el correo incómodo de "te dejaste algo" cuando la persona ya pagó hace diez minutos.

Decisiones clave

• Idempotencia por id de pedido. Un webhook que llega dos veces no duplica nada.
• Cola con reintentos. Si la API del CRM devuelve un límite de peticiones, el evento espera; no se pierde.
• Adaptadores por plataforma. Migrar de WooCommerce a Magento es reescribir una pieza, no la integración.
• Bitácora de eventos. Cada mensaje queda registrado con su resultado, para poder responder "¿por qué este contacto no se actualizó?" en un minuto.

Aprendizajes

La parte difícil no es mover pedidos: es decidir quién manda en cada campo y qué hacer cuando un evento llega dos veces, tarde o incompleto. Resuelto eso, la integración se vuelve aburrida —que es exactamente lo que se busca.

Resultado

Una arquitectura donde el equipo consulta el CRM y ve al cliente completo, las automatizaciones se disparan con datos de compra reales, y cambiar de plataforma de ecommerce no obliga a rehacerlo todo.

Este es un Concept Project: un caso ilustrativo para mostrar enfoque y arquitectura. No representa a ningún cliente real.