NexTool Solutions

Asignar cada ticket al técnico correcto parece trivial, pero en mesas de servicio reales esa decisión manual se convierte en un cuello de botella: alguien tiene que leer la cola, entender la categoría y despachar - y mientras tanto el reloj del SLA ya está corriendo. El módulo Smart Assign de NexTool automatiza ese paso por categoría, aplicando balanceo de carga o rotación secuencial entre los técnicos del grupo responsable en el instante en que se crea el ticket.

El problema

Una operación sin asignación automática siempre tiene un único punto de decisión: alguien abre la cola de tickets recién creados, lee categoría y asunto y decide a quién enviarlos. Ese papel suele recaer en el coordinador o en el analista con más experiencia - justo la persona que menos quieres atrapada en un triaje repetitivo.

El efecto práctico aparece de dos formas. Primero, la cola crece en horas pico porque nadie ha tomado el ticket todavía; existe, está abierto, pero sigue sin responsable mientras corre el plazo. Segundo, la distribución queda desigual: un técnico acumula quince tickets y otro tiene tres, no por competencia sino por quién estaba mirando la pantalla en ese momento. Ambos escenarios erosionan el SLA y la percepción de calidad del usuario.

Smart Assign elimina ese intermediario. En cuanto se crea el ticket, el módulo evalúa las reglas configuradas y define el responsable antes incluso de que un humano abra la cola. El triaje deja de depender de quién está de guardia frente a la pantalla.

Cómo funciona Smart Assign

El módulo actúa en el hook de creación de tickets de GLPI: los tickets que ya existen no se redistribuyen. La distribución se activa por categoría, el técnico sale del grupo responsable de la categoría y el modo de distribución, elegido en la pestaña Funcionalidades del módulo, vale para todo el entorno:

• Distribución por categoría - en cada categoría ITIL, la pestaña Smart Assign activa o desactiva la distribución y muestra el grupo responsable, los técnicos elegibles y el criterio de elección. Ideal para equipos especializados, donde cada área (infraestructura, ERP, redes) tiene su propio grupo.
• Técnicos del grupo responsable - participan los técnicos activos del grupo responsable de la categoría, con la opción de dejar fuera a los gerentes del grupo; quién recibe lo decide uno de los dos modos siguientes.
• Modo balanceo (menos tickets) - el ticket va al técnico del grupo con el menor número de tickets abiertos en ese momento. Iguala la carga real, no la teórica.
• Modo rotación (secuencial) - los tickets se distribuyen en orden, un técnico tras otro, sin importar la carga. Útil cuando todos tienen capacidad equivalente y el volumen no es el criterio.
• Adaptación automática - cuando alguien entra o sale del grupo, la rotación y el balanceo se ajustan solos, sin reconfiguración manual.
• Registro dedicado - cada decisión queda guardada en la base de datos y aparece en la pestaña Registros del módulo, con el motivo cuando el ticket no se distribuye, lo que aporta trazabilidad para auditoría de proceso y para investigar reclamos de "por qué me llegó este ticket".

Smart Assign frente a las reglas de negocio nativas

GLPI ya resuelve parte de esto con las Reglas de negocio para tickets (Configuración > Reglas). Pueden asignar por criterios como la categoría, pero de forma estática: siempre apuntan al mismo destino. La tabla siguiente muestra dónde termina cada enfoque:

Cómo activarlo

1. Instala el plugin NexTool en GLPI.
2. Ve a Configuración > NexTool > Módulos.
3. Activa el módulo Smart Assign.
4. En la pestaña Funcionalidades del módulo, elige el modo de distribución (balanceo o rotación), que vale para todo el entorno, y cómo se cuenta la carga (por grupo o por categoría). Después, en cada categoría ITIL, activa la distribución en la pestaña Smart Assign y revisa el grupo responsable.
5. Abre un ticket de prueba en la categoría configurada y confirma el técnico asignado en el propio ticket y en la pestaña Registros del módulo.

Lo que aprendimos operándolo

En las operaciones de clientes que sostenemos, el patrón que más se rompe no es la falta de una regla - es la "regla que apunta a una persona". El cliente crea una regla de negocio nativa que envía toda la categoría "Redes" al técnico X. Funciona durante meses, hasta que el técnico X se va de vacaciones: los tickets se le siguen asignando, quedan parados y el SLA se incumple en silencio porque la cola "tenía responsable". El error común es confundir tener dueño con estar atendido. Por eso, en grupos con más de tres técnicos, migramos esas reglas estáticas al modo balanceo de Smart Assign: en lugar de un nombre fijo, el ticket cae en quien tiene menos carga en ese minuto, y quien se va de vacaciones deja de recibir en cuanto se le quita del grupo responsable o se le desactiva en GLPI. Un detalle que solo aparece en la operación: el balanceo cuenta tickets abiertos, no los cerrados en el día, así que un técnico que resuelve rápido vuelve a recibir pronto - así se iguala la carga real, no la teórica.

El mismo conteo que usa el módulo para decidir el destino se puede reproducir en la base de datos para auditar la distribución. Esta consulta lista los tickets abiertos por técnico asignado, exactamente el número que el modo balanceo minimiza cuando la carga se cuenta por grupo, la opción por defecto:

SELECT u.name AS tecnico, COUNT(t.id) AS tickets_abiertos
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_users u ON u.id = tu.users_id
WHERE t.status IN (1,2,3,4)   -- nuevo, en curso, planificado, pendiente
  AND t.is_deleted = 0
GROUP BY u.id
ORDER BY tickets_abiertos DESC;

Y cada decisión queda registrada en la pestaña Registros del módulo, en la cuadrícula estándar de GLPI, con filtro por nivel, evento, ticket y técnico: a quién se asignó el ticket y, cuando no se asignó, el motivo (categoría inactiva, categoría sin grupo responsable o grupo sin técnico elegible). Eso acorta mucho la investigación de "por qué me llegó este ticket".

Para quién es (y cuándo no usarlo)

Smart Assign aporta valor claro en:

• Equipos con tres o más técnicos donde la distribución desigual es recurrente.
• Mesas de servicio con picos de volumen donde el coordinador se vuelve un cuello de botella de triaje.
• Entornos con categorías bien definidas y equipos especializados por área.
• Operaciones que deben demostrar, en una auditoría, cómo se distribuyeron los tickets.

Cuándo no vale la pena: en equipos de uno o dos técnicos la ganancia es marginal - el reparto manual no cuesta nada. Y cuando la asignación depende de un contexto sensible (cliente VIP, un especialista concreto para un sistema crítico), ese enrutamiento fino sigue siendo mejor en las reglas de negocio nativas; en ese caso usa Smart Assign para el volumen común y reserva las reglas nativas para las excepciones, en lugar de apilar ambas decisiones sobre el mismo ticket.

Compatibilidad

• GLPI: 10.x y 11.x
• Plan: FREE
• Plugin: NexTool 6.10.1+
• PHP: 8.0+

Próximo paso

Smart Assign forma parte de NexTool, un plugin modular para GLPI. Conoce los demás módulos o habla con el equipo para una demostración en tu entorno.

Revisado por el equipo de NexTool Solutions.