Cómo automatizar pedidos por email al ERP con IA para distribuidores (2026)

Automatización

11 de noviembre de 20267 min read

Miguel Ángel Rodríguez (Miguelo DEV)Especialista en automatización de procesos con n8n

En casi cualquier distribuidora hay una persona que empieza el día abriendo correos y tecleando pedidos. Vienen en PDF, en una hoja de cálculo, en el cuerpo del mensaje, en una foto de un albarán hecha desde el almacén del cliente.

Cuando alguien plantea automatizar esto, lo primero que mira es la lectura del correo. Y ahí está el malentendido. Leer el correo es la parte fácil. Lo difícil es que el cliente pide cuarenta cajas del tornillo del grande y tú tienes que saber que eso es tu referencia concreta, con su formato de venta y su tarifa.

¿Por qué lo difícil de automatizar pedidos con IA y n8n no es leer el correo?

Porque un modelo de lenguaje lee bien casi cualquier cosa, incluida la foto torcida del albarán. Lo que no sabe es tu catálogo.

El problema real tiene tres capas y solo la primera es de lectura.

• Qué cliente es. Suele resolverse por el dominio del remitente, y se complica cuando un grupo pide desde cinco direcciones distintas o cuando escribe un comercial desde su correo personal.
• Qué artículo es cada línea. Aquí está el noventa por ciento del trabajo. Cada cliente tiene su vocabulario, su código interno o directamente una descripción libre.
• Si el pedido es coherente. Cantidades en múltiplos de venta, artículo activo, tarifa correcta y crédito disponible.

De las tres, la segunda es la que decide si el proyecto funciona. Un montaje que lee perfectamente y no acierta con la referencia produce pedidos mal grabados, que es bastante peor que no tener nada.

¿Cómo se traduce la referencia del cliente a tu código de artículo?

Con una tabla de equivalencias por cliente que no se escribe a mano, se construye sola.

El mecanismo es sencillo y es lo que separa un proyecto que mejora cada mes de uno que se queda igual. Cada vez que una línea no se resuelve sola y una persona la asigna en la cola de revisión, esa equivalencia queda guardada para ese cliente. La próxima vez que escriba lo mismo, se resuelve sin intervención.

El reparto de trabajo acaba siendo este.

• Lo que coincide exactamente con tu código o con el código de cliente ya registrado pasa directo.
• Lo que se parece mucho a una equivalencia conocida pasa con una marca, para que se revise por muestreo y no línea a línea.
• Lo que no tiene equivalencia sube a la cola, se resuelve una vez y queda aprendido para siempre.

Al cabo de unas semanas, lo que sube a revisión son casi solo artículos nuevos y clientes nuevos. Ese descenso es la métrica del proyecto, mucho más que el porcentaje de acierto del primer día.

¿Qué hay que validar antes de grabar un pedido en el ERP?

Cuatro comprobaciones duras, y ninguna depende del modelo. Esto es lo mismo que en cualquier montaje con inteligencia artificial, se valida contra cosas que no son el modelo.

• Cliente identificado y activo, con su bloqueo comercial comprobado si lo tenéis.
• Artículo existente y no descatalogado. Un código que no existe en el maestro es casi siempre un error de interpretación, no un alta.
• Cantidad en múltiplo de venta. Pedir siete unidades de algo que se vende en cajas de seis no es un pedido, es una llamada.
• Precio de la tarifa de ese cliente. El precio nunca se lee del correo, se trae de tu sistema. Si el cliente escribe otro, eso es una incidencia comercial y sube a revisión.

Y una quinta que no es validación sino diseño. La clave de idempotencia, para que el mismo correo reenviado dos veces no genere dos pedidos. Se construye con el remitente, la referencia del cliente y la fecha, y se comprueba antes de cualquier efecto. Es la misma pieza que sostiene la entrada de pedidos de una tienda online, que desarrollo en sincronizar stock y pedidos entre tu tienda y el ERP.

¿Por qué el acuse al cliente es la pieza más rentable del montaje?

Porque convierte un error silencioso en una respuesta de dos minutos, y los errores silenciosos en distribución se pagan en camiones.

El acuse que funciona no dice hemos recibido su pedido. Dice esto es lo que hemos entendido, con las líneas interpretadas, los códigos tuyos, las cantidades y los precios de su tarifa. Si algo no cuadra, el cliente lo ve antes de que salga el albarán.

Tiene además dos efectos que nadie espera. El primero es que los clientes empiezan a pedir mejor, porque ven cómo interpretas lo que escriben. El segundo es que la discusión del mes siguiente sobre una entrega equivocada deja de ser una cuestión de palabra y pasa a ser un correo con fecha. Si además vendéis online, este acuse encaja con el resto de avisos automáticos que repaso en automatizar un ecommerce con IA y n8n.

¿Cuándo no automatizar la entrada de pedidos con IA y n8n?

Te lo digo aunque me quite proyectos, porque este montaje se puede vender muy bien y fallar muy rápido.

Si recibís pocos pedidos al día, el retorno no aparece. Una persona los teclea en media hora y el proyecto tarda años en pagarse.

Si vuestro maestro de artículos está desordenado, con códigos duplicados o descripciones que no distinguen variantes, automatizar reparte ese desorden a toda la cartera. Primero se ordena el maestro.

Si nadie va a mirar la cola de revisión, no lo montéis. En distribución una línea mal interpretada es un palé equivocado, no un correo molesto.

Y si lo que buscáis es que nadie mire ningún pedido, esto no es para vosotros. El objetivo realista es que solo se miren las líneas nuevas, que al cabo de unos meses son pocas.

Cómo monto yo la entrada automática de pedidos

Empiezo por los tres clientes que más pedidos mandan. No por el formato más difícil ni por el catálogo entero. Tres clientes bien resueltos dan resultados en semanas y además generan el histórico con el que aprende la tabla de equivalencias.

Monto la identificación del cliente antes que la lectura de líneas. Si no sé de quién es el pedido, no puedo aplicar su tarifa ni su vocabulario, así que todo lo demás sobra.

Pongo las cuatro validaciones antes del modelo, no después. Son las que deciden qué pasa y qué se encola, y no dependen de que la lectura haya sido buena.

Dejo la cola de revisión con el motivo escrito en cada línea y con el aprendizaje incorporado. Resolver una línea no es corregir un pedido, es enseñar al sistema para siempre.

Y mando el acuse interpretado desde el primer día, aunque el volcado al ERP siga siendo manual al principio. Es la pieza que más confianza genera, en el cliente y en vuestro propio equipo.

Traducido a vuestro dinero, esto no se mide en pedidos automatizados. Se mide en cuántas líneas suben a revisión cada semana y en cuántas entregas equivocadas dejáis de tener. Cómo se conecta todo esto con el resto de sistemas lo cuento en integrar tu ERP con el resto de sistemas, y cómo planteo un proyecto completo en automatizaciones con n8n.

Si te quedas con una sola idea, que sea esta. El proyecto no va de leer correos, va de construir el diccionario que traduce el idioma de cada cliente al tuyo.