Automatizar EDI con n8n: del correo duplicado al ERP en un solo paso
Cómo automatizar el ciclo de pedidos EDI/ERP con n8n para eliminar captura manual, errores y SLA vulnerable. Lo que aprendí implementándolo en una operación real de retail B2B.
Por Juan Pablo Zuluaga
El pedido que se duplicaba tres veces
En retailer B2B internacional, el problema más costoso no es la falta de tecnología: es la traducción manual entre formatos. El cliente envía el pedido por email en formato libre, alguien lo digita en el ERP, el sistema lo rechaza, alguien lo digita otra vez — y el SLA se cae mientras el cliente espera.
Este patrón me costó dos años de operación real. El impacto medible cuando lo automatizamos: 40% de mejora en el SLA del flujo documental. No por componer nuevo software, sino por reemplazar la traducción humana con un workflow en n8n.
Por qué EDI sigue vivo (y por qué sigue doliendo)
EDI existe porque los retailers grandes (Whole Foods, Walmart, Safeway) lo exigen como contrato operacional. Pero EDI no habla con tu ERP solo. Hay un espacio en el medio:
- Formato EDI 850 (purchase order) que el retailer envía.
- Tu ERP que espera otro formato.
- Reglas de validación (SKU, cantidad, dirección, lead time) que son tuyas.
En muchos equipos ese espacio lo cubre un humano. Es exactamente donde n8n encaja.
La topología que utilicé
EDI 850 (email / VAN) → intake n8n → normaliza a JSON
→ valida SKU + cantidad + lead time
→ si pasa: crea orden en ERP
→ si falla: ticket separado al humano con contexto completo
El punto clave es qué va al humano y qué va al sistema. Quien automatiza el 100% no escala; el 5% que rompe la regla se acumula y empeora la relación con el retailer.
Lo que aprendí:
- El humano con contexto completo es más barato que el humano sin contexto. Antes, el operador abría el email, abría el ERP, abría el sistema de tickets. Ahora, every excepción llega con el JSON ya normalizado, las reglas que fallaron marcadas, y el draft del ticket preparado.
- Mide exception rate, no solo throughput. Si el flujo rompe el 20% de las veces, irás a la deriva sin saberlo porque el SLA general sigue bien: las excepciones se resuelven con sobreesfuerzo invisible.
- El cliente no necesita entender EDI para ver el resultado. El indicador que más conecta es "tu última orden se procesó en X minutos, sin tocarla manualmente". Es más concreto que cualquier dashboard.
La decisión comercial que casi nadie toma
El bloque >= real de automatizar EDI no es técnico. Es la decisión de dónde cortar la automatización y dejar una例外 lista para humano. Mi regla:
- Si la falla es de formato o SKU desconocido → escala a humano, con el draft del ticket ya hecho.
- Si la falla es de dirección o lead time → bloquear el envío al ERP y avisar al cliente en su canal preferido con el detalle exacto.
- Si todo valida → va directo al ERP y el cliente recibe confirmación inmediata.
Resultados que se sienten: el cliente deja de preguntar "¿llegó mi orden?". En muchos equipos se gasta entre un 30% y un 50% del tiempo de un CSM en responder esa pregunta. Si el sistema la elimina, liberas capacidad de CSM para conversaciones que sí mueven retención.
Cómo empezar en una semana
- Define los 3 tipos de pedidos que más volumen y SLA mueven. No intentes todo a la vez.
- Levanta el webhook de intake (n8n acepta email-in, webhook público o lectura de SFTP). El canal depende del retailer.
- Construye el validador de SKU + cantidad solo. Es la pieza que más valor resuelve.
- Mide la tasa de excepciones limpias (con contexto). Si es > 15%, los ASK/reglas de validación se desajustaron; vale la pena revisarlas antes de avanzar.
Esto es todo lo que necesitas para el primer experimento. Si lo quieres en tu operación con tu EDI y tu ERP reales, te respondo en 1 día hábil con un brief de scoping que mapea tu canal → tu ERP → tu volumen.