NexTool Solutions

La mayoría de los Service Desks funciona en modo reactivo: espera a que llegue el ticket y corre a resolverlo. El embudo de atención invierte esa lógica - cada capa filtra la demanda antes de que llegue al técnico. En GLPI el embudo no es un botón que se enciende: es un arreglo de categorías, reglas de negocio, base de conocimiento y cron que hay que medir y ajustar. Esta guía muestra cómo montar cada capa con lo que GLPI ya trae, y las trampas que hemos visto derribar embudos enteros en el mantenimiento de entornos de clientes.

Antes de montar el embudo, mide de dónde viene el volumen

El error más común es montar el embudo al revés: escribir decenas de artículos y formularios genéricos esperando que reduzcan tickets. En el mantenimiento hacemos lo contrario - primero descubrir qué categorías concentran el volumen, porque ahí es donde cada capa tiene retorno real. La consulta de abajo, ejecutada con un usuario de solo lectura, lista las categorías que más demanda generan en los últimos 90 días y separa incidente de requisición, la distinción que decide si la demanda va al autoservicio o al N1:

-- Top categorías por volumen (últimos 90 días): donde las capas de
-- prevención y autoservicio tienen mayor retorno. Usar usuario de solo lectura.
-- type: 1 = incidente, 2 = requisición
SELECT
    COALESCE(c.completename, '(sin categoría)') AS categoria,
    COUNT(*)        AS chamados,
    SUM(t.type = 1) AS incidentes,
    SUM(t.type = 2) AS requisicoes
FROM glpi_tickets t
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.is_deleted = 0
  AND t.date >= DATE_SUB(CURDATE(), INTERVAL 90 DAY)
GROUP BY t.itilcategories_id
ORDER BY chamados DESC
LIMIT 15;

De ahí salen dos lecturas. Las categorías de requisición repetitiva (restablecimiento de contraseña, alta de acceso, instalación estándar) son candidatas a autoservicio y automatización: el usuario no debería necesitar un técnico. Las categorías de incidente con alto volumen apuntan a fallos recurrentes que la capa de prevención debería captar antes de que el usuario los note. Y si "(sin categoría)" aparece arriba, el problema es anterior al embudo: la clasificación está suelta y ninguna regla puede enrutar lo que no se ha clasificado.

La matriz de decisión: cada demanda en su capa

Un embudo no es una jerarquía de personas, es enrutamiento de demanda. Cada tipo de demanda tiene una capa correcta y un mecanismo nativo de GLPI que la sostiene. La matriz de abajo es el punto de partida que usamos al diseñar el embudo de un cliente:

Capa 1 - Prevención: el ticket que nace de la monitorización

La meta de esta capa es el ticket que el equipo (o el propio sistema) abre antes de que el usuario note el problema. En la práctica:

• La monitorización crea el ticket: Zabbix, GLPI Agent u otro colector dispara un ticket vía correo (collector) o API cuando se cruza un umbral - disco al 90%, servicio caído, certificado por vencer. El ticket llega ya categorizado y en el grupo de infra.
• Mantenimiento programado comunicado: antes de una ventana, un anuncio en el portal y una notificación evitan la avalancha de "¿está caído?".
• Corrección de causa raíz: los incidentes que se repiten se convierten en un Problema (Problem) en GLPI, tratado una vez en lugar de N tickets iguales.

La ganancia es medible: la tasa de prevención es el porcentaje de incidentes cuyo primer registro vino de la monitorización, no del usuario. La integración de Zabbix con GLPI es el camino más directo a esta capa.

Capa 2 - Autoservicio: publicar no es lo mismo que aparecer

Aquí vive la trampa que más hemos visto matar la capa de autoservicio: el equipo escribe decenas de artículos y aun así el portal de autoservicio no le muestra nada al usuario. En GLPI un artículo solo aparece en la FAQ pública cuando coinciden tres condiciones:

1. el artículo está publicado (con fecha de inicio de validez, no en borrador);
2. está marcado como visible en la FAQ (el campo is_faq);
3. tiene público objetivo que incluya el perfil de autoservicio (o "todos") - sin destinatario, el artículo solo es visible para quien lo creó.

Falta una de las tres y el artículo existe en la base pero es invisible para quien lo necesita. Suma a eso la visibilidad de la categoría: una categoría no marcada como visible en el helpdesk no aparece en el formulario de apertura, así que el usuario ni siquiera llega a autoservirse ahí. Además de los artículos, esta capa incluye formularios guiados (restablecer contraseña, solicitudes estandarizadas) que resuelven o enrutan sin intervención. Empieza la base de conocimiento por las categorías que el SQL de arriba señaló en lo alto, no por el manual del producto de la A a la Z.

Capa 3 - Resolución: enrutamiento por regla, no por correo

Lo que no se previno ni se autoatendió debe llegar rápido a quien lo resuelve - y llegar al lugar correcto. El motor aquí son las Reglas de negocio para tickets (RuleTicket): asignan grupo, categoría, prioridad y SLA según criterios (categoría, origen, palabra en el título, solicitante). El enrutamiento por regla es auditable y reproducible; el enrutamiento por "reenvía el correo a fulano" no escala y desaparece cuando fulano se va de vacaciones. La consulta de abajo lista las reglas de ticket activas en el orden en que GLPI las ejecuta:

-- Reglas de negocio de ticket (RuleTicket) activas, en orden de ejecución.
-- GLPI procesa por `ranking`; una acción "detener el procesamiento" en una
-- regla anterior impide que las siguientes se ejecuten. Usar usuario de solo lectura.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
  AND is_active = 1
ORDER BY ranking;

El orden (columna ranking) importa porque una acción de "detener el procesamiento" interrumpe las reglas siguientes. El error común es crear una regla nueva al final de la cola esperando que ajuste la prioridad, sin notar que una regla anterior, con "detener el procesamiento" activado, ya cerró el enrutamiento - la nueva nunca se ejecuta. Los niveles N1/N2/N3 son grupos; el escalado entre ellos es regla más SLA por prioridad, no una decisión manual caso por caso.

El error que derriba cualquier embudo: la automatización que nunca se dispara

Puedes montar las tres capas con esmero y aun así que nada ocurra solo. Escalado de SLA, envío de notificaciones, cierre automático de tickets resueltos, alertas - todo eso en GLPI depende de las Acciones Automáticas (CronTask), y solo se ejecutan de forma fiable cuando hay un cron externo del sistema operativo llamando a GLPI. En el modo por defecto "GLPI" (disparo por la navegación web), las acciones se ejecutan de forma irregular, dependen de que alguien abra la interfaz y se traban bajo carga. El síntoma clásico que nos toca atender: "el SLA no escala", "la notificación no llega", "el ticket no se cierra solo" - y la causa casi siempre es la misma. La línea de abajo lo resuelve (ajusta la ruta a la raíz de tu GLPI y el usuario de PHP):

# GLPI - acción automática EXTERNA, cada 1 minuto, como usuario de PHP.
# Sin esto, SLA/escalado, notificaciones y cierre automático NO se ejecutan.
# Ajusta la ruta a la raíz de tu GLPI (GLPI 10 y 11 usan front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Luego, en Configurar > Acciones automáticas, cambia el modo de las tareas de "GLPI" a "CLI". Sin ese paso, buena parte del embudo es decorativa.

Del mantenimiento: el embudo que existía solo en el papel

Al asumir el mantenimiento de un entorno que ya funcionaba, encontramos el escenario más común de todos: el embudo estaba dibujado en la diapositiva pero no en el sistema. La base de conocimiento tenía más de cien artículos - todos guardados como borrador, ninguno marcado como FAQ ni con público objetivo, así que el portal de autoservicio aparecía vacío para el usuario. Las reglas de asignación existían, pero la tercera tenía "detener el procesamiento" activado y se tragaba la mitad de los tickets en el grupo equivocado. Y el cron externo nunca se había configurado, así que el SLA no escalaba y el cierre automático estaba parado - el backlog se inflaba con tickets resueltos que nadie confirmaba. Ejecutamos el SQL de volumen por categoría antes de tocar nada: restablecer contraseña y VPN sumaban buena parte del total. Publicamos y marcamos como FAQ media docena de artículos de esas dos categorías, corregimos el orden de las reglas y encendimos el cron externo. En pocas semanas el volumen de esas categorías bajó de forma visible en el mismo informe - no porque el problema desapareciera, sino porque dejó de convertirse en ticket. El embudo no era nuevo; simplemente nunca había salido del papel.

Montar el embudo en GLPI es menos sobre plugins y más sobre orden: medir el volumen, enrutar por regla, publicar el autoservicio de verdad y garantizar que la automatización se dispara. El mantenimiento de GLPI de NexTool incluye exactamente este diseño - de la matriz de categorías a las reglas y al cron - y el seguimiento mensual que muestra cada capa reduciendo la demanda que llega al técnico.

Revisado por el equipo de NexTool Solutions.