Qué se conecta.
- Clientes y datos de facturación
- Pedidos y estados
- Productos y categorías
- Importes y métodos de pago
- Devoluciones e incidencias
- Carritos abandonados
El pedido no es el final, es el principio.
La mayoría de integraciones de ecommerce se detienen en volcar el pedido al CRM. Eso está bien para consultar, pero no cambia nada del proceso comercial.
Lo que aporta valor es lo que se dispara después: una segunda compra que activa un seguimiento, un pedido de importe alto que genera una tarea, una devolución que abre una incidencia, o un cliente inactivo que entra en una campaña de recuperación.
Dónde suele fallar.
- Clientes invitados sin cuenta
- Un mismo cliente con varios correos
- Estados de pedido mal mapeados
- Pedidos de prueba en producción
- Volumen en campañas de rebajas
- Datos fiscales incompletos
Cómo decidimos la vía técnica.
- Conector nativo si existe y basta
Es lo más barato de mantener. Si cubre el caso, no hay razón para construir nada.
- Automatización no-code si hay lógica
Make o n8n cuando hay condiciones, transformaciones o varios pasos encadenados.
- API y webhooks si hay volumen o reglas propias
Cuando el caso es específico, el volumen alto o hace falta control sobre errores y reintentos.
- Siempre con registro de errores
Toda integración falla alguna vez. La diferencia es si te enteras el mismo día o tres semanas después.
Preguntas frecuentes
¿Se pueden sincronizar pedidos antiguos?
Sí, con una carga inicial. Conviene revisar y limpiar los datos antes, porque los históricos suelen traer duplicados y direcciones incompletas.
¿Y si vendemos también por otro canal?
Es el caso habitual. La integración debe contemplar desde el principio que un mismo cliente puede comprar por varios canales y no debe duplicarse.
¿Afecta al rendimiento de la tienda?
Bien montada, no. El envío al CRM se hace en segundo plano para no retrasar la confirmación del pedido al comprador.