Todo equipo de soporte de IT quiere resolver más solicitudes sin sumar más agentes. Una de las formas más efectivas de lograrlo es la desviación de tickets (ticket deflection): ayudar a los empleados a encontrar respuestas o completar tareas comunes antes de que generen un ticket de soporte.
Bien implementada, la desviación de tickets reduce el volumen de tickets sin sacrificar la experiencia del empleado. Los usuarios obtienen respuestas más rápido, los agentes dedican menos tiempo a trabajo repetitivo, y la mesa de ayuda puede concentrarse en las solicitudes que requieren experiencia humana. El desafío está en construir un sistema que la gente realmente use.
En esta guía aprenderás qué es la desviación de tickets, cómo funciona, qué estrategias producen los mejores resultados y cómo medir su impacto. También te mostraremos cómo implementar la desviación de tickets con InvGate Service Management combinando soporte con IA, una base de conocimiento y capacidades de autoservicio.
Puntos clave
- La desviación de tickets reduce la cantidad de tickets que llegan a un agente al resolver los problemas mediante autoservicio antes de que se creen.
- La tasa de desviación se calcula como: (interacciones desviadas / interacciones potenciales totales) × 100.
- La base de conocimiento, el portal de autoservicio y los agentes virtuales (chatbots) son los tres mecanismos principales de desviación en una plataforma de ITSM.
- Una tasa de desviación alta basada en la fricción (usuarios que abandonan sin resolver) es peor que una tasa baja: la calidad de la medición importa.
¿Qué es la desviación de tickets en ITSM?
La desviación de tickets (también llamada derivación de tickets o reducción de incidencias) es el proceso de resolver una solicitud o consulta mediante recursos de autoservicio antes de que se cree formalmente un ticket en la mesa de servicio. El usuario encuentra una respuesta, completa una acción o recibe ayuda de un agente automatizado, y el ticket nunca llega a existir. Sin intervención de un agente, sin ingreso a la cola, sin tiempo de gestión.
Esa distinción es importante. La desviación de tickets no es lo mismo que cerrar tickets más rápido o lograr una alta resolución en el primer contacto (FCR, por sus siglas en inglés). La FCR mide qué tan rápido se resuelve un ticket existente sin escalarlo. La desviación ocurre antes, río arriba, antes de que el ticket se registre. Confundir ambos conceptos lleva a programas que optimizan lo incorrecto.
Una nota sobre la desviación por fricción. No toda interacción que termina sin un ticket es una desviación exitosa. Si el usuario busca en la base de conocimiento, no encuentra nada útil y abandona el autoservicio para crear un ticket por otro canal (correo electrónico, teléfono, una visita presencial a IT), eso no es desviación. Eso es fricción. El volumen de tickets puede parecer más bajo en un canal mientras aumenta en otro, y la métrica de desviación se ve mejor de lo que realmente es. Cómo mides importa tanto como qué mides.
Cómo funciona la desviación de tickets: los mecanismos principales
En ITSM, la desviación puede realizarse por varios mecanismos de autoservicio. Algunos de los más comunes incluyen:
- Base de conocimiento: el usuario busca una respuesta antes de abrir un ticket, encuentra un artículo relevante y resuelve el problema de forma independiente.
- Portal de autoservicio: el usuario encuentra el servicio que necesita, completa un formulario o sigue un flujo guiado para resolver una solicitud sin intervención del service desk. En plataformas más avanzadas, el catálogo de servicios y la automatización ejecutan la solicitud automáticamente.
- Agentes virtuales o chatbots: una interfaz conversacional que ayuda a responder preguntas, recomendar artículos, recopilar información o iniciar solicitudes. Según la plataforma, puede funcionar con reglas, IA o una combinación de ambas.
- Automatización de solicitudes comunes: algunas plataformas ejecutan tareas repetitivas sin intervención humana una vez que el usuario inicia la solicitud, como restablecer una contraseña, aprovisionar acceso o crear una cuenta. En esos casos, el ticket puede no crearse o cerrarse automáticamente tras completar el flujo.
- Sugerencias contextuales o búsqueda inteligente: mientras el usuario escribe una consulta o completa un formulario, la plataforma recomienda artículos, respuestas o servicios relacionados que pueden resolver el problema antes de enviar la solicitud.
Por qué la desviación de tickets importa para los equipos de IT (el costo de no desviar)
La mayoría de las colas de IT tienen un problema estructural: una parte significativa de los tickets entrantes son solicitudes repetitivas y de baja complejidad que podrían resolverse sin un agente. Los restablecimientos de contraseña por sí solos pueden representar cerca del 30% de los tickets de IT en las organizaciones. Cuando esas solicitudes llegan a la cola (triaje manual, asignación manual, resolución manual) consumen tiempo que debería destinarse a trabajo de mayor prioridad.
Las consecuencias operativas se acumulan rápido.
-
Agotamiento de los agentes. Los técnicos senior dedican su día a solicitudes de Nivel 1 que un artículo de la base de conocimiento o un flujo del catálogo podrían gestionar. El trabajo no es desafiante, pero es constante. Con el tiempo, ese desequilibrio contribuye a la desmotivación y la rotación en equipos que ya operan con recursos ajustados.
-
Costo por ticket. Los tickets gestionados manualmente tienen un costo real: estimaciones de analistas de la industria lo ubican entre $22 y más de $100, dependiendo de la complejidad y el tiempo de gestión. A volumen, esa cifra se vuelve difícil de ignorar.
-
Backlog permanente. Cuando la cola se llena de ruido de bajo valor, los incidentes de alta prioridad quedan enterrados. El triaje de tickets se vuelve más difícil de ejecutar porque todo compite por la misma atención limitada. Los tiempos de respuesta para problemas críticos se ven afectados, no porque al equipo le falte capacidad, sino porque la señal se pierde en el volumen.
Nada de esto se resuelve contratando más agentes. Se resuelve evitando que los tickets que no deberían existir entren a la cola.
Cómo medir la tasa de desviación de tickets
La tasa de desviación de tickets es el porcentaje de interacciones de soporte potenciales que se resolvieron sin crear un ticket. Es el indicador más directo de qué tan efectivamente está funcionando el autoservicio.
Fórmula:
Tasa de Desviación (%) = (Interacciones Desviadas ÷ Interacciones Potenciales Totales) × 100
Definiendo las variables:
- Interacciones desviadas: sesiones de autoservicio, conversaciones con el VSA o búsquedas en la base de conocimiento que terminaron sin que se creara un ticket. El usuario resolvió el problema, o al menos no envió una solicitud.
- Interacciones potenciales totales: todas las interacciones de soporte iniciadas, hayan sido desviadas o hayan resultado en un ticket. Interacciones desviadas + tickets creados = interacciones potenciales totales.
Advertencias de medición: sin ellas, la métrica puede ser engañosa.
Doble conteo. La misma solicitud puede registrarse en dos canales; por ejemplo, un usuario prueba el VSA, se rinde y envía un correo electrónico. Si ambas interacciones se cuentan, el denominador se infla y la tasa cae artificialmente. Define la atribución de canales con claridad antes de medir.
Desviación por fricción. Como se mencionó antes: el usuario abandona el autoservicio sin resolver y crea un ticket por otro canal. La sesión de autoservicio se cuenta como "desviada" en algunos sistemas de seguimiento, pero no se entregó ningún valor. Una medición limpia distingue entre sesiones que terminaron con una resolución confirmada y sesiones que simplemente no generaron un ticket en ese canal.
Desviación vacía. La base de conocimiento muestra un artículo que parece responder la pregunta, pero el artículo está desactualizado. El usuario lo lee, no encuentra la respuesta que necesita y crea un ticket de todos modos. La sesión de búsqueda puede seguir contándose como desviada, dependiendo de cómo esté configurado el seguimiento.
Referencias (a nivel de industria, no atribuibles a InvGate):
- Las organizaciones sin una estrategia activa de desviación suelen registrar tasas cercanas al 23%.
- Los equipos con una base de conocimiento conectada y un VSA reportan tasas entre el 40% y el 60%.
- Los programas maduros con desviación asistida por IA pueden superar el 70% en categorías de solicitudes específicas.
Estos números son útiles como referencia, no como objetivos. La meta correcta no es la tasa de desviación más alta posible, sino la tasa más alta en la que las desviaciones representan resoluciones reales. Una tasa del 70% donde los usuarios resuelven sus propios problemas es un resultado sólido. Una tasa del 70% donde los usuarios abandonan el autoservicio y vuelven a abrir tickets por otros canales no genera ningún beneficio operativo y erosiona activamente la confianza en la función de soporte.
Cómo mejorar la desviación de tickets con InvGate Service Management
Paso 1 — Alimenta la base de conocimiento a partir de las resoluciones de tickets, no de un proyecto de redacción separado
Cuando un agente cierra un ticket, InvGate Service Management puede generar un primer borrador de un artículo de conocimiento a partir de esa resolución en menos de 30 segundos, utilizando los detalles de la solicitud y los pasos de resolución del ticket como material fuente. El agente revisa y edita antes de publicar: la IA produce un punto de partida, no un artículo terminado.
Por separado, Knowledge Discovery analiza los tickets cerrados de forma recurrente y extrae unidades más pequeñas llamadas Knowledge Snippets: patrones y soluciones extraídos del historial de tickets que no requieren que nadie escriba un artículo completo. Cada Snippet comienza invisible y pasa por una cola de moderación; un revisor decide si es suficientemente preciso para potenciar las Solution Recommendations orientadas a agentes, las respuestas del Virtual Service Agent orientadas al usuario final, o ambas.
Esta es la base de un ciclo KCS (Knowledge-Centered Service): la base de conocimiento crece como subproducto de hacer soporte, no como un proyecto de documentación separado que compite con el tiempo de los agentes. El efecto práctico es que los tipos de tickets más comunes, los que generan el mayor volumen, son también los que tienen más probabilidades de acumular buena cobertura en la base de conocimiento con el tiempo.
Paso 2 — Construye el Catálogo de Servicios según categorías de solicitud que los usuarios reconocen
El catálogo de servicios de InvGate permite a los equipos organizar las categorías según cómo los usuarios experimentan sus necesidades, no según cómo IT las clasifica internamente. Cada categoría puede incluir los campos de datos específicos que requiere ese tipo de solicitud, la lógica de aprobación y las reglas de enrutamiento, configurables sin código.
Cuando el catálogo refleja el lenguaje y la intención del usuario, la adopción del portal aumenta y la creación de tickets sin estructura disminuye. Los usuarios encuentran el camino correcto rápidamente, envían información completa en el primer intento, y el flujo de trabajo se ejecuta automáticamente. Cuando el catálogo refleja el organigrama interno de IT en lugar de esto, los usuarios se confunden, elegien categorías incorrectas y crean tickets sin estructura que requieren retrabajo manual en cada paso.
Reestructurar el catálogo suele ser el cambio de mayor impacto que un equipo puede hacer para mejorar la tasa de desviación, y no requiere implementación técnica.
Paso 3 — Implementa el Agente Virtual de Servicio
El Agente Virtual de Servicio de InvGate opera en los tres canales desde una única configuración, sin necesidad de una configuración separada por canal. Responde utilizando los artículos aprobados de la Base de Conocimiento y los Snippets descritos en el Paso 1, por lo que su calidad es una función directa de qué tan bien mantenida está esa capa, no una capacidad de IA independiente.
Cuando no puede resolver la solicitud, la escalación lleva consigo el contexto completo de la conversación (qué se preguntó, qué ya se intentó) hacia el ticket, de modo que el agente no parte de un ticket en blanco y el usuario no repite su explicación. Para los equipos que ya trabajan en Microsoft Teams, esto también significa que el soporte ocurre sin cambiar de contexto hacia un portal separado.
Paso 4 — Da seguimiento a las métricas de desviación
InvGate Service Management incluye más de 150 métricas incorporadas, dashboards configurables y reportes OLAP, sin módulos adicionales. Para la desviación específicamente, las señales relevantes son:
- Artículos de la base de conocimiento que resolvieron consultas de usuarios (y cuáles no generaron un ticket de seguimiento)
- Tasa de adopción del portal por categoría de servicio (qué categorías se están usando, cuáles se están evitando)
- Volumen de interacciones del VSA y el porcentaje que terminó sin creación de ticket
Estas señales identifican dónde la base de conocimiento tiene vacíos, qué categorías del catálogo tienen fricción alta y qué tipos de solicitud siguen generando volumen de tickets a pesar de que el autoservicio está disponible. Esos datos alimentan la siguiente iteración: actualizar la base de conocimiento, reestructurar categorías del catálogo, ajustar los flujos de respuesta del VSA.
Errores comunes que perjudican los programas de desviación de tickets
- Base de conocimiento desconectada del portal. Los artículos que los usuarios no pueden encontrar en el momento de la intención, cuando están a punto de abrir un ticket, no desvían nada. La integración con el flujo de creación de tickets no es negociable.
- Catálogo de servicios organizado según la taxonomía de IT, no el lenguaje del usuario. Cuando los usuarios no pueden identificar la categoría correcta, se saltan el catálogo y abren tickets sin estructura. La adopción colapsa y la oportunidad de desviación desaparece.
- Métricas de desviación infladas por fricción. Contar sesiones de autoservicio abandonadas como desviaciones exitosas produce un número que se ve bien pero no dice nada útil. Mide resoluciones confirmadas, no sesiones que simplemente no generaron un ticket en un solo canal.
- VSA operando sobre una base de conocimiento desactualizada. Un agente conversacional que da respuestas incorrectas entrena a los usuarios para evitar el autoservicio. El daño a la adopción tarda meses en repararse. El mantenimiento de la base de conocimiento no es opcional una vez que se implementa un VSA.
- Sin ciclo de mejora a partir de los tickets escalados. Cada ticket que llega a un agente es una señal: algo en el autoservicio no funcionó. Los equipos que no usan los tickets escalados para identificar vacíos en la base de conocimiento y en el catálogo están perdiendo la principal fuente de información para mejorar la desviación con el tiempo.
Preguntas frecuentes
¿Cómo se calcula la tasa de desviación de tickets?
Tasa de Desviación (%) = (Interacciones Desviadas ÷ Interacciones Potenciales Totales) × 100. Las interacciones desviadas son sesiones de autoservicio, búsquedas en la base de conocimiento o conversaciones con el VSA que terminaron sin que se creara un ticket. Las interacciones potenciales totales son la suma de las interacciones desviadas y los tickets enviados. El resultado es el porcentaje de demanda de soporte que se gestionó sin intervención de un agente.
¿Qué es una buena tasa de desviación de tickets?
Depende de la madurez del programa. Las organizaciones sin una estrategia activa de desviación suelen registrar tasas cercanas al 23%. Los equipos con una base de conocimiento conectada y un Virtual Service Agent reportan tasas entre el 40% y el 60%. Los programas maduros asistidos por IA pueden superar el 70% en categorías específicas. La meta no es el número más alto posible, sino la tasa más alta en la que las desviaciones representan resoluciones reales. Una tasa basada en usuarios que abandonan el autoservicio sin resolver no genera ningún valor real, sin importar qué tan alto se vea el porcentaje.
¿Cuál es la diferencia entre la desviación de tickets y la resolución en el primer contacto?
La resolución en el primer contacto (FCR) mide si un ticket que ya existe se resuelve sin escalarlo a otro equipo o nivel. La desviación de tickets ocurre antes de que el ticket se cree: el usuario resuelve el problema mediante autoservicio y ningún ticket ingresa a la cola. Ambas métricas importan, pero miden cosas distintas: la FCR refleja qué tan eficientemente el equipo de soporte gestiona la demanda, la desviación refleja cuánta demanda nunca llega al equipo.
¿La desviación de tickets puede perjudicar la calidad del servicio?
Sí, si se basa en fricción en lugar de resolución. Cuando los usuarios abandonan el autoservicio porque no pueden encontrar una respuesta y se ven forzados a crear un ticket por otro canal, las métricas de desviación pueden verse saludables mientras la experiencia real del usuario se deteriora. Una base de conocimiento desactualizada, un catálogo de servicios confuso o un VSA con cobertura pobre pueden producir "desviaciones" que en realidad son interacciones fallidas. La desviación de tickets efectiva mejora la experiencia del usuario; la desviación por abandono la erosiona y hace que la métrica sea poco confiable.
