Casi todos los equipos de soporte tienen alguna forma de asignación automática de tickets. El problema es que en la mayoría de casos se basa en reglas rígidas escritas hace años: si el asunto contiene "factura", va a administración; si entra por este formulario, va al grupo de nivel 1. Funciona hasta que un cliente escribe "no me ha llegado el recibo de la app" y el ticket se pasea entre tres equipos durante dos días.
Este artículo va de cómo se diseña un enrutado que acierta de verdad: qué criterios debe tener en cuenta, cuándo conviene sustituir las reglas por clasificación semántica, cómo se mide la precisión del sistema y qué hay que vigilar para que no se degrade con el tiempo. Es la parte de la automatización de tickets de soporte con IA donde se concentra el retorno, porque un ticket bien asignado a la primera se resuelve en una fracción del tiempo.
El coste real de un enrutado que falla
Cuando un ticket llega al equipo equivocado, no se pierde solo el tiempo de la reasignación. Se pierde el tiempo de lectura de la persona que lo recibe, el de la conversación interna para decidir de quién es, el del cliente esperando y, a menudo, la fiabilidad del propio SLA, porque el reloj sigue corriendo mientras el ticket rebota.
Un indicador sencillo lo resume todo: la tasa de reasignación, es decir, qué porcentaje de tickets cambia de responsable después de la asignación inicial. En equipos que enrutan con reglas antiguas es habitual verla por encima del 20 %. Cada uno de esos tickets cuesta, tirando por lo bajo, entre 10 y 20 minutos adicionales repartidos entre varias personas, además del retraso acumulado para el cliente.
Los seis criterios que debe cruzar una buena asignación
Un enrutado que acierta no decide por una sola variable, sino cruzando varias:
- Materia del ticket. De qué va realmente, más allá de las palabras que use el cliente.
- Competencia del agente. Quién sabe resolver ese tipo de caso, no solo quién está en el grupo.
- Carga de trabajo actual. De poco sirve asignar al mejor especialista si tiene 40 tickets abiertos.
- Prioridad y SLA aplicable. Según el tipo de cliente, el contrato y el impacto declarado.
- Idioma y zona horaria. Crítico en equipos distribuidos o con clientes internacionales.
- Historial del cliente. Si es continuación de un caso anterior, debe volver a quien lo llevaba.
La mayoría de sistemas de reglas cubre bien los criterios dos, tres y cuatro, y falla estrepitosamente en el primero y el sexto. Ahí es donde entra la inteligencia artificial.
¿Reglas o inteligencia artificial para clasificar los tickets?
Las reglas funcionan cuando la señal es explícita y estable: un formulario con un desplegable de categoría, una dirección de correo dedicada, un cliente concreto que siempre va a un equipo. Son transparentes, baratas y auditables, y conviene conservarlas para esos casos. El problema aparece cuando la señal está en el texto libre, que es como escribe la gente de verdad: descripciones ambiguas, varias cuestiones en el mismo mensaje, vocabulario del cliente que no coincide con la taxonomía interna, capturas de pantalla como única explicación. Un clasificador basado en modelos de lenguaje entiende la intención más allá de las palabras exactas, distingue una consulta de facturación disfrazada de problema técnico y puede detectar que un mensaje contiene dos peticiones distintas. La arquitectura que mejor funciona no elige: aplica primero las reglas deterministas, que son rápidas y predecibles, y deja a la IA todo lo que las reglas no resuelven, que en un servicio de soporte típico es la mayor parte del volumen entrante.
Cómo se construye el modelo de asignación
Partir del histórico, no de la teoría
La materia prima está en el propio sistema de tickets: miles de casos ya resueltos con su categoría final y su responsable real. Ese histórico dice cómo se enrutan las cosas en la práctica, que casi nunca coincide con el organigrama. Antes de configurar nada conviene analizarlo para detectar dos cosas: qué categorías se confunden entre sí de forma sistemática y qué agentes acumulan de facto un tipo de caso aunque no figure en su descripción de puesto.
Definir una taxonomía que la gente entienda
Un error frecuente es diseñar 60 categorías porque el sistema lo permite. Cuantas más categorías, más confusión y menos precisión. Es preferible una taxonomía de 10 a 15 tipos claramente diferenciados, con la posibilidad de subcategorizar después, y revisarla cada pocos meses con el propio equipo.
Dejar salidas para la incertidumbre
El sistema debe poder decir "no lo tengo claro". Cuando la confianza de la clasificación está por debajo de un umbral, lo correcto no es forzar una asignación, sino enviar el ticket a una cola de triaje humana. Esos casos son, además, los mejores ejemplos para mejorar el sistema.
¿Cómo se mide si la asignación automática funciona?
Con cuatro métricas y ninguna más. La primera es la tasa de reasignación, que debería bajar de forma visible en las primeras semanas y es el indicador más honesto de si el enrutado acierta. La segunda es el tiempo hasta la primera respuesta útil, que mejora cuando el ticket llega directamente a quien sabe resolverlo. La tercera es la distribución de carga entre agentes, para comprobar que el sistema no está concentrando trabajo en los mismos de siempre. Y la cuarta es el cumplimiento del SLA por tipo de ticket, que es donde se ve el efecto económico. Conviene fijar la línea base de las cuatro antes de tocar nada, porque sin esa medición previa cualquier discusión posterior sobre si el sistema funciona se convierte en una guerra de percepciones. Y conviene revisarlas mensualmente: un modelo de enrutado se degrada cuando cambian los productos, el equipo o el tipo de clientes.
Más allá de la asignación: qué más se automatiza en el mismo flujo
Una vez que el ticket está bien clasificado, el mismo análisis sirve para varias cosas más dentro de la automatización del soporte con IA. Se puede generar un resumen del caso para que el agente no tenga que leer un hilo de quince mensajes. Se pueden adjuntar automáticamente los artículos de la base de conocimiento relevantes. Se puede detectar y responder el subconjunto de tickets que son pura repetición —estado de pedido, restablecer contraseña, horarios, copia de factura— sin intervención humana. Y se puede identificar el tono de urgencia o enfado para elevar la prioridad de casos que, por su redacción educada, pasarían desapercibidos.
El orden recomendable es ese: primero clasificar y enrutar bien, después asistir al agente, y solo al final responder de forma autónoma. Empezar por la respuesta automática sin haber resuelto la clasificación produce el peor resultado posible, que es contestar con seguridad algo equivocado.
Gobierno: quién manda sobre el sistema
Una asignación automática no es un proyecto que se entrega y se olvida. Necesita un responsable interno que revise mensualmente los casos mal enrutados, ajuste la taxonomía cuando aparezcan tipos de caso nuevos y valide los cambios antes de aplicarlos. También necesita que el equipo pueda corregir una asignación con un clic y que esa corrección alimente la mejora del sistema, en lugar de perderse.
Y necesita transparencia: cuando un agente recibe un ticket, debería poder ver por qué se le ha asignado. Un sistema opaco genera desconfianza y, en la práctica, la gente acaba saltándoselo.
En MG Solutions diseñamos e implantamos automatizaciones de soporte integradas con el sistema de tickets que ya usa la empresa, empezando siempre por medir cómo se enruta hoy. Si tu equipo pierde tiempo en reasignaciones y el SLA se te escapa, escríbenos y analizamos tu histórico de tickets.