Saltar al contenido
Implementa.

Solución · Por problema

Los pedidos entran por seis sitios distintos y alguien los teclea uno a uno

Email con el PDF adjunto, un Excel que cada cliente maquetó a su manera, el portal del distribuidor, un EDI que solo usan los dos grandes y, todavía, un fax escaneado. Al final del embudo hay una persona copiando referencias a mano en el ERP. Eso es un trabajo, no un destino: se automatiza.

El problema

El cuello de botella no es el ERP. Es el teclado que hay delante.

  • Cada cliente manda el pedido en su formato: un PDF con la plantilla de su departamento de compras, un Excel con columnas propias, el cuerpo de un correo en texto plano. Ninguno coincide con el siguiente.
  • La referencia del cliente no es tu referencia. Alguien tiene que traducir su código, su descripción o su nombre comercial a tu SKU, y ese alguien lo hace de memoria.
  • El pedido urgente entra a las 17:50 y se mete mañana, porque quien lo teclea ya se ha ido. La entrega se retrasa un día por un motivo administrativo, no logístico.
  • Los precios se validan a ojo contra la tarifa del cliente. Cuando no cuadra, se descubre en la factura y acaba en una nota de abono.

Coste de seguir igual

El coste no está en las horas de teclear, aunque las pagues: está en lo que esas horas dejan pasar. Un dígito mal copiado en una cantidad se convierte en una expedición equivocada, una devolución, un abono y una llamada de un cliente que ya no te da la urgencia por defecto. Los errores en pedidos B2B no son marginales —el B2B Buyer Report 2025 de Sana Commerce, con investigación de Sapio Research sobre 750 compradores profesionales de Estados Unidos, Reino Unido, México, Alemania, Australia y Países Bajos, sitúa en el 33% los pedidos online con algún error, y en el 29% los compradores que señalan imprecisiones de precio—. Y el EDI no lo resuelve solo: en España, según la encuesta ETICCE del INE (datos de 2024 publicados en 2025), el 56% de las ventas por comercio electrónico llegan por intercambio electrónico de datos, lo que también significa que casi la mitad entra por otro sitio, y ese otro sitio es una bandeja de entrada. Mientras tanto, escalar ventas significa contratar a otra persona para teclear, y el pico de campaña se nota antes en la cola de pedidos que en el almacén.

La solución

Una capa de captura que lee cualquier formato, casa contra tu maestro y deja el pedido creado con las dudas marcadas

  1. 1Conectamos todas tus entradas reales a un mismo sitio: el buzón de pedidos, los adjuntos en PDF y Excel, el portal donde algunos clientes suben ficheros y el canal EDI que ya tengas. Nada de pedir a tus clientes que cambien cómo compran: el que manda un PDF sigue mandando un PDF.
  2. 2Un agente extrae las líneas del documento —referencia, descripción, cantidad, precio, fecha pedida, dirección de entrega— y las normaliza. La parte difícil no es leer el PDF: es que el mismo artículo se llama de tres formas distintas en tres clientes, y ahí es donde la IA aporta frente a una plantilla rígida.
  3. 3Cada línea se casa contra tu maestro de artículos y contra la tarifa de ese cliente: SKU correcto, unidad de medida correcta, precio y descuento que le corresponden por contrato. Lo que no llega a un nivel de confianza suficiente no se inventa: se marca como excepción con el documento original al lado, para que una persona resuelva solo eso.
  4. 4El pedido se crea en tu ERP —SAP Business One, Odoo, Business Central, Sage, Holded o el que uséis— con su confirmación automática al cliente. Y lo dejamos medido: qué porcentaje entra sin tocar, cuántas excepciones por cliente y por formato, y cuánto tarda un pedido desde que llega hasta que existe en el sistema.

Lo que cambia

Lo que dejas de perder

  • El 33% de los pedidos online B2B contenía algún error, y el 29% de los compradores señaló imprecisiones de precio. Ámbito: 750 compradores profesionales de EE. UU., Reino Unido, México, Alemania, Australia y Países Bajos; campo de septiembre de 2024.

    Sana Commerce, B2B Buyer Report 2025 (investigación de Sapio Research) — https://www.sana-commerce.com/report/b2b-buyer/

  • El pedido deja de depender del horario de quien lo teclea: entra a las 17:50 y existe en el ERP a las 17:51, con la excepción marcada si la hay. Lo que se gana no es tiempo administrativo, es un día de entrega.

    Mecanismo

  • Qué medimos: % de pedidos creados sin intervención humana, excepciones por cliente y por formato de entrada, tiempo desde la recepción hasta el pedido creado, líneas corregidas a mano después de la captura y abonos por error de precio o cantidad.

    Qué medimos

Ficha técnica

Trabajo que elimina
teclear a mano en el ERP los pedidos que llegan por email, PDF, Excel o portal
Implementación habitual
3–5 semanas
Entrada
pedido del cliente en su formato: PDF, Excel, cuerpo de correo, fichero de portal o EDI
Salida
pedido creado en el ERP con líneas casadas contra tu maestro y tu tarifa, y las dudas marcadas como excepción
Compatible con
SAP Business OneOdooMicrosoft Dynamics 365 Business CentralSageHolded
Puede conectarse con
Microsoft 365 o Google WorkspaceTu maestro de artículos y tarifas por clienteTu canal EDI actual
Qué medimos
% de pedidos creados sin intervención humanaexcepciones por cliente y por formato de entradatiempo desde la recepción hasta el pedido creado en el ERPabonos por error de precio o cantidad
Adecuado para
empresas que reciben pedidos recurrentes por varios canales y tienen un maestro de artículos y tarifas mantenido
No adecuado para
pedidos de proyecto configurados a medida, donde cada línea se negocia y no existe catálogo estable contra el que casar

Preguntas frecuentes

No, y de hecho conviven bien. El EDI resuelve el pedido de los clientes grandes que ya tienen su propio sistema y aceptan un formato acordado: cuando existe, funciona y no lo tocamos. El problema es todo lo demás — el cliente mediano que manda un PDF, el que rellena un Excel con sus columnas, el que escribe las referencias en el cuerpo del correo. Pedirles a todos que se pasen a EDI es una negociación comercial que puede llevar años y que algunos no van a aceptar. Esta capa cubre exactamente ese hueco: acepta el pedido tal y como el cliente quiere mandarlo y lo convierte en un pedido estructurado en tu ERP. Si mañana uno de esos clientes se pasa a EDI, mejor: entra por el canal bueno y esta capa deja de tocarlo.

Se marca y se para esa línea, no el pedido entero ni el sistema. La regla de diseño es que lo dudoso nunca se completa a ojo: si la referencia del cliente no casa con una sola de tus SKU, si la unidad de medida no cuadra, si el precio se aleja de la tarifa que tiene firmada o si falta la fecha pedida, esa línea va a una cola de excepciones con el documento original al lado y la propuesta del sistema marcada como propuesta. Una persona la resuelve en segundos en vez de teclear el pedido entero. Y esa cola es la mejor métrica que vas a tener: si un cliente concreto genera excepciones todas las semanas, ya sabes con quién merece la pena hablar de formato, y si un tipo de excepción se repite, es una regla que falta.

Depende de dónde pongas el umbral, y esa decisión es tuya, no nuestra. Lo montamos con un nivel de confianza configurable por tipo de campo: se puede empezar en modo conservador, donde todo pedido pasa por una confirmación humana de un clic y el sistema solo ahorra el tecleo, y bajar la supervisión a medida que los números lo justifican, cliente a cliente y formato a formato. Los campos con consecuencia —cantidad, precio, dirección de entrega— pueden quedarse siempre en revisión aunque el resto vaya solo. Y todo queda trazado: qué documento originó cada línea, qué extrajo el sistema, qué cambió una persona. La comparación honesta tampoco es contra un proceso infalible: es contra alguien tecleando cuatrocientas líneas un viernes por la tarde.

¿Lo montamos en tu negocio?

Tú tienes el problema localizado. Nosotros lo dejamos funcionando y medido.

Ver el servicio
Los pedidos entran por seis sitios distintos y alguien los teclea uno a uno · Implementa