Não cria a encomenda duas vezes: o que separa a demo da produção

O cliente escreve no WhatsApp: "sim, confirma essas 40 caixas". Passam três segundos, a rede treme, ele não vê o visto azul e escreve outra vez: "confirmado?". Do outro lado, o teu assistente automático processou as duas mensagens. E agora tens duas ordens de 40 caixas no armazém, dois picking slips a sair da impressora, e alguém da equipa a passar a manhã a perceber se o cliente quer 40 ou 80.

Esta é a parte que nenhuma demo bonita te mostra. Responder a uma pergunta é fácil. Escrever no teu ERP sem estragar nada é que é o trabalho — e é exatamente aí que o bot de €25 e o agente ligado ao teu sistema deixam de ser a mesma coisa.

Um "ok" repetido não é uma ordem nova

O problema tem nome de engenharia: idempotência. Traduzindo para linguagem de operações — uma ação idempotente pode ser executada duas, três, dez vezes e o resultado é sempre o mesmo que se fosse executada uma vez só. Carregar duas vezes no botão do elevador não chama dois elevadores. Um "ok, confirma" repetido não deve criar duas encomendas.

Parece óbvio dito assim. Mas o software não sabe, por defeito, que a segunda mensagem é a mesma intenção da primeira. Para ele são dois pedidos distintos, cada um a bater à porta do ERP a dizer "cria a ordem". Se ninguém desenhou a proteção, o ERP obedece às duas. E os motivos para a mensagem chegar em duplicado são triviais e diários: o cliente impaciente que reenvia, a app que faz retry automático quando o Wi‑Fi falha, o webhook da Meta que entrega o mesmo evento duas vezes porque não recebeu confirmação a tempo. Não é um caso raro de laboratório — é terça-feira de manhã.

O que o bot de €25 faz (e o que não faz)

O bot comoditizado, no melhor cenário, não escreve no teu ERP — ele "anota" a intenção num guião e alguém da tua equipa transcreve à mão para o sistema. Aí a duplicação é um problema humano: a pessoa vê duas mensagens iguais, hesita, pergunta ao cliente, perde tempo. Custo escondido, mas ainda recuperável.

No pior cenário, ligaram o bot ao ERP por um webhook qualquer sem pensar no dia mau. Aí a duplicação vira uma ordem a mais que já entrou no picking, já reservou stock que não existe, e talvez já gerou uma fatura. Agora não é hesitação — é uma nota de crédito, um cliente irritado e stock bloqueado.

A diferença não está em qual dos dois "conversa melhor". Está em quem foi desenhado para o momento em que as coisas correm mal.

Como se escreve no ERP a sério: a chave de idempotência

Um agente feito para produção resolve isto com três peças, e nenhuma delas é magia:

1. Chave de idempotência. No instante em que a conversa gera a intenção "criar encomenda", o agente calcula uma chave estável a partir do que a define — cliente, artigos, quantidades, janela de tempo. Essa chave viaja com o pedido de escrita. O ERP (ou a camada de integração à frente dele) guarda-a. Chega um segundo pedido com a mesma chave? O sistema responde "já processei este" e devolve a mesma ordem que criou à primeira, em vez de criar outra. O cliente pode carregar em "confirma" as vezes que quiser: a ordem número 2026/1487 continua a ser uma só.

2. Estado de confirmação explícito. O agente não salta da conversa para a escrita. Ele constrói um rascunho, mostra-o — "40 caixas, artigo X, para entrega quinta, confirmas?" — e só o "sim" transita o estado de rascunho para confirmado. Entre os dois há uma fronteira clara, não uma inferência a partir do tom da frase.

3. Log de auditoria por origem. Cada tentativa de escrita fica registada: quem pediu, quando, com que chave, qual foi a resposta do ERP, e se foi uma criação nova ou um pedido repetido ignorado. Quando o cliente ligar a dizer "recebi duas confirmações", tens a resposta em dez segundos, com o trilho, em vez de um encolher de ombros.

O mesmo problema muda de fato conforme o setor

Armazém e logística. A duplicação come stock. Reservas o dobro, o picking bloqueia mercadoria que ia para outro cliente, e o inventário deixa de bater com a prateleira. A escrita idempotente mantém uma ordem = uma reserva.

Faturação eletrónica. Aqui não há "desfazer" fácil. Uma fatura emitida em duplicado numa plataforma como o SII no Chile ou o e-invoicing da AT em Portugal é um documento fiscal com folio consumido e comunicação feita ao Estado. Corrigir significa nota de crédito, novo documento, e uma conversa com a contabilidade. A chave de idempotência é o que impede que o segundo "emite" gere um segundo DTE assinado.

Saúde e cuidados. Numa casa de repouso, uma ordem de medicação registada duas vezes não é um custo — é um risco clínico. Um sistema de circuito fechado com leitura de código de barras confirma a administração uma vez, e recusa a segunda leitura da mesma dose com uma mensagem clara, deixando o registo auditado que a norma exige.

Calibração e QMS. Um certificado de calibração emitido em duplicado quebra a rastreabilidade que a ISO te obriga a manter. O número do certificado tem de ser único por origem, e o sistema tem de garantir isso — não confiar em que o técnico não carregou duas vezes.

Porque é que um agente grounded ganha ao bot que adivinha

Um chatbot baseado em guião ou só num modelo de linguagem adivinha a resposta a partir de padrões de texto. Não tem noção de estado: para ele, cada mensagem é nova, sem memória do que já escreveu no mundo real. É por isso que a duplicação lhe escapa — ele não sabe que já criou a ordem porque não é ele que a cria, é o teu sistema, e ele nunca olhou lá.

Um agente grounded trabalha ao contrário: antes de agir, consulta o teu ERP (read-only, auditado) para saber o que já existe. "Este cliente já tem uma ordem aberta com estes artigos criada há 30 segundos? Então não crio outra — mostro a que existe." A resposta não sai da eloquência do modelo; sai dos teus dados. É essa a linha inteira desta discussão: não é quem responde mais bonito, é quem verifica antes de escrever.

A objeção honesta: "não posso só pôr o bot a não repetir?"

Podes tentar. E vais descobrir que "não repetir" é fácil no caminho feliz e difícil em todos os outros: mensagens que chegam fora de ordem, o mesmo cliente com duas encomendas legítimas parecidas no mesmo dia, o retry que chega 40 segundos depois quando o rascunho já expirou. Cada um destes exige uma decisão de desenho — quanto tempo a chave é válida, o que conta como "a mesma" ordem, o que fazer quando há dúvida. É trabalho de engenharia de integração, não uma caixa que se liga num painel no-code numa tarde. É precisamente por isso que a escrita fiável custa €250 a €1.200 por mês e o bot custa €25: um deles tomou estas decisões por ti, o outro empurra-as para a tua equipa.

O próximo passo, concreto

Pega no teu assistente atual — ou no que te andam a vender — e faz-lhe uma pergunta só: o que acontece se o cliente confirmar a mesma encomenda duas vezes em cinco segundos? Se a resposta for "criava duas" ou "não sei", já sabes qual dos dois estás a comprar.

Se quiseres ver como fica uma escrita idempotente e auditada sobre o teu ERP — PHC, Primavera ou o que tens — mostramos-te o trabalho, com o log à frente. Fala connosco em leiritech.pt ou hello@leiritech.com.