Automatizar pedidos por email al ERP en 2 min

La bandeja de entrada de tu equipo de ADV es probablemente tu sistema principal de gestión de pedidos. No SAP. No tu portal de cliente. Tu bandeja de Outlook.

Es donde llega el 60 a 70% de los pedidos B2B reales en las empresas industriales marroquíes. Un comprador enviando un archivo Excel. Un cliente escribiendo detalles del pedido en el cuerpo del mensaje. Una cuenta clave adjuntando una orden de compra PDF oficial. Un contacto respondiendo a un hilo de hace tres días para confirmar una cantidad. Todos estos correos electrónicos llegan a la misma bandeja. Todos ellos esperan a que un operador de ADV abra, lea, interprete, lance SAP, vuelva a ingresar los datos y envíe una confirmación manual.

Este flujo no está optimizado ni instrumentado. No aparece en ningún panel de control operativo. No genera alerta cuando un correo electrónico ha estado esperando cuatro horas sin ser procesado. Y sin embargo, es el canal de pedidos dominante en prácticamente todas las empresas industriales marroquíes.

Este artículo describe exactamente cómo automatizar este flujo de extremo a extremo. Desde el mensaje entrante hasta el pedido creado en SAP, en menos de 2 minutos, sin intervención humana en el flujo estándar.

Anatomía de un Pedido por Correo Electrónico: Los Cinco Formatos Reales

Antes de diseñar cualquier automatización, necesitas mapear lo que realmente llega a la bandeja de entrada de ADV. Hay cinco formatos distintos, y cada uno presenta un desafío técnico diferente.

El primer formato es el correo electrónico con un documento PDF de orden de compra adjunto. Este es el caso más estructurado. El cliente tiene un ERP o software de gestión que genera un documento PDF estandarizado. El diseño es fijo, los campos son identificables, la calidad del archivo es alta. Es el caso más fácil de procesar y el menos común en la realidad del mercado marroquí.

El segundo formato es el correo electrónico con una hoja de cálculo Excel adjunta. El cliente gestiona sus pedidos en un archivo Excel personal, a menudo diferente de un pedido a otro, con columnas renombradas, filas de totales mezcladas con filas de productos, y múltiples pestañas donde debe identificarse la correcta. Este es un formato que OCR no puede manejar en absoluto, y que la IA de documentos estándar maneja mal.

El tercer formato es el correo electrónico de texto sin formato. El cuerpo del mensaje contiene toda la información necesaria para crear el pedido: "Hola, necesito 30 cajas ref 4402 y 15 pallets ref 7801 para entrega el jueves en el almacén de Ain Sebaa, por favor confirmar." Sin adjuntos. Sin estructura. Un texto conversacional que solo un agente LLM puede interpretar correctamente.

El cuarto formato es el correo electrónico con una imagen escaneada. La orden de compra existe en papel, ha sido firmada y sellada, luego fotografiada o escaneada y enviada como adjunto JPEG o PDF. La calidad del escaneo varía. Puede haber anotaciones manuscritas en los márgenes. Este es el formato más difícil de procesar y uno de los más comunes en los sectores de construcción y distribución regional.

El quinto formato es la confirmación dentro de un hilo de correo electrónico. El pedido real está en una respuesta a un hilo de discusión existente, incrustado en intercambios relacionales. "De acuerdo con las cantidades, adelante." Sin el contexto del hilo, esta frase no significa nada. Con el contexto, es un pedido completo. Solo un agente que lea todo el hilo puede procesarlo correctamente.

Un sistema que no cubra estos cinco formatos no cubre la realidad del mercado marroquí. Automatiza una fracción del flujo y deja el resto como procesamiento manual.

El flujo de trabajo completamente automatizado: paso a paso

Para automatizar pedidos por correo electrónico e introducirlos en un ERP, el flujo estándar incluye los siguientes pasos.

Paso 1: Recepción y clasificación. El correo electrónico llega a una bandeja de entrada de pedidos dedicada o a la bandeja de entrada general del departamento de ventas. El agente lee el correo electrónico entrante y determina su naturaleza: pedido, solicitud de precio, reclamación, correo relacional. Esta clasificación es la primera decisión del sistema. No se basa en palabras clave predefinidas sino en la comprensión del contenido. Un correo que dice "¿puedes enviarme un precio para 50 unidades?" es una solicitud de precio. Un correo que dice "confirmado para 50 unidades, puedes preparar" es un pedido.

Paso 2: Extracción de datos. Una vez que el correo se identifica como un pedido, el agente extrae los campos necesarios para crear el pedido en SAP: cliente, referencia de producto, cantidad, unidad, fecha de entrega solicitada, dirección de entrega, condiciones especiales mencionadas. La extracción se adapta al formato: texto, PDF, Excel, imagen, hilo de mensajes. La fuente se rastrea para cada dato extraído.

Paso 3: Validación contra los datos de referencia de SAP. Cada campo extraído se valida contra los datos de referencia de la empresa. El cliente existe en SAP y está activo. La referencia de producto está presente en el catálogo y disponible. El precio implícito o declarado coincide con la tarifa aplicable para este cliente. La dirección de entrega está vinculada a la cuenta de cliente correcta. Esta validación es automática y toma menos de 3 segundos.

Paso 4: Decisión y acción. Si todos los campos se validan con suficiente confianza, la orden se crea directamente en SAP. Si uno o más campos son ambiguos o inválidos, el agente aísla esos campos específicos y genera una notificación interna para el operador ADV. La notificación contiene solo los elementos en cuestión, no toda la orden que debe ser reingresada.

Paso 5: Confirmación del cliente. Independientemente de si hubo o no intervención humana, se envía una confirmación automática al cliente una vez creada la orden: número de orden, resumen de líneas confirmadas, fecha de entrega esperada. El cliente recibe una respuesta dentro de 2 minutos de su correo electrónico, sin importar la hora en que realizó su pedido.

Este flujo de trabajo procesa una orden estándar en 45 segundos a 2 minutos según la complejidad del documento fuente. Se ejecuta 24 horas al día, 7 días a la semana, sin picos de carga de fin de mes.

Casos ambiguos: Cómo decide el sistema

Aquí es donde los sistemas simples se detienen y donde los agentes marcan la diferencia. Los casos ambiguos no son raros. Representan del 3 al 7% del flujo real según el perfil del cliente. Aquí hay tres casos concretos y el comportamiento esperado de un sistema diseñado correctamente.

Primer caso: el cliente realiza un pedido de una referencia obsoleta. La referencia "4402-B" fue reemplazada en el catálogo por la referencia "4402-C" hace dos meses. El cliente no ha actualizado sus órdenes de compra internas. El agente identifica que "4402-B" ya no existe en el catálogo activo. Identifica la referencia de reemplazo designada en el sistema. Genera una excepción con ambas referencias, el motivo de la sustitución propuesta, y somete la decisión al operador de ADV. No crea el pedido con una referencia inexistente, y no rechaza el pedido sin proponer una solución.

Segundo caso: el pedido llega desde un correo electrónico no registrado. Un nuevo contacto de un cliente existente envía un pedido desde su dirección de correo electrónico personal, aún no registrada en SAP. El agente identifica el dominio de correo electrónico del remitente, lo vincula a la cuenta de cliente correspondiente en la base de datos, crea el pedido bajo la cuenta de cliente correcta, notifica al gestor de cuenta para que registre el nuevo contacto, y confirma la recepción al cliente. El pedido no se bloquea porque el remitente es nuevo.

Tercer caso: la cantidad pedida excede el stock disponible. El cliente realiza un pedido de 200 cajas de una referencia con solo 140 cajas en stock. El agente no rechaza el pedido y no lo crea para 200 cajas con un problema oculto. Crea un pedido firme de 140 cajas del stock disponible, genera automáticamente un pedido pendiente para las 60 cajas faltantes con la fecha de reabastecimiento esperada, y envía dos confirmaciones separadas al cliente: entrega inmediata de 140 cajas, entrega diferida de 60 cajas en la fecha de reabastecimiento.

Los tres comportamientos comparten la misma lógica: el agente ni bloquea ni deja pasar un error. Propone una resolución o aísla el problema para que un humano pueda manejarlo con contexto completo.

Lo que el Equipo de ADV Realmente Gana

El cambio no es cuantitativo. Es cualitativo en la naturaleza del trabajo realizado.

Antes de la automatización, cada pedido por correo electrónico sigue el mismo ciclo. El operador abre el correo, lee el contenido, lo identifica como un pedido, abre SAP, reingresa los datos campo por campo, verifica la consistencia, guarda, regresa al correo, envía una confirmación manual. Para un pedido estándar sin complicaciones, esta secuencia toma entre 8 y 12 minutos. Para un pedido con una anomalía, una referencia a verificar, o un cliente con condiciones especiales, toma entre 20 y 30.

Después de la automatización, del 93 al 97% de los pedidos por correo electrónico pasan a SAP sin intervención humana. El operador de ADV maneja excepciones, promediando 30 segundos por excepción, con contexto completo visible. No reingresan nada. Deciden sobre los casos que justifican una decisión humana.

El resultado operativo directo es este. Un equipo ADV de dos personas gestiona el volumen que requería cuatro personas sin automatización. No porque las dos personas restantes trabajen más rápido, sino porque el 95% de la carga de trabajo mecánica ha desaparecido. Las dos personas restantes realizan un trabajo diferente: gestionan excepciones, relaciones complejas con clientes, y casos que requieren un verdadero juicio humano.

Integración Técnica: Qué Es y Qué No Es Necesario

La pregunta técnica más común en reuniones previas a la implementación es esta: ¿qué necesitamos modificar en nuestra infraestructura?

La respuesta es directa. No es necesario modificar SAP. No es necesario desplegar nueva infraestructura de servidores. No es necesario abrir acceso complejo a ERP o lanzar un proyecto de integración de 6 meses.

La integración con SAP se realiza a través de la API estándar existente o mediante un conector certificado. El agente tiene acceso de lectura a los datos de referencia necesarios, catálogo de productos, base de datos de clientes y tablas de tarifas, y acceso de escritura al módulo de creación de pedidos. Este es un alcance de acceso estrecho y auditable, revocable en cualquier momento.

El despliegue en un flujo de pedidos por correo electrónico homogéneo, es decir, un conjunto de clientes con formatos de documento relativamente estables, requiere de 3 a 4 semanas. La primera semana se dedica al mapeo de formatos entrantes y a la configuración de reglas de validación. Las próximas dos semanas al despliegue en modo de observación, donde el agente procesa pedidos en paralelo con el equipo de ADV y se comparan los resultados. La cuarta semana es el cambio de activación con supervisión.

Los datos permanecen dentro del entorno de la empresa. El despliegue es posible en nube privada o en las instalaciones según los requisitos de seguridad de la organización.

Conclusión

Su bandeja de entrada de ADV no es un canal de comunicación. Es un sistema de pedidos no estructurado que gestiona del 60 al 70% de su flujo entrante sin instrumentación, sin trazabilidad automática, y con un costo en tiempo y errores que nadie en la organización ha consolidado nunca porque es invisible en los informes estándar.

Automatizar este flujo es la decisión con la mejor relación impacto-tiempo de despliegue disponible hoy para una empresa industrial marroquí. El volumen procesado se vuelve inmediatamente visible. Los ahorros de tiempo son medibles desde la primera semana. Los errores desaparecen estructuralmente, no gradualmente.

El único requisito previo es decidir que la bandeja de entrada ADV merece la misma atención operativa que el ERP que recibe desde ella.