Segunda de manhã, chega uma mensagem no WhatsApp de um cliente de revenda: "Manda-me 5 do detergente de 1 litro para sexta." Quem está no balcão há dez anos sabe o que isto quer dizer, porque conhece o cliente, sabe que ele nunca compra avulso e que "5" são cinco caixas. O bot de €25 por mês não sabe nada disto. Lê "5", encontra um artigo com o nome parecido, multiplica pelo preço que estiver à mão e responde com toda a confiança do mundo.
O problema não é o bot ser mal-educado ou lento. É que ele responde a uma pergunta que não tem resposta sem a ficha do artigo. E a ficha do artigo está no teu ERP, onde ele não entra.
"5" não é um número, é uma pergunta
Num ERP de distribuição, um artigo raramente tem uma só unidade. Tem, no mínimo:
- unidade base — aquela em que o stock é contado (o frasco, o comprimido, a peça);
- unidade de venda — aquela em que o artigo se vende a um tipo de cliente (caixa, pack, palete);
- fator de conversão — quantas unidades base há em cada unidade de venda (1 caixa = 12 frascos);
- quantidade mínima e múltiplo de encomenda — "não vendemos menos de 1 caixa a revenda", "só em múltiplos de 6";
- preço por unidade e por tabela — a caixa não custa 12 vezes o frasco, tem desconto, e o desconto depende da tabela do cliente.
Tudo isto vive em campos concretos da ficha do artigo e da ficha do cliente. Nada disto vive na mensagem "quero 5". Um modelo de linguagem sem acesso a esses campos faz a única coisa que sabe fazer: escolhe a leitura mais provável do texto. E a leitura mais provável de "5 do detergente" é, estatisticamente, cinco frascos. Não é má intenção, é probabilidade. O teu negócio é que não funciona à base de probabilidade.
O exemplo com números
Pega num artigo real de um distribuidor de limpeza:
- Detergente 1 L. Unidade base: frasco. Unidade de venda para revenda: caixa de 12. Palete: 60 caixas.
- Tabela de revenda: €2,10 o frasco avulso, €23,40 a caixa (sai a €1,95 o frasco).
- Mínimo para revenda: 1 caixa.
O cliente queria 5 caixas: 60 frascos, €117,00 mais IVA.
Cenário A — o bot lê cinco frascos. Responde "5 unidades, €10,50, entrega sexta". O cliente, que já escreveu "5" dezenas de vezes, confirma sem ler. Na sexta chegam cinco frascos. Faltam 55. Há uma segunda viagem, uma loja que fica sem produto no fim de semana e uma conversa desconfortável sobre o preço que o bot prometeu por escrito. A diferença entre o que foi cotado e o que era devido é de onze vezes.
Cenário B — alguém "corrige" o bot para assumir sempre caixas. Agora é um café que pede 5 frascos e recebe 60. Devolução de 55, transporte de volta, nota de crédito, e um cliente pequeno que aprende a não voltar a usar o WhatsApp.
Nos dois casos, o erro não é da conversa. É de conversão. E aparece exatamente agora: as encomendas grossistas para o quarto trimestre e para o Natal começam em outubro, quando os volumes sobem e cada caixa trocada custa margem que já é curta.
O que faz o agente ligado ao ERP
O agente não "percebe melhor" a mensagem. Tem ferramentas que o bot não tem, e usa-as antes de responder:
- Identifica o cliente pelo número de telefone associado à ficha — e, com isso, a tabela de preços e o tipo de cliente (revenda ou consumidor).
- Lê a ficha do artigo no ERP, em modo de leitura: unidade base, unidades de venda, fatores, mínimo, múltiplo.
- Faz a conversão em código, não no modelo. O fator vem da base de dados e a multiplicação é feita por uma função determinística. O modelo de linguagem nunca faz contas de dinheiro de cabeça.
- Olha para o histórico do cliente: as últimas 20 encomendas deste artigo foram todas em caixa? Isso é uma pista, não uma decisão.
- Confirma numa frase, com tudo explícito: "5 caixas de 12 = 60 frascos, €117,00 + IVA, entrega sexta 2/10. Confirmas?"
Só depois do "sim" é que a encomenda é criada, e fica registado quem pediu, a mensagem original, a versão da ficha lida, o fator aplicado e a confirmação. Se amanhã houver dúvida, abres o registo e vês exatamente o que foi decidido e com base em quê. É este o sentido de "grounded": a resposta sai dos teus dados, não da imaginação do modelo, e fica auditada.
Onde isto dói fora do armazém
A mesma confusão aparece noutros sítios, com consequências diferentes.
Saúde e lares. "Faltam 5 de paracetamol" pode querer dizer cinco caixas de 20 comprimidos ou cinco comprimidos para fechar a semana de um utente. A farmácia fornece em caixas; a administração faz-se em comprimidos, por dose. No Doseo, o nosso ERP para lares, a conversão entre embalagem e dose unitária vem do registo do medicamento e é essa que alimenta o circuito fechado da medicação com código de barras. Aqui um erro de unidade não custa margem, custa uma rutura de medicação.
Calibração. Um laboratório recebe "calibrar 5 pesos". São cinco massas avulsas ou cinco conjuntos de massas padrão, cada um com várias peças e um certificado por conjunto? O preço, o tempo de bancada e o número de certificados mudam completamente. No PrüfMittel, cada equipamento e cada conjunto têm a sua ficha; o agente não orça sem a ler.
Faturação eletrónica. Cada linha de um documento no SAF-T PT leva a sua unidade de medida. Com a faturação eletrónica estruturada a caminho (CIUS-PT), a fatura deixa de ser lida por uma pessoa e passa a ser cruzada automaticamente pelo sistema do teu cliente com a encomenda dele. Se ele encomendou 5 caixas e a tua fatura diz 60 unidades sem conversão coerente, a reconciliação falha do lado de lá. A unidade errada deixa de ser um detalhe e passa a ser um documento rejeitado.
"Basta pôr no prompt para perguntar sempre"
É a objeção mais comum, e merece resposta a sério. Sim, podes configurar o bot barato para perguntar "caixas ou unidades?" em todas as encomendas. Três problemas:
- Ele pergunta, mas não sabe a resposta seguinte. O cliente diz "caixas" e o bot continua sem saber quantas unidades tem a caixa, qual é o mínimo nem quanto custa a caixa na tabela daquele cliente. Trocaste um palpite por outro.
- Irrita quem já sabe o que quer. A DECO avaliou em março o atendimento digital de 24 empresas e deu notas entre "Mau" e "Razoável", com queixas precisamente de menus sucessivos e perguntas que não levam a lado nenhum. Um grossista que encomenda o mesmo há anos não quer um questionário.
- Não aprende com os teus dados. O agente só pergunta quando a ficha é ambígua ou quando o pedido foge ao histórico. No resto dos casos, afirma a conversão e pede uma confirmação.
Não é por acaso que o mercado já cobra isto à parte. No Brasil, onde os preços de bots são públicos, um bot por fluxos custa R$49–99 por mês, mas ligá-lo ao ERP é orçado como projeto de R$2.000 a R$15.000. A conversa é barata. A integração é o produto.
"E se a ficha estiver errada?"
Vai estar, nalguns artigos. Fatores deixados a 1 por defeito, unidades escritas como "CX", "Cx." e "CAIXA" no mesmo catálogo, artigos com caixa de 12 que passou a 10 há dois anos e ninguém atualizou. O agente herda esses erros, é verdade. A diferença é que os torna visíveis: cada resposta regista o fator usado, e um fator suspeito aparece no primeiro pedido em vez de ficar escondido na cabeça de quem está ao balcão. Corriges uma vez no ERP e fica corrigido para o agente, para a faturação e para o armazém.
Por isso, antes de pôr qualquer agente a falar com clientes, fazemos um diagnóstico em modo de leitura: quantos artigos ativos têm mais de uma unidade, quantos têm fator igual a 1 onde não devia, quantos têm unidade de venda diferente entre tabelas. Normalmente é uma tarde de consultas e uma lista curta de correções.
Próximo passo
Faz este exercício no teu ERP, hoje: pega nos 20 artigos que mais vendes por WhatsApp ou telefone e verifica, para cada um, unidade base, unidade de venda, fator e mínimo. Se encontrares mais de dois com dúvidas, o teu bot já está a adivinhar.
Se quiseres, fazemos esse diagnóstico contigo, sobre o teu PHC ou outro ERP, sem mexer em nada: leitura apenas, com registo de cada consulta. Escreve para hello@leiritech.com ou liga para o +351 914 572 595. Falas diretamente com quem escreve o código.
