Qué datos enviar a soporte cuando falla la web de tu empresa

«La web no funciona» puede significar que nadie puede entrar, que un botón falla en el móvil o que un formulario confirma el envío pero el correo no llega. Son problemas diferentes y necesitan comprobaciones distintas. Un aviso concreto ayuda a empezar por el recorrido afectado, sin convertir al responsable del negocio en técnico.

La información más útil cabe en un mensaje: qué intentabas hacer, dónde, cuándo y qué ocurrió en su lugar. Si no puedes cobrar, recibir solicitudes o acceder a la web, comunícalo por el canal de soporte acordado cuanto antes. Los detalles que falten se pueden completar después.

Explica primero qué actividad está bloqueada

Empieza por la consecuencia observable: «no se puede terminar una compra», «el formulario no entrega correos» o «no podemos editar una ficha». No hace falta diagnosticar el origen ni atribuirlo a un plugin.

Separa lo que has comprobado de lo que sospechas. Que un fallo aparezca después de un cambio es una pista, no una demostración de su causa. Y que una persona haya tenido el problema no significa que afecte a todos los visitantes.

Para facilitar la prioridad, indica si hay una alternativa temporal y quién parece afectado: visitantes, administradores, compradores de un método de pago o usuarios de móvil. Evita estimar ventas perdidas si no tienes datos que permitan calcularlas.

Los seis datos que conviene reunir

1. Página y función afectadas

Facilita la dirección pública de la página y el nombre del botón, formulario o paso donde ocurre. «En contacto, al pulsar Enviar» orienta mejor que una captura de la portada.

Revisa la dirección antes de copiarla: algunos enlaces incluyen identificadores, claves de acceso o datos de una sesión. No los pegues en un formulario público. Si el problema está dentro de una zona privada, describe cómo llegar y acuerda con soporte el acceso necesario.

2. Momento de la primera observación

Anota fecha, hora aproximada y zona horaria, junto con la última vez que recuerdas que funcionó. «Lo he visto hoy a las 10:20, hora peninsular» no equivale a «lleva fallando desde las 10:20»: la diferencia importa cuando se revisan registros.

Si no sabes cuándo empezó, dilo. Una referencia aproximada identificada como tal resulta más útil que una precisión inventada.

3. Pasos y resultado esperado

Describe una secuencia corta: entrar en la página, seleccionar una opción y pulsar el botón. Después señala qué esperabas y qué apareció realmente. Copia el mensaje de error tal como se muestra, retirando cualquier dato privado que contenga.

No repitas un pago ni un envío con datos de clientes para obtener una prueba. En una tienda, la comprobación debe acordarse para no generar cobros, pedidos o correos no autorizados.

4. Dispositivo y navegador

Indica si utilizabas ordenador o móvil, el navegador y si estabas identificado en la web. La versión puede añadirse si la conoces; no debe convertirse en una barrera para pedir ayuda.

Si ya has observado que funciona en otro dispositivo, inclúyelo. No es necesario probar todas las combinaciones ni borrar datos del navegador antes de avisar: eso puede hacer que pierdas el contexto en el que aparecía el problema.

5. Cambios recientes conocidos

Menciona actualizaciones, cambios de contenido, ajustes de correo o intervenciones de otro proveedor que conozcas. Añade también las acciones que ya has intentado y su resultado.

No actualices o desactives extensiones en bloque para «ver si se arregla». Encadenar cambios sin registrar el estado inicial puede añadir problemas y dificultar la investigación. El siguiente paso técnico debe decidirse según la instalación y su actividad.

6. Una evidencia breve y revisada

Una captura del mensaje de error o un vídeo corto del recorrido puede aclarar lo que el texto no explica. Recorta lo innecesario y oculta de forma irreversible nombres, correos, direcciones, importes privados y referencias de clientes antes de compartir el archivo.

Evita mostrar otras pestañas, notificaciones o gestores de contraseñas. Las normas del soporte de WordPress prohíben publicar información personal y solicitar o facilitar accesos en sus foros. Un foro público no sustituye a un canal privado acordado con tu proveedor.

Plantilla para copiar al comunicar el problema

Puedes usar este esquema en tu canal habitual de soporte. Completa solo lo que conozcas y no incluyas contraseñas:

Web y página afectada: dirección pública o recorrido dentro del panel.

Qué necesito hacer: acción que está fallando.

Impacto observado: qué impide hacer y a quién parece afectar.

Cuándo lo he observado: fecha, hora y zona horaria; última ocasión en que funcionó, si la conozco.

Pasos: acciones previas al fallo, en orden.

Resultado esperado / resultado obtenido: diferencia y mensaje de error sin datos privados.

Entorno: móvil u ordenador, navegador y sesión iniciada o no.

Cambios o pruebas previas: qué se ha hecho y qué ocurrió.

Evidencia: captura revisada, si hace falta y el canal permite adjuntarla.

Ejemplo: una descripción útil sin afirmar una causa

Este escenario es ficticio y solo ilustra cómo redactar el aviso:

«En la página de contacto, el botón Enviar muestra la confirmación, pero no hemos recibido el correo de la prueba autorizada. Lo observamos hoy por la mañana desde un móvil, sin iniciar sesión. La última recepción que hemos confirmado fue ayer. No sabemos si afecta a todos los envíos y no hemos cambiado ninguna configuración desde que lo detectamos».

El mensaje delimita el problema, pero no afirma que el formulario haya perdido los datos ni que el servidor de correo sea responsable. Soporte tendrá que comprobar el recorrido y distinguir entre registro de la solicitud, envío y entrega.

Qué información técnica puede pedirte soporte después

El primer aviso no necesita un volcado completo de la web. Según el problema, el técnico puede pedir versiones, configuración o un fragmento de un registro. Si tienes WooCommerce, su informe de estado del sistema reúne datos como versiones y ajustes del servidor para ayudar al diagnóstico.

Comparte ese informe únicamente cuando sea necesario, con el destinatario adecuado y por el canal acordado. No lo publiques íntegro ni envíes una copia de la base de datos por iniciativa propia. Si no puedes acceder al panel, comunica esa limitación: no necesitas resolverla antes de abrir la incidencia.

Acuerda también cómo se dará por resuelta

Una incidencia no debería cerrarse solo porque la portada vuelva a cargar. Identifica el recorrido que debe funcionar al terminar: recibir la solicitud de prueba, completar una reserva autorizada o volver a editar el contenido afectado.

Mantén las novedades en el mismo hilo para conservar la secuencia de hechos. Si surge otro problema distinto, sepáralo y explica si apareció después de la intervención. Así es más fácil distinguir una incidencia pendiente de una nueva solicitud.

Si tu empresa necesita un responsable que atienda estos avisos y organice los cambios con continuidad, consulta nuestro servicio de mantenimiento web. Antes de empezar, concretamos las funciones de tu web, el alcance del trabajo y las condiciones de atención. Describir bien el problema ayuda a investigarlo; no sustituye al diagnóstico ni garantiza un plazo de resolución.