El Freshservice Benchmark Report 2025, que analizó más de 187 millones de tickets de soporte técnico abiertos por clientes de la plataforma en 118 países, arrojó un número que a primera vista parece bueno: los equipos de TI resolvieron el 74% de los tickets ya en el primer contacto con el usuario.
El problema es que ese número mide otra cosa. Dice si el ticket se resolvió en el momento, no si esa misma falla va a volver a aparecer la semana siguiente, atendida por otra persona, desde cero, como si fuera la primera vez que alguien la ve.
Esa segunda pregunta es la que decide si la TI de una empresa realmente está resolviendo el problema o solo está empujando el mismo problema hacia adelante, ticket tras ticket. Y es la que cuesta dinero, tiempo del equipo y la paciencia de quien solo quería volver a trabajar: tres cosas que quien aprueba el presupuesto siente mucho antes de que llegue cualquier informe a la mesa.
Ninguna empresa contrata soporte técnico esperando escuchar la misma queja todos los meses. Pero eso es exactamente lo que ocurre cuando el único objetivo de cada atención es cerrar el ticket que está en pantalla, sin mirar el historial de tickets parecidos que llegaron antes.
El costo de no registrar la causa
Todo ticket tiene un costo, incluso cuando parece simple de resolver. Según un relevamiento de la consultora MetricNet, compilado en 2024, atender un ticket en un help desk norteamericano cuesta alrededor de US$22 cuando se resuelve ya en el primer nivel de atención, y supera los US$100 cuando debe escalar a un nivel más especializado, con más tiempo de investigación y personal más caro involucrado. Los números de un help desk latinoamericano no son iguales a los estadounidenses, pero la lógica se repite: cuanto más escala la solución, más cara se vuelve.
Ahora cambie la pregunta: ¿cuánto cuesta cuando la misma falla vuelve seis veces en tres meses? No es el costo de un ticket, es el costo de un ticket multiplicado, sin que nada cambie de una vez a la otra. Es dinero pagado de nuevo por el mismo problema, no por uno nuevo.
Esto solo ocurre porque, en la mayoría de los entornos, el ticket cerrado guarda la palabra "resuelto" y nada más. No guarda qué causó la falla, qué se intentó, ni qué finalmente funcionó. Existe una distinción clásica en el soporte técnico que separa dos cosas que parecen la misma: atender el ticket de hoy e investigar por qué sigue ocurriendo. La primera es rápida y urgente. La segunda exige que alguien lea el historial acumulado y pregunte por qué volvió, y esa segunda etapa suele ser justamente la que falta.
En una empresa pequeña o mediana, esto tiene una cara conocida: la misma computadora se cuelga todos los viernes, el mismo sistema cae después de la rutina de respaldo nocturna, el mismo empleado llama contando la misma historia por cuarta vez, y nadie llegó nunca a preguntar por qué. Cada ticket, por separado, parece pequeño. Sumados, se convierten en la mayor parte del trabajo de la semana.
Por qué apagar el incendio no alcanza
La forma común de manejar la TI en una empresa que no tiene estructura propia es reactiva: se llama a alguien cuando algo se rompe, se resuelve lo que está enfrente, y la rutina sigue hasta que se rompe de nuevo. Nadie está equivocado al trabajar así: es lo único posible sin un proceso detrás, y sin ese proceso, apagar el incendio es realmente la única opción disponible.
El problema es que apagar el incendio de hoy no impide el de mañana, si ambos tienen la misma causa. Una de las técnicas que usan quienes investigan la causa raíz en TI es simplemente estimar, en dinero, cuánto cuesta esa falla cada vez que se repite, y no detenerse en la primera explicación que aparece, preguntando "por qué" más de una vez, hasta llegar a un proceso ausente o mal hecho, y no a una persona o a una casualidad aislada.
Sin ese paso, el soporte técnico se convierte en una carrera para cerrar el ticket, no para resolver el problema. Y cada cambio de técnico empeora la carrera: quien llega ahora no sabe qué intentó su colega la última vez, porque nunca quedó escrito en ningún lado. El usuario cuenta la historia de nuevo. El técnico empieza el diagnóstico de nuevo. Y la falla sigue exactamente donde estaba, solo que ahora ya consumió dos, tres, cuatro rondas de atención.
Lo que tiene que existir en la práctica
Un entorno de TI bien cuidado tiene algunos mecanismos que resuelven exactamente este punto, no como promesa, sino como rutina que se puede verificar.
Ticket registrado con causa y solución. Todo ticket cerrado explica qué causó el problema y qué se hizo para corregirlo, no solo "resuelto". Sin esto, el próximo técnico no tiene de dónde partir.
Alguien mirando el patrón, no solo el ticket aislado. Una persona, o una rutina, revisa periódicamente el historial acumulado de tickets buscando repetición: mismo equipo, mismo usuario, mismo horario, mismo tipo de error.
Acción preventiva para lo que se repite. Cuando una falla aparece varias veces, deja de ser "un ticket más" y se convierte en un ítem para resolver de raíz: cambiar la pieza, ajustar la configuración, capacitar a quien usa el sistema en el día a día.
Un dueño del historial, no varios proveedores. Con cuatro proveedores distintos cuidando piezas separadas del entorno, nadie ve el patrón que atraviesa los tickets de todos ellos.
Inventario actualizado de lo que tiene la empresa. Sin saber qué equipos y sistemas existen y dónde están, es difícil señalar que la falla recurrente siempre está en el mismo servidor o en la misma marca de computadora.
Así es como trabaja Skills IT: todo ticket se registra con causa y solución, y lo que se repite se convierte en acción preventiva, no en un ticket más igual al de la semana pasada.
La ganancia de resolver la causa
La ganancia de cerrar este ciclo es operativa antes que financiera. Menos tickets repetidos significa menos tiempo parado: para el empleado que no trabaja mientras espera, y para el técnico que no rehace el mismo diagnóstico por enésima vez. Queda tiempo de equipo para lo que realmente es nuevo, en lugar de revivir algo que ya debería estar resuelto desde hace meses.
Del lado del presupuesto, la ganancia es previsibilidad. Una empresa que sabe qué fallas se repiten puede decidir, con información concreta, si vale la pena reemplazar un equipo ya desgastado o renegociar un contrato de mantenimiento, en lugar de descubrirlo solo cuando el equipo deja de funcionar del todo, siempre en el peor momento posible.
Esto vale tanto para quien transfiere toda la TI a los servicios gestionados de Skills IT como para quien mantiene un equipo propio y solo necesita refuerzo en puntos específicos: el mecanismo es el mismo, y el registro de la causa es lo que cambia el resultado a fin de mes.
Hay además una ganancia menos comentada: el clima interno. El empleado que ve que la misma falla se toma en serio una vez, y desaparece de verdad, confía más en la TI que aquel que debe abrir un ticket cada mes por el mismo problema y escuchar la misma explicación de siempre.
Una hoja de ruta para empezar
Antes de contratar algo nuevo o de reescribir cualquier proceso, una hoja de ruta simple ayuda a ver dónde está la empresa hoy.
-
Confirme si el ticket cerrado registra el motivo. Pida ver los últimos diez tickets cerrados el mes pasado. ¿Cuántos dicen solo "resuelto" y cuántos explican qué causó el problema y qué lo corrigió?
-
Releve lo que se repite. Pida la lista de tickets organizada por tipo de falla, no por fecha de apertura. Si el mismo ítem aparece varias veces con el mismo equipo o el mismo usuario, eso ya no es un ticket suelto: es un problema.
-
Pregunte quién decide cuándo algo se convierte en acción preventiva. Alguien tiene que tener la responsabilidad de decir "esto ya apareció demasiadas veces, vamos a resolverlo de raíz ahora". Sin esa persona definida, la lista de fallas repetidas solo crece.
-
Pregúntele a su equipo qué problema "siempre vuelve". Si alguien puede responder de memoria, sin consultar nada, ese ya es el primer candidato para convertirse en acción preventiva antes de fin de mes.
