IA para distribuidora e atacado: pedido, tabela e trava de desconto

IA para distribuidora e atacado funciona melhor quando assume uma tarefa estreita: receber pedidos recorrentes pelo WhatsApp, identificar o cliente, consultar a tabela e a condição comercial dele e montar o pedido para confirmação. Preço, desconto e exceção ficam em regras fixas e na aprovação do comercial, nunca na improvisação de um modelo de linguagem. O ganho vem da redução de digitação e de consulta manual, sem abrir mão da margem.

Principais pontos

• O melhor primeiro uso é o pedido recorrente: o cliente já sabe o que quer, e o agente organiza, confere e registra.
• A tabela de preços e a condição por cliente devem vir do sistema da empresa (ERP ou planilha controlada), nunca da memória do modelo.
• O desconto precisa de uma trava determinística: um teto por cliente ou perfil, acima do qual só o comercial libera.
• Todo pedido deve deixar um registro de decisão: o que o cliente pediu, o que foi consultado, o que foi proposto e quem aprovou.
• Comece por um fluxo real e pequeno, com métrica combinada, e só depois decida se expande, ajusta ou para.

Por que pedido recorrente e tabela são o melhor ponto de partida

Em distribuidoras e atacados, boa parte do volume de conversa no WhatsApp é repetição: o mesmo comprador pedindo os mesmos itens, com pequenas variações de quantidade. O vendedor ou o atendente de televendas gasta tempo lendo áudios, procurando o código do produto, abrindo a tabela do cliente e digitando o pedido no sistema. É um trabalho necessário, mas com pouco julgamento envolvido.

Esse perfil combina com automação parcial. O pedido tem estrutura (cliente, itens, quantidades, data de entrega, forma de pagamento), a tabela é um dado objetivo, e o erro é fácil de detectar quando há conferência. Já negociações novas, clientes em atraso e pedidos fora do padrão exigem pessoa.

Um detalhe de linguagem: isso não é superinteligência. É um agente de software com acesso limitado a dados e ações. Quem quiser entender a diferença entre os termos pode ler AGI, ASI e agentes de IA: o que sua empresa opera. Para o dono da distribuidora, o que importa é que o agente faz bem uma etapa do processo e respeita limites.

O que o agente faz e o que ele nunca decide

A divisão de responsabilidades precisa estar escrita antes de qualquer configuração. Uma forma prática é separar em três grupos.

O agente pode fazer sozinho:

• Identificar o cliente pelo número e pelo cadastro, pedindo confirmação quando houver dúvida.
• Ler texto e áudio do pedido e transformar em itens com código, unidade e quantidade.
• Consultar o histórico de compras para sugerir o pedido habitual, sempre como sugestão.
• Consultar a tabela e a condição de pagamento do cliente e apresentar o resumo.
• Informar prazo e disponibilidade conforme o que o sistema retornar.

O agente só faz com confirmação humana:

• Aplicar qualquer desconto acima do teto previamente definido.
• Aceitar condição de pagamento diferente da cadastrada.
• Fechar pedido de cliente bloqueado, com limite de crédito estourado ou cadastro incompleto.
• Substituir um item em falta por outro de preço ou marca diferente.

O agente nunca decide:

• Preço fora da tabela, por conta própria ou por insistência do cliente.
• Mudança de cadastro, limite de crédito ou prazo de pagamento.
• Promessa de entrega que o sistema logístico não confirmou.

Essa lista vira instrução do agente e também vira teste. Para escrever as instruções com clareza, vale consultar como montar o prompt de um agente de vendas no WhatsApp.

Como a consulta de tabela e condição por cliente deve funcionar

O erro mais comum é colocar a tabela de preços dentro do texto do prompt ou pedir que o modelo "lembre" dos preços. Tabelas mudam, variam por cliente, região, canal e volume, e o modelo pode misturar linhas. A arquitetura mais segura é consultar uma fonte oficial no momento do pedido.

Na prática, isso significa uma ferramenta de consulta com entrada e saída bem definidas. Entrada: identificador do cliente e código do produto. Saída: preço da tabela aplicável, unidade de venda, múltiplo mínimo, condição de pagamento cadastrada e teto de desconto permitido. O modelo recebe o resultado e apenas o apresenta e organiza. A documentação da Anthropic sobre como escrever ferramentas eficazes para agentes trata exatamente desse desenho: ferramentas com propósito claro e respostas que o agente consiga usar sem ambiguidade.

Alguns cuidados que fazem diferença:

• A ferramenta de consulta deve ser somente leitura. Quem grava o pedido é outra ferramenta, com regras próprias.
• A consulta deve usar o cliente identificado na conversa, e não um nome citado no texto. Se alguém escreve "preço do cliente tal", o agente não pode revelar a tabela de outro comprador.
• Quando o sistema não retornar preço, o agente avisa que vai confirmar com o comercial, em vez de estimar.
• A data e a versão da tabela consultada entram no registro do pedido.

Para quem usa ERP, planilha ou um sistema de pedidos próprio, o ponto é o mesmo: existe uma fonte única de verdade, e o agente lê dela. Se hoje cada vendedor tem sua própria planilha, esse é o primeiro problema a resolver, antes de qualquer IA.

Como funciona a trava de desconto e a aprovação do comercial

Desconto é onde a margem se perde, e é onde a IA não deve ter liberdade. A trava precisa ser código e regra de negócio, não uma frase no prompt pedindo que o modelo "tenha cuidado". Um prompt pode ser contornado por uma conversa insistente, e a lista das principais vulnerabilidades em aplicações com modelos de linguagem, mantida pela OWASP, inclui justamente esse tipo de manipulação e o excesso de autonomia do agente.

Um desenho simples e robusto:

• Cada cliente ou perfil tem um teto de desconto definido pelo comercial, guardado no sistema.
• Se o cliente pedir desconto, o agente não negocia. Ele registra o pedido de desconto e verifica o teto.
• Dentro do teto já previsto na condição do cliente, o agente apenas aplica o que a tabela diz.
• Acima do teto, o pedido fica em estado pendente e o comercial recebe um resumo: cliente, itens, valor da tabela, desconto solicitado, histórico recente e motivo informado.
• O comercial aprova, recusa ou faz contraproposta. Só então o agente comunica o resultado ao cliente.
• A aprovação fica registrada com quem aprovou e quando.

O princípio é o de autorização por quem tem permissão, validada fora do modelo. O guia de autorização da OWASP descreve a lógica de negar por padrão e verificar permissão a cada ação, e ela se aplica diretamente: o agente só recebe a permissão de registrar pedido dentro do teto, e a ferramenta de gravação recusa o resto.

Uma observação sobre o texto ao cliente: o agente deve dizer algo neutro, como "vou confirmar essa condição com o comercial e retorno em seguida". Evite respostas que sugiram que o desconto é provável. Quem vai conversar com o cliente sobre a expectativa de preço é o vendedor.

Cenário ilustrativo: reposição semanal de um cliente

Cenário ilustrativo, sem relação com nenhuma empresa real. Um distribuidor de bebidas e itens de mercearia atende um mercado de bairro que repõe estoque toda semana. Na segunda, o comprador manda um áudio pelo WhatsApp pedindo o "de sempre" e mais algumas caixas de um item novo.

O agente identifica o número no cadastro, confirma o nome da loja e transcreve o áudio. Ele consulta o histórico e propõe o pedido habitual, pedindo confirmação das quantidades. Para o item novo, consulta a tabela do cliente e informa a unidade de venda e o preço cadastrado.

O comprador pergunta se há desconto pelo volume. O agente verifica o teto do cliente: o volume pedido ultrapassa o que está previsto. Ele responde que vai consultar o comercial, marca o pedido como pendente e envia ao vendedor responsável um resumo com os itens, o valor de tabela e o pedido de desconto.

O vendedor aprova um desconto menor que o solicitado. O agente comunica a condição aprovada, o cliente confirma, e o pedido é gravado no sistema com o registro de quem aprovou. Se o vendedor não responder dentro do prazo combinado, o agente avisa o cliente de que o retorno virá por uma pessoa da equipe, e o pedido não é fechado com desconto.

Plano em passos para um piloto controlado

O método de trabalho que recomendamos segue quatro movimentos: mapear, limitar, pilotar e transferir. Aplicado a este caso, fica assim.

Mapear: levantar como o pedido chega hoje (áudio, texto, foto de lista, ligação), quem digita, onde a tabela mora, quem aprova desconto e quanto tempo o processo leva. Esse baseline é o que permitirá dizer, depois, se o piloto ajudou.

Limitar: definir quais clientes entram, quais produtos, quais ações o agente pode executar e qual é o teto de desconto. Também decidir quais dados o agente enxerga. Ele não precisa ver o cadastro financeiro inteiro, só o que serve ao pedido.

Pilotar: rodar um fluxo real, com um grupo pequeno de clientes recorrentes, com logs e uma métrica combinada de antemão (por exemplo, tempo entre mensagem e pedido registrado, ou quantidade de correções manuais). Antes de colocar clientes, testar com dados simulados, como descrito em como testar agentes de IA com mocks e sandbox.

Transferir: entregar documentação, regras, painel de registros e responsáveis internos. Depois, decidir com base nos dados se expande, ajusta ou encerra.

Um roteiro prático para o piloto:

• Escolher um canal de entrada e um grupo de clientes com pedidos repetitivos e cadastro limpo.
• Higienizar a tabela e os cadastros: códigos duplicados, unidades ambíguas e clientes sem condição definida.
• Definir o teto de desconto por perfil e quem aprova acima dele, com substituto para ausências.
• Montar a ferramenta de consulta somente leitura e a de gravação com validações próprias.
• Escrever as instruções do agente, incluindo o que ele deve responder quando não souber.
• Montar casos de teste: cliente desconhecido, pedido de desconto alto, produto inexistente, tentativa de ver preço de terceiros, áudio confuso.
• Rodar em modo assistido, em que o atendente revisa cada pedido antes do registro.
• Revisar os registros com o comercial e ajustar regras antes de reduzir a revisão.

Sobre o canal: se o agente também precisar iniciar conversas, por exemplo para lembrar de reposição, há regras da plataforma sobre janela de atendimento e modelos de mensagem. O texto sobre a janela de atendimento no WhatsApp API explica como o agente deve se comportar nesse ponto.

Quais riscos de dados e segurança precisam de atenção?

Tabela de preços e condição comercial são informações sensíveis para o negócio, embora nem sempre sejam dados pessoais. Já o cadastro de compradores traz nome, telefone e, em muitos casos, dados de pessoa física, o que atrai a LGPD. A Autoridade Nacional de Proteção de Dados reúne orientações oficiais em gov.br/anpd. Defina a finalidade do tratamento, limite o que o agente acessa e registre quem pode ver os logs.

Outros cuidados concretos:

• Separar permissões por cliente, para que uma conversa nunca acesse a tabela de outro comprador.
• Tratar mensagens recebidas como entrada não confiável: um cliente pode escrever instruções tentando mudar o comportamento do agente. A validação de preço e desconto deve ocorrer fora do modelo.
• Guardar o registro de cada decisão, para auditoria e para resolver divergências com o cliente.
• Definir o que acontece quando o sistema está fora do ar: o agente avisa e encaminha, sem inventar resposta.
• Revisar se algum dado sai do país ao usar serviços de modelo hospedados fora do Brasil, tema tratado em transferência internacional de dados com IA.

Se a regra de preço depende do modelo se comportar bem, ela não é uma regra, é uma esperança.

Perguntas frequentes

IA para distribuidora e atacado serve para empresas pequenas? Serve quando existe volume repetitivo de pedidos e uma tabela organizada, independentemente do tamanho. Uma operação pequena com cadastro bagunçado tende a ganhar mais arrumando tabela e processo antes de automatizar. O tamanho importa menos que a clareza das regras.

O agente pode negociar desconto com o cliente? Não é recomendável. Ele pode registrar o pedido de desconto, verificar o teto e encaminhar ao comercial com um resumo. A negociação e a decisão ficam com a pessoa, porque envolvem margem, relacionamento e contexto que o sistema não vê por inteiro.

Como evitar que o agente informe um preço errado? Fazendo o preço vir de uma consulta ao sistema no momento do pedido, e não do texto do modelo. Quando a consulta falha ou não retorna valor, o agente avisa que vai confirmar. Testes com casos de erro e a revisão dos registros no piloto ajudam a encontrar falhas antes de ampliar.

Preciso trocar meu ERP para usar IA nos pedidos? Em geral, não. O necessário é que a tabela, o cadastro e a gravação de pedidos possam ser acessados de forma controlada, por API, integração ou uma camada intermediária. Se o sistema atual não permite isso, o piloto pode começar com o agente gerando o pedido para conferência humana, sem gravar direto.

Fontes

• OWASP: Top 10 para aplicações com LLM
• OWASP: Authorization Cheat Sheet
• Anthropic: Writing effective tools for agents
• ANPD: Autoridade Nacional de Proteção de Dados