Una persona reporta que no puede entrar al sistema; otra pide instalar una aplicación y alguien más señala que una impresora compartida dejó de funcionar. Si todas las solicitudes llegan por mensajes, llamadas y correos sin un registro común, el equipo de TI puede perder contexto o no saber qué atender primero. La gestión de tickets de soporte TI comienza por registrar cada solicitud, entender qué tipo de ayuda requiere y asignar un responsable. Un flujo claro no promete que cada caso se resolverá automáticamente: sirve para que el equipo pueda encontrarlo, priorizarlo y dar seguimiento con información suficiente.
Define qué entra como ticket
Antes de crear categorías, explica qué solicitudes debe recibir el canal de soporte y cuáles tienen otra vía. Algunos ejemplos de rutina pueden ser dificultades con una aplicación aprobada, problemas con un periférico o preguntas sobre una herramienta interna. Un incidente de seguridad, una pérdida de acceso urgente o una sospecha de exposición de datos puede requerir un procedimiento especializado; no lo trates como un ticket cotidiano ni permitas que una regla automática cambie permisos o responda por cuenta propia.
Un ticket necesita un identificador, fecha de recepción, persona o área solicitante, descripción, sistema afectado y canal de contacto autorizado. Pide solo la información necesaria para entender el caso. Evita guardar contraseñas, datos personales sensibles o capturas con información ajena a la solicitud. Si la persona no sabe cómo describir el problema, el formulario puede ofrecer opciones sencillas o permitir una explicación libre.
Crea categorías que ayuden a decidir
Una categoría es útil cuando cambia quién debe revisar la solicitud o qué proceso se activa. Separa, por ejemplo, petición de servicio, consulta y falla reportada si esas diferencias ayudan a organizar el trabajo. Para cada tipo, define una descripción y un responsable inicial. Demasiadas categorías confunden; una lista demasiado amplia tampoco permite ver patrones. Revisa las solicitudes reales y ajusta los nombres cuando el equipo no pueda elegir entre opciones sin preguntar.
Atlassian describe en Jira Service Management los tickets, categorías de trabajo y tipos de solicitud como formas de organizar requerimientos dentro de su herramienta. ServiceTonic también explica registro, clasificación, prioridad, asignación y seguimiento en el ciclo de vida de un ticket. Son referencias de proveedores sobre sus propios productos y prácticas, no evidencia de demanda dominicana ni funciones confirmadas de Jarvis. Fuentes: https://www.atlassian.com/es/itsm/service-request-management/it-ticketing-system y https://www.servicetonic.com/es/ayuda/gestion-de-tickets-ti/.
Prioriza con criterios transparentes
La prioridad debe reflejar el efecto del problema y la urgencia que el negocio haya definido. Una solicitud que afecta a muchas personas o detiene una tarea crítica puede necesitar atención antes que una petición de conveniencia. Documenta qué significan los niveles, quién puede cambiar una prioridad y cómo se escala un caso sin respuesta. No copies plazos de ejemplo de un proveedor como compromisos de tu empresa; los objetivos de servicio deben corresponder a la capacidad real del equipo.
Si los datos son insuficientes, pide aclaración en vez de deducir la prioridad por el tono del mensaje. Un formulario podría preguntar cuántas personas están afectadas, desde cuándo ocurre y si existe una alternativa aprobada. Una persona responsable decide la prioridad en los casos ambiguos o de alto impacto. Mantén separadas las decisiones técnicas que puedan modificar sistemas, accesos o información.
Asigna, registra avances y cierra
Define reglas simples para dirigir cada categoría a una bandeja o responsable inicial. Asignar no significa que el caso esté resuelto; el ticket debe mostrar quién lo tiene, qué paso espera y cuándo se revisará. Anota cambios relevantes, comunica al solicitante que el caso fue recibido y explica cuando se necesita más información. Al cerrar, registra una resolución entendible y confirma si el problema quedó atendido. Si vuelve a ocurrir, conserva el historial necesario para que el equipo pueda investigarlo.
Con una herramienta de tickets configurada, algunas tareas repetitivas podrían automatizarse, como asignar una solicitud de impresora a una cola apropiada o avisar a un responsable de un caso próximo a vencer. Antes de activar reglas, prueba que la categoría sea correcta y que exista una vía de corrección. No automatices cambios de acceso, ejecución de instrucciones técnicas, decisiones de seguridad ni cierres de casos que nadie haya verificado. Las herramientas y permisos de cada organización determinan qué integración es posible; este artículo no atribuye una función de ticketing a Jarvis.
Empieza con un flujo pequeño
Elige tres o cuatro tipos de solicitudes frecuentes y documenta para cada uno qué campos hacen falta, quién revisa y cómo se define el siguiente paso. Prueba el flujo con ejemplos internos: descripción incompleta, caso que afecta a varias personas, solicitud dirigida al área equivocada y posible incidencia de seguridad que debe escalarse. Comprueba que la persona pueda corregir una categoría, que el ticket conserve su historial y que ninguna automatización ejecute acciones que excedan el propósito del canal.
Revisa periódicamente los casos cerrados con el equipo. Si una categoría se usa poco, está mal definida o agrupa asuntos distintos, ajústala. Si hay solicitudes que no deberían pasar por el sistema de rutina, describe claramente dónde se reportan. El paso práctico para esta semana es registrar cinco solicitudes internas recientes y comprobar si otra persona puede entender su estado y responsable sin buscar en conversaciones dispersas. Un buen enrutamiento organiza el trabajo; el juicio técnico y la responsabilidad siguen en manos del equipo.