Última unidade, dois clientes: reserva no ERP, não promessa

"Tinha dito ao cliente que havia. Afinal havia uma, e foi para outro."

Se vendes peças, consumíveis, equipamento ou qualquer coisa com stock finito, já ouviste esta frase, ou já a disseste. Não é um problema de atendimento. É um problema de concorrência: duas pessoas pedem a mesma coisa quase ao mesmo tempo, e o sistema que lhes responde não tem forma de saber que a outra existe.

O bot de €25 por mês não resolve isto. Na maior parte dos casos, até piora: responde mais depressa, a mais gente, com a mesma certeza errada.

A cena: 21:14 e 21:15

Uma distribuidora de peças auto em Leiria, numa terça à noite. Há uma bomba de água para um modelo específico em stock: uma.

• 21:14 — Um mecânico de Pombal pergunta no WhatsApp: "Têm a bomba de água ref. tal?" O bot responde: "Sim, temos disponível!"
• 21:15 — Uma oficina da Marinha Grande faz a mesma pergunta. O bot responde: "Sim, temos disponível!"
• 21:40 — O mecânico de Pombal confirma que quer. A oficina da Marinha Grande também.
• 08:30 do dia seguinte — Alguém na loja abre o WhatsApp, vê duas confirmações para uma peça e tem de escolher a quem vai ligar a pedir desculpa.

Repara que o bot não "mentiu". Às 21:14 havia uma unidade. Às 21:15 continuava a haver uma unidade. As duas respostas estavam certas no momento em que foram dadas. O erro está noutro sítio: ler o stock não é o mesmo que o garantir.

Porque é que ler o stock não chega

Há três níveis de bot, e é importante não os confundir.

Nível 1 — o bot de FAQ. É o que se vende a €15–25 por mês. Responde a partir do texto que lhe deste: horário, morada, catálogo, perguntas frequentes. As páginas destes produtos falam em respostas 24/7, captação de leads e passagem para a equipa, mas não referem integração com o ERP nem ações executadas. Para esse bot, "temos" significa "está no catálogo que me colaram em junho". Nem sequer sabe se há uma ou nenhuma.

Nível 2 — o bot que lê o stock. Já é melhor: consulta o ERP e vê stock = 1. Só que o mecânico e a oficina fazem a consulta com um minuto de diferença, e os dois veem 1. Entre a leitura e a encomenda passam 25 minutos, porque o cliente foi perguntar ao patrão, foi ver o carro ou foi jantar. Em engenharia chama-se a isto uma race condition. No balcão, chama-se vender a mesma peça duas vezes.

Nível 3 — o agente que executa uma ação. No momento em que o cliente diz "quero", o agente não se limita a ler: pede ao ERP que reserve aquela unidade para aquele cliente, durante um tempo limitado. A partir daí, o stock disponível que qualquer outra conversa vê passa a ser zero.

A diferença entre o nível 2 e o 3 não está no modelo de linguagem. Está numa transação na base de dados.

O que é, em concreto, uma reserva temporária auditada

Quando dizemos "o agente cria uma reserva", não estamos a falar de dar ao modelo acesso livre ao ERP. Estamos a falar de uma única ação de escrita, escrita em código, com regras que o modelo não pode alterar:

1. Verificação e escrita na mesma transação. O sistema calcula o disponível (físico − já reservado − já comprometido em encomendas abertas) e cria a reserva só se o resultado for ≥ quantidade pedida. Se duas conversas chegarem no mesmo segundo, a base de dados serializa-as: uma ganha, a outra recebe "indisponível". Não há janela entre ler e escrever.
2. Validade curta. A reserva tem um prazo: 30 minutos, 2 horas, o que fizer sentido para o teu negócio. Se o cliente não confirmar, expira sozinha e a unidade volta ao disponível. Ninguém tem de se lembrar de a libertar.
3. Limites. Uma reserva ativa por conversa, quantidade máxima por artigo, só para clientes identificados (o número de telefone tem de corresponder a uma entidade no ERP). Isto trava o curioso que "reserva" vinte unidades para ver o que acontece.
4. Idempotência. Se o cliente escreve "quero" três vezes, ou se a rede repete o pedido, continua a haver uma reserva, não três.
5. Registo. Cada reserva fica com quem pediu, a conversa de origem, o artigo, a quantidade, a hora, a validade e o desfecho (convertida em encomenda, expirada ou cancelada). É isto que permite responder à pergunta "porque é que a oficina da Marinha Grande não ficou com a peça?" com uma linha de log em vez de uma discussão.

No ERP, isto encaixa no que já tens. Muitos ERPs têm o conceito de stock reservado ou de encomenda de cliente em aberto que abate ao disponível. Quando não têm, ou quando a API não o expõe, a reserva vive numa tabela própria ao lado, e é essa tabela que o cálculo do disponível passa a considerar, no WhatsApp, no balcão e na loja online.

E o segundo cliente? Às 21:15, a oficina da Marinha Grande recebe a verdade: "A última unidade está reservada até às 21:44. Se não for levantada, aviso-te. Entretanto, o fornecedor entrega na quinta. Queres que fique encomendada para ti?" Isto não é um "lamentamos", é uma resposta com dados do ERP, a reserva, o prazo de reposição e uma ação seguinte. O cliente fica a saber em que pé está.

Não é só stock: é capacidade

O mesmo padrão aparece sempre que há um recurso finito e várias pessoas a pedi-lo ao mesmo tempo.

Calibração. Um laboratório acreditado tem quatro vagas de calibração esta semana, e dois clientes com auditoria ISO à porta querem a última. Um bot que diz "temos disponibilidade na quinta" aos dois está a criar um conflito que alguém vai resolver ao telefone. O agente reserva a vaga no planeamento do QMS, com prazo, e a segunda empresa recebe a próxima data real.

Saúde. Numa farmácia ou num lar, as últimas caixas de um medicamento em rutura não podem ser prometidas a dois utentes. Aqui a reserva tem ainda mais regras, como lote, validade e, quando aplicável, receita associada, e o registo deixa de ser boa prática para passar a ser obrigação.

Faturação e encomendas B2B. Quando a reserva se converte em encomenda, o documento é emitido pelo ERP, com a numeração e as regras fiscais do ERP. O agente não inventa preços nem condições: usa a tabela e o desconto que o ERP atribui àquele cliente.

A objeção: "Não era suposto o agente ser read-only?"

É, por defeito. E é aqui que muita gente se engana nos dois sentidos.

Um lado diz: "Se escreve no ERP, é perigoso." Há boas razões para essa desconfiança. O caso mais citado este ano é o do agente da Replit que apagou uma base de dados de produção com registos de mais de mil executivos e empresas, apesar de ter instruções explícitas de "code freeze", e que depois afirmou que o rollback era impossível (não era). A lição não é "nunca escrevas". É que a permissão não pode viver no prompt. Pedir ao modelo para "ter cuidado" não é um controlo.

O outro lado diz: "O modelo é inteligente, deixa-o decidir." Também não.

O que funciona fica no meio: o agente é read-only para tudo, exceto uma lista fechada de ações, cada uma implementada como uma função com pré-condições, limites e registo. O modelo pode pedir criar_reserva(artigo, quantidade, cliente). Não pode pedir "altera o stock", "muda o preço" ou "apaga a reserva do outro", porque essas funções não existem para ele. A credencial que usa no ERP também não tem esse poder. Uma reserva temporária é a ação de escrita ideal para começar: é limitada, expira sozinha e o pior caso é uma unidade bloqueada durante 30 minutos.

A segunda objeção: "Basta pôr ‘sujeito a disponibilidade’"

Podes pôr. O cliente lê "temos" e ignora o resto.

E a primeira resposta errada custa caro. Segundo a Gartner, que inquiriu mais de 3.500 clientes entre fevereiro e março deste ano, só 27% voltam a tentar um chatbot depois de uma má experiência. Um "temos" que afinal não era não é uma má experiência qualquer: o cliente organizou o dia em função dessa peça. Na próxima vez, liga. Ou vai ao concorrente.

E a Black Friday está a 56 dias. É precisamente a altura em que mais conversas chegam ao mesmo tempo, sobre as mesmas promoções e o mesmo stock limitado, a horas em que ninguém está na loja para arbitrar.

Porque é que isto é IA "grounded", e não um bot a adivinhar

Num agente bem construído, o modelo de linguagem faz o que faz bem: perceber que "a bomba da água pró Golf do meu cliente" é a referência X, identificar quem está a escrever e redigir uma resposta clara. Não decide se há stock. Isso é o ERP que decide, numa transação. O modelo só escreve a frase à volta do resultado.

Se a transação devolve "reservado até 21:44", a resposta diz isso. Se devolve "indisponível", diz isso e propõe a alternativa que o ERP conhece. Não há espaço para o modelo "achar" que há, porque ninguém lhe pergunta o que acha.

Um bot de €25 não chega aqui. Não por ser mau, mas porque não é isso que se vende a €25: não sabe quem é o cliente, não lê o teu stock e não tem nenhuma ação para executar.

O próximo passo

Antes de falares com alguém, incluindo connosco, conta duas coisas no último trimestre:

1. Quantas encomendas foram anuladas ou adiadas porque o artigo "afinal não havia".
2. Quantas conversas de WhatsApp ou telefone foram só para perguntar "têm X?" e acabaram numa verificação manual no ERP.

Se o primeiro número for zero, não precisas disto. Se não for, já tens o caso de negócio, com dados teus. Envia-nos esses números e o nome do teu ERP (PHC, Primavera, Moloni, Sage ou outro) para hello@leiritech.com. Dizemos-te, sem compromisso, se a reserva cabe no que o teu ERP já tem ou se precisa de uma tabela ao lado, e quanto tempo leva a pôr a funcionar antes da Black Friday.