title: "E-commerce automatizado: del pedido al envío sin que nadie toque nada" slug: ecommerce-automatizado-de-compra-a-envio excerpt: "Una tienda con 300 pedidos al día y 2 personas o tiene un problema de organización o tiene automatización. Te explicamos el flujo completo, paso a paso, y los casos límite que hay que resolver antes de que el sistema falle en el peor momento." category: automatizacion tags: [ecommerce, automatizacion, n8n, woocommerce, logistica, envios] author: Flexum date: 2026-06-15

E-commerce automatizado: del pedido al envío sin que nadie toque nada

Una tienda online con 300 pedidos al día y dos personas gestionándola tiene dos opciones: o tiene un problema serio de organización, o tiene automatización. No hay una tercera opción sostenible.

Con 300 pedidos diarios y una jornada de 8 horas, cada persona tiene 1,6 minutos por pedido si no hace nada más que procesar pedidos. Sin automáticas, el equipo pasa esas horas mirando pantallas, copiando números de pedido de un sistema a otro y respondiendo emails de clientes que preguntan dónde está su paquete. Con automatización bien diseñada, esas mismas dos personas gestionan excepciones, atienden incidencias complejas y mejoran el negocio mientras el 85% de los pedidos se procesan solos.

El flujo manual que hay que sustituir

Antes de automatizar, hay que entender exactamente qué hace una persona cuando procesa un pedido a mano. En la mayoría de tiendas medianas el flujo tiene entre 6 y 10 pasos, cada uno ejecutado por una persona, cada uno con su propio riesgo de error.

El email de confirmación de WooCommerce sale automático. Eso ya funciona solo. A partir de ahí empieza el trabajo manual: alguien verifica que el stock real en el almacén coincide con el stock que figura en el sistema (raramente coinciden del todo), genera la factura en el programa de facturación, copia los datos del pedido para notificar al almacén, el almacén prepara el bulto, imprime la etiqueta del transportista, solicita la recogida al transportista, alguien actualiza el pedido en WooCommerce con el número de seguimiento, y alguien envía ese número al cliente.

Cada uno de esos pasos es una oportunidad para que algo salga mal: el número de tracking se copia incorrectamente, el pedido se queda en estado "procesando" y el cliente no recibe el email de envío, el almacén no recibe la notificación a tiempo y el bulto pierde el camión del día.

Cómo automatizar con n8n, paso a paso

Paso 1: Trigger en WooCommerce

El flujo empieza cuando un pedido cambia de estado a "processing" en WooCommerce. n8n recibe el webhook instantáneamente con todos los datos del pedido: líneas de producto, cantidades, datos del cliente, dirección de envío, método de pago.

No se necesita polling ni revisar WooCommerce periódicamente. El webhook dispara el flujo en tiempo real, en el momento en que el pago se confirma.

Paso 2: Verificación de stock contra ERP

Antes de hacer nada más, el flujo consulta el ERP (ya sea Holded, Odoo, un sistema propio, o la base de datos del almacén) para verificar que el stock disponible cubre el pedido.

Si hay stock: el flujo continúa al siguiente paso.

Si no hay stock: el flujo ejecuta la secuencia de cancelación. Primero llama a la API del procesador de pago (Stripe, Redsys, PayPal) para emitir el reembolso. Luego envía un email al cliente explicando la situación y entregando un código de descuento como compensación. Luego actualiza el estado del pedido en WooCommerce a "cancelado" con una nota interna. Finalmente alerta al equipo por el canal de Telegram del equipo para que revisen el stock y tomen decisiones sobre reposición.

Todo esto sin que nadie lo haya tocado. El cliente recibe su dinero de vuelta en minutos, no en días.

Paso 3: Generación de factura en el sistema de facturación

Con el stock confirmado, el flujo crea la factura en Holded o Billin. Pero antes de crearla, busca si el cliente ya existe en el sistema para evitar duplicados (problema endémico en sistemas de facturación que acaban con el mismo cliente registrado 4 veces con variaciones de su dirección de email).

Si el cliente existe: se asocia la factura a su registro existente. Si no existe: se crea el registro del cliente primero, luego la factura.

La factura queda vinculada al número de pedido de WooCommerce para poder hacer la trazabilidad inversa desde cualquier extremo.

Paso 4: Notificación al almacén

La notificación al almacén viaja por dos canales en paralelo, cada uno con su función.

El email contiene el albarán completo en formato imprimible: referencia del pedido, líneas de producto con SKU y descripción, cantidad, ubicación en almacén si el sistema lo tiene, y datos de envío del cliente. El email queda como registro formal y se puede reenviar o imprimir en cualquier momento.

El mensaje de Telegram al canal del equipo de almacén es la alerta inmediata. El operario que está con el móvil o con el ordenador lo ve en segundos, no espera a revisar el email. El mensaje incluye el número de pedido, un resumen de las líneas de producto y la prioridad si la hay (pedidos exprés, etc.).

Ambos canales son necesarios porque resuelven necesidades distintas: el email es el registro, el Telegram es la reactividad.

Paso 5: Integración con el transportista

Este es el paso donde la mayoría de los ecommerce siguen trabajando a mano, y donde más tiempo se pierde.

n8n puede conectarse directamente con las APIs de Correos, GLS, MRW y la mayoría de transportistas que operan en España. El flujo crea el envío via API con los datos del destinatario, el peso estimado del bulto (calculado desde las líneas de producto si el sistema tiene los pesos), y el tipo de servicio (estándar, exprés, etc.).

La API devuelve el número de tracking y la etiqueta en formato PDF. El PDF de la etiqueta se envía a la impresora de etiquetas del almacén (si está configurada como impresora de red) o al email del operario del almacén. El número de tracking se guarda en el pedido de WooCommerce.

Paso 6: Comunicación con el cliente

El email que recibe el cliente no es el genérico de WooCommerce con el número de tracking en texto plano. Es un email personalizado con el nombre del cliente, un resumen de lo que ha pedido, el número de seguimiento como enlace directo al tracking del transportista, y la fecha estimada de entrega si la API del transportista la proporciona.

Dos días después del envío, el flujo comprueba el estado del envío via API del transportista:

Si el paquete está entregado: el flujo envía un email de solicitud de valoración del producto y la experiencia de compra. El momento es importante: el email llega cuando el cliente acaba de recibir el pedido, no 15 días después.

Si después de 5 días laborables el paquete sigue sin entregarse y sin incidencia registrada: el flujo alerta al equipo para que contacte con el transportista y con el cliente. Los paquetes que se pierden en silencio son los que generan las valoraciones negativas más duras.

Los casos límite que hay que resolver

Pedidos con stock parcial

Un pedido tiene 3 productos. Dos están en stock, uno no. La decisión que tiene que tomar el sistema no es trivial: ¿cancela el pedido completo y reembolsa? ¿Envía los dos disponibles y gestiona el tercero por separado? ¿Espera a tener los tres?

La respuesta depende de la política de la tienda, y esa política tiene que estar definida antes de diseñar el flujo. El sistema puede ejecutar cualquiera de las tres opciones, pero alguien tiene que decidir cuál es la política y cuándo aplica cada variante.

Devoluciones

Cuando un cliente solicita una devolución, el flujo verifica si el artículo está dentro del plazo de devolución y si el motivo entra dentro de la política. Si sí: genera la etiqueta de devolución automáticamente y la envía al cliente, actualiza el estado del pedido, y cuando el sistema de logística registra la recepción del bulto devuelto, emite el reembolso automáticamente.

Las excepciones (fuera de plazo, productos no retornables, casos con daño que requiere evaluación) escalan al equipo con toda la información del caso.

Pedidos con múltiples almacenes

Si la operación tiene más de un almacén o punto de preparación, el flujo tiene que decidir desde qué almacén sale el pedido. La lógica habitual es el almacén con stock más cercano a la dirección de entrega, pero puede haber criterios adicionales (coste de envío, capacidad de preparación en el momento).

Los pedidos que no pueden servirse desde un único almacén generan envíos parciales con notificación al cliente de que el pedido llegará en dos bultos.

El resultado real

Con este sistema implementado, una tienda con 300 pedidos diarios y dos personas procesa el 85% de los pedidos de forma completamente automática. El equipo interviene en el 15% restante: incidencias de stock, devoluciones con excepciones, incidencias con el transportista, errores de dirección que el transportista detecta antes de intentar la entrega.

Esas intervenciones del equipo son trabajo real, con criterio y con valor. No son copiar y pegar números de un sistema a otro.

Antes de empezar: el diagnóstico de datos

La automatización de un ecommerce falla frecuentemente no por problemas técnicos sino por problemas de datos. Antes de configurar el primer webhook, hay tres preguntas que determinan si el proyecto va a funcionar:

¿Es fiable el stock del sistema? Si el stock en WooCommerce y en el almacén difieren habitualmente, la automatización va a generar reembolsos innecesarios o va a intentar enviar pedidos de productos que no existen. Primero hay que sincronizar los sistemas de stock.

¿Son consistentes los SKUs entre sistemas? El SKU es el identificador que conecta WooCommerce con el ERP con el sistema del almacén. Si hay variaciones (con guiones, sin guiones, mayúsculas, minúsculas, prefijos distintos), el flujo no puede hacer el match automáticamente. Primero hay que limpiar y estandarizar los SKUs.

¿Están las direcciones de envío en el formato que acepta el transportista? Los errores de dirección son la primera causa de incidencias con transportistas. Si hay un alto porcentaje de direcciones con errores o con formato incompatible, hay que agregar validación de dirección en el proceso de checkout antes de automatizar el envío.

Si la respuesta a cualquiera de estas tres preguntas es "no del todo", el orden correcto es: limpiar los datos primero, automatizar después.

Plazos reales de implementación

La implementación de un flujo completo de este tipo tarda entre 4 y 8 semanas. Las primeras dos semanas habitualmente se van en la integración con el ERP y la limpieza de datos: es el trabajo menos visible y el más crítico.

La fase de configuración de n8n, los webhooks y las integraciones con transportistas tarda entre una y dos semanas adicionales. La fase de pruebas y ajuste, otros 10-15 días.

La fase de pruebas no se puede acortar. Una automatización que falla en producción falla 300 veces al día antes de que alguien lo detecte. Probar con volumen real controlado durante al menos dos semanas antes de desactivar completamente el proceso manual es la diferencia entre una implementación que funciona y una crisis de atención al cliente.