Toda agência conhece esse e-mail. Assunto: «problema no site». Corpo: «o formulário da página de contato não está funcionando no meu computador». Remetente: o cliente, com o assistente dele em cópia, encaminhado duas vezes. Sem navegador, sem URL além de «a página de contato», sem erro, e com uma captura de tela de um documento do Word que contém uma captura de tela. Duas horas faturáveis depois, você descobre que era uma extensão do navegador.
Bugs reportados por clientes fazem parte do trabalho de qualquer agência: durante o desenvolvimento, na homologação (UAT) e em todo contrato de manutenção. O canal por onde eles chegam decide se vão custar minutos ou tardes inteiras.
Por que o e-mail é o pior canal possível
O e-mail perde todo o contexto técnico já na origem. O cliente descreve o que lembra, de um ambiente que você não vê, sobre uma página que você precisa adivinhar. Aí começam os custos de verdade:
O ciclo de esclarecimentos. «Qual navegador? Pode mandar o link exato? Onde você clicou primeiro?» Cada ida e volta leva um dia de calendário e um pouco da boa vontade do cliente.
Nenhum estado compartilhado. O cliente não sabe se você viu o e-mail, se alguém está cuidando disso ou por que aquilo que ele reportou no mês passado ainda não foi corrigido. Então ele cobra, e as cobranças também precisam de resposta.
Nenhuma fronteira entre projetos. Dez clientes com contrato de manutenção significam relatórios de bug de dez sites misturados numa caixa de entrada, e cada um precisa ser encaminhado, transcrito para o seu bug tracker e acompanhado à mão.
Repare no padrão: estão pedindo ao cliente que faça o trabalho de um analista de QA (observar, documentar, contextualizar), e ele não sabe fazer isso nem tem obrigação de fazer. A solução é parar de pedir.
O modelo do widget
Coloque o mecanismo de relatório no próprio site do cliente. Um pequeno botão flutuante em todas as páginas: o cliente clica, escreve uma frase, se quiser circula o problema numa captura de tela, e envia. A ferramenta captura todo o resto naquele momento: URL da página, navegador, SO, dispositivo, viewport, logs do console com os erros sinalizados, requisições de rede com as falhas destacadas e um replay de sessão do que ele fez até o relatório.
No BugDump, a instalação é uma tag de script por site:
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="site-specific-key"></script>Detalhes que importam no contexto de uma agência:
Um projeto por site de cliente. Cada projeto tem a própria chave, o próprio quadro e o próprio histórico de relatórios. Nada se mistura. O plano Ultra comporta até 100 projetos justamente para esse tipo de uso.
White label. Nos planos pagos, a marca BugDump sai do widget, e ele parece parte do site que você construiu, não um acessório de terceiros.
Combine com o site. Tema (claro/escuro/automático), ícone do botão, posição e cada texto da interface são configuráveis, inclusive com tradução completa para clientes cujos sites não estão em inglês.
Na homologação, convide a reportar. Um balão ao lado do botão («Viu algum problema?») transforma as rodadas de revisão, que antes chegavam como um PDF de capturas anotadas, em relatórios estruturados que você resolve um por um.
A experiência do cliente se resume a: ver o problema, clicar, digitar uma frase, pronto. Sem login, sem formulário, sem «qual navegador você está usando», nunca mais.
O que muda do seu lado
Os relatórios chegam prontos para o diagnóstico. O erro do console e a requisição que falhou estão no relatório. O alarme falso causado por uma extensão se revela em minutos, e não depois de reconstruir o site. O «não consigo reproduzir» praticamente some, porque você lê a falha em vez de recriá-la.
A triagem vira um estado visível. Os relatórios de cada projeto caem num quadro kanban: novo, em andamento, concluído. Quando o cliente liga perguntando do problema da semana passada, basta olhar o quadro, sem escavar a caixa de entrada. Relatórios duplicados se acumulam na mesma tarefa, o que também serve de sinal de severidade.
Os bugs entram no seu fluxo de entrega. As integrações encaminham os relatórios para onde a sua equipe já trabalha: Slack ou Discord para todo mundo ficar sabendo, GitHub Issues, Jira ou Asana para os que viram tickets. Sem etapa de transcrição, sem bug perdido entre a caixa de entrada e o backlog.
A primeira leitura pode ficar com um assistente. O servidor MCP do BugDump dá ao Claude Code ou ao Cursor acesso aos relatórios de um projeto, com o contexto de console, rede e replay. Num contrato de manutenção, «resuma os relatórios desta semana do site da Meridian e aponte o que parecer regressão» é uma consulta real de segunda de manhã.
Como fazer a passagem do projeto
Para uma agência, encerrar um projeto sem pontas soltas é questão de sobrevivência. Duas práticas:
Limite o acesso por projeto. As chaves são por projeto, então um prestador de serviço que ajuda no site de um cliente vê só esse projeto. Se alguém sai, as chaves MCP são trocadas na hora nas configurações.
Decida explicitamente quem cuida da manutenção. Se o cliente assumir o site, transfira para ele um projeto próprio ou remova a tag na entrega. Um widget que envia relatórios para uma conta que ninguém olha é pior do que nenhum widget; deixe isso combinado no contrato.
Do ponto de vista do contrato de manutenção
Um widget de relatório de bug melhora discretamente a rentabilidade dos contratos de manutenção. O tempo de diagnóstico cai porque o contexto chega junto com o relatório. O esforço de comunicação cai porque o status fica num quadro, e não em threads de e-mail. E o próprio histórico de relatórios vira um registro de tudo o que foi encontrado e corrigido, útil na hora da renovação de um jeito que um arquivo de e-mails nunca é.
Os custos são pequenos e previsíveis: uma tag de script por site e um preço baseado em volume, e não por usuário, então toda a sua equipe e a do cliente podem acompanhar sem fazer conta de licenças.
O e-mail ainda vai chegar de vez em quando. Mas «é só clicar no botão de bug na página e enviar» é uma resposta de uma linha, e o relatório que volta é um que você consegue corrigir.
Leia também
Como coletar relatórios de bug de beta testers sem perder metade deles — como montar o canal de um beta para que os testers reportem no momento do bug e vejam o que aconteceu depois.
Relatórios de bug em QA e UAT: como tornar eficazes os testers não técnicos — por que a planilha da homologação perde metade das evidências e como fazer testers não técnicos enviarem relatórios úteis.
Bug tracker leve para equipes pequenas: quando o Jira é demais — o que um bug tracker precisa ter numa equipe pequena e como escolher um que os usuários de fato alimentem.