Por que a conta de um cliente aparecia como expirada semanas depois de a cobrança ser aprovada
Um cliente tinha pagado em dia, e a conta dele continuava aparecendo como expirada. Nada no sistema tinha gerado um erro, porque nada tinha dado errado que o sistema conseguisse enxergar.
O que parecia um caso isolado
Minha primeira leitura foi a mais comum: uma confusão de cobrança, dessas que se resolvem com um aviso e um crédito. Corrigimos a conta, lançamos o pagamento que faltava e estendemos o prazo. Na maioria das vezes, a história para por aí.
Esta não parou, porque os números não fechavam direito. A cobrança era real. O registro dela dentro do nosso próprio sistema, não. Um pagamento nunca tinha aparecido para ser tratado, então o nosso tratamento nunca foi o problema.
Três lugares para olhar, um que se encaixou
Havia três explicações plausíveis.
- Uma etapa de renovação poderia ter rodado e falhado, o que deixaria um pagamento registrado com a data de validade errada.
- O nosso tratamento da notificação poderia ter aceitado a mensagem e perdido no meio do caminho, o que deixaria um erro em algum lugar nos logs.
- A própria notificação nunca chegou.
As duas primeiras deixam rastro. Aqui não havia nenhum dos dois. Nem registro de pagamento, nem erro. Essa ausência apontava para fora, para além do nosso código, até um ponto de conexão entre um serviço externo e o nosso que tinha parado de repassar mensagens. Estava assim havia semanas. Os clientes continuavam sendo cobrados. Só que o nosso lado simplesmente nunca ficava sabendo.
Por que vigiar os erros não bastava
Tudo o que a gente tinha montado vigiava algo dando errado depois que uma mensagem chegava. Nada perguntava se a mensagem tinha chegado, para começo de conversa. Em um dashboard construído em torno de erros, uma conexão que não entrega nada fica igualzinha a uma que está saudável e quieta. Chamados de suporte e conferências de conta são úteis depois que o cliente percebe. Não servem para pegar o problema antes disso.
A solução foi uma comparação
O instinto é criar um alerta para a coisa específica que quebrou. Isso remenda o incidente e deixa a brecha aberta. A próxima mudança sem relação com aquele mesmo ponto de conexão poderia causar o mesmo silêncio, e a gente deixaria passar de novo.
A solução que se sustentou foi uma comparação permanente entre dois lados. De um lado, o que o serviço externo informa que realmente aconteceu. Do outro, o que o nosso sistema registrou no mesmo período. Quando os dois deixam de concordar, algo está errado, seja a causa uma mudança de roteamento, um problema de autenticação ou um sistema de qualquer uma das pontas que parou de enviar. A comparação não precisa saber qual é a causa. Ela só precisa saber que os dois lados não batem mais.
O que o agente de IA fez e o que ficou com a gente
O trabalho de rastreamento era uma comparação que um agente de IA conseguia executar rápido, mostrando o que fez. Ele descartou as duas explicações que teriam deixado evidência e depois seguiu a ausência até o lugar onde ela realmente estava. Também esboçou o formato da verificação contínua: o que medir em cada lado e quando uma diferença entre eles deve contar como um problema que vale acordar alguém.
Decidir que isso merecia uma investigação de verdade, e não uma correção pontual, foi decisão nossa. Também foi nossa a decisão sobre o que se devia ao cliente e sobre qual diferença entre os dois lados é normal o bastante para o alerta ficar quieto. Um agente de IA pode mostrar que dois números não batem mais. Ele não deveria ser quem decide quanto essa divergência vale para o negócio, nem o que acontece com a conta que está diante dele.
Se o seu negócio depende de outro serviço avisar que algo aconteceu, vigie o silêncio desse serviço tanto quanto as falhas barulhentas. Em um dashboard que só conta erros, silêncio e saúde parecem a mesma coisa.