Cuando cada correo de pedido se ingresa manualmente en el ERP

5 min de lectura

Cada mañana la bandeja de entrada se llena de pedidos: en correos de texto, en PDF o en formularios escaneados. En el servicio de atención al cliente, alguien los introduce a mano en el ERP, línea por línea. Esto consume horas, genera errores de transcripción y retiene a personal que debería estar asesorando en lugar de introduciendo datos. Estos correos de pedidos son datos oscuros: sin medir, sin estructurar y costosos. Un modelo de lenguaje puede extraer y preparar los datos de estos pedidos. Pero esto solo resulta viable si un formato de datos estricto disciplina la salida y una persona la valida al final.

Relacionado:Cuando el agente contabiliza la factura de entrada por sí mismo  /  La optimización de procesos fracasa en el traspaso

Los pedidos que nadie cuenta

En muchas empresas medianas, la recepción de pedidos se gestiona a través de un buzón genérico. El cliente escribe lo que necesita, ya sea en una tabla impecable, en texto corrido o, a menudo, en la foto de un albarán manuscrito. El equipo de back office lee, clasifica y teclea. El lunes por la mañana se acumula el trabajo porque los pedidos siguen llegando durante el fin de semana.

Se repiten tres tipos de errores. Una línea se asigna incorrectamente porque el número de artículo del cliente no coincide con el interno. Una cantidad se descuadra porque se confunde la unidad de embalaje con el número de unidades. Un precio varía porque el cliente hace referencia a un presupuesto antiguo. Cada uno de estos errores acaba costando más que el minuto que se tardó en teclearlo. Quien conoce sus costes de proceso identifica aquí una partida oculta, comparable a la trampa del mantenimiento del ERP en las pymes.

Cómo lee la IA y cómo el formato la disciplina

El patrón subyacente no está vinculado a un fabricante concreto. Se ejecuta en cuatro pasos. Primero, el ERP se sincroniza con el buzón de correo a través de una interfaz de correo como Microsoft Graph o IMAP y lee los nuevos mensajes junto con sus archivos adjuntos. A continuación, un modelo de lenguaje analiza el contenido basándose en instrucciones predefinidas. Posteriormente, el modelo no devuelve los datos reconocidos como texto continuo, sino en un formato JSON fijo. Por último, un proceso de validación comprueba el resultado, lo escribe en una tabla intermedia y crea el pedido de forma automática o tras una aprobación manual.

El truco decisivo es el esquema forzado. Un modelo de lenguaje tiende a formular respuestas de forma libre. Un esquema JSON especifica cada campo que debe rellenarse. La charla informal se convierte así en una estructura legible por máquinas. Esto disciplina la forma, no la veracidad del contenido. El esquema evita respuestas libres y reduce los errores de formato. Sin embargo, no sustituye a una revisión técnica. De este mismo modo se pueden abordar casos complejos: un primer prompt clasifica el correo como pedido, ticket o documento y lo deriva en consecuencia. Quien piense más allá del paso del buzón a la contabilización, llegará rápidamente a la pregunta de cuándo un agente contabiliza por sí mismo la factura recibida.

Esta clasificación muestra tendencias. Con pocos formatos de pedido estables, una plantilla OCR sigue siendo a menudo la opción más económica.

Cómo implementan hoy los proveedores este patrón

Varios tipos de proveedores siguen este camino. Los especialistas en procesamiento de documentos como ABBYY o Konfuzio extraen datos de los comprobantes y los transmiten. Las plataformas de automatización como UiPath o Microsoft Power Automate encadenan pasos entre distintos sistemas. Las grandes casas de ERP construyen sus propios módulos, por ejemplo, en torno a SAP o Microsoft Dynamics. Los fabricantes de ERP, a su vez, integran directamente el patrón en su propia plataforma, donde llega al procesamiento de pedidos sin capa intermedia. Qué camino es el adecuado depende del grado de integración en el ERP propio, de la soberanía de los datos y de la madurez de la validación humana, no de la promesa más rimbombante. Que la herramienta rara vez es el problema queda patente cuando la optimización de procesos fracasa en el traspaso.

La empresa de software austriaca Multidata, por ejemplo, implementa este patrón en su plataforma MD-Premium. Según el fabricante, el buzón se sincroniza a través de Microsoft Graph, un modelo europeo de Mistral analiza el correo y devuelve los datos en un JSON estricto. Si falta el número de artículo propio, el sistema lo identifica mediante puntos de datos alternativos como la dirección de entrega, el número de cliente, la UID o el EAN. Una validación detecta los obstáculos típicos. Si un cliente pide tres unidades al precio de 144 unidades, el sistema reconoce la unidad de embalaje y lo corrige a tres por 48. En detalles como este se decide cuánta carga asume realmente la automatización.

Europeo no significa automáticamente conforme

Optar por un modelo europeo como Mistral es para las pymes algo más que simbólico. Reduce la dependencia de proveedores extracomunitarios y da en el clavo del debate sobre la soberanía digital. Pero el sello de origen por sí solo no resuelve la cuestión legal. Hay que distinguir cuatro afirmaciones: un modelo europeo, un alojamiento en la UE, un entrenamiento sin datos de clientes y una cadena de suministro sin subencargados fuera de la UE. Solo en conjunto conforman una política de privacidad sólida, blindada mediante un contrato de tratamiento de datos. Quien introduzca la IA en el servicio de atención al cliente debe aclarar estos cuatro puntos por escrito antes de que el primer correo real de un cliente pase por el modelo. De lo contrario, se corre el riesgo de caer en una variante de la IA en la sombra en las pymes, solo que esta vez aprobada.

Dónde debe seguir interviniendo el factor humano

El mayor error de concepto es confundir el esquema con la seguridad. Un modelo puede entregar un JSON formalmente válido en el que figure el cliente equivocado. La estructura es correcta, el contenido no. Por eso, la tabla intermedia con validación manual no es un defecto estético, sino el componente fundamental.

Quien fija el umbral de confianza demasiado alto, automatiza errores directamente en la contabilización. Quien lo fija demasiado bajo, devuelve cada correo al factor humano y no gana nada. El umbral adecuado es una decisión operativa, no técnica.

Cuatro preguntas antes de comenzar

Estas cuatro preguntas separan el proyecto rentable del intento costoso. Quien pueda responderlas, ya conoce la mitad de la respuesta.

1. ¿Cuántos pedidos pasan diariamente por el buzón de correo? ¿Cuántas variantes de formato hay entre ellos?
2. ¿Qué campos puede registrar el sistema automáticamente y cuáles necesitan autorización?
3. ¿Dónde se alojan el modelo y los datos? ¿Está firmado el contrato de encargado del tratamiento?
4. ¿Quién mide la tasa de corrección para que la automatización no se convierta en un vuelo a ciegas?

El correo de pedido no desaparece. Simplemente, o se transcribe a mano o lo lee una máquina supervisada por un humano. Quien configure el patrón correctamente, recupera tiempo para lo que ningún modelo puede hacer: consultas, reclamaciones y asesoramiento. Quien lo configure sin autorización ni medición, solo desplaza el error a un lugar donde nadie vuelve a verlo.

Preguntas frecuentes

Recomendaciones de lectura de la redacción

Fuente de la imagen: generada por IA (junio de 2026)