Cómo escribir el ticket de manos remotas perfecto: el formato que los proveedores agradecen

noviembre 10, 2026 6 min de lectura Por Noxtel

Cuando el técnico de manos remotas abre tu ticket mientras estás en guardia, debe saber exactamente qué equipo falló y qué mediciones obtuviste. Si en ese momento no puede saber qué equipo falló, qué mediste y qué esperas, no tiene por dónde empezar: diagnostica desde cero y tú pagas ese tiempo de espera sin saberlo.

Un ticket bien escrito no es un texto largo. Son cinco campos que contestan las cinco preguntas que el técnico ya trae preparadas. Este es el formato exacto, con un ejemplo de cómo se ve mal y otro de cómo se ve bien.

Por qué «el servidor está lento» no es un ticket

«El servidor está lento» no es un síntoma, es una conclusión. El técnico no sabe cuál de tus servidores, ni en qué sala está, ni qué significa lento para tu operación. Cada dato que falta es una pregunta, y cada pregunta es un turno de espera.

El costo más caro no es la espera, es la discusión. Cuando nadie escribió qué se esperaba como resultado, dos personas pueden revisar el trabajo y concluir que se hizo todo. Lo que sigue es un intercambio de correos para acordar si algo quedó bien.

Los 5 campos que debe tener tu ticket

Equipo identificado. Ubicación exacta, modelo y número de serie. Si el técnico tiene que deducir el modelo a partir de la descripción del gabinete, pierde tiempo en el primer paso.

Síntoma observable. Qué pasa, desde cuándo y con qué frecuencia. Escribe mediciones y no adjetivos: «ping de 480 ms contra 8 ms en operación normal» sirve; «va lento» no.

Qué ya se revisó. Lo que tú probaste y con qué resultado. Este campo evita que el técnico repita el camino que tú ya recorriste, que es la causa más común de sentir que nada avanza.

Acción solicitada. Qué esperas que haga, y también qué no esperas. Acotar el alcance evita que una revisión se convierta en mantenimiento que nadie autorizó.

Criterio de cierre. Cómo se sabe que quedó resuelto. Sin esta línea, el ticket se cierra por falta de respuesta en lugar de por solución.

El ticket mal escrito y por qué no avanza

Este es el caso más frecuente. Tiene toda la información, pero nada de ella es accionable:

Título: Problema en servidores Descripción: El servidor está lento, está causando problemas al equipo de ventas. Favor de revisar. Desde hace unos días. Bundle algo.

Falta el equipo, falta la medición, falta el alcance y falta el criterio de cierre. El técnico no puede empezar sin preguntar, y la primera respuesta siempre llega con dudas: eso convierte una revisión de veinte minutos en varias horas de ida y vuelta.

El título también cuenta. «Problema en servidores» no dice qué equipo ni qué falla: obliga a abrir el ticket para entenderlo. «Rackserv-SRV-07: latencia de 480 ms» ya resume equipo y síntoma, y el técnico puede decidir su ruta de entrada.

El ticket bien escrito, con los 5 campos

La misma falla, descrita de forma que se pueda trabajar de inmediato:

Título: Rackserv-SRV-07: latencia de red a 480 ms de forma intermitente Campo 1, equipo: Rackserv-SRV-07, rack A-14, nodo de respaldo. Modelo Supermicro SYS-1029U, serie S5A7K3. Monitor 10.20.4.87. Campo 2, síntoma: Desde el lunes 20 de octubre, la latencia entre este nodo y el switch principal sube a 480 ms de forma intermitente, unas 12 veces por hora. Ocurre sobre todo entre 14:00 y 16:00. El servicio de aplicación sigue arriba. Campo 3, ya se revisó: Reiniciamos el servicio de red del nodo el martes 21 a las 09:30 y la latencia bajó a 9 ms durante dos horas, después volvió a subir. No encontramos caída de energía en la bitácora del UPS. Campo 4, acción solicitada: Revisar el puerto de uplink y el cableado del rack A-14. No reinicien el nodo ni cambien la configuración del switch: estamos midiendo el comportamiento en caliente. Campo 5, criterio de cierre: Cerramos cuando el ping al switch principal se mantenga por debajo de 20 ms durante seis horas, con una foto antes y una foto después, y con la hora en que se hizo el cambio.

La evidencia pesa en ambas direcciones. Una foto del frente del equipo tomada antes del desmontaje y otra al terminar demostrarían dentro de seis meses que el trabajo se hizo, cuando ya nadie recuerde quién lo hizo ni qué se cambió.

Errores comunes que devuelven el ticket

Adjuntar la evidencia al final. La foto de la alerta, la foto del frente del equipo y la captura del monitor van en campos señalados, no pegadas al final sin contexto.

Confundir la causa con el síntoma. «Se quedó sin red» es un diagnóstico, no una observación. Escribe lo que mediste y deja que el técnico determine la causa.

Pedir todo junto. «Revisar por qué anda lento y de paso cambiarlo» mezcla diagnóstico y cambio. Separa en un ticket la investigación y el trabajo autorizado.

Cerrar por cansancio. Sin criterio de cierre escrito, el ticket se marca resuelto porque nadie tiene tiempo de seguirlo.

La plantilla que puedes copiar mañana

Si quieres el formato en una sola línea por campo, aquí está. Sustituye los corchetes y ya no dejarás margen a interpretaciones erróneas en tu proveedor:

Equipo: [nombre o serie, rack y sala, modelo] Síntoma: [qué pasa, desde cuándo, cada cuánto, con qué medición] Revisado: [qué probaste y qué pasó] Solicito: [qué se espera] · [qué no se autoriza] Cierre: [condición medible] + [evidencia antes y después]

La diferencia entre los dos tickets no es de redacción, es de tiempos: uno empieza con una ronda de preguntas, el otro con el técnico entrando a la sala. Escríbelo como si lo fuera a leer alguien que no conoce tu operación.

Antes de mandarlo, reléelo como si fuera ajeno y pregúntate si el técnico sabría qué hacer sin escribirte. Esa es la diferencia entre una intervención que arranca en diez minutos y una que se pasa un turno en preguntas.