Qualquer site ou aplicação web
O botão de reporte que te avisa que o site está quebrado antes que os clientes desistam
Uma ferramenta cai, uma página lança um erro, um formulário para de funcionar silenciosamente — e o dono é o último a saber. Um botão pré-preenchido 'Reportar um problema' transforma visitantes confusos num sistema de alerta antecipado para a sua equipa de dev.
Reduz o tempo de deteção de horas para minutos
Imagine uma pequena ferramenta SaaS numa terça à tarde. Um deploy sai, um valor de configuração está errado, e o formulário de registo começa a lançar um erro para toda a gente. Nada estoira ruidosamente. O servidor está de pé, a homepage carrega, e o painel parece normal para a equipa porque já estão autenticados. Durante três horas, cada novo visitante bate num formulário morto, encolhe os ombros, e sai. O dono descobre nessa noite — a partir de um único tweet irritado. Esta é a forma silenciosa como sites perdem dinheiro. Não uma falha dramática, mas uma pequena avaria que só os visitantes veem, e os visitantes quase nunca dizem. Assumem que alguém já sabe. Assumem que é a própria ligação. Na maioria das vezes, seguem em frente. ## O problema: você descobre por último Quando algo se parte num site em produção, quem repara primeiro são os menos capazes de resolver: os seus visitantes. Entre eles e os seus programadores há uma parede de atrito. Para reportar um bug, um visitante teria normalmente de encontrar a sua página de contacto, descobrir que email usar, descrever um problema técnico com as próprias palavras, e lembrar-se em que página estava. Quase ninguém faz tudo isso por uma empresa em que não trabalha. Por isso o reporte nunca chega. A sua monitorização pode apanhar uma queda total do servidor, mas raramente apanha um botão partido, um formulário que só falha no Safari, um checkout que dá erro só quando é aplicado um cupão, ou uma imagem que dá 404 numa página de produto. Estas falhas 'parciais' são comuns, invisíveis de dentro, e são exatamente as que lhe custam registos e vendas. A falha não é técnica. É humana. Precisa de tornar o reporte de um problema tão fácil que um estranho ligeiramente aborrecido o faça mesmo. ## A solução: um botão pré-preenchido 'Reportar um problema' Adicione um pequeno botão **Reportar um problema** sempre visível ao seu site — no rodapé, num canto, e sobretudo nos ecrãs de erro e de estado vazio. Em vez de apontar para um formulário de contacto, é um link `mailto:` que abre o próprio email do visitante com a mensagem já escrita. O visitante clica uma vez. O email abre com a sua equipa de dev no campo Para, um assunto claro, e um corpo curto de modelo. Escreve uma linha sobre o que correu mal e carrega em enviar. Essa é toda a interação — sem formulários, sem logins, sem conta. Aqui está o link atrás do botão: ```html <a href="mailto:dev-team@yoursite.com?subject=Site%20problem%20reported&body=What%20I%20was%20doing%3A%0AWhat%20went%20wrong%3A%0A%0APage%3A%0ABrowser%3A"> Reportar um problema </a> ``` O gerador deste site constrói e codifica esse link por si, para que um espaço perdido ou um parênteses nunca o partam. ## O que o reporte deve conter O valor está no corpo pré-preenchido. Um link 'escreva-nos' em branco dá-lhe 'não funciona'. Um reporte pré-preenchido dá-lhe algo em que pode agir. Peça as três coisas que um programador pergunta sempre: - **O que o visitante estava a fazer** — a ação que falhou. - **O que correu mal** — o texto do erro ou o que esperava ver. - **Contexto** — o URL da página, e idealmente o navegador e a hora. Se o botão vive dentro da sua própria app, pode preencher o contexto automaticamente. Um pequeno script pode colocar o URL atual, a string do navegador, e um timestamp diretamente no corpo antes de o email abrir, para que o visitante escreva apenas uma frase: ```html <a id="report" href="#">Reportar um problema</a> <script> const a = document.getElementById('report'); const body = 'What I was doing:\nWhat went wrong:\n\n' + 'Page: ' + location.href + '\n' + 'Browser: ' + navigator.userAgent; a.href = 'mailto:dev-team@yoursite.com' + '?subject=' + encodeURIComponent('Site problem: ' + document.title) + '&body=' + encodeURIComponent(body); </script> ``` Agora cada reporte chega marcado com a página exata e o ambiente. O seu programador consegue muitas vezes reproduzir o bug antes de responder. ## Configuração em cinco minutos 1. Escolha o endereço que deve receber reportes. Uma caixa partilhada ou alias como `dev-team@` funciona bem, para toda a equipa ver. 2. Construa o link no gerador: defina o destinatário, um assunto claro como 'Site problem reported', e um corpo curto com os três pontos acima. 3. Copie o snippet HTML e cole-o no seu rodapé e na sua página de erro. 4. Se vive dentro de uma app, adicione o pequeno script para que o URL e o navegador sejam preenchidos automaticamente. 5. Envie um reporte de teste a si próprio para confirmar que o rascunho abre corretamente. Sem backend, sem serviço de formulários de terceiros, sem nova fatura. O link `mailto:` faz parte do HTML, por isso funciona num site estático, numa landing page, num artigo de help-desk, ou numa aplicação web completa. ## O que lhe poupa A poupança está no **tempo até à deteção**. Suponha que o seu site tem 1.000 visitas por dia e um formulário parte silenciosamente às 14h. Sem caminho de reporte, pode descobrir isso à noite — seis horas e algumas centenas de registos perdidos depois. Com um botão de reporte de um clique, o primeiro visitante confuso avisa a sua equipa em minutos. Perde uma mão-cheia de registos em vez de uma tarde deles. Há uma poupança de suporte também. Emails vagos de 'o vosso site está partido' custam a um agente vários minutos só para descobrir qual página e navegador. Um reporte pré-preenchido responde a essas perguntas à cabeça, e a triagem cai de minutos para segundos. E como reportar é sem esforço, mais pessoas o fazem — transformando um problema silencioso num sinal constante e honesto sobre o que está realmente a partir-se na prática. Também protege a confiança. Um visitante que consegue reportar uma falha num clique sente-se ouvido, mesmo quando algo está partido. Um visitante que bate num formulário morto e não tem forma de o dizer sai e lembra-se do seu site como o que não funcionou. ## Como o tornar ainda melhor - Coloque o botão nas suas páginas **404 e de erro**, onde a frustração está no auge e o reporte é mais valioso. - Use uma **tag no assunto** como `Site problem:` para uma regra simples da caixa encaminhar cada reporte para o sítio certo. - Mantenha o endereço **ofuscado** em páginas públicas para que bots de spam não o colham — um pequeno script que monta o link no clique chega. - Emparelhe com uma nota visível ('Alguma dificuldade? Diga-nos') para que as pessoas saibam que o botão está lá para elas. ## Pontos-chave - Os seus visitantes veem a avaria primeiro, mas quase nunca a reportam — o atrito é alto demais. - Um botão `mailto:` pré-preenchido 'Reportar um problema' remove esse atrito: um clique, uma frase, enviado. - Preencha automaticamente o URL da página e o navegador para que cada reporte seja reproduzível. - Não precisa de backend nem de orçamento, e reduz o tempo até à deteção de horas para minutos. Construa o seu próprio botão de reporte no [gerador](/#generator), ou copie a configuração abaixo para começar.
Imagine uma pequena ferramenta SaaS numa terça à tarde. Um deploy sai, um valor de configuração está errado, e o formulário de registo começa a lançar um erro para toda a gente. Nada estoira ruidosamente. O servidor está de pé, a homepage carrega, e o painel parece normal para a equipa porque já estão autenticados. Durante três horas, cada novo visitante bate num formulário morto, encolhe os ombros, e sai. O dono descobre nessa noite — a partir de um único tweet irritado.
Esta é a forma silenciosa como sites perdem dinheiro. Não uma falha dramática, mas uma pequena avaria que só os visitantes veem, e os visitantes quase nunca dizem. Assumem que alguém já sabe. Assumem que é a própria ligação. Na maioria das vezes, seguem em frente.
O problema: você descobre por último
Quando algo se parte num site em produção, quem repara primeiro são os menos capazes de resolver: os seus visitantes. Entre eles e os seus programadores há uma parede de atrito. Para reportar um bug, um visitante teria normalmente de encontrar a sua página de contacto, descobrir que email usar, descrever um problema técnico com as próprias palavras, e lembrar-se em que página estava. Quase ninguém faz tudo isso por uma empresa em que não trabalha.
Por isso o reporte nunca chega. A sua monitorização pode apanhar uma queda total do servidor, mas raramente apanha um botão partido, um formulário que só falha no Safari, um checkout que dá erro só quando é aplicado um cupão, ou uma imagem que dá 404 numa página de produto. Estas falhas 'parciais' são comuns, invisíveis de dentro, e são exatamente as que lhe custam registos e vendas.
A falha não é técnica. É humana. Precisa de tornar o reporte de um problema tão fácil que um estranho ligeiramente aborrecido o faça mesmo.
A solução: um botão pré-preenchido 'Reportar um problema'
Adicione um pequeno botão Reportar um problema sempre visível ao seu site — no rodapé, num canto, e sobretudo nos ecrãs de erro e de estado vazio. Em vez de apontar para um formulário de contacto, é um link mailto: que abre o próprio email do visitante com a mensagem já escrita.
O visitante clica uma vez. O email abre com a sua equipa de dev no campo Para, um assunto claro, e um corpo curto de modelo. Escreve uma linha sobre o que correu mal e carrega em enviar. Essa é toda a interação — sem formulários, sem logins, sem conta.
Aqui está o link atrás do botão:
<a href="mailto:dev-team@yoursite.com?subject=Site%20problem%20reported&body=What%20I%20was%20doing%3A%0AWhat%20went%20wrong%3A%0A%0APage%3A%0ABrowser%3A">
Reportar um problema
</a>
O gerador deste site constrói e codifica esse link por si, para que um espaço perdido ou um parênteses nunca o partam.
O que o reporte deve conter
O valor está no corpo pré-preenchido. Um link 'escreva-nos' em branco dá-lhe 'não funciona'. Um reporte pré-preenchido dá-lhe algo em que pode agir. Peça as três coisas que um programador pergunta sempre:
- O que o visitante estava a fazer — a ação que falhou.
- O que correu mal — o texto do erro ou o que esperava ver.
- Contexto — o URL da página, e idealmente o navegador e a hora.
Se o botão vive dentro da sua própria app, pode preencher o contexto automaticamente. Um pequeno script pode colocar o URL atual, a string do navegador, e um timestamp diretamente no corpo antes de o email abrir, para que o visitante escreva apenas uma frase:
<a id="report" href="#">Reportar um problema</a>
<script>
const a = document.getElementById('report');
const body =
'What I was doing:\nWhat went wrong:\n\n' +
'Page: ' + location.href + '\n' +
'Browser: ' + navigator.userAgent;
a.href = 'mailto:dev-team@yoursite.com'
+ '?subject=' + encodeURIComponent('Site problem: ' + document.title)
+ '&body=' + encodeURIComponent(body);
</script>
Agora cada reporte chega marcado com a página exata e o ambiente. O seu programador consegue muitas vezes reproduzir o bug antes de responder.
Configuração em cinco minutos
- Escolha o endereço que deve receber reportes. Uma caixa partilhada ou alias como
dev-team@funciona bem, para toda a equipa ver. - Construa o link no gerador: defina o destinatário, um assunto claro como 'Site problem reported', e um corpo curto com os três pontos acima.
- Copie o snippet HTML e cole-o no seu rodapé e na sua página de erro.
- Se vive dentro de uma app, adicione o pequeno script para que o URL e o navegador sejam preenchidos automaticamente.
- Envie um reporte de teste a si próprio para confirmar que o rascunho abre corretamente.
Sem backend, sem serviço de formulários de terceiros, sem nova fatura. O link mailto: faz parte do HTML, por isso funciona num site estático, numa landing page, num artigo de help-desk, ou numa aplicação web completa.
O que lhe poupa
A poupança está no tempo até à deteção. Suponha que o seu site tem 1.000 visitas por dia e um formulário parte silenciosamente às 14h. Sem caminho de reporte, pode descobrir isso à noite — seis horas e algumas centenas de registos perdidos depois. Com um botão de reporte de um clique, o primeiro visitante confuso avisa a sua equipa em minutos. Perde uma mão-cheia de registos em vez de uma tarde deles.
Há uma poupança de suporte também. Emails vagos de 'o vosso site está partido' custam a um agente vários minutos só para descobrir qual página e navegador. Um reporte pré-preenchido responde a essas perguntas à cabeça, e a triagem cai de minutos para segundos. E como reportar é sem esforço, mais pessoas o fazem — transformando um problema silencioso num sinal constante e honesto sobre o que está realmente a partir-se na prática.
Também protege a confiança. Um visitante que consegue reportar uma falha num clique sente-se ouvido, mesmo quando algo está partido. Um visitante que bate num formulário morto e não tem forma de o dizer sai e lembra-se do seu site como o que não funcionou.
Como o tornar ainda melhor
- Coloque o botão nas suas páginas 404 e de erro, onde a frustração está no auge e o reporte é mais valioso.
- Use uma tag no assunto como
Site problem:para uma regra simples da caixa encaminhar cada reporte para o sítio certo. - Mantenha o endereço ofuscado em páginas públicas para que bots de spam não o colham — um pequeno script que monta o link no clique chega.
- Emparelhe com uma nota visível ('Alguma dificuldade? Diga-nos') para que as pessoas saibam que o botão está lá para elas.
Pontos-chave
- Os seus visitantes veem a avaria primeiro, mas quase nunca a reportam — o atrito é alto demais.
- Um botão
mailto:pré-preenchido 'Reportar um problema' remove esse atrito: um clique, uma frase, enviado. - Preencha automaticamente o URL da página e o navegador para que cada reporte seja reproduzível.
- Não precisa de backend nem de orçamento, e reduz o tempo até à deteção de horas para minutos.
Construa o seu próprio botão de reporte no gerador, ou copie a configuração abaixo para começar.