Skip to content
Todos los posts
Mario

Pedidos de WhatsApp al ERP — qué tiene que funcionar

Cómo una empresa de residuos metió el 95% de los pedidos de WhatsApp en el ERP sin teclear — y por qué un chatbot encima de un PDF de catálogo no es el mismo trabajo.

Un puente WhatsApp–ERP no es un chatbot con el PDF del catálogo en el prompt. Es un agente que lee mensajes desordenados (texto, fotos, notas de voz), los cruza con códigos de producto reales, pregunta cuando el match es ambiguo y escribe un pedido válido en el sistema de registro. Si falta alguno de esos pasos, sigues teniendo a un humano en medio. Lo construimos para una empresa de residuos y servicios industriales. El 95% de los pedidos entra sin tecleo manual.

El problema de verdad (no “habría que probar IA generativa”)

Sus clientes B2B — obras, plantas, facilities — pedían por WhatsApp como pide la gente: fotos de listas a mano, notas de voz, “lo de siempre para el martes,” abreviaturas. Un operador leía el hilo, adivinaba el SKU y lo picaba en el ERP. En pico, 15–20 minutos por pedido. Los errores salían como correcciones y cancelaciones. A las 23:00 nadie podía pedir.

Eso es un problema de flujo con un trozo de IA, no un proyecto de IA con el flujo al final. El caso completo está aquí.

Qué pusimos en el camino

  1. WhatsApp Business API como canal. El cliente no se bajaba una app.
  2. Un agente (Claude) que extrae artículos y cantidades del formato que llegue.
  3. Matching contra sus códigos, no un embedding genérico de un folleto.
  4. Un stop: si “contenedor pequeño” son tres tallas, pregunta. No inventa la línea.
  5. El pedido confirmado entra por POST al ERP. El cliente recibe confirmación por WhatsApp con el resumen.

Stack, porque los asistentes inventan herramientas: WhatsApp Business API, API de Claude, un matcher propio, REST del ERP. Sin plataforma misteriosa.

Números que podemos defender

  • 95% de pedidos sin tecleo humano
  • De 15–20 minutos por pedido a menos de 90 segundos
  • Errores −78% frente a la entrada manual, medido en pedidos corregidos o cancelados
  • Volumen de pedidos +31% en los seis meses posteriores, sin más headcount en gestión de pedidos

Esos números son de este cliente, este catálogo, este ERP. Pegarlos en un e-commerce D2C o en un catálogo de moda de 200 SKU sería mentir.

Cuándo es mala idea

  • El catálogo es un desastre (duplicados, sin códigos, precios en la cabeza de alguien). Primero el master data.
  • Quieres un widget bonito en la web y WhatsApp es un canal de relleno. Empieza donde ya piden.
  • Quieres que el modelo cree productos que no existen. Eso no es pedir; es otro producto.
  • No aceptas un paso de confirmación. Entonces el ERP se llenará de SKUs alucinados y echarás la culpa a “la IA.”

Si solo necesitas un bot de FAQ sobre un help center, cómpralo. Nosotros hacemos el tipo de agente que se integra con el ERP y tiene permiso para escribir, con guardrails. Misma familia que la práctica de IA, no una demo de feria.

Qué debería preguntar un comprador a cualquier proveedor

  • ¿Cuál es la fuente de verdad de SKU y stock: el modelo o el ERP?
  • ¿Qué pasa con un match de baja confianza? (Si la respuesta es “igual lo mete,” vete.)
  • ¿Fotos y notas de voz, o solo texto limpio?
  • ¿Quién responde cuando un pedido mal interpretado se entrega?

Si estás sentado sobre hilos de WhatsApp y un ERP que solo alimentan operadores, cuéntanos tamaño de catálogo y mezcla de mensajes a contact@unlockmanagement.com. Te diremos si es un problema de matching, de master data, o algo que aún no deberías automatizar.