Cómo gestionan los tickets las empresas de diseño de sistemas informáticos y servicios de TI

Cuando un cliente informa de una integración averiada, un compañero no puede acceder a un sistema o hay que revisar un cambio planificado, el ticket es el registro compartido que permite al equipo entender la solicitud, saber quién se ocupa de la siguiente acción y conservar lo ocurrido. Esta guía ofrece un método práctico para empresas de diseño de sistemas informáticos y servicios de TI, sin suponer que todas usan el mismo centro de servicio o modelo contractual.

1. En qué consiste el trabajo, paso a paso

La gestión de tickets no es solo una cola. Es una secuencia de decisiones que convierte una solicitud poco clara en trabajo controlado. Las etapas exactas dependen del cliente, el contrato y el servicio, pero una base útil puede ser la siguiente:

1. Recibir y confirmar. Aceptar solicitudes por los canales acordados, crear un único registro e informar a quien la envió de los siguientes pasos. Si llega por chat o correo, trasladar los datos necesarios al sistema de registro; la conversación no debe ser el único registro.
2. Registrar el contexto necesario. Anotar el servicio o cliente afectado, quién solicita ayuda y un medio seguro de contacto, qué esperaba, qué ocurrió, cuándo empezó, qué impacto observa y qué comprobaciones se hicieron. Solicitar registros o capturas solo por canales aprobados y eliminar credenciales o datos personales innecesarios.
3. Clasificar y evaluar el impacto. Distinguir una interrupción del servicio de una consulta, una solicitud de acceso, un cambio planificado o una tarea de proyecto. Aplicar las definiciones de urgencia e impacto acordadas con el cliente. Un mensaje alarmante no es automáticamente un incidente de seguridad; un aviso discreto también puede requerir una escalada inmediata.
4. Asignar una persona responsable. Asignar el trabajo a un equipo o función concreta que pueda dar el siguiente paso. Una cola no es una persona responsable. Si debe actuar otro equipo, registrar la transferencia, el motivo y quién debe responder.
5. Investigar y comunicar. Mantener una cronología breve de observaciones, comprobaciones, decisiones y cambios. Informar de lo que se sabe, lo que aún no está claro y cuándo recibirá otra actualización. No prometer un plazo de resolución si el acuerdo de servicio aplicable no lo respalda.
6. Resolver, verificar y cerrar. Describir qué cambió y cómo se verificó el resultado. Pedir confirmación a quien solicitó ayuda cuando el proceso lo contemple. Cerrar solo cuando se cumpla la condición acordada y facilitar la reapertura si el problema vuelve.
7. Aprender del trabajo recurrente. Vincular tickets relacionados cuando compartan causa o servicio. Convertir las respuestas repetibles en conocimiento revisado y derivar los defectos o riesgos subyacentes al proceso adecuado de problemas, cambios o seguridad.

Este es un modelo operativo, no una afirmación de que todas las empresas sigan una norma universal. Ante un incidente que interrumpa el servicio, hay que distinguir la gestión habitual de solicitudes de la respuesta a incidentes. la guía de Atlassian sobre respuesta a incidentes describe un ciclo de vida específico y funciones de respuesta claras; para incidentes de ciberseguridad, utilice el plan aprobado de la organización y fuentes autorizadas vigentes como NIST SP 800-61, revisión 3.

Para profundizar en dos aspectos relacionados del proceso, consulte nuestras guías sobre el enrutamiento de tickets y los portales de autoservicio.

2. Dónde falla la gestión de tickets en una empresa real de diseño de sistemas informáticos y servicios de TI

Imaginemos una empresa ficticia de diseño de sistemas que presta soporte a la aplicación financiera de un cliente. Un lunes por la mañana, varias personas informan de que un flujo de trabajo falla. Un mensaje llega por correo, otro por el chat del proyecto y un tercero por el portal de servicio. Al principio, el equipo los trata como consultas independientes. La persona responsable de la entrega está reunida con el cliente, el ingeniero que conoce la integración trabaja en otra versión y quien informó del problema no sabe si alguien se ha hecho cargo.

El síntoma técnico puede ser sencillo. El problema operativo es que los registros no indican si los avisos están relacionados, quién coordina la respuesta, qué compromisos con el cliente se aplican o si hay que detener el cambio subyacente. Una empresa que entrega proyectos, ofrece soporte gestionado y trabaja con acuerdos específicos puede tener varias vías de trabajo válidas; un único campo genérico de «prioridad» rara vez recoge todo el contexto necesario para elegir entre ellas.

Entre los fallos habituales están:

• Las solicitudes están dispersas. El chat, el correo, los tableros de proyecto y las mesas de servicio guardan partes distintas de la historia. Se duplica trabajo o se supone que otra persona ya respondió.
• Falta el contexto del cliente o del servicio. Sin volver a preguntar, el equipo no puede saber qué entorno, integración o acuerdo de soporte está afectado.
• La prioridad significa cosas distintas para cada persona. La urgencia percibida por el cliente, la gravedad técnica, el impacto comercial y el plazo contractual de respuesta están relacionados, pero no son equivalentes.
• Las transferencias no confirman la aceptación. «Enviado a ingeniería» registra una transferencia, no confirma que un ingeniero haya aceptado la responsabilidad.
• Las actualizaciones se escriben para la cola, no para quien solicita ayuda. La jerga interna puede ser técnicamente correcta, pero deja a la persona afectada sin claridad sobre el estado o los siguientes pasos.
• El cierre solo guarda el mensaje final. Sin el recorrido de diagnóstico y la verificación, el siguiente ingeniero no sabe qué se probó ni si se repite la misma causa.
• Las señales de seguridad se tratan como soporte rutinario. Los avisos de acceso inesperado, credenciales expuestas, actividad sospechosa o posible pérdida de datos deben seguir la vía de seguridad designada, no recibir una respuesta automática de «resuelto».

La solución no es exigir más campos en todas partes. Hay que pedir el contexto mínimo necesario para asignar y actuar, y hacer visibles la persona responsable y la próxima comunicación.

3. Qué automatizar primero y qué no se debe automatizar nunca

Empiece por tareas administrativas repetitivas que sigan reglas claras y puedan corregirse de forma segura. Mantenga a una persona responsable de las decisiones que dependan de un impacto incierto, compromisos con clientes, criterios de seguridad o cambios irreversibles.

Buenos primeros candidatos

• Confirmar la recepción y mostrar la referencia del ticket y la próxima actualización prevista.
• Comprobar los campos obligatorios y pedir un dato concreto cuando falte información.
• Sugerir una categoría o cola según reglas explícitas y revisables, permitiendo que el personal las corrija.
• Detectar posibles duplicados y mostrar registros relacionados para que una persona los confirme.
• Enviar recordatorios cuando un ticket asignado no tenga novedades de su responsable, conforme a las reglas de servicio reales de la empresa.
• Preparar un borrador del estado a partir del historial del ticket para que la persona responsable lo revise antes de enviarlo.

Mantener la decisión en manos de una persona

• No permita que un modelo decida que una solicitud ambigua es inofensiva, de bajo impacto o ajena al acuerdo con el cliente.
• No cierre tickets automáticamente porque quien los envió no haya respondido o porque se haya enviado una respuesta sugerida.
• No ejecute cambios en producción, conceda accesos, desactive controles ni elimine datos basándose únicamente en el texto de un ticket.
• No oculte ni reduzca la prioridad de un posible incidente de seguridad, exposición de datos, problema de seguridad física o sospecha de intrusión.
• No envíe contenido sin revisar que incluya información confidencial del cliente, credenciales o compromisos no respaldados.

Si un ticket parece relacionado con la seguridad, siga el procedimiento aprobado de respuesta a incidentes. La guía de respuesta a incidentes es una referencia para las organizaciones que desarrollan esa capacidad; no sustituye un acuerdo de escalada específico del cliente ni el asesoramiento jurídico.

4. Cómo probar de forma segura con datos anteriores durante dos semanas

Una prueba de dos semanas con datos históricos es una evaluación acotada, no una demostración de que la automatización esté lista para actuar sobre solicitudes reales. Úsela para averiguar si la asistencia propuesta es útil y dónde falla.

1. Elija un caso de uso limitado. Por ejemplo, sugerir una cola de soporte para un único tipo de solicitud. No combine en un experimento el enrutamiento, las decisiones de prioridad, las respuestas a clientes y el cierre automático.
2. Obtenga la aprobación de quien gestiona los datos. Confirme que el equipo puede usar los tickets históricos seleccionados para la evaluación. Respete los contratos con clientes, las reglas de conservación, las políticas internas de privacidad y los requisitos de seguridad.
3. Minimice y proteja la muestra. Elimine credenciales, tokens, datos personales innecesarios y detalles de clientes ajenos a la prueba. Restrinja el acceso, use un entorno aprobado y establezca una fecha de eliminación. Si no puede tratar los registros de forma segura, utilice ejemplos sintéticos.
4. Defina un conjunto de evaluación representativo. Incluya casos habituales, solicitudes incompletas, casos poco comunes pero válidos, duplicados y tickets mal asignados. Añada ejemplos sensibles para la seguridad solo con autorización y protección adecuadas. Base los resultados esperados en las reglas documentadas del equipo.
5. Ejecútelo en modo sombra. Permita que el sistema proponga un resultado sin modificar el ticket histórico, avisar al cliente ni activar acciones. Pida a revisores que comparen cada sugerencia con el resultado documentado.
6. Registre los errores, no solo los promedios. Registre sugerencias de cola equivocadas, señales de escalada no detectadas, suposiciones sin respaldo, exposición de datos sensibles y casos en los que el modelo debería haberse abstenido. Revise las discrepancias con las personas responsables del proceso de servicio.
7. Decida antes de cualquier prueba real. Defina las condiciones de aceptación y parada antes de revisar los resultados. Si la evidencia no es concluyente, mantenga la automatización como apoyo consultivo. Una prueba real requiere autorización aparte, supervisión, un plan de reversión y una persona claramente responsable.

Las dos semanas son el periodo de prueba propuesto para este ejercicio práctico, no un referente del sector ni una garantía de confianza estadística. No publique afirmaciones de rendimiento basadas en una muestra histórica pequeña sin un diseño de medición sólido y una revisión autorizada.

5. Una lista de comprobación para copiar

• Recepción: ¿Existe un único sistema de registro y una vía clara para cada tipo de solicitud?
• Contexto: ¿Puede el equipo identificar al cliente, el servicio, el entorno afectado, el impacto observado y el resultado esperado sin recopilar datos sensibles innecesarios?
• Clasificación: ¿Se distinguen solicitudes, incidentes, cambios, problemas y avisos de seguridad mediante definiciones documentadas?
• Responsabilidad: ¿Hay una persona o equipo responsable de la siguiente acción y cada transferencia confirma su aceptación?
• Comunicación: ¿Sabe quien hizo la solicitud qué está ocurriendo y cuándo llegará la próxima actualización?
• Resolución: ¿El cierre indica qué se hizo y cómo se verificó el resultado?
• Automatización: ¿Cada paso automatizado es reversible, queda registrado, se limita a una regla aprobada y una persona puede anularlo fácilmente?
• Seguridad: ¿Los casos de seguridad, privacidad, acceso, cambios en producción y requisitos específicos del cliente se asignan a una persona identificada?
• Evaluación: ¿Se aprobó y revisó en materia de privacidad la prueba en modo sombra, se comparó con resultados documentados y se definieron condiciones explícitas de parada?
• Aprendizaje: ¿Puede el equipo identificar causas recurrentes y mejorar el proceso sin considerar que el volumen de tickets, por sí solo, sea un indicador de éxito?

En resumen: una buena gestión de tickets deja clara la siguiente acción y quién debe asumirla. Automatice primero las tareas administrativas predecibles; deje el criterio, los compromisos con clientes y las acciones de impacto en manos de personas responsables.

Fuentes y lecturas adicionales

• SP 800-61, rev. 3: recomendaciones de respuesta a incidentes y consideraciones para gestionar riesgos de ciberseguridad: perfil comunitario de CSF 2.0 (NIST; publicada en abril de 2025). Referencia para planificar la respuesta a incidentes de ciberseguridad; se cita para contextualizar la escalada de seguridad, no como norma general para mesas de servicio.
• Respuesta a incidentes (Atlassian). Guía práctica sobre funciones y ciclo de respuesta a incidentes; se utiliza para distinguir las solicitudes de servicio de una respuesta coordinada a incidentes.