Un help desk se queda corto cuando el equipo deja de saber cuántas solicitudes hay abiertas, cuáles pasaron el plazo y de quién es la responsabilidad. Las señales aparecen antes que la crisis: reaperturas, escalamientos informales por chat y reportes que se arman a mano todos los meses.
La mayoría de los equipos de TI no decide cambiar de help desk un día concreto: llega a esa pregunta por acumulación. Primero se vuelve habitual consultar a una persona para saber cómo va un caso. Después aparecen los reportes armados a mano, las respuestas por chat y los casos que nadie recuerda haber recibido. Cuando por fin se discute si hace falta otra herramienta, el equipo ya lleva meses compensando con esfuerzo personal lo que el sistema no resuelve.
Esta guía ordena esos síntomas en siete señales, explica qué números conviene mirar antes de decidir y separa lo que se resuelve con proceso de lo que realmente exige una herramienta. Es un autodiagnóstico: la idea es recorrerlo con los casos reales del equipo, no leer una definición.
Las siete señales, una por una
La tabla siguiente describe cada señal, qué la causa normalmente y qué conviene hacer primero. Casi siempre el primer paso es de proceso, no de tecnología: ordenar la entrada, las colas y los responsables antes de tocar cualquier herramienta.
| Señal | Qué la causa normalmente | Qué hacer primero |
|---|---|---|
| 1. Nadie sabe cuántos casos hay abiertos | Solicitudes repartidas entre correo, chat y llamadas, sin un lugar único donde contarlas. | Definir un canal único de entrada, contar una vez todo lo abierto y, desde ahí, registrar cada caso nuevo. |
| 2. Casos que pasan el plazo sin que nadie lo note | Plazos no definidos, o definidos pero no medidos; alertas que dependen de que alguien revise. | Fijar plazos de respuesta y resolución para las categorías de mayor volumen y hacer visible lo que vence primero. |
| 3. Reaperturas frecuentes | Cierres sin confirmar con el usuario, casos resueltos sin atacar la causa e información incompleta al abrir. | Pedir confirmación antes de cerrar, registrar la solución aplicada y revisar los motivos de reapertura de un mes. |
| 4. Escalamientos informales por chat | Falta de reglas de escalamiento: el nivel correcto se encuentra conociendo a la persona adecuada. | Escribir quién atiende qué y cuándo se escala, y dejar el escalamiento registrado en el caso, no en el chat. |
| 5. Reportes armados a mano todos los meses | Datos dispersos en hojas y correos, con categorías que cada persona escribe distinto. | Acordar un reporte mínimo (abiertos, cerrados, tiempo promedio y plazos cumplidos) alimentado desde un único registro. |
| 6. Solicitudes que llegan por fuera del canal oficial | El canal oficial es más lento o incómodo que escribirle directamente al técnico. | Medir qué porcentaje llega por fuera y reducir la fricción del canal antes de prohibir los demás. |
| 7. Casos sin responsable claro | Colas sin dueño y reasignaciones que ocurren solo cuando el usuario insiste. | Asignar un responsable por cola y una regla simple para cuando nadie toma el caso. |
Conviene leer la tabla con una idea en mente: una señal aislada suele ser un ajuste de proceso, mientras que varias a la vez, sobre todo las que tienen que ver con trazabilidad, indican un problema de estructura. Si el equipo reconoce las señales 1, 2 y 5 al mismo tiempo, lo más probable es que nadie tenga una visión confiable de la operación.
En la práctica, estas señales se ven así. Un caso llega por correo a un técnico, se discute por chat y se resuelve por teléfono: tres canales y ningún registro, de modo que cuando el usuario vuelve a preguntar nadie puede reconstruir qué se hizo. A fin de mes, alguien combina dos planillas y un buzón para armar el reporte, y dos personas obtienen cifras distintas con los mismos datos. Una persona se va de vacaciones y con ella se va el único mapa de a quién escalar cada tipo de caso.
Estas señales aparecen antes que la crisis porque son costos que se absorben en silencio. Una reapertura consume tiempo que no figura en ningún reporte; un escalamiento por chat funciona hasta el día en que la persona adecuada está de vacaciones; un reporte armado a mano es confiable solo mientras quien lo arma recuerda cada ajuste. Ninguno de estos costos provoca una caída visible, y por eso se acumulan hasta que la operación depende del esfuerzo de unas pocas personas.
Qué mirar en los números antes de decidir
Antes de comparar herramientas, conviene medir la operación actual. Cuatro números alcanzan para saber si el problema es de proceso, de herramienta o de ambos:
- Backlog: los casos abiertos al cierre de cada semana. Lo que importa no es la cifra sino la tendencia: un backlog que crece mes a mes indica que entra más trabajo del que el proceso logra cerrar.
- Reaperturas: la proporción de casos cerrados que vuelven a abrirse. Una proporción alta suele indicar cierres apresurados o falta de información al abrir el caso.
- Tiempo de primera respuesta: desde que llega la solicitud hasta que alguien responde con contenido útil. Conviene mirar la mediana y también los casos más lentos, porque son los que generan reclamos.
- Porcentaje de casos fuera del canal oficial: las solicitudes que llegan por correo directo, chat o llamada sobre el total. Es el número que más revela cuánto del trabajo real queda fuera del sistema.
No existe un valor universal que separe lo bueno de lo malo. Lo útil es comparar cada número contra el propio historial de varios meses y observar la dirección. Y hay una conclusión que ya vale por sí sola: si estos cuatro números no pueden obtenerse sin armar planillas a mano, el equipo está frente a la primera señal de la tabla.
Qué se resuelve con proceso y qué exige herramienta
Antes de cambiar de herramienta conviene separar los dos tipos de problema, porque mezclarlos lleva a decisiones caras. Cambiar de sistema sin ordenar el proceso traslada el desorden a una plataforma nueva; ordenar el proceso sin una herramienta que lo sostenga funciona un tiempo y después se erosiona.
Se resuelve con proceso: un canal único de entrada, colas por tipo de solicitud, prioridades y plazos acordados, un responsable por cola y la confirmación del usuario antes de cerrar. Nada de esto requiere comprar software, y todo se puede empezar la semana próxima.
Exige herramienta: un registro único con historial, alertas de vencimiento, escalamiento automático, reportes que no se armen a mano, y un portal donde el usuario vea el estado de su caso. Estas funciones no se sostienen con disciplina individual: dependen de que el sistema las haga por defecto. Para ver cómo se resuelven estas funciones en una plataforma concreta, conozca OTRS con Aufiero.
Hay además una tentación frecuente: responder a la sobrecarga sumando personas. Sumar personas a un proceso desordenado multiplica el desorden. Primero el canal y las colas; después, si la carga lo justifica, el equipo.
Cómo evaluar sin frenar la operación
Evaluar un cambio no requiere detener el servicio ni lanzar un proyecto largo. Una secuencia razonable, que cada paso produce un resultado visible, es la siguiente:
- 1. Medir durante 30 días. Obtener los cuatro números de la sección anterior, aunque sea con esfuerzo manual. Es la línea de base contra la cual se juzgará cualquier mejora.
- 2. Ordenar una cola piloto. Elegir una sola área o cola, definir su canal de entrada, su responsable y sus prioridades. Empezar por una cola y un plazo simple, y ampliar después.
- 3. Medir otra vez. Comparar los cuatro números de la cola piloto contra la línea de base. Si el proceso solo mejora la situación, la herramienta puede esperar; si la mejora se estanca por falta de registro, alertas o reportes, la señal es otra.
- 4. Evaluar herramientas con criterios y una demostración. Los criterios de evaluación del Post 2 sirven como guía para conducir la demostración con casos reales del equipo. Conviene llevar tres casos del último mes: uno que se reabrió, uno que venció el plazo y uno que llegó por fuera del canal, y pedir que se muestre cómo los trataría la herramienta. Esa prueba dice más que cualquier lista de funciones.
- 5. Decidir con datos. La decisión deja de ser una opinión y pasa a apoyarse en lo que se midió: qué se resolvió con proceso y qué sigue pendiente.
Aufiero Informática es distribuidor oficial de OTRS para América Latina, con contratos locales y soporte en portugués y español. La plataforma actual funciona como SaaS, administrada o instalada en infraestructura propia, de modo que la decisión sobre dónde corre queda en manos de la organización. Para ubicar al equipo en una escala de madurez y decidir por dónde empezar, Aufiero ofrece un checklist de madurez.
Descarga el checklist de madurez de Aufiero →
Preguntas frecuentes sobre help desk
¿Qué es un help desk?
Es el punto de atención que resuelve incidentes y solicitudes puntuales de los usuarios de TI.
¿Cuándo un help desk deja de alcanzar?
Cuando se pierde la trazabilidad: nadie sabe cuántos casos hay abiertos ni cuáles pasaron el plazo.
¿La solución siempre es cambiar de herramienta?
No. Buena parte se resuelve definiendo colas, prioridades y un canal único de entrada.
¿Cómo se mide la sobrecarga?
Por backlog, reaperturas, tiempo de primera respuesta y porcentaje de casos fuera del canal oficial.
¿Conviene sumar personas o cambiar el proceso?
Sumar personas a un proceso desordenado multiplica el desorden. Primero el canal y las colas.
Aufiero Informática es distribuidor oficial de OTRS en Latinoamérica.
