Si tu empresa distribuye o fabrica, muchos pedidos llegan por email: en el cuerpo, en un PDF o en un Excel con el formato de cada cliente. Alguien de administración los teclea en el ERP, línea a línea. Esta guía explica cómo montar un sistema con IA que hace ese trabajo, cómo empezar con un piloto y qué suele fallar.

Qué hace el sistema, de principio a fin

El objetivo es convertir cada email en un pedido de venta correcto en tu ERP, o en una excepción clara para una persona. El flujo tiene siete pasos:

  1. Vigilar el buzón de pedidos.
  2. Extraer el texto del cuerpo y de los adjuntos.
  3. Pedir a un modelo de lenguaje un JSON con una estructura fija.
  4. Cruzar cliente y productos con los datos maestros del ERP.
  5. Aplicar reglas de validación.
  6. Enviar las excepciones a una cola de revisión humana.
  7. Escribir el pedido en el ERP y registrar todo.

La calidad depende de los pasos 4, 5 y 6, no del modelo.

Pasos 1 y 2: buzón y adjuntos

Vigilar el buzón

Usa un buzón dedicado, por ejemplo pedidos@tuempresa.es. Para detectar emails nuevos tienes dos opciones habituales:

  • n8n: el nodo Gmail Trigger puede descargar los adjuntos como datos binarios. Para Outlook, el nodo Microsoft Outlook Trigger detecta los mensajes y el nodo Microsoft Outlook descarga los adjuntos.
  • Microsoft 365 con código propio: con una suscripción de Microsoft Graph a un buzón o carpeta, Graph avisa a tu webhook de cada mensaje nuevo.

Extraer el contenido

Separa el email en piezas antes de llamar al modelo:

Tipo de contenidoCómo lo tratas
Cuerpo del emailTexto plano, sin firmas ni historial citado.
PDF generado por ordenadorExtrae el texto, o pasa el PDF a un modelo que lo acepte.
PDF escaneado o fotoOCR o un modelo con visión. Es el caso más difícil.
Excel o CSVLéelo con una librería de hojas de cálculo.

Guarda siempre el email original y los adjuntos para revisar errores y auditar.

Paso 3: extracción con un esquema JSON

No pidas al modelo "un resumen del pedido". Pídele un JSON que cumpla un esquema concreto. Las APIs de OpenAI y de Anthropic ofrecen salidas estructuradas: pasas un JSON Schema y la respuesta respeta esa estructura. Revisa en la documentación de OpenAI y de Anthropic qué partes de JSON Schema admite cada una.

Un esquema mínimo para un pedido puede ser este:

json
{
  "type": "object",
  "additionalProperties": false,
  "required": ["cliente", "referencia_pedido_cliente", "fecha_entrega", "lineas", "dudas"],
  "properties": {
    "cliente": {
      "type": "object",
      "additionalProperties": false,
      "required": ["nombre", "cif", "email_remitente"],
      "properties": {
        "nombre": { "type": ["string", "null"] },
        "cif": { "type": ["string", "null"] },
        "email_remitente": { "type": "string" }
      }
    },
    "referencia_pedido_cliente": { "type": ["string", "null"] },
    "fecha_entrega": { "type": ["string", "null"], "format": "date" },
    "lineas": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["texto_original", "referencia", "descripcion", "cantidad", "unidad"],
        "properties": {
          "texto_original": { "type": "string" },
          "referencia": { "type": ["string", "null"] },
          "descripcion": { "type": ["string", "null"] },
          "cantidad": { "type": "number" },
          "unidad": { "type": "string", "enum": ["unidad", "caja", "palet", "kg", "metro", "otra"] }
        }
      }
    },
    "dudas": { "type": "array", "items": { "type": "string" } }
  }
}

El esquema no incluye precios: el ERP ya tiene las tarifas de cada cliente. Cada línea guarda el texto_original, para que quien revisa vea de dónde sale el dato. El campo dudas da al modelo un sitio para decir lo que no tiene claro.

El prompt acompaña al esquema:

text
Eres un asistente que extrae pedidos de venta de emails de clientes.
Devuelve solo los datos que aparecen en el email o en sus adjuntos.
Si un dato no aparece, usa null. No lo deduzcas.
Copia la referencia del producto tal como la escribe el cliente.
Si una línea es ambigua, extráela y explica la duda en "dudas".
Ignora firmas y mensajes anteriores citados.

Un campo vacío se corrige rápido. Un dato inventado puede llegar al almacén.

Pasos 4 y 5: cruce con datos maestros y validación

Cruzar cliente y productos

El modelo devuelve lo que pone el email, pero tu ERP necesita sus códigos. Este cruce lo hace tu código, no el modelo:

  1. Identifica al cliente por el dominio del remitente o por el CIF.
  2. Busca cada referencia del cliente en una tabla de equivalencias con tus códigos de artículo.
  3. Si no hay equivalencia, busca por la referencia interna o por el código EAN.
  4. Si no hay coincidencia, propone candidatos por descripción y marca la línea para revisión.

La tabla de equivalencias es lo más valioso del proyecto. Cada vez que una persona resuelve una línea dudosa, el sistema guarda la equivalencia nueva.

Reglas de validación

Antes de crear nada, aplica reglas fijas:

  • La cantidad es mayor que cero y encaja con el múltiplo de venta del artículo.
  • La unidad del pedido coincide con la unidad de venta, o existe una conversión conocida.
  • El artículo está activo y el cliente puede comprarlo.
  • No existe ya un pedido con la misma referencia del cliente. Así evitas duplicados si el cliente reenvía el email.

Si una regla falla, el pedido va a revisión.

Pasos 6 y 7: revisión humana y escritura en el ERP

La cola de revisión

La cola es una pantalla sencilla: el email a un lado y el pedido propuesto al otro, con las líneas dudosas marcadas. La persona corrige, aprueba o rechaza.

Al principio, todos los pedidos pasan por esta cola. Un cliente pasa a automático solo cuando sus pedidos salen bien de forma constante.

Escribir el pedido

Comprueba qué ofrece tu ERP. Estos tienen API pública para pedidos de venta:

  • Holded: la API de documentos crea documentos por tipo, y uno de los tipos es salesorder.
  • Odoo: la API externa crea registros del modelo sale.order. Odoo 19 añade el endpoint /json/2. En Odoo Online, la API externa exige el plan Custom.
  • SAP Business One: el Service Layer acepta un POST a /Orders con CardCode y DocumentLines.
  • Microsoft Dynamics 365 Business Central: la API v2.0 tiene el recurso salesOrders.

Si usas Sage, a3ERP u otro ERP, confirma con tu partner si tu versión tiene API de pedidos. Si no la tiene, pregunta por la importación de ficheros CSV o XML.

Crea el pedido en borrador cuando el ERP lo permita. Guarda el identificador del ERP junto al email original, quién lo revisó y qué se extrajo.

Qué suele fallar

  • PDF escaneados: faxes, fotos con el móvil y sellos encima del texto. Mándalos a revisión al principio.
  • Referencias ambiguas: el cliente escribe "tornillo 6x40 inox" sin código. El sistema propone candidatos y decide una persona.
  • Unidades mezcladas: el cliente pide "10" y no dice si son cajas o unidades. El esquema obliga a indicar la unidad y una regla la valida.
  • Precios que no cuadran: el precio del pedido no coincide con tu tarifa. Usa el del ERP y avisa a comercial.
  • Emails que no son pedidos: reclamaciones, cambios o anulaciones. Clasifica antes cada email y manda esos casos a una persona.

Cómo empezar con un piloto y cómo medirlo

El piloto

  1. Elige entre tres y cinco clientes que envían muchos pedidos con un formato estable.
  2. Reúne pedidos reales ya tecleados en el ERP. Son tu conjunto de prueba, porque conoces el resultado correcto.
  3. Pasa esos pedidos por el sistema y compara campo a campo con el ERP.
  4. Pon el sistema en modo sombra: propone pedidos, pero una persona los sigue creando como siempre.
  5. Cuando los resultados sean buenos, activa la cola de revisión y deja de teclear.

Qué medir

Mide tu caso antes y después con los mismos criterios:

  • Tiempo medio desde que llega el email hasta que el pedido está en el ERP.
  • Porcentaje de pedidos que pasan sin ninguna corrección.
  • Líneas corregidas en revisión y el motivo.
  • Errores que llegan al almacén o al cliente.
  • Minutos de trabajo humano por pedido, contando la revisión.

Apunta estos datos durante dos o tres semanas antes del piloto. Sin esa línea base, no sabrás si el sistema ayuda.

Cuándo compensa pedir ayuda

Puedes montar una primera versión con n8n, un modelo con salidas estructuradas y la API de tu ERP. Compensa pedir ayuda si tienes muchos formatos distintos, PDF escaneados frecuentes, un ERP sin API clara o reglas comerciales complejas. También si nadie del equipo puede mantener la tabla de equivalencias.

En Buildylab construimos este sistema para pymes. Puedes ver cómo trabajamos en la página del agente de pedidos por email. Una llamada de 20 minutos suele bastar para saber si tu caso encaja.