Del email del cliente al ERP: qué automatizar y qué validar antes de crear un pedido

Un cliente envía «os adjunto el pedido revisado» y añade un PDF. El asunto conserva el número anterior, hay una referencia descatalogada y el adjunto cambia la fecha de entrega. Administración debe entender qué ha cambiado, consultar condiciones comerciales y crear o modificar el registro correcto en el ERP.

Automatizar este flujo con IA no consiste en copiar el PDF al sistema. Consiste en transformar una entrada variable en una propuesta de pedido, comprobarla contra datos fiables y confirmar el resultado de la escritura. El beneficio aparece cuando el equipo deja de reconstruir siempre el mismo contexto, sin perder control sobre precios, cantidades y compromisos al cliente.

Este artículo trata pedidos de clientes que llegan desde fuera. El artículo sobre ERP, Excel y correo en pedidos internos explica cómo dar visibilidad a solicitudes entre equipos. Aquí la entrada es una orden comercial que puede crear obligaciones de suministro.

Dibujar el recorrido antes de elegir un modelo

El equipo debe identificar canal de entrada, tipos de archivo, clientes, campos obligatorios y autoridad sobre cada dato. Una fecha de entrega solicitada por el cliente no es una fecha confirmada por producción. Un precio escrito en un PDF puede discrepar del contrato vigente. Esas diferencias definen las comprobaciones.

Un flujo mínimo tiene siete pasos: recibir, identificar al cliente, detectar si es pedido nuevo o revisión, extraer líneas, validar, aprobar excepciones y escribir en el ERP con confirmación. En cada paso hace falta un resultado explícito o un motivo de bloqueo.

Dato	Fuente del cliente	Comprobación interna
Referencia	PDF, Excel o cuerpo del correo	Catálogo, equivalencias y estado del artículo
Cantidad y unidad	Línea de pedido	Unidad comercial, mínimos y múltiplos
Precio	Puede aparecer o no	Contrato y condiciones vigentes
Fecha solicitada	Pedido o correo	Capacidad y plazo confirmable
Dirección	Pedido o firma	Entidad y destino autorizado

La IA ayuda a interpretar formatos variables. Las comprobaciones dependen de los sistemas y reglas comerciales. Microsoft Document Intelligence documenta extracción de campos y tablas, pero la coherencia con el ERP es una tarea adicional.

Ejemplo: una revisión que no debe crear un segundo pedido

Imaginemos un correo ficticio de Cliente Beta con el pedido PO-418. Primero solicita 80 unidades de P-72. Una hora después manda un PDF «corregido» con 120 unidades y la misma referencia de pedido. La automatización detecta que se trata de una versión posterior, presenta el cambio y mantiene el pedido en revisión. Si el primer envío ya entró en el ERP, no crea un segundo pedido por leer el nuevo PDF.

El operador necesita saber cuál es el estado del registro anterior: borrador, confirmado, planificado o parcialmente servido. Según ese estado, el cambio puede ser una actualización, una solicitud comercial o una incidencia. El modelo no decide por sí solo que 120 unidades son aceptables.

La identidad del pedido puede combinar cliente, referencia externa, versión, fecha y contexto de conversación. Ninguno de esos datos aislado es infalible. Un asunto reenviado o un número reutilizado puede producir una coincidencia falsa.

Dónde aporta IA y dónde bastan reglas

El correo libre y los adjuntos heterogéneos justifican una capa de interpretación. Puede clasificar el mensaje, detectar que hay una corrección, extraer líneas y señalar campos dudosos. Una importación de Excel con columnas estables quizá solo requiera un mapeo determinista. Si el cliente envía siempre EDI con un esquema acordado, introducir IA en esa parte puede añadir complejidad sin mejorar el resultado.

La validación necesita reglas: artículos existentes, unidades permitidas, clientes activos, precios, dirección, duplicados y datos obligatorios. Una referencia parecida a otra puede proponerse para revisión, no sustituirse sin autorización. El sistema debe conservar qué texto o celda originó cada campo.

En una arquitectura de correo, la API de Microsoft Graph ofrece acceso autorizado a mensajes y datos de conversación de Outlook. La conexión con otro proveedor será distinta. Lo importante es separar captura del buzón, interpretación, validación y escritura en ERP para poder comprobar cada fallo.

Confirmar la escritura y responder al cliente

«Enviado al ERP» no significa «pedido creado». La integración debe registrar la respuesta del sistema y, cuando sea posible, consultar el pedido resultante. Si una petición agota su tiempo de espera, un reintento no debe producir un duplicado. Antes hay que verificar si el alta ya se realizó.

La confirmación al cliente requiere su propio control. No se debe prometer una fecha que solo figuraba como solicitada ni devolver un precio no aprobado. El correo de respuesta puede prepararse a partir del estado confirmado, con una revisión humana para excepciones. Si hay un artículo sustituido o una cantidad ajustada, la respuesta debe explicarlo sin esconder el cambio.

Diseñar las excepciones comerciales antes de la automatización completa

Un piloto necesita una política para precios diferentes al contrato, referencias no reconocidas, cambios de dirección, pedidos por debajo de un mínimo y clientes bloqueados. No todos los casos deben detener el pedido entero: una línea válida puede avanzar como propuesta mientras otra espera aclaración, si el ERP y el procedimiento permiten pedidos parciales. Esa decisión no debería quedar en manos del modelo.

La interfaz de revisión debe mostrar dato leído, valor propuesto y dato maestro. Si el cliente escribió 12 cajas y el catálogo contiene 12 unidades por caja, el operador necesita ver la multiplicación y su fuente antes de aceptar 144 unidades. Un resumen que solo muestre el resultado final elimina la posibilidad de detectar un factor equivocado.

También conviene definir cuándo se acusa recibo. El equipo puede confirmar «hemos recibido tu pedido» antes de aceptar condiciones o fecha. Ese mensaje no debe parecer una confirmación comercial. Separar recepción, aceptación y compromiso de entrega evita que una automatización convierta una interpretación preliminar en una promesa.

Separar recepción, propuesta y compromiso

En el recorrido del pedido hay al menos tres momentos que una interfaz debería distinguir. «Recibido» significa que el correo entró y se guardó. «Preparado» significa que los datos se interpretaron y pasaron ciertas comprobaciones. «Confirmado» significa que la empresa aceptó las condiciones y, si corresponde, creó el pedido en el ERP. Una automatización que une esos estados en una sola marca verde puede generar promesas involuntarias.

El acuse de recepción puede ser rápido y sobrio: identifica la referencia y dice que se revisará. No debería repetir una fecha o precio que aún no se ha comprobado. Después, la propuesta interna reúne líneas, condiciones y excepciones con sus fuentes. Solo cuando el responsable valida y el ERP confirma el alta se prepara una comunicación comercial que indique qué se ha aceptado. La redacción con IA debe depender de ese estado, no del entusiasmo del correo original.

Hay situaciones en que el pedido se acepta parcialmente. Un artículo puede estar disponible y otro requerir sustitución. El sistema necesita representar línea aceptada, línea pendiente y línea rechazada, con motivos. Si solo dispone de un estado global de pedido, debe evitar comunicar «confirmado» sin explicar la excepción. Este diseño requiere acuerdo entre administración comercial, ventas y operaciones. El modelo no puede decidir el significado de «confirmado» por todos ellos.

La fecha solicitada es especialmente delicada. Puede ser una necesidad del cliente, no un compromiso. Si el ERP o la planificación devuelven otra fecha, se debe presentar el cambio al responsable y al cliente según el procedimiento. Una respuesta generada que recicle la fecha del PDF como fecha confirmada convertiría una lectura correcta en un error comercial.

Comprobar precios y referencias con contexto

Una referencia externa puede corresponder a un código interno, a una variante o a un artículo que ya no se vende. El mapeo debe conservar historia. Si el cliente usó A-17 durante años y ahora existe A-17B, quizá se haya pactado una sustitución, pero esa relación necesita aprobación y fecha. El parecido entre códigos no basta.

Con el precio pasa algo parecido. Puede haber contrato por cliente, tarifa por volumen, descuento temporal o condición negociada por correo. La validación debe indicar qué fuente aplica a la fecha y a la cantidad del pedido. Si el cliente escribió un precio diferente, no se corrige silenciosamente para que coincida con el maestro. Se abre una discrepancia que una persona resuelve o traslada al cliente.

Imaginemos un ejemplo ficticio: Cliente Beta pide 80 cajas de P-72 a 18 € por caja. El catálogo interno muestra 12 unidades por caja y el contrato vigente recoge 19 €. El sistema presenta 80 cajas, equivalencia a 960 unidades si el ERP trabaja así, diferencia de precio de 1 € por caja y fuente de ambos datos. No crea un pedido de 80 unidades ni confirma 18 €. El operador decide si existe una excepción comercial autorizada.

La misma transparencia se aplica a direcciones y sociedades. Un cliente puede tener varias plantas con condiciones de entrega diferentes. El dominio del remitente no identifica necesariamente la entidad facturable o el destino. Si la dirección del PDF difiere de la habitual, el flujo pide verificación y evita usar la primera coincidencia del ERP.

Tratar la integración como una transacción verificable

El ERP puede rechazar un pedido por campo obligatorio, bloqueo comercial o límite de crédito. La herramienta de entrada necesita conservar la propuesta y el motivo del rechazo, sin marcarlo como completado. Si el operador corrige una línea y vuelve a enviar, debe poder ver qué cambió y qué versión del pedido se intenta crear.

Una clave de idempotencia o una consulta previa puede ayudar a evitar duplicados, dependiendo de la interfaz del ERP. El problema aparece cuando la llamada se procesa, pero la respuesta se pierde: repetir ciegamente puede crear dos registros. El flujo debe consultar el resultado o usar el mecanismo de identidad que admita el sistema antes de reintentar. No todos los ERP exponen la misma API. El diseño se valida con el producto concreto.

También hay que definir quién puede modificar pedidos existentes. Capturar un correo de corrección es distinto de sobrescribir una orden que ya activó fabricación o reserva de stock. En esos estados, quizá sea obligatorio abrir una solicitud de cambio. La automatización puede preparar la diferencia línea a línea y asignar la tarea, pero no debe eludir el control operativo.

Registrar «mensaje recibido → propuesta → validaciones → aprobación → escritura confirmada → respuesta al cliente» permite diagnosticar dónde se atasca el proceso. Sin ese rastro, una reducción de tiempo de captura puede ocultar un aumento de errores en almacén o facturación.

Implantar por etapas con criterios de salida

La primera etapa puede ser observación: la herramienta lee correos y produce propuestas que se comparan con pedidos introducidos manualmente, sin escribir en el ERP. Ahí se mide extracción, asociación de cliente, duplicados y discrepancias. La segunda permite al operador aprobar una propuesta y crear el pedido mediante la integración. Una tercera, si los datos lo justifican, automatiza un subconjunto bien definido de pedidos rutinarios.

No ampliaría de una etapa a otra por una cifra global de «precisión». Pediría resultados por campo crítico y tipo de excepción. Un porcentaje alto puede esconder errores poco frecuentes de cantidad o destino que tienen mucho impacto. También comprobaría que el equipo tarda menos en revisar la propuesta que en introducir el pedido desde cero.

El piloto debe contemplar mantenimiento. Cambian referencias, tarifas, formatos de clientes y permisos del ERP. Alguien debe tener capacidad de actualizar reglas, revisar incidencias y comprobar que los mensajes siguen entrando. Automatizar un flujo comercial no termina el día que se conecta la API.

Un piloto que pruebe casos incómodos

Escogería una familia de pedidos frecuente y clientes con condiciones conocidas. La muestra debe incluir PDFs, Excel y correos, además de revisiones, duplicados, líneas no reconocidas, precios discrepantes y fechas imposibles. El resultado esperado lo marcan administración comercial y operaciones antes de ejecutar la prueba.

Mediría minutos de intervención por pedido, tasa de errores que llegan al ERP, cambios de pedido mal interpretados, tiempo hasta confirmación y correos que necesitan corrección. También contaría el mantenimiento de reglas y referencias. Una mejora real reduce re-tecleo y aclaraciones posteriores sin trasladar al cliente un error más rápido.

La normalización de PDF, Excel y texto libre debe evaluarse por separado de las validaciones comerciales. Así se sabe si un error nació en la lectura del pedido o en la regla que decidió incorporarlo al ERP.