Soporte de IT Hecho Bien: Una Guía Práctica de Campo

La mayoría del trabajo de soporte de IT se juzga por velocidad, pero la velocidad sin método solo mueve el mismo problema a otro lado. Un ticket cerrado en cinco minutos que se reabre en tres días cuesta más que uno que toma veinte minutos y realmente se soluciona. Esta guía cubre los hábitos que separan a alguien que cierra tickets de alguien que resuelve problemas.

Comienza con una ingesta real, no una suposición

Antes de tocar una máquina, pide al usuario que describa el problema con sus propias palabras, luego haz tres preguntas de seguimiento: cuándo comenzó, qué cambió recientemente, y sucede cada vez o intermitentemente. "Mi internet es lento" podría significar resolución DNS, un canal Wi-Fi saturado, una NIC defectuosa, o un navegador con cuarenta pestañas abiertas. Anota el texto de error exacto si hay uno. Las capturas de pantalla superan a las descripciones cada vez — pide una antes de pedir al usuario que intente algo.

Resiste la tentación de saltar directo a "¿ya intentaste reiniciar?" Funciona lo suficientemente a menudo para que la gente lo use por defecto, pero si omites la ingesta te perderás patrones. Si tres personas en el mismo switch reportan la misma lentitud en la misma hora, ese es un ticket diferente que una laptop con un driver defectuoso.

Reproduce antes de arreglar

Si no puedes reproducir un problema, no puedes confirmar que lo arreglaste. Pide al usuario que te guíe por los pasos exactos en una pantalla compartida, o hazlo tú mismo en su máquina si las herramientas remotas lo permiten. Revisa ipconfig /all en Windows o ip a en Linux para sanidad básica de red, busca en Event Viewer (eventvwr.msc) errores de aplicación y sistema alrededor del tiempo reportado, y revisa journalctl -xe --since "1 hour ago" en máquinas Linux para la misma ventana.

Para bloqueos de aplicación, obtén el número de compilación exacto y la versión del OS. "Se bloqueó" no te dice nada; "Outlook 16.0.17726 se bloquea al abrir una invitación de calendario con un adjunto .ics" te dice dónde buscar. Verifica contra problemas conocidos en las notas de lanzamiento del proveedor antes de asumir que es local.

Triage por impacto, no por quién grita más fuerte

Un único usuario bloqueado de email es un inconveniente. Un servidor de archivos compartido inalcanzable para cuarenta personas es una interrupción. Crea una escala de severidad simple — algo como P1 para interrupciones que afectan múltiples usuarios o sistemas críticos, P2 para bloqueadores de un solo usuario, P3 para degradado pero funcional, P4 para solicitudes cosméticas o de conveniencia — y aplícala consistentemente, incluso bajo presión de un gerente que quiere lo suyo primero.

Documenta la decisión de severidad en el ticket mismo. Esto te protege más tarde cuando alguien pregunta por qué su P3 estuvo esperando dos días mientras manejabas tres P1s.

Arregla la causa raíz, no el síntoma

Reinicia un servicio que sigue fallando compra tiempo, no una solución. Si un print spooler muere diariamente, revisa Get-WinEvent -LogName Application -MaxEvents 50 para el error actual antes de reiniciarlo de nuevo. Si la contraseña de un usuario sigue expirando inesperadamente, revisa la política de grupo aplicada a su OU en lugar de solo reiniciarla y seguir adelante.

Mantén un registro personal de arreglos recurrentes. Si te encuentras escribiendo el mismo comando PowerShell o el mismo arreglo de registro tres veces, eso es una señal de que pertenece en un script o un runbook documentado, no en tu cabeza.

Documenta como si alguien más lo fuera a leer

Cada resolución de ticket debe responder: cuál fue la causa actual, cuál fue el arreglo, y qué verificarías primero si esto sucede de nuevo. "Arreglado" como nota de resolución es inútil para el próximo técnico, incluyendo tú mismo en seis meses sin memoria de este ticket.

Una buena nota de resolución se ve así: "Causa raíz: scope DHCP en VLAN 20 agotado, nuevos dispositivos obtuvieron direcciones APIPA. Arreglo: extendido scope de /24 a /23, reservación para impresora añadida. Verifica: revisa conteo de leases DHCP mensualmente, umbral de alerta establecido en 90%." Esa tercera oración es la que la mayoría de técnicos omiten, y es la que previene el ticket repetido.

Escalada con contexto, no solo un envío

Cuando un ticket va a tier 2 o a un proveedor, incluye qué ya descartaste. "Verificado cableado, intercambiado puerto, confirmado config VLAN, aún sin luz de enlace" le ahorra a la próxima persona rehacer tus primeros veinte minutos. Las escaladas vagas como "el usuario dice que está roto, por favor avísame" solo mueven el retraso en lugar de eliminarlo.

Cierra el circuito con el usuario

Dile al usuario qué estaba mal en lenguaje simple, no solo "arreglado." Las personas confían más en el soporte cuando entienden qué sucedió, y reduce que la misma persona presente el mismo ticket el próximo mes porque no se da cuenta de que está conectado.

Si quieres profundizar en el lado técnico de cualquiera de esto — fundamentos de redes, registros de eventos de Windows, o escribir tus propias herramientas de diagnóstico — Korra Studio tiene segmentos sobre Networking, Systems, y Scripting que vale la pena trabajar a continuación.