Una distribuidora B2B gana con IA en tres puntos: pedido estructurado en la entrada, previsión de demanda por cliente y producto, y ruteo de entregas. El orden importa. Sin pedidos registrados como datos, no hay historial para prever ni dirección confiable para rutear. Por eso el primer proyecto suele ser el más simple: sacar el pedido de la planilla.
La distribución es un negocio de margen ajustado y de operación diaria. El dueño conoce a cada cliente, el comprador sabe de memoria qué pide cada restaurante los martes, y el chofer ya tiene la ruta en la cabeza. Ese conocimiento funciona hasta el día en que la empresa crece, alguien sale de vacaciones o un cliente grande cambia su patrón. IA para una distribuidora es, en la práctica, convertir ese conocimiento en datos que la operación pueda usar sin depender de una persona.
¿El pedido por WhatsApp es un problema?
No. El problema es el pedido que llega por WhatsApp y no se convierte en dato.
El caso de RDR Distribuidora muestra por qué el canal no debe cambiarse. RDR entrega frutas, legumbres y verduras a restaurantes, mercados, cocinas industriales y consumidores en São Paulo y su región metropolitana, y recibe la mayoría de los pedidos por WhatsApp. Cuando construimos el sitio, la decisión fue no crear un canal paralelo con carrito y registro que el cliente de restaurante no usaría. El sitio responde dónde entrega RDR, qué vende y cómo pedir, y después lleva al visitante a la conversación. El formulario de contacto ya pregunta el tipo de cliente, y RDR se compromete a responder en hasta 2 horas en horario comercial.
El canal quedó donde está el cliente. Lo que falta, en casi toda distribuidora que opera así, es la etapa siguiente: alguien lee el mensaje, digita el pedido en el sistema o en la planilla y verifica stock y precio. Es trabajo repetitivo, sujeto a errores de tipeo e invisible para cualquier análisis.
Un agente de IA en ese punto lee el mensaje del cliente, identifica los ítems, las cantidades, la unidad (caja, kilo, atado), la dirección de entrega y la ventana pedida, y devuelve el pedido estructurado para que la persona confirme. No sustituye la atención. Saca el tipeo del camino y crea el registro que los otros dos proyectos necesitan.
¿Cómo prever la demanda de productos perecederos?
Las frutas y verduras son el caso más difícil de previsión de demanda, y por eso son una buena prueba. El producto dura días, el precio cambia con la cosecha y el cliente de restaurante pide según el movimiento de la semana. Errar hacia arriba se convierte en pérdida; errar hacia abajo, en un cliente sin producto.
Lo que cambia respecto a la previsión de retail común:
- El horizonte es corto. Prever la semana que viene vale más que prever el trimestre. El modelo corre con frecuencia y se corrige rápido.
- La unidad es el cliente, no solo el producto. En B2B, pocos clientes concentran la mayor parte del volumen. Prever el pedido de cada restaurante grande, por día de la semana, es más útil que prever el total de tomate.
- El patrón semanal domina. El restaurante pide para el fin de semana, la cocina industrial pide para la producción del lunes. RDR ya arma kits semanales para restaurantes y residencias, lo que es una forma de estandarizar esa demanda antes de cualquier modelo.
La primera versión del modelo puede ser modesta: para los clientes que más compran, la cantidad esperada por ítem en la próxima semana, con un rango de error. El comprador la compara con lo que compraría por su cuenta. Si el modelo se equivoca menos, pasa a orientar la compra. Si se equivoca más, el dato está incompleto, y eso también es una respuesta útil.
¿Vale la pena el ruteo para una flota pequeña?
Vale cuando el área de entrega es conocida y las ventanas de los clientes son rígidas. RDR cubre las cinco zonas de la ciudad de São Paulo y ciudades como Guarulhos, Osasco, Barueri, Santo André, São Bernardo y Diadema. El restaurante recibe antes del almuerzo; el mercado recibe temprano. Con esa combinación, el orden de las paradas cambia el costo del día.
El ruteo no necesita empezar con un sistema de optimización completo. La primera versión agrupa los pedidos del día por zona, ordena las paradas dentro de cada zona respetando las ventanas y los distribuye entre los vehículos. Eso ya reduce kilómetros recorridos y atrasos. El modelo más sofisticado, que considera tiempo de descarga, tráfico y capacidad por vehículo, entra cuando lo básico ya funciona y la dirección de cada cliente está limpia en el registro. Aquí vuelve la dependencia del primer proyecto: sin pedido estructurado, la dirección llega mal y la ruta también.
| Proceso | Cómo se hace en la planilla | Con datos e IA | Métrica para seguir |
|---|---|---|---|
| Entrada del pedido (RDR: WhatsApp, formulario o Instagram, 4 pasos hasta la entrega) | Alguien lee el mensaje y digita ítem, cantidad y dirección | El agente estructura el pedido y la persona solo confirma | Tiempo de respuesta (RDR: hasta 2 horas en horario comercial) y errores por pedido |
| Compra y previsión de demanda | El comprador estima de memoria, por experiencia | Previsión semanal por cliente y por ítem, con rango de error | Error del modelo contra la estimación manual; pérdida de perecederos |
| Ruteo de las entregas (RDR: 5 zonas de la capital y 6 ciudades del área metropolitana) | El chofer define la secuencia de memoria | Agrupación por zona y orden de paradas respetando ventanas | Kilómetros por entrega y entregas fuera de la ventana |
| Análisis del negocio | Informe armado a mano a fin de mes | Base de datos única con pedido, entrega y cliente | Tiempo para responder "cuánto vendimos al cliente X" |
| Validación de cada proyecto | No existe; se cambia el proceso y se ve qué pasa | PoC de 3 a 6 semanas con plazo cerrado y criterio de éxito | Decisión de seguir o parar al final del plazo |
Dónde viven esos datos
Los tres proyectos dependen de una base única: pedido, cliente, entrega y compra en el mismo lugar, con historial. Para una distribuidora, eso rara vez exige la arquitectura de datos de una empresa grande. Una base de datos relacional bien modelada, alimentada por el agente de pedidos y por el sistema de facturación, resuelve la mayoría de los casos. La elección entre un data warehouse y un data lake, y cuándo tiene sentido cada uno, está en el post sobre data lake o data warehouse en 2026.
El mayor riesgo no es técnico. Es que el modelo de previsión quede bonito en la presentación y nunca entre en la rutina del comprador. Eso pasa cuando el modelo se construye lejos de quien compra, sin comparación con la estimación manual y sin una forma simple de consultar el resultado todos los días. Tratamos las causas en por qué los modelos de machine learning no llegan a producción. En distribución, la regla práctica es: si el comprador no abre el resultado del modelo antes de cerrar el pedido con el proveedor, el modelo no existe.
El servicio de datos e IA de Cortex IQ empieza por ese diseño: qué dato ya produce la operación, cuál falta y qué proyecto viene primero para que los otros dos tengan base.
Siguiente paso
Si tu distribuidora recibe pedidos por mensaje y compra por experiencia, el primer proyecto es hacer que el pedido se convierta en dato; previsión y ruta vienen después. La página de distribución y logística muestra lo que ya hicimos en el sector, y la de datos e IA explica cómo estructuramos la base para los tres proyectos.