Técnico no cliente sem a peça: o agente vê onde há e cria a transferência

São 10h20 de uma terça de dezembro. O teu técnico está numa fábrica na Marinha Grande, com a bomba de calor aberta e o diagnóstico feito: falta uma válvula de expansão. Na carrinha não há. Então começa o ritual que conheces de cor: liga para o escritório, o escritório abre o ERP, vê que "há 3 em stock", liga para o armazém, o armazém vai à prateleira e descobre que duas estão reservadas para outra obra. Alguém se lembra de que o colega de Pombal "deve ter uma na carrinha". Mais duas chamadas. Quarenta minutos depois, o cliente continua sem aquecimento e o técnico continua à espera, a ser pago para esperar.

Nada disto é um problema de conversa. É um problema de dados e de ação: saber onde está a peça, reservá-la e pô-la a caminho. E é aqui que a diferença entre um bot de €25 por mês e um agente ligado ao ERP deixa de ser teórica.

O que o bot de €25 faz com este pedido

Olha para o que se vende hoje no mercado português: chatbot para o site a €15 por mês, mais €10 pelo add-on de WhatsApp, €100 de setup, pronto "em alguns dias". Responde a partir do teu site, do catálogo de serviços e das FAQ. Capta leads. É multilíngue e funciona 24/7. Em lado nenhum da página aparece a palavra ERP.

Para o dono de uma loja que quer responder a "qual é o horário?", é honesto e barato. Mas manda-lhe a mensagem do técnico — "preciso de uma válvula de expansão ref. X para a obra da Marinha Grande" — e o melhor que ele consegue é "Obrigado! O teu pedido foi registado, a equipa entrará em contacto". Ou seja, volta tudo ao telefone. O bot não sabe que armazéns tens, não sabe o que está reservado, não sabe o que anda nas carrinhas. Não é defeito do produto: é o limite de um sistema que só lê o teu site.

A DECO avaliou recentemente o atendimento digital de 24 empresas e a queixa repetia-se: os chatbots "empurram para FAQ em vez de permitir registar a reclamação". Com a equipa interna acontece o mesmo, só que ninguém faz reclamação: o técnico simplesmente deixa de usar o bot e volta a ligar ao escritório.

O que um agente ligado ao ERP faz, passo a passo

O mesmo pedido, agora com um agente ligado ao teu ERP (PHC, Primavera, Sage ou um ERP à medida) através da API:

1. Identifica quem pede. O número de WhatsApp está associado a um utilizador do ERP com um papel: técnico. Isto define o que ele pode ver e o que pode pedir.
2. Consulta o stock por localização, em modo só leitura. Não é o "stock total" do artigo. É o stock por armazém e por carrinha, com as reservas descontadas: "Leiria: 2 disponíveis (1 reservada). Pombal: 0. Carrinha 07 (João): 1."
3. Propõe a ação, não a executa logo. "Posso criar a transferência de 1 unidade Leiria → Carrinha 03, associada à ordem de serviço 2026/1184. Confirmas?" O técnico vê exatamente o que vai acontecer antes de acontecer.
4. Executa uma única ação permitida. Com o "sim", o agente chama o endpoint de transferência do ERP. É o ERP que cria o documento, move o stock e fica com a verdade. O agente não escreve em tabelas: pede ao sistema, pela porta que o sistema oferece.
5. Avisa quem prepara. O armazém de Leiria recebe a tarefa de picking no terminal, com a referência, a quantidade e o destino.
6. Regista tudo. Quem pediu, a que horas, com que parâmetros, que resposta deu o ERP e o número do documento criado.

Tempo total: o que o técnico demora a ler duas mensagens. E se a unidade mais próxima estiver na carrinha do João, a resposta é outra: "O João está a 12 km e tem 1. Queres que lhe pergunte?" Continua a ser uma decisão humana, só que com os dados à frente.

A carrinha também é um armazém

Aqui está o detalhe que separa uma integração a sério de uma demonstração. Na maior parte das empresas de assistência técnica, o stock das carrinhas ou não existe no ERP ou está lá, mas ninguém confia nele, porque as saídas se registam ao fim da semana, quando se registam.

Um agente só pode ser tão bom como os dados que consulta. Se as carrinhas não forem armazéns no ERP, ele vai dizer "0" para uma peça que está no banco de trás de alguém. Por isso, o primeiro trabalho num projeto destes raramente é o agente. É modelar as carrinhas como localizações e fazer com que o consumo da peça numa ordem de serviço dê baixa no stock dessa carrinha. É trabalho de ERP, pouco vistoso, e é precisamente o que o bot de €25 não pode fazer por ti.

Há um bónus sazonal: o inventário de fim de ano está a menos de três meses. As diferenças de inventário que vais encontrar em dezembro são, em boa parte, transferências que aconteceram por telefone e nunca chegaram ao sistema. Cada transferência criada pelo agente é um movimento que fica registado.

"E se o agente se engana?"

É a objeção certa, e a resposta não pode ser "o modelo é muito bom". Tem de ser arquitetura:

• Só leitura por defeito. O agente consulta stock, ordens de serviço e reservas. Escrever é a exceção, não a regra.
• Uma ação, com âmbito fechado. Um técnico pode pedir transferências para a sua carrinha, até um limite de quantidade ou de valor. Não anula documentos nem mexe em preços. A chave de integração tem exatamente essas permissões, e não as de administrador.
• Pré-visualização e confirmação. Nada se escreve sem o "sim" explícito de quem pediu, depois de ver a ação completa.
• Idempotência. Se a rede falhar e o técnico carregar duas vezes, sai uma transferência, não duas.
• Compensação. Se a transferência foi um erro, desfaz-se com a transferência inversa, também registada. Não se apaga nada.
• Registo auditável. Cada ação fica ligada a uma pessoa, a uma hora e a um documento do ERP. Quando alguém perguntar "quem tirou a válvula de Leiria?", a resposta está lá.

É isto que queremos dizer com grounded: o agente não "acha" que há stock. Lê o número do teu ERP e diz-te de onde veio. Quando não sabe, diz que não sabe. Quando age, age através do ERP, com um rasto que o teu responsável de operações consegue ler.

"O meu ERP já faz transferências"

Faz, e ainda bem. O agente não substitui o módulo de stocks. Tira do caminho as três chamadas e os quarenta minutos entre "falta a peça" e "a transferência está criada". O ERP continua a ser a fonte da verdade; o WhatsApp passa a ser só a porta de entrada mais rápida para quem está no terreno, de luvas e sem portátil.

Uma nota prática: se a peça circular por estrada entre instalações tuas, a movimentação pode exigir um documento de transporte comunicado à AT antes de sair. Esse documento tem de ser emitido pelo teu software de faturação certificado, e não por um modelo de linguagem. O agente pede-o ao ERP; não o inventa.

Porque é que isto importa agora

O inverno é a época alta da assistência técnica: AVAC, caldeiras, bombas de calor, refrigeração industrial. É quando há mais chamadas, mais técnicos na estrada e mais peças em falta. Cada deslocação repetida porque a peça não veio custa combustível, horas de técnico e, sobretudo, a paciência de um cliente que está sem aquecimento.

Pensa nas contas com os teus números. Se a tua equipa perde 30 minutos ao telefone em cada peça em falta e isto acontece 5 vezes por dia, são 2,5 horas diárias de técnicos parados. Não precisas de acreditar numa percentagem de ganhos de nenhum fornecedor. Basta contar as chamadas da próxima semana.

Por onde começar

Não comeces pelo agente. Começa por três perguntas ao teu ERP:

1. As carrinhas existem como armazéns e o consumo dá baixa nelas?
2. As reservas por obra ou ordem de serviço estão no sistema, ou só na cabeça do chefe de armazém?
3. A API do teu ERP expõe a criação de transferências? (No PHC GO, por exemplo, isso significa a Full API e um acordo de developer, não a Simple API.)

Se as três respostas forem "sim", o agente está a umas semanas de distância. Se alguma for "não", é por aí que começamos, e é trabalho que se paga sozinho mesmo sem IA.

Somos uma equipa pequena, em Leiria, que escreve o código do ERP e do agente. Manda-nos a lista dos teus armazéns e carrinhas para hello@leiritech.com e dizemos-te, sem compromisso, o que já dá para ligar e o que falta.