A frase mais cara do suporte
“Você poderia nos mandar uma captura de tela e dizer qual navegador estava usando?” É uma pergunta educada e razoável, e é o motivo de um bug de dois minutos levar três dias para ser corrigido. O cliente está ocupado, então a resposta chega amanhã. A captura mostra a mensagem de erro, mas não o clique que a causou. A versão do navegador está errada porque ele conferiu no celular. Quando a engenharia vê o ticket, ninguém lembra exatamente o que aconteceu, nem o próprio cliente.
A solução não é um formulário de bug melhor. É parar de pedir ao cliente evidências que você mesmo poderia ter capturado, no momento em que o problema aconteceu.
O que um bom relato de bug realmente contém
Engenheiros precisam de cinco coisas para reproduzir um bug:
- O que o cliente fez: os cliques e as entradas, em ordem.
- O que ele esperava: o resultado que tentava alcançar.
- O que realmente aconteceu: o erro, a tela em branco, o botão que não fez nada.
- O ambiente: página, navegador, dispositivo, tamanho da tela e de onde ele veio.
- O rastro técnico: os erros do console e as requisições de rede que falharam.
Um cliente consegue informar com confiança o segundo item e parte do terceiro. Os outros três são exatamente o que um replay de sessão grava: a sequência de ações, a página e o navegador, o log do console e as chamadas de rede. Pedir que as pessoas reconstruam isso de memória é pedir justamente a parte que elas menos conseguem dar.
Anexe a sessão em vez de pedi-la
O ponto de partida mais simples é o próprio relato. Quando um cliente envia um widget de feedback ou um formulário de bug dentro do app, a sessão está ali: a página em que ele está, os erros que acabaram de disparar, as requisições que falharam um segundo antes. Capture-a junto com o relato, e o ticket já chega com o que a engenharia precisa.
Isso muda a primeira resposta. Em vez de “pode mandar uma captura?”, o agente abre o replay, vê o TypeError no console dois segundos antes de o cliente clicar em Pagar de novo, e consegue dizer na mesma hora “vimos o que deu errado, e aqui está uma solução temporária”.
O e-mail é mais difícil, porque um e-mail não tem sessão anexada. Dois hábitos ajudam. Identifique os usuários logados na sua análise para que um ticket de um endereço conhecido possa ser associado às sessões recentes dele, e coloque um link de feedback dentro do produto para que o próximo relato venha da página onde está o problema, e não de uma caixa de entrada um dia depois.
Faça a triagem por bug, não por ticket
Quando os tickets trazem o erro, você pode agrupá-los por ele. É aqui que a maioria das equipes ganha mais. Um bug no checkout não gera um ticket; gera trinta, cada um escrito de um jeito: “pagamento falhou”, “não consigo comprar”, “botão quebrado”. Lidos um por um, parecem trinta problemas. Agrupados pela mensagem de erro em comum, são um bug só com trinta clientes afetados, e é esse número que faz ele ser priorizado.
Agrupar também muda como você fecha o ciclo. Escale o bug uma única vez, para uma issue no Linear, GitHub ou Jira, e vincule a ela cada ticket correspondente. Quando a correção for publicada, todos esses clientes podem ficar sabendo, e não só os cinco que escreveram de novo.
Para isso funcionar, o agrupamento precisa bater com o que a engenharia já vê. Se o suporte conta “problemas de pagamento” e a engenharia conta Cannot read properties of undefined (reading 'total'), as duas listas nunca se encontram. Agrupe os tickets pela mesma mensagem de erro normalizada que o seu rastreamento de erros usa.
Resolva a privacidade antes que ela resolva você
Anexar sessões aos tickets significa que os agentes de suporte veem mais do que os clientes fizeram, então defina as regras primeiro:
- Mascare os campos de formulário por padrão e nunca grave senhas nem campos de pagamento.
- Informe na sua política de privacidade que o suporte pode revisar a sessão ligada a uma solicitação.
- Restrinja o acesso aos replays a quem trabalha com os tickets, não a todos que têm login.
- Respeite o consentimento: um visitante que recusou a análise não deveria ter uma sessão para anexar.
Feito assim, o contexto de sessão é menos invasivo do que a alternativa, que é pedir aos clientes que compartilhem a tela ou mandem por e-mail capturas da conta deles.
Um fluxo para começar esta semana
- Adicione um widget de feedback ou de relato de bug dentro do app nas páginas onde os problemas mais acontecem: checkout, onboarding, configurações.
- Capture a sessão em cada envio, para que cada ticket traga o replay, o log do console e as requisições com falha.
- Identifique os usuários logados, para que os tickets por e-mail de clientes conhecidos possam ser associados às sessões deles.
- Agrupe os tickets por erro e revise os principais grupos toda semana com a engenharia.
- Escale cada bug uma única vez e responda a cada cliente vinculado quando ele for corrigido.
O que medir
Quatro números mostram se isso está funcionando:
- Parcela dos tickets de bug com sessão anexada. É o indicador antecedente; aumente-o primeiro.
- Tempo até a primeira resposta útil, ou seja, uma resposta que não pede mais informações.
- Tickets por bug. Se esse número cai, você está corrigindo os bugs que geram mais carga de suporte.
- Taxa de reabertura dos tickets de bug, que cai quando a primeira resposta está certa.
O help desk do PulsePanda foi construído em torno desse ciclo: o feedback vira ticket com o replay e os erros anexados, os tickets são agrupados pelos mesmos erros da página Erros, e escalar para Linear, GitHub ou Jira permite responder a cada cliente afetado quando a issue é fechada.