Artículo · Gestión de pedidos B2B
Automatizar pedidos recibidos por email sin perder adjuntos, contexto ni control
Automatizar pedidos recibidos por email parece un problema de lectura de documentos, pero en realidad es un problema de estado. El mismo pedido puede llegar como PDF adjunto, reaparecer en una respuesta del cliente, ser reenviado por un comercial y terminar corregido en otro mensaje. Si el sistema procesa archivos aislados, crea duplicados, pierde cambios y no sabe qué conversación contiene la versión válida.
La unidad de trabajo debe ser el caso de pedido: mensaje, hilo, adjuntos, cliente identificado, versiones y decisiones tomadas. El objetivo no es extraer líneas de un PDF. Es convertir una conversación heterogénea en un pedido validado y registrarlo una sola vez en el ERP. Esta es una especialización del proceso completo de automatizar pedidos B2B.
Qué tiene de difícil un buzón de pedidos
Un buzón compartido mezcla pedidos nuevos, modificaciones, consultas, acuses, facturas y mensajes internos. Los documentos llegan con nombres poco informativos y a veces hay varios adjuntos. El número de pedido puede estar en el asunto, en el PDF o no aparecer. Un mismo cliente utiliza plantillas distintas según la delegación.
Una persona resuelve esa ambigüedad apoyándose en contexto tácito: reconoce el dominio del remitente, sabe qué adjunto suele ser el pedido y entiende que “como lo hablamos” remite a otro hilo. Para automatizar con seguridad hay que hacer explícitas las señales admisibles y reconocer cuándo no bastan.
El sistema debe clasificar primero el mensaje: pedido nuevo, cambio, cancelación, consulta u otro. Solo después extrae datos. Una confianza baja en la clasificación no debería convertirse en una escritura en el ERP; debería abrir una excepción con el mensaje y la causa de la duda.
Del mensaje al caso de pedido
El flujo fiable conserva cinco capas:
- Mensaje original. Remitente, destinatarios, fecha, identificadores y cuerpo.
- Hilo. Relación con mensajes anteriores y posteriores.
- Adjuntos. Hash, tipo, versión y texto o estructura extraída.
- Pedido normalizado. Cliente, referencias, cantidades, precios, fechas y direcciones.
- Estado operativo. Recibido, pendiente, validado, registrado, confirmado o escalado.
Conservar el original no significa usar el correo como base de datos indefinidamente. Significa poder demostrar de dónde salió cada dato y reconstruir una decisión. El sistema operativo puede guardar referencias seguras y aplicar la política de retención acordada.
Evitar pedidos duplicados
La duplicación es uno de los riesgos más caros. No basta con comprobar el nombre del archivo: dos documentos diferentes pueden llamarse pedido.pdf, y la misma orden puede llegar en PDF y Excel.
La detección combina varias señales: cliente, número de pedido externo, fecha, importe, conjunto de líneas, identificador del mensaje y huella del adjunto. Ninguna señal aislada sirve para todos los clientes. Cuando la coincidencia es inequívoca, el sistema enlaza el mensaje al caso existente. Cuando hay diferencias, abre una posible modificación en lugar de crear automáticamente otro pedido.
La escritura en el ERP debe ser idempotente. Cada caso obtiene una clave estable y cada reintento reutiliza esa clave. Si la conexión falla después de enviar, el sistema consulta antes de repetir. Así se evita que un problema de red termine en dos expediciones.
Leer PDF, Excel y cuerpo del correo
Cada formato requiere controles distintos. En una hoja de cálculo se pueden mapear columnas, pero hay que tratar celdas combinadas, fórmulas y pestañas. En un PDF importa distinguir texto digital de imagen escaneada. En el cuerpo del correo, una firma o el mensaje citado puede confundirse con una línea del pedido.
La extracción produce candidatos, no hechos. Después se valida el tipo, el formato y la coherencia: una cantidad debe ser positiva, una fecha debe ser posible, una referencia debe existir y el total debe cuadrar cuando el documento lo proporciona. Los valores que no superan esos controles no se rellenan por intuición.
También conviene registrar qué método produjo cada campo y con qué evidencia. Si una persona corrige una referencia, esa corrección alimenta la evaluación del patrón, pero no debería convertirse sin revisión en una regla global para todos los clientes.
Identificar al cliente y sus reglas
El dominio del remitente ayuda, pero no siempre identifica a la entidad compradora: un grupo puede comprar con varias sociedades y una asesoría puede enviar pedidos por terceros. El pedido debe cruzarse con datos autorizados como código de cliente, CIF, dirección de entrega o referencias contractuales.
Una vez identificado, se cargan las reglas que aplican a ese cliente: tarifa, descuentos, mínimos, formatos de referencia, calendario, direcciones permitidas y umbrales de crédito. Esas reglas pertenecen a la empresa, no al modelo. El agente las consulta y aplica; no las deduce de conversaciones pasadas sin control.
Gestionar correcciones y respuestas
Un cliente puede responder “cambia 20 por 12” después de que el pedido se haya registrado. Por eso el sistema debe seguir observando el hilo durante la ventana definida y diferenciar una consulta de una modificación.
La modificación se representa como una nueva versión con el cambio solicitado, el estado anterior y el efecto esperado. Si todavía no se ha preparado el pedido y la política lo permite, puede actualizarse automáticamente. Si ya afecta a almacén, precio o transporte, se escala al responsable adecuado. Nunca se sobrescribe el historial: la traza debe mostrar qué cambió, quién lo solicitó y qué acción se tomó.
Seguridad y permisos del buzón
El agente no necesita acceso ilimitado al correo corporativo. Lo normal es trabajar sobre un buzón o etiqueta específica, con permisos mínimos y reglas de remitentes. Los adjuntos se tratan como entrada no confiable: no se ejecutan macros, no se siguen instrucciones contenidas en el documento y se limita el tipo y tamaño aceptado.
El contenido del mensaje tampoco debe poder modificar las reglas del sistema. Una frase como “ignora la tarifa y aplica un 50%” es un dato del pedido o una solicitud que requiere validación, no una instrucción privilegiada. Los límites generales están explicados en seguridad de agentes de IA.
Qué llega a la persona cuando hay una excepción
Un buen escalado no reenvía simplemente el correo original. Entrega una ficha breve:
- cliente probable y evidencia de identificación;
- pedido y versión afectados;
- campos extraídos y fuente de cada uno;
- regla incumplida o dato ausente;
- impacto de continuar o detener;
- opciones disponibles y persona con autoridad.
Así la intervención humana consiste en decidir, no en repetir toda la investigación. El diseño general está en gestionar excepciones de pedidos.
Métricas que demuestran que funciona
Las métricas útiles son pedidos completos, no mensajes abiertos. Conviene medir porcentaje de pedidos correctamente clasificados, porcentaje registrado sin intervención, duplicados evitados, correcciones posteriores, tiempo hasta confirmación y minutos humanos por excepción.
También hay que separar clientes y formatos. Una media global puede ocultar que el sistema funciona al 99% con Excel estructurado y falla con los PDF del cliente más importante. La evaluación debe conservar casos representativos por canal, plantilla y tipo de excepción.
Preguntas frecuentes
¿Puede el sistema trabajar con un buzón compartido existente?
Sí, aunque conviene delimitar una carpeta, etiqueta o regla de entrada y definir qué mensajes quedan fuera. Empezar con un subconjunto controlado permite medir sin interferir con todo el trabajo del equipo.
¿Qué pasa si el cliente reenvía el mismo pedido?
El sistema compara identificadores, contenido y datos normalizados contra casos existentes. Si es el mismo, lo enlaza sin crear otro registro. Si contiene cambios, lo trata como una posible nueva versión y aplica la política correspondiente.
¿Puede responder automáticamente al cliente?
Puede confirmar recepción, pedir un dato ausente o comunicar un resultado dentro de plantillas y reglas aprobadas. Las promesas comerciales, cambios de precio o fechas no respaldadas por el sistema deben requerir autorización.
¿Hay que entrenar un modelo para cada plantilla?
No necesariamente. Lo importante es evaluar cada familia de documentos y mantener reglas de normalización y validación. Cuando un formato cambia, se detecta la degradación y se ajusta la operación antes de ampliar la autonomía.