Cómo automatizar pedidos por WhatsApp hasta Odoo

El problema: una persona dedicada a pasar fotos de órdenes a Odoo

Así funcionaba antes: el vendedor visita el supermercado, recibe la orden de compra en papel, le toma una foto y la manda a un grupo de WhatsApp. Del otro lado, una persona revisa el grupo todo el día, descarga cada imagen, la lee, pasa los datos a una hoja de Google Sheets, luego al ERP, genera el presupuesto y lo envía. Una persona completa dedicada a transcribir.

Además del salario, el costo estaba en el tiempo entre la foto y el presupuesto (horas, a veces un día), en los errores de dedo en cantidades y precios y, lo más caro, en que nadie tenía tiempo de mirar los datos. Los pedidos existían en fotos y en celdas sueltas, pero no había un reporte que dijera cuánto vendió cada vendedor esta semana o qué tienda está comprando menos que el mes pasado.

Esto es típico en empresas CPG que venden a cadenas: la orden de compra nace en papel o en el sistema del cliente, y el trabajo de "meterla a tu sistema" recae en alguien. Es exactamente el tipo de tarea repetitiva que la automatización de procesos con inteligencia artificial resuelve bien, porque la entrada es desordenada (una foto) pero la salida es siempre la misma (un presupuesto con columnas fijas).

Qué hace el sistema, en 7 pasos

El vendedor sigue mandando la foto por WhatsApp, igual que siempre. Lo que cambió es lo que pasa después: un flujo en n8n descarga la imagen, la inteligencia artificial extrae las columnas de la orden, el sistema valida que no falte nada, guarda un respaldo en Google Sheets y crea el presupuesto en Odoo. Si algo no se lee, le pregunta al vendedor en lugar de adivinar.

1. El vendedor manda la foto de la orden de compra al número de WhatsApp de la empresa (WhatsApp Cloud API, no un celular con WhatsApp Web).
2. n8n recibe el mensaje, descarga la imagen y la guarda en una carpeta de Google Drive, ordenada por fecha y vendedor. Ese es el historial: cualquier orden se puede volver a ver.
3. El modelo de visión lee la imagen y devuelve las columnas predeterminadas en JSON: tienda, fecha, número de orden, productos, cantidades, precios y total.
4. Validación. Si falta una columna obligatoria (foto borrosa, un dedo tapando el total, una esquina cortada), el sistema no sigue.
5. Aviso al vendedor. Le responde por WhatsApp: "En la orden 4471 no se lee el campo total. ¿Me reenvías la foto?". El vendedor la vuelve a tomar y el flujo arranca de nuevo.
6. Respaldo y presupuesto. Si la orden está completa, se escribe una fila en Google Sheets (fecha, número de orden, tienda, vendedor, número de productos, total) y se crea el presupuesto en Odoo. La factura final la sigue emitiendo una persona desde ese presupuesto.
7. Reportes. Con esas filas, el sistema arma solo el reporte diario, el semanal y el mensual. Más abajo explico por qué el reporte es la parte que más valor dejó.

Arquitectura: WhatsApp Cloud API → n8n → inteligencia artificial → Drive y Sheets → Odoo

Cinco piezas, ninguna exótica:

• WhatsApp Cloud API (la API oficial de Meta) recibe las fotos y envía los avisos. Un número de empresa, no el celular de alguien.
• n8n es el orquestador: escucha el webhook, mueve archivos, llama al modelo, escribe en Sheets y en Odoo.
• Un modelo de visión (usamos un modelo de Gemini) hace el trabajo de "leer" la foto y devolver datos estructurados.
• Google Drive y Google Sheets guardan la imagen y una fila por orden.
• Odoo recibe el presupuesto por su API. No tocamos la base de datos directamente.

Por qué guardamos todo en Google Sheets antes de Odoo

Parece redundante, pero la hoja cumple tres funciones. Es el respaldo si algo falla en Odoo, es la pista de auditoría (cada fila apunta a la imagen original en Drive) y es la fuente de los reportes, que se arman sobre la hoja sin pegarle al ERP cada hora. Además, el equipo ya sabía usar Sheets: cuando algo se ve raro, lo revisan ahí.

Qué pasa cuando la foto está borrosa o falta un dato

Este fue el diseño más importante del proyecto. La regla es que el sistema no adivina. Si el modelo no encuentra una columna obligatoria, la marca en un campo faltantes y el flujo se detiene antes de escribir nada en Odoo. El vendedor recibe el aviso con el nombre exacto del campo que falta y vuelve a mandar la foto.

El contrato de salida del modelo es estricto. Esto es lo que le pedimos que devuelva, siempre, aunque la foto venga mal. El sku sale del mapeo de catálogo del que hablamos más abajo: el modelo lee la descripción de la cadena y la resuelve al código del producto en Odoo.

{
  "tienda": "Supermercado Zona 10",
  "fecha": "2026-08-19",
  "numero_orden": "4471",
  "vendedor": "+502 5XXX XXXX",
  "lineas": [
    {"sku": "PROD-001", "producto": "Producto A (caja 24)", "cantidad": 12, "precio_unitario": 38.00},
    {"sku": "PROD-002", "producto": "Producto B 2 L", "cantidad": 8, "precio_unitario": 14.50}
  ],
  "total": 572.00,
  "faltantes": []
}

Ejemplo de referencia: la estructura es la real, los datos no. Nombres de tienda, productos, códigos y montos son inventados para el artículo.

Si faltantes trae algo (por ejemplo ["total"]), no se crea nada y se avisa. Si viene vacío, se valida que total sea un número y que la suma de líneas cuadre, y recién entonces se escribe en Sheets y en Odoo.

Los reportes: diario, semanal, mensual y el "pedido ideal" por tienda

Aquí está el cambio que el dueño sintió más. Antes los datos existían y nadie los miraba; ahora llegan solos:

• Diario: monto total del día, cantidad de productos, órdenes por vendedor. Y una alerta por tienda contra su pedido ideal.
• Semanal: lo mismo consolidado, con el avance de cada vendedor contra su meta.
• Mensual: alertas más claras, tiendas que llevan semanas por debajo, productos que cayeron, vendedores que subieron o bajaron.

El pedido ideal es la proyección de cuánto debería pedir cada tienda según su historial y su tamaño. Si la tienda de zona 10 debería pedir 25 unidades de un producto y pidió 5, el reporte del día lo marca: "Zona 10: 20 % del pedido ideal". El gerente de ventas no tiene que descubrirlo: el lunes ya sabe a qué tienda mandar al vendedor.

Para esto no hizo falta un dashboard caro, sino datos limpios y a tiempo; eso fue lo primero que resolvió la automatización.

Qué cambió en la operación

La cuenta más simple es la de tiempo. La persona que capturaba tardaba unos 12 minutos por orden y procesaba alrededor de 10 al día: dos horas diarias solo en transcribir. Hoy cada orden entra en uno o dos minutos y esa persona ya no transcribe, revisa: abre los presupuestos del día, confirma y aprueba para facturar. Entre 75 % y 90 % menos tiempo en la misma tarea, según cuántas fotos vengan mal.

Los otros cambios no se miden en minutos, pero pesan igual:

• Cero errores llegando a facturación. El sistema no adivina y hay una revisión humana antes de facturar. Lo que antes se colaba en una cantidad o un precio mal tecleado, hoy se detiene antes.
• Los errores se arreglan en el momento. Antes, un dato mal leído aparecía cuando alguien iba a facturar, cuatro horas después; para entonces el vendedor ya iba en otra tienda y la corrección quedaba para el día siguiente. Ahora el aviso sale al minuto, mientras el vendedor sigue frente al supermercado con la hoja en la mano.
• Mejor control de pedidos mínimos. Cada tienda se compara todos los días contra lo que debería pedir. Antes, que una tienda pidiera la mitad de lo normal se notaba a fin de mes, si alguien lo buscaba.
• Todo queda respaldado. El 100 % de las órdenes tiene su imagen en Drive y su fila en Sheets, con el número de orden y el vendedor. Antes el respaldo dependía de quién hubiera guardado qué.
• Reportes sin pedirlos. Diario, semanal y mensual, con el desempeño de cada vendedor. Antes existían cuando alguien tenía tiempo de armarlos.

La empresa mueve más de Q250,000 al mes en pedidos de supermercados. Con ese volumen, lo que más pesa es que el presupuesto llega al cliente el mismo día y que el equipo sabe, cada mañana, en qué tienda está perdiendo venta.

Lo que aprendimos en campo

1. No todos los modelos siguen las instrucciones al pie de la letra. En pruebas, uno de los modelos escribía QQ1000 en lugar de Q1000. Parece una tontería, pero el monto dejaba de ser un número y pasaba a ser texto: las fórmulas se rompían y las sumatorias del reporte no cuadraban porque unas celdas sumaban y otras no. La lección fue validar tipos (número o texto) antes de guardar, probar mucho más de lo que parece razonable antes de salir a producción y tener una forma de auditar cada orden contra su imagen.

2. Duplicados. Un vendedor reenviaba la misma foto dos veces "por si acaso", o dos vendedores mandaban la misma orden. El resultado eran dos presupuestos iguales. Ahora el flujo revisa el número de orden y una huella de la imagen antes de crear nada; si ya existe, responde "esta orden ya está registrada".

3. Los nombres del supermercado no son los nombres de tu catálogo. Cada cadena describe los productos a su manera ("GASEOSA 2LT" no es el nombre del producto en Odoo). Hubo que construir un mapeo de productos por cadena para que el sistema resuelva la línea al producto correcto; sin eso, el presupuesto sale con productos genéricos y alguien lo tiene que corregir a mano.

¿Sirve para tu empresa?

Conviene si se cumplen tres cosas: recibes órdenes en papel, foto o PDF con cierta frecuencia (digamos, más de veinte a la semana); tienes un ERP con API (Odoo, SAP Business One, Dynamics, o uno a la medida) y tus vendedores ya viven en WhatsApp. Si tus clientes te mandan las órdenes por EDI o por un portal estructurado, el problema es otro y la solución también.

La misma arquitectura aplica a facturas de proveedores, comprobantes de pago o formularios en papel: cualquier flujo donde la entrada es una imagen y la salida es un registro con columnas fijas. Es el patrón que más vemos en empresas de consumo masivo en Guatemala.

Preguntas frecuentes

¿Funciona si mi ERP no es Odoo?

Sí. Lo único que cambia es el último paso. Hemos conectado el mismo flujo con SAP Business One y con sistemas a la medida; el requisito es que el ERP tenga una API o una forma segura de crear documentos. Nunca escribimos directo en la base de datos.

¿Qué pasa si la foto está borrosa o falta un dato?

El sistema no crea nada y le pide al vendedor que reenvíe la foto, indicando el campo que no se leyó. La orden se registra solo cuando está completa y los totales cuadran.

¿Mis vendedores tienen que cambiar cómo trabajan?

Casi nada: mandan la foto como siempre, pero a un número de empresa en lugar de a un grupo. A veces, en recomendamos Telegram en lugar de WhatsApp por temas de costos (sobre todo ahora que Meta va a cobrar por mensaje enviado) Lo que sí ayuda es una guía de dos líneas de cómo tomar la foto (luz, sin dedos, hoja completa); baja mucho el número de reenvíos.

¿Cuánto tarda implementarlo?

Entre cuatro y seis semanas en un caso como este: una o dos para conectar WhatsApp y n8n, dos para el modelo y las validaciones con órdenes reales, y el resto para la integración con el ERP, los reportes y las pruebas con los vendedores. Lo más complejo suele ser crear los mapas de productos, seguido de las pruebas para confirmar que todo funciona correctamente.

¿También automatiza la facturación?

En este caso, no todavía: el sistema crea el presupuesto y una persona emite la factura desde ahí. Es el siguiente paso natural, y depende de las reglas de crédito y de facturación electrónica de cada empresa. Primero le damos confianza a la empresa de que la primera sección funciona y que es confiable y luego podemos automatizar el resto.