Uma distribuidora B2B ganha com IA em três pontos: pedido estruturado na entrada, previsão de demanda por cliente e por produto, e roteirização das entregas. A ordem importa. Sem pedido registrado como dado, não há histórico para prever nem endereço confiável para rotear. Por isso o primeiro projeto costuma ser o mais simples: tirar o pedido da planilha.
Distribuidora é um negócio de margem apertada e de operação diária. O dono conhece cada cliente, o comprador sabe de cabeça o que cada restaurante pede na terça, e o motorista já tem a rota na memória. Esse conhecimento funciona até o dia em que a empresa cresce, alguém sai de férias ou um cliente grande muda o padrão. IA para distribuidora é, na prática, transformar esse conhecimento em dado que a operação consegue usar sem depender de uma pessoa.
O pedido pelo WhatsApp é um problema?
Não. O problema é o pedido que chega pelo WhatsApp e não vira dado.
O case da RDR Distribuidora mostra por que o canal não deve ser trocado. A RDR entrega frutas, legumes e verduras para restaurantes, mercados, cozinhas industriais e consumidores em São Paulo e na Grande São Paulo, e recebe a maior parte dos pedidos pelo WhatsApp. Quando construímos o site, a decisão foi não criar um canal paralelo com carrinho e cadastro que o cliente de restaurante não usaria. O site responde onde a RDR entrega, o que vende e como pedir, e depois manda o visitante para a conversa. O formulário de contato já pergunta o tipo de cliente, e a RDR se compromete a responder em até 2 horas no horário comercial.
O canal ficou onde o cliente está. O que falta, em quase toda distribuidora que opera assim, é a etapa seguinte: alguém lê a mensagem, digita o pedido no sistema ou na planilha e confere estoque e preço. É trabalho repetitivo, sujeito a erro de digitação e invisível para qualquer análise.
Um agente de IA nesse ponto lê a mensagem do cliente, identifica os itens, as quantidades, a unidade (caixa, quilo, maço), o endereço de entrega e a janela pedida, e devolve o pedido estruturado para a pessoa confirmar. Ele não substitui o atendimento. Ele tira a digitação do caminho e cria o registro que os outros dois projetos precisam.
Como prever demanda em produto perecível?
Hortifruti é o caso mais difícil de previsão de demanda, e por isso é um bom teste. O produto dura dias, o preço muda com a safra e o cliente de restaurante pede conforme o movimento da semana. Errar para cima vira perda; errar para baixo vira cliente sem produto.
O que muda em relação à previsão de varejo comum:
- O horizonte é curto. Prever a semana que vem vale mais do que prever o trimestre. O modelo roda com frequência e se corrige rápido.
- A unidade é o cliente, não só o produto. Em B2B, poucos clientes concentram a maior parte do volume. Prever o pedido de cada restaurante grande, por dia da semana, é mais útil do que prever o total de tomate.
- O padrão semanal domina. Restaurante pede para o fim de semana, cozinha industrial pede para a produção da segunda. A RDR já monta kits semanais para restaurantes e residências, o que é uma forma de padronizar essa demanda antes de qualquer modelo.
A primeira versão do modelo pode ser modesta: para os clientes que mais compram, a quantidade esperada por item na próxima semana, com uma faixa de erro. O comprador compara com o que compraria por conta própria. Se o modelo erra menos, ele passa a orientar a compra. Se erra mais, o dado está incompleto, e isso também é uma resposta útil.
Roteirização vale a pena para uma frota pequena?
Vale quando a área de entrega é conhecida e as janelas dos clientes são rígidas. A RDR cobre as cinco zonas da capital paulista e cidades como Guarulhos, Osasco, Barueri, Santo André, São Bernardo e Diadema. Restaurante recebe antes do almoço; mercado recebe cedo. Com essa combinação, a ordem das paradas muda o custo do dia.
Roteirização não precisa começar com um sistema de otimização completo. A primeira versão agrupa os pedidos do dia por zona, ordena as paradas dentro de cada zona respeitando as janelas e distribui entre os veículos. Isso já reduz quilômetro rodado e atraso. O modelo mais sofisticado, que considera tempo de descarga, trânsito e capacidade por veículo, entra quando o básico já roda e o endereço de cada cliente está limpo no cadastro. Aqui volta a dependência do primeiro projeto: sem pedido estruturado, o endereço vem errado e a rota também.
| Processo | Como é feito na planilha | Com dados e IA | Métrica para acompanhar |
|---|---|---|---|
| Entrada do pedido (RDR: WhatsApp, formulário ou Instagram, 4 passos até a entrega) | Alguém lê a mensagem e digita item, quantidade e endereço | Agente estrutura o pedido e a pessoa só confirma | Tempo de resposta (RDR: até 2 horas no horário comercial) e erros por pedido |
| Compra e previsão de demanda | Comprador estima de cabeça, por experiência | Previsão semanal por cliente e por item, com faixa de erro | Erro do modelo contra a estimativa manual; perda de perecível |
| Roteirização das entregas (RDR: 5 zonas da capital e 6 cidades da Grande SP) | Motorista define a sequência na memória | Agrupamento por zona e ordem das paradas respeitando janelas | Quilômetro por entrega e entregas fora da janela |
| Análise do negócio | Relatório montado à mão no fim do mês | Base de dados única com pedido, entrega e cliente | Tempo para responder "quanto vendemos para o cliente X" |
| Validação de cada projeto | Não existe; muda-se o processo e vê o que acontece | PoC de 3 a 6 semanas com prazo fechado e critério de sucesso | Decisão de seguir ou parar ao fim do prazo |
Onde esses dados moram
Os três projetos dependem de uma base única: pedido, cliente, entrega e compra no mesmo lugar, com histórico. Para uma distribuidora, isso raramente exige a arquitetura de dados de uma empresa grande. Um banco relacional bem modelado, alimentado pelo agente de pedidos e pelo sistema de faturamento, resolve a maior parte dos casos. A escolha entre um data warehouse e um data lake, e quando cada um faz sentido, está no post sobre data lake ou data warehouse em 2026.
O maior risco não é técnico. É o modelo de previsão ficar bonito na apresentação e nunca entrar na rotina do comprador. Isso acontece quando o modelo é construído longe de quem compra, sem comparação com a estimativa manual e sem um jeito simples de consultar o resultado todo dia. Tratamos as causas em por que modelos de machine learning não chegam à produção. Em distribuidora, a regra prática é: se o comprador não abre o resultado do modelo antes de fechar o pedido com o fornecedor, o modelo não existe.
O serviço de dados e IA da Cortex IQ começa por esse desenho: qual dado a operação já produz, qual falta e qual projeto vem primeiro para que os outros dois tenham base.
Próximo passo
Se a sua distribuidora recebe pedidos por mensagem e compra por experiência, o primeiro projeto é fazer o pedido virar dado; previsão e rota vêm em seguida. A página de distribuição e logística mostra o que já fizemos no setor, e a de dados e IA explica como estruturamos a base para os três projetos.