Qué anotar antes de llamar al soporte técnico

Llamar al soporte con el problema delante y no saber por dónde empezar es muy común. La pantalla muestra algo raro, hemos probado varias cosas y cada intento ha borrado un poco el orden de los acontecimientos. Una nota preparada antes de la llamada evita reconstruirlo todo mientras alguien espera al otro lado.

No hace falta escribir un informe técnico. Seis datos caben en media página: mensaje, hora, acción anterior, alcance, versión y cambios recientes. Con eso la conversación puede empezar por una pista y no por una descripción como “de repente dejó de ir”.

Copia el mensaje exacto

Escribo el texto tal como aparece, incluida la puntuación y cualquier código. Si es largo, hago una captura recortada y copio las dos primeras líneas. No traduzco el mensaje ni sustituyo palabras técnicas por lo que creo que significan.

Los códigos importan. La propia ayuda de Microsoft sobre reinicios inesperados y errores de detención explica que la pantalla puede mostrar un código y recomienda tener en cuenta cambios recientes de hardware. Esa combinación de mensaje y contexto orienta mejor que decir solo que el equipo “se quedó azul”.

Si el aviso incluye un identificador de solicitud, lo guardo. Si contiene una dirección de correo, un nombre de archivo privado o parte de una clave, no lo pego en una consulta pública. El soporte puede indicar un canal seguro si necesita información sensible.

Anota la hora y la acción anterior

La hora aproxima el fallo a registros que el servicio ya puede tener. No necesito una precisión de milisegundos. “A las 10:02, justo después de pulsar Enviar” es suficiente para empezar.

La acción anterior debe ser concreta. “Estaba trabajando” describe toda la mañana. “Adjunté un PDF y pulsé Guardar” señala un paso reproducible. Si el error apareció al encender, indico si el apagado anterior fue normal o si hubo un corte.

No intento rellenar los huecos con seguridad falsa. Si no recuerdo qué ocurrió, escribo “no lo sé”. Una duda reconocida es más útil que una secuencia inventada que lleve a probar otra cosa.

Define el alcance

Pregunto qué funciona y qué no. Si solo falla una página, lo anoto. Si ninguna aplicación tiene conexión, la escala es distinta. Si el problema afecta a una cuenta pero otra entra en el mismo equipo, esa comparación también importa.

Pruebo únicamente contrastes seguros: otra página, otra ventana del mismo navegador o un segundo archivo conocido. No instalo programas, no desactivo protecciones y no restablezco el equipo para llegar a la llamada con “más información”.

Cuando otra persona usa el mismo servicio, puedo preguntar si ve el fallo, pero no le pido que comparta credenciales ni documentos. “También ocurre en otro equipo” es una pista. Acceder con una cuenta ajena crea un problema nuevo.

Apunta versiones sin perderte en ellas

El nombre de la aplicación y su versión ayudan a saber si la interfaz o el comportamiento han cambiado. En el sistema operativo, anoto la edición y la versión que muestra el apartado Acerca de. No hace falta copiar veinte líneas de información del sistema.

Si hay un dispositivo implicado, incluyo el modelo visible y cómo está conectado: cable, Bluetooth o Wi-Fi. No leo números de serie en voz alta si no son necesarios. El soporte puede pedirlos más tarde por un canal adecuado.

También indico el navegador cuando el fallo ocurre en una web. Decir “Firefox actualizado esta mañana” aporta más que “Internet”. Navegador y conexión no son la misma cosa.

Separa cambios recientes de intentos posteriores

Hago dos listas cortas. En la primera van cambios anteriores al fallo: una actualización, un cable nuevo, una contraseña modificada o una extensión instalada. En la segunda van pruebas que hice después: recargar, reiniciar o abrir una ventana privada.

Esta separación evita presentar una solución intentada como posible causa. También permite al soporte no repetir pasos que ya hicimos. Anoto el resultado de cada prueba, no solo su nombre. “Reinicié y funcionó diez minutos” cuenta una historia distinta de “reinicié y siguió igual”.

Si cambié varios ajustes a la vez, lo digo. No intento ordenar a posteriori algo que no pude observar. La siguiente prueba deberá modificar una sola cosa.

Ten a mano, pero no compartas de entrada

Preparo el número de cliente o la referencia del servicio, si existe. Mantengo las contraseñas, códigos de verificación y claves de recuperación fuera de la conversación. Nadie necesita que le dicte una contraseña para ayudarme a cambiar un ajuste.

Si la llamada requiere control remoto, confirmo que he contactado con el canal oficial y leo qué herramienta se va a usar. Cierro documentos privados antes de compartir la pantalla. También pregunto cómo terminar la sesión remota cuando acabemos.

La nota puede incluir una captura, pero revisada. Las pestañas, notificaciones y rutas personales no aportan nada. El mensaje y el área de la aplicación suelen bastar.

Una ficha de seis líneas

Mi plantilla final es esta:

1. Mensaje y código exactos.
2. Hora aproximada.
3. Acción inmediatamente anterior.
4. Qué funciona y qué no.
5. Aplicación, sistema y conexión implicados.
6. Cambios recientes y pruebas ya realizadas.

Con esa ficha no resuelvo el fallo antes de llamar. Hago algo más sencillo: conservo el orden. La persona de soporte puede preguntar mejor y yo puedo responder sin adivinar. Cuando el problema termine, la misma nota servirá para reconocerlo si vuelve a aparecer.