"A caixa chegou com duas chaleiras partidas. Quero a nota de crédito." A mensagem chega ao WhatsApp às 18h40 de uma sexta-feira. O bot de €25 responde o que sabe responder: "Lamentamos o sucedido! A nossa equipa vai tratar do seu pedido." E depois não acontece nada. Não fica registo, não fica número, e na segunda-feira alguém do back-office tem de começar do zero: procurar a fatura, confirmar o que foi entregue, ver se já houve alguma devolução e fazer as contas.
A DECO avaliou em março o atendimento digital de 24 empresas de 8 setores e deu notas entre "Mau" e "Razoável". A queixa principal é esta mesma: o chatbot faz triagem, empurra o cliente para uma FAQ ou um formulário e não regista a reclamação. O cliente não quer empatia. Quer o problema resolvido.
Há duas maneiras erradas de resolver isto. A primeira é o bot que não faz nada. A segunda é o bot que faz tudo, incluindo emitir uma nota de crédito sozinho. Este artigo explica a terceira: o agente prepara o documento, uma pessoa aprova e emite, e fica tudo registado.
Porque é que a nota de crédito é o teste certo
A maior parte das perguntas no WhatsApp são de leitura: onde está a minha encomenda, quanto devo, há stock. Aí o risco é baixo. Se o agente só lê, está ligado ao teu ERP e cada resposta vem de um registo real, o pior que pode acontecer é uma resposta incompleta.
A nota de crédito é diferente, por três razões:
- É um documento fiscal. Em software certificado não se apaga. Se emitires mal, a única correção é outro documento, e ambos ficam no SAF-T.
- Mexe em dinheiro e em IVA. Para regularizares o IVA a teu favor, precisas de prova de que o cliente tomou conhecimento da retificação. Um "ok 👍" no WhatsApp não chega como processo.
- É um vetor de fraude. Se o agente emitir créditos a quem os pedir por mensagem, basta alguém saber o número de uma fatura e ter um telemóvel.
Por isso a nota de crédito serve de fronteira. Um sistema que a trata bem trata bem quase tudo o resto. Um sistema que a trata mal devia ficar longe do teu ERP.
O que o agente faz, passo a passo
Pega na mensagem de sexta-feira. Um agente ligado ao ERP faz isto, por esta ordem:
1. Verifica quem está a pedir. O número de telemóvel tem de corresponder a um contacto autorizado do cliente na ficha do ERP. Se não corresponder, o agente não lê faturas nem mostra valores. Regista o pedido e passa-o a uma pessoa. Não é um detalhe: num estudo da Sinch, 74% das organizações tiveram de desligar ou reverter chatbots de IA, e a exposição de dados pessoais foi a causa mais citada (31%).
2. Encontra a fatura de origem. O cliente diz "a encomenda de quarta". O agente procura as faturas desse cliente nos últimos dias e encontra a FT 2026/1842, com 12 chaleiras a €24,90 cada, sem IVA.
3. Cruza com o que foi entregue e com o que já foi creditado. Confirma na guia de remessa que as 12 unidades saíram. Confirma que não existe nenhuma nota de crédito anterior sobre essa linha. Se já houvesse uma, o agente não podia propor mais do que o saldo que falta creditar. É este cruzamento que o bot de €25 não consegue fazer, porque não vê as tabelas.
4. Aplica a política comercial. Está dentro do prazo de reclamação? O artigo tem devolução física obrigatória ou basta a foto? A regra está escrita no sistema, não na memória de quem atende.
5. Prepara o rascunho. Duas unidades × €24,90 = €49,80. IVA a 23% = €11,45. Total: €61,25, a referenciar a FT 2026/1842, linha 3. O documento fica em rascunho. Ainda não tem número definitivo nem ATCUD, e não foi comunicado. Juridicamente, ainda não existe.
6. Responde ao cliente com a verdade. "Registei o teu pedido com o n.º DEV-0417: 2 chaleiras da fatura FT 2026/1842, crédito de €61,25 com IVA. A equipa valida e envia-te a nota de crédito." Tem um número, um valor e o próximo passo. É o oposto de "vamos tratar disso".
O que o humano faz: vinte segundos em vez de vinte minutos
Na segunda-feira, a pessoa do back-office já não começa do zero. Abre o rascunho e tem à frente a fatura de origem, a guia, as fotos que o cliente enviou, a regra aplicada e as contas feitas. Confirma e emite. O documento recebe número e ATCUD e segue pelo circuito normal do ERP.
A pessoa continua a decidir, mas deixa de fazer trabalho de arquivo. É esta a troca que interessa: o agente faz o trabalho demorado e sujeito a erro, que é encontrar, cruzar e calcular, e o humano faz o que não pode ser delegado, que é assumir a responsabilidade por um documento fiscal.
Tudo fica no trilho de auditoria: quem pediu, a que horas, que registos o agente leu, que valor propôs, quem aprovou e quando. Se daqui a um ano um auditor ou o teu contabilista perguntar porque é que aquela nota de crédito existe, a resposta está lá, completa.
Os limites estão no código, não no prompt
É aqui que muitas "integrações" falham. Escrever no prompt "nunca emitas notas de crédito" não é um controlo. É um pedido educado a um modelo de linguagem, e os modelos alucinam (no mesmo estudo da Sinch, 22% das falhas foram alucinações).
Os limites a sério estão abaixo do modelo:
- A credencial do agente só pode criar rascunhos. O utilizador de base de dados ou de API com que o agente trabalha não tem permissão para finalizar documentos. Mesmo que o modelo "queira", o ERP recusa.
- A leitura é livre por defeito, a escrita é uma lista fechada. O agente pode ler faturas, guias e fichas de cliente. Só pode escrever em três ou quatro tipos de registo: pedidos de devolução, rascunhos, notas internas.
- Há tetos. Acima de um valor definido por ti, por exemplo €500, o rascunho precisa de duas aprovações. Não se propõem créditos sobre faturas com mais de X dias sem revisão de um supervisor.
- Cada escrita fica registada, com os dados que a justificaram.
Com isto, o pior cenário é um rascunho errado que uma pessoa rejeita. Não é uma nota de crédito emitida por engano que obriga a emitir outro documento para a corrigir.
"Não era mais rápido deixá-lo emitir sozinho?"
É a objeção certa, e merece uma resposta honesta: sim, poupavas os vinte segundos da aprovação. Em troca, ficavas exposto a:
- documentos fiscais irreversíveis emitidos a partir de uma conversa de WhatsApp;
- um canal onde qualquer pessoa com um número de fatura pode tentar pedir créditos;
- uma conversa difícil com o teu contabilista quando ele encontrar notas de crédito que ninguém da equipa aprovou.
A assimetria é grande. A aprovação custa segundos e um erro custa horas, mais a confiança do cliente. Pode fazer sentido automatizar totalmente créditos muito pequenos e repetitivos, com regras apertadas, mas essa decisão deve ser tua, tomada com dados de alguns meses de rascunhos aprovados. Não deve ser o ponto de partida.
O mesmo padrão noutros setores
Calibração. Um laboratório fatura duas vezes a mesma calibração de um paquímetro: uma pela ordem de serviço e outra pela recalibração em garantia. O agente deteta as duas linhas para o mesmo equipamento e o mesmo certificado e propõe o crédito. A responsável da qualidade aprova, e fica o registo que a auditoria ISO vai querer ver.
Saúde. Num lar, um utente esteve cinco dias internado no hospital e a mensalidade foi faturada por inteiro. A família pergunta no WhatsApp. O agente confirma a identidade do familiar autorizado, cruza os registos de ausência com a fatura e prepara o acerto. A direção aprova. Os dados de saúde nunca saem do sistema para a conversa: o agente diz o valor e o período, não o motivo clínico.
Faturação eletrónica. No Chile, uma nota de crédito eletrónica (DTE tipo 61) tem de referenciar o documento de origem e é assinada e enviada ao SII. Não há "desfazer". Em Portugal, com o fim da aceitação do PDF como fatura eletrónica previsto para 31/12/2026 e o CIUS-PT a ganhar peso, a margem para erros em documentos fiscais vai ficar menor, não maior.
Armazém. É o caso das chaleiras. E daqui a 60 dias é Black Friday: as devoluções de dezembro vão chegar todas pelo mesmo canal, à mesma hora.
Porque é que isto não se faz com um bot de €25
O bot barato e o Meta Business Agent gratuito conversam bem. Mas a integração com sistemas externos, no caso da Meta, só existe na versão enterprise. No Brasil, o mercado já cobra a integração de um bot com o ERP à parte, entre R$2.000 e R$15.000 de implementação. O preço confirma o que interessa: a conversa é barata e o valor está na integração.
O que distingue um agente a sério não é falar melhor. É ter acesso de leitura auditado aos teus dados, saber o que "creditado" significa nas tuas tabelas e ter permissões de escrita tão estreitas que o pior erro possível é um rascunho rejeitado.
Próximo passo
Escolhe o documento que mais tempo tira ao teu back-office. Pode ser a nota de crédito, o acerto de mensalidade ou a devolução. Escreve as três regras que uma pessoa aplica sempre antes de o emitir. Estas regras são a especificação do agente.
Se quiseres ver este fluxo em cima do teu ERP (PHC, Primavera ou um sistema próprio), fala connosco: hello@leiritech.com ou +351 914 572 595. Fazemos a primeira conversa com quem escreve o código, em modo só de leitura, sobre os teus dados reais.
