El botón de reporte que te avisa que tu sitio está roto antes de que los clientes se rindan

Imagina una pequeña herramienta SaaS un martes por la tarde. Se hace un deploy, un valor de configuración es incorrecto y el formulario de registro comienza a lanzar un error para todos. Nada falla ruidosamente. El servidor está funcionando, la página de inicio carga y el panel de control se ve bien para el equipo porque ya han iniciado sesión. Durante tres horas, cada nuevo visitante se topa con un formulario inactivo, se encoge de hombros y se va. El dueño se entera esa noche — por un único tuit molesto. Esta es la forma silenciosa en la que los sitios web pierden dinero. No es una caída dramática, sino una pequeña falla que solo los visitantes pueden ver, y los visitantes casi nunca te lo dicen. Asumen que alguien ya lo sabe. Asumen que es su propia conexión. La mayoría de las veces, simplemente siguen adelante. ## El problema: te enteras el último Cuando algo se rompe en un sitio en producción, las primeras personas en darse cuenta son las menos capaces de solucionarlo: tus visitantes. Entre ellos y tus desarrolladores hay un muro de fricción. Para reportar un bug, un visitante normalmente tendría que encontrar tu página de contacto, averiguar qué email usar, describir un problema técnico con sus propias palabras y recordar en qué página estaba. Casi nadie hace todo eso por una empresa para la que no trabaja. Así que el reporte nunca llega. Tu monitorización podría detectar una caída completa del servidor, pero rara vez detecta un botón roto, un formulario que falla solo en Safari, un proceso de pago que da error solo cuando se aplica un cupón, o una imagen que da 404 en la página de un producto. Estas fallas "parciales" son comunes, son invisibles desde adentro y son exactamente las que te cuestan registros y ventas. La brecha no es técnica. Es humana. Necesitas hacer que reportar un problema sea tan fácil que un extraño ligeramente molesto realmente lo haga. ## La solución: un botón prellenado de "Reportar un problema" Agrega un pequeño botón, siempre visible, de **Reportar un problema** a tu sitio — en el pie de página, en una esquina, y especialmente en tus pantallas de error y de estados vacíos. En lugar de apuntar a un formulario de contacto, es un enlace `mailto:` que abre la propia aplicación de correo del visitante con el mensaje ya escrito para ellos. El visitante hace clic una vez. Su aplicación de correo se abre con tu equipo de desarrollo en el campo Para, un asunto claro y una plantilla corta en el cuerpo. Escriben una línea sobre lo que salió mal y presionan enviar. Esa es toda la interacción — sin formularios, sin inicios de sesión, sin cuentas. Aquí está el enlace detrás del botón: ```html <a href="mailto:[email protected]?subject=Site%20problem%20reported&body=What%20I%20was%20doing%3A%0AWhat%20went%20wrong%3A%0A%0APage%3A%0ABrowser%3A"> Reportar un problema </a> ``` El generador de este sitio construye y codifica ese enlace por ti, para que un espacio perdido o un corchete nunca lo rompan. ## Qué debería contener el reporte El valor está en el cuerpo prellenado. Un enlace en blanco de "escríbenos" te da un "no funciona". Un reporte prellenado te da algo sobre lo que puedes actuar. Solicita las tres cosas que un desarrollador siempre pregunta: - **Qué estaba haciendo el visitante** — la acción que falló. - **Qué salió mal** — el texto del error o lo que esperaba ver. - **Contexto** — la URL de la página, e idealmente el navegador y la hora. Si el botón vive dentro de tu propia app, puedes rellenar el contexto automáticamente. Un pequeño script puede colocar la URL actual, la cadena del navegador y una marca de tiempo directamente en el cuerpo antes de que se abra el correo, para que el visitante solo escriba una oración: ```html <a id="report" href="#">Reportar un 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:[email protected]' + '?subject=' + encodeURIComponent('Site problem: ' + document.title) + '&body=' + encodeURIComponent(body); </script> ``` Ahora cada reporte llega etiquetado con la página exacta y el entorno. Tu desarrollador a menudo puede reproducir el bug antes de responder. ## Configuración en cinco minutos 1. Elige la dirección que debería recibir los reportes. Una bandeja de entrada compartida o un alias como `dev-team@` funciona bien, para que todo el equipo lo vea. 2. Construye el enlace en el generador: define el destinatario, un asunto claro como "Site problem reported", y un cuerpo corto con las tres solicitudes anteriores. 3. Copia el fragmento de HTML y pégalo en tu pie de página y en tu página de error. 4. Si vive dentro de una app, agrega el pequeño script para que la URL y el navegador se llenen automáticamente. 5. Envíate un reporte de prueba para confirmar que el borrador se abre correctamente. Sin backend, sin servicios de formularios de terceros, sin una nueva factura. El enlace `mailto:` es parte del HTML, por lo que funciona en un sitio estático, una landing page, un artículo de help-desk o una aplicación web completa. ## Lo que te ahorra El ahorro está en el **tiempo de detección**. Supón que tu sitio tiene 1.000 visitas al día y un formulario se rompe silenciosamente a las 2 p.m. Sin una ruta de reporte, podrías enterarte de ello esa noche — seis horas y unos cientos de registros perdidos después. Con un botón de reporte de un clic, el primer visitante confundido avisa a tu equipo en cuestión de minutos. Pierdes un puñado de registros en lugar de toda una tarde de ellos. También hay un ahorro en el soporte. Correos electrónicos vagos de "tu sitio está roto" le cuestan a una persona de soporte varios minutos cada uno solo para averiguar en qué página y navegador. Un reporte prellenado responde esas preguntas por adelantado, por lo que el triaje se reduce de minutos a segundos. Y como reportar no requiere esfuerzo, más personas lo hacen — convirtiendo un problema silencioso en una señal constante y honesta sobre lo que realmente está fallando en la práctica. También protege la confianza. Un visitante que puede reportar una falla en un clic se siente escuchado, incluso cuando algo está roto. Un visitante que se topa con un formulario inactivo y no tiene forma de decírtelo simplemente se va y recuerda tu sitio como el que no funcionó. ## Hazlo aún mejor - Pon el botón en tus **páginas 404 y de error**, donde la frustración es mayor y un reporte es más valioso. - Usa una **etiqueta en el asunto** como `Site problem:` para que una simple regla de la bandeja de entrada encamine cada reporte al canal correcto. - Mantén la dirección **ofuscada** en las páginas públicas para que los bots de spam no la recolecten — un pequeño script que ensamble el enlace al hacer clic es suficiente. - Acompáñalo con una nota de estado visible ("¿Tienes problemas? Cuéntanos") para que las personas sepan que el botón está ahí para ellos. ## Puntos clave - Tus visitantes ven las fallas primero, pero casi nunca las reportan — la fricción es demasiado alta. - Un botón prellenado `mailto:` de "Reportar un problema" elimina esa fricción: un clic, una oración, enviado. - Autocompleta la URL de la página y el navegador para que cada reporte sea reproducible. - No necesita backend ni presupuesto, y reduce tu tiempo de detección de horas a minutos. Construye tu propio botón de reporte en el [generador](/#generator), o copia la configuración a continuación para comenzar.