Um usuário me enviou um feedback sobre o Premail: ele estava recebendo um erro 404 ao tentar finalizar a compra. Foi constrangedor na hora. Eu não deveria colocar nada no ar que retorne um 404 onde deveria haver uma página funcionando, e muito menos no exato momento em que alguém está tentando me pagar.
Eu tenho testes. Tenho alertas. Tenho alarmes de infraestrutura. Nenhum deles pegou o problema. Quem pegou foi a pessoa do outro lado do meu checkout quebrado.
O que tornou esse incidente interessante, além da frustração de descobri-lo, foi como eu de fato fiquei sabendo dele. Um recurso que eu tinha adicionado ao Premail poucos dias antes trouxe à tona o feedback que todo o resto não tinha conseguido colocar diante dos meus olhos. Meu produto teve uma falha, e depois meu produto me ajudou a lidar com ela.
Como você deveria descobrir que seu checkout quebrou?
O cliente não deveria ter sido o alarme. Há algo particularmente doloroso em uma falha no checkout. A pessoa já fez o trabalho de encontrar seu produto, entender o que ele faz e decidir que vale a pena pagar por ele. E então você coloca um beco sem saída na frente dela.
Teria sido totalmente razoável essa pessoa fechar a aba e seguir em frente. Ela não me devia um relatório de bug, uma captura de tela ou uma explicação de por que eu não estava fechando a venda. Ela estava tentando comprar algo, não se voluntariando para o controle de qualidade.
Em vez disso, ela dedicou tempo para enviar um feedback. Fiquei realmente grato e dei 50% de desconto como agradecimento. Ela me deu a oportunidade de corrigir um problema do qual, de outra forma, eu talvez nunca tivesse sabido.
Essa também é a parte desconfortável. Eu sei da pessoa que me avisou. Não sei se mais alguém encontrou o mesmo problema e foi embora sem dizer nada. Um checkout que falha pode parecer muito com uma pessoa que simplesmente decidiu não comprar, a menos que você esteja de fato capturando a falha.
A minha não estava sendo capturada. Qualquer que fosse a confiança que eu tinha nos meus testes e no meu monitoramento, isso foi uma demonstração bem inequívoca de que eles tinham deixado passar algo importante.
Nada disso é uma ideia nova. A orientação de SRE do Google traça a mesma linha entre observar sinais internos e checar o que um usuário realmente vê, e a documentação do Playwright diz para testar o comportamento visível em vez dos detalhes de implementação. Eu sabia das duas. Só nunca tinha aplicado nenhuma delas ao único fluxo que recebe dinheiro.
O e-mail que eu precisava notar
Meu formulário de feedback me envia uma breve notificação por e-mail avisando que há um feedback para revisar. É um pequeno aviso, não o feedback completo. Para saber o que alguém escreveu, preciso notar esse e-mail e ir conferir.
Eu tinha deixado passar. Mas essa notificação apareceu no meu briefing matinal do Premail, e vi imediatamente que havia um feedback sobre o qual eu precisava agir. Fui lê-lo, soube do problema no checkout e pus mãos à obra.
Vale fazer esta distinção: o Premail não detectou o 404. Ele não inspecionou meu checkout, não diagnosticou o bug nem substituiu de alguma forma o monitoramento que deveria tê-lo pegado. O cliente encontrou o problema. O Premail trouxe à tona a notificação que me levou a ler o que ele havia relatado.
Era exatamente o tipo de coisa que eu queria que os briefings fizessem, e aconteceu enquanto eu mesmo ainda estava me acostumando a usá-los.
Usando o que acabei de construir
Adicionei os briefings ao Premail há apenas alguns dias. Estou tentando me treinar para parar de ir por padrão ao meu cliente de e-mail e, em vez disso, usar meus briefings como um resumo do que precisa da minha atenção. Para mim, isso é uma mudança de hábito, não apenas o lançamento de um recurso.
Abrir uma caixa de entrada e descobrir o que importa são duas atividades diferentes. Consigo olhar o e-mail sem notar a mensagem específica que deveria mudar o que faço em seguida. Neste caso, uma pequena notificação sobre um feedback precisava se tornar uma tarefa de verdade: vá ler isto e responda.
O briefing matinal fez essa conexão por mim. Vi algo que tinha deixado passar, entendi que precisava agir e agi imediatamente. Não houve muita ambiguidade sobre se ele tinha sido útil.
Uma coisa é construir um recurso porque você acredita que ele vai ajudar as pessoas. Outra é vê-lo puxar algo importante do seu próprio e-mail e mudar o rumo da sua manhã. Eu teria preferido um exemplo menos constrangedor, mas esse foi bem convincente.
Consertando mais do que o checkout
O problema do checkout já está corrigido. Também corrigi os alertas, os alarmes de infraestrutura e os testes que não conseguiram pegá-lo. Fazer a página funcionar era necessário, mas parar por aí me deixaria dependendo do próximo cliente prestativo para me avisar quando algo desse errado.
Não vou declarar que nada parecido pode voltar a acontecer. Eu me esforcei para evitar da primeira vez, e mesmo assim aconteceu. O objetivo dessas mudanças é evitar uma repetição e, se ela acontecer, me deixar ciente antes que um cliente precise relatar ou que um cliente em potencial desista em silêncio.
A lição certamente não é que um briefing matinal seja um substituto aceitável para testes e monitoramento. “Esperar alguém reclamar e depois resumir a notificação” seria uma péssima estratégia de confiabilidade. Eu precisava consertar os sistemas que deixaram o problema chegar a um cliente em primeiro lugar.
Mas também pude ver o Premail fazer algo genuinamente útil depois que esses sistemas falharam. Ele trouxe uma mensagem esquecida à minha atenção, e essa mensagem levou diretamente a uma correção.
A falha no checkout não fica menos constrangedora porque meu próprio aplicativo me ajudou a descobri-la. As duas coisas são verdadeiras: deixei um cliente esbarrar em um checkout quebrado, e um recurso que eu tinha acabado de construir me ajudou a responder. Sou grato por o cliente ter se dado ao trabalho de me avisar, e feliz por meu briefing matinal ter garantido que eu notasse.