Toda agencia conoce ese email. Asunto: «problema en la web». Cuerpo: «el formulario de la página de contacto no funciona en mi equipo». Remitente: el cliente; en copia, su asistente; reenviado dos veces. Ni navegador, ni más URL que «la página de contacto», ni error, y una captura de pantalla de un documento de Word que contiene una captura de pantalla. Dos horas facturables después descubres que era una extensión del navegador.
Los bugs que reportan los clientes son parte fija del trabajo de una agencia: durante el desarrollo, en el UAT y a lo largo de cada contrato de mantenimiento. El canal por el que llegan decide si cuestan minutos o tardes enteras.
Por qué el email es el peor canal posible
El email elimina todo el contexto técnico en el origen. El cliente describe lo que recuerda, desde un entorno que no ves, sobre una página que tienes que adivinar. Y entonces empieza lo caro:
El ciclo de aclaraciones. «¿Qué navegador? ¿Me pasas el enlace exacto? ¿Dónde hiciste clic primero?» Cada ida y vuelta se lleva un día de calendario y un pedazo de la buena voluntad del cliente.
No hay un estado compartido. El cliente no sabe si viste el email, si alguien está trabajando en ello o por qué lo que reportó el mes pasado sigue sin arreglarse. Así que vuelve a escribir, y esos seguimientos también necesitan respuesta.
No hay fronteras entre proyectos. Diez clientes con contrato de mantenimiento son reportes de bug de diez webs mezclados en una bandeja de entrada, y cada uno hay que derivarlo, pasarlo a tu tracker y seguirlo a mano.
Fíjate en el patrón: al cliente se le pide el trabajo de un ingeniero de QA (observar, documentar, poner en contexto), y ni puede ni tiene por qué hacerlo. La solución es dejar de pedírselo.
El modelo del widget
Pon el mecanismo de reporte en la propia web del cliente. Un pequeño botón flotante en cada página: el cliente hace clic, escribe una frase, si quiere marca el problema en una captura de pantalla y lo envía. La herramienta captura todo lo demás en ese momento: URL de la página, navegador, sistema operativo, dispositivo, viewport, logs de consola con los errores marcados, peticiones de red con los fallos resaltados y una repetición de sesión de lo que hizo el cliente antes del reporte.
Con BugDump, instalarlo es una etiqueta script por web:
<script src="https://bugdump.com/sdk/latest.js" async data-api-key="site-specific-key"></script>Detalles que importan en una agencia:
Un proyecto por web de cliente. Cada proyecto tiene su propia clave, su propio tablero y su propio historial de reportes. Nada se mezcla. El plan Ultra admite hasta 100 proyectos justo para este tipo de uso.
Marca blanca. En los planes de pago, el widget deja de mostrar la marca BugDump: se percibe como parte de la web que construiste, no como un añadido de terceros.
Que encaje con la web. El tema (claro/oscuro/automático), el icono del botón, la posición y cada texto de la interfaz se configuran, incluida la traducción completa para clientes cuyas webs no están en inglés.
Durante el UAT, invita a reportar. Una burbuja junto al botón («¿Viste un problema?») convierte las rondas de revisión, que antes eran un PDF de capturas anotadas, en reportes estructurados que puedes resolver uno a uno.
La experiencia del cliente se reduce a esto: ve el problema, hace clic, escribe una frase y listo. Sin inicio de sesión, sin formulario y sin «¿qué navegador usas?», nunca más.
Qué cambia de tu lado
Los reportes llegan listos para diagnosticar. El error de consola y la petición fallida están en el reporte. La falsa alarma causada por una extensión se delata en minutos, no después de rehacer la web. El «no se puede reproducir» casi desaparece, porque lees el fallo en lugar de recrearlo.
El triaje se convierte en un estado visible. Los reportes de cada proyecto llegan a un tablero kanban: nuevo, en progreso, hecho. Cuando el cliente llama para preguntar por el problema de la semana pasada, la respuesta es un vistazo, no una excavación en la bandeja de entrada. Los reportes duplicados se acumulan en la misma tarea, y eso sirve a la vez como señal de gravedad.
Los bugs entran en tu flujo de entrega. Las integraciones envían los reportes adonde tu equipo ya trabaja: Slack o Discord para enterarse, GitHub Issues, Jira o Asana para los que se convierten en tickets. Sin paso de transcripción y sin bugs perdidos entre la bandeja de entrada y el backlog.
La primera lectura se puede delegar en un asistente. Con el servidor MCP de BugDump, Claude Code o Cursor leen los reportes de un proyecto, con el contexto de consola, red y repetición de sesión incluido. En un contrato de mantenimiento, «resume los reportes de esta semana de la web de Meridian y marca lo que parezca una regresión» es una consulta real de lunes por la mañana.
Cómo gestionar la entrega del proyecto
Las agencias viven o mueren por cómo cierran los proyectos. Dos prácticas:
Limita el acceso por proyecto. Las claves son por proyecto, así que un colaborador externo que ayuda en la web de un cliente solo ve ese proyecto. Las claves MCP se rotan al instante desde los ajustes si alguien deja el proyecto.
Decide de forma explícita qué pasa con el mantenimiento. Si el cliente se queda con la web, transfiérele un proyecto propio o quita la etiqueta script en la entrega. Un widget que reporta a una cuenta que nadie mira es peor que no tener ninguno: deja las expectativas claras en el contrato.
Lo que gana el contrato de mantenimiento
Un widget de reporte de bugs mejora, sin hacer ruido, la economía de los contratos de mantenimiento. El tiempo de diagnóstico baja porque el contexto llega con el reporte. La carga de comunicación baja porque el estado vive en un tablero y no en hilos de email. Y el propio historial de reportes se convierte en un documento: un registro de todo lo que se encontró y se corrigió, útil a la hora de renovar como nunca lo es un archivo de emails.
Lo que cuesta es poco y se sabe de antemano: una etiqueta script por web y un precio por volumen, no por usuario, así que todo tu equipo y el del cliente pueden estar al tanto sin calcular licencias.
El email seguirá llegando de vez en cuando. Pero «haz clic en el botón de bugs de la página y envíalo» es una respuesta de una línea, y el reporte que vuelve es uno que de verdad puedes corregir.
Te puede interesar
Reporte de bugs en QA y UAT: cómo hacer eficaces a los testers no técnicos — por qué una ronda de UAT acaba en una hoja de cálculo de sesenta filas y cómo conservar la evidencia.
Cómo recopilar reportes de bug de tus beta testers sin perder la mitad — un widget dentro del producto, contexto capturado automáticamente y un triaje que responde al tester.
Seguimiento de bugs ligero para equipos pequeños: cuando Jira es demasiado — qué necesita un sistema de seguimiento ligero y cómo elegir uno que los usuarios de verdad alimenten.