Chega uma mensagem ao WhatsApp da empresa às 22h47: "Boa noite, quero 4 caixas do artigo 7781, entrega para a morada nova." O bot responde em três segundos, simpático, e regista o pedido. Na manhã seguinte alguém do armazém abre a encomenda e percebe o problema: aquele artigo só se vende em paletes de 12, o cliente está com a conta-corrente bloqueada há duas semanas por faturas vencidas, e o preço que o bot confirmou é o de tabela — não o escalão negociado que este cliente tem há três anos. Três erros numa mensagem. E o bot fez exatamente aquilo para que foi feito: aceitou.
Este é o ponto que separa um bot de €25/mês de um agente ligado ao teu ERP. Não é a qualidade da conversa. É se o sistema conhece — e faz cumprir — as tuas regras comerciais.
O bot não tem onde ler a regra
Um bot comoditizado funciona sobre um guião: um conjunto de respostas escritas à mão, mais um modelo de linguagem a preencher os espaços. Ele não tem acesso ao teu catálogo, à tua tabela de preços por cliente, ao estado de crédito de cada conta. Não porque seja mau — porque não está ligado a lado nenhum. Vive fora dos teus dados.
Por isso, quando lhe pedem "4 caixas", ele não tem como saber que a quantidade mínima de venda são 12. Quando confirma um preço, tira-o do guião — que alguém atualizou pela última vez em março. Quando o cliente diz o nome, o bot não o cruza com a conta-corrente, porque não sabe o que é uma conta-corrente. Ele completa a frase mais provável e segue em frente. Parece competente. É o problema.
As tuas regras comerciais não são texto num FAQ. São dados vivos que mudam todos os dias: um cliente que entrou em incumprimento ontem, um escalão de desconto renegociado esta semana, um artigo que passou a ter quantidade mínima por causa de uma alteração de fornecedor. Um guião estático nunca vai conhecer o estado de hoje. E é impossível manter um guião a par de um ERP que a tua equipa altera dezenas de vezes por dia.
O que o agente faz de diferente
Um agente ligado ao teu ERP não responde a partir de um guião. Antes de confirmar seja o que for, vai ler — em tempo real, read-only — o registo real do artigo, do cliente e do preço. E aplica a regra que lá está.
Pega no mesmo pedido das 22h47. O agente faz três leituras antes de dizer uma palavra:
- Quantidade mínima. Consulta o artigo 7781, lê que a venda mínima é 12 unidades. Responde: "Este artigo vende-se em múltiplos de 12. Queres 12 ou ajusto para outra quantidade?" Não regista 4.
- Escalão de preço. Identifica o cliente pelo contacto, lê o escalão negociado dele, e aplica o preço certo — não o de tabela. O cliente vê o valor que combinou, não uma surpresa que dá origem a uma reclamação amanhã.
- Crédito bloqueado. Cruza a conta-corrente. Vê o bloqueio por faturas vencidas e, em vez de aceitar uma encomenda que a empresa nunca vai poder expedir, encaminha para uma pessoa: "Tenho de confirmar uns valores em conta com a equipa comercial antes de avançar." Sem expor dados sensíveis, sem prometer o que não pode cumprir.
A diferença não é que o agente responde melhor. É que ele recusa o que não bate — porque leu a regra na fonte. E cada uma dessas leituras fica registada: que campos consultou, quando, em nome de que utilizador. Read-only e auditado por construção. É a mesma abordagem do Nemea, o produto com que ligamos um assistente conversacional diretamente ao ERP do cliente — pergunta em linguagem natural, resposta fundamentada nos dados reais, sem escrever nada que não esteja controlado.
"Mas o meu bot também sabe dizer que não"
Sabe dizer que não quando lhe escreves a regra à mão. Podes ensinar-lhe que o artigo 7781 vende em paletes de 12. Depois muda o fornecedor e a palete passa a 10. Alguém tem de se lembrar de ir editar o guião. Multiplica isto pelos teus milhares de artigos, pelas centenas de clientes com condições próprias, pelas faturas que vencem todos os dias — e percebes que manter o guião sincronizado com o ERP é um trabalho a tempo inteiro que ninguém está a fazer.
O agente não tem esse problema porque não guarda uma cópia da regra. Vai buscá-la à fonte, no momento. Quando a equipa comercial altera o escalão do cliente no ERP, o agente já responde com o novo escalão na mensagem seguinte — sem que ninguém toque no assistente. A regra vive num sítio só: o teu ERP. É aí que já vive hoje.
Porque um sistema fundamentado ganha ao que adivinha
Um modelo de linguagem, por si, é uma máquina de completar frases: dá-lhe uma pergunta e ele produz a resposta estatisticamente mais provável. Isso é ótimo para conversar e péssimo para uma decisão comercial, porque "provável" não é "verdadeiro". O preço provável não é o preço deste cliente. O stock provável não é o stock de hoje.
Fundamentar (grounding) é obrigar o sistema a ir buscar o facto ao teu sistema antes de responder, e a citar de onde o tirou. Deixa de adivinhar e passa a consultar. É por isso que insistimos em read-only auditado: o agente lê o que precisa, faz cumprir a regra, e deixa rasto — mas não inventa e não escreve à solta. A conversa é a interface; a integração é o produto.
O próximo passo concreto
Antes de assinares qualquer assistente, faz-lhe um teste de uma pergunta: pede-lhe uma encomenda que viole uma regra tua — abaixo da quantidade mínima, para um cliente bloqueado, ou com um preço que não é o dele. Um bot regista. Um agente ligado ao teu ERP recusa e explica porquê. Essa única resposta diz-te tudo sobre o que estás a comprar.
Se quiseres ver o teu próprio ERP a responder assim — com as tuas regras, os teus artigos e os teus clientes — fala connosco em hello@leiritech.com ou +351 914 572 595. Mostramos-te o trabalho sobre os teus dados, não uma demo com dados de brincar.
