NexTool Solutions

La maggior parte dei Service Desk opera in modalità reattiva: aspetta che il ticket arrivi e corre a risolverlo. L'imbuto di assistenza ribalta questa logica - ogni livello filtra la domanda prima che raggiunga il tecnico. In GLPI l'imbuto non è un pulsante da accendere: è un insieme di categorie, regole di business, base di conoscenza e cron da misurare e regolare. Questa guida mostra come costruire ogni livello con ciò che GLPI offre già, e le insidie che abbiamo visto far crollare interi imbuti nella manutenzione di ambienti dei clienti.

Prima di costruire l'imbuto, misuri da dove arriva il volume

L'errore più comune è costruire l'imbuto al contrario: scrivere decine di articoli e moduli generici sperando che riducano i ticket. In manutenzione facciamo l'opposto - prima scoprire quali categorie concentrano il volume, perché è lì che ogni livello rende davvero. La query seguente, eseguita con un utente in sola lettura, elenca le categorie che generano più domanda negli ultimi 90 giorni e separa incidente da richiesta, la distinzione che decide se la domanda va al self-service o al L1:

-- Top categorie per volume (ultimi 90 giorni): dove i livelli di
-- prevenzione e self-service rendono di più. Usare un utente in sola lettura.
-- type: 1 = incidente, 2 = richiesta
SELECT
    COALESCE(c.completename, '(senza categoria)') 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;

Ne escono due letture. Le categorie di richiesta ripetitiva (reset password, concessione accessi, installazione standard) sono candidate al self-service e all'automazione: l'utente non dovrebbe aver bisogno di un tecnico. Le categorie di incidente ad alto volume indicano guasti ricorrenti che il livello di prevenzione dovrebbe intercettare prima che l'utente se ne accorga. E se "(senza categoria)" compare in cima, il problema è a monte dell'imbuto: la triage è allentata e nessuna regola può instradare ciò che non è stato classificato.

La matrice decisionale: ogni domanda nel suo livello

Un imbuto non è una gerarchia di persone, è instradamento della domanda. Ogni tipo di domanda ha un livello giusto e un meccanismo nativo di GLPI che lo sostiene. La matrice seguente è il punto di partenza che usiamo nel progettare l'imbuto di un cliente:

Livello 1 - Prevenzione: il ticket che nasce dal monitoraggio

L'obiettivo di questo livello è il ticket che il team (o il sistema stesso) apre prima che l'utente noti il problema. In pratica:

• Il monitoraggio crea il ticket: Zabbix, GLPI Agent o un altro collector genera un ticket via e-mail (collector) o API quando si supera una soglia - disco al 90%, servizio fermo, certificato in scadenza. Il ticket arriva già categorizzato e nel gruppo infra.
• Manutenzione programmata comunicata: prima di una finestra, un annuncio nel portale e una notifica evitano la valanga di "è giù?".
• Correzione della causa radice: gli incidenti che si ripetono diventano un Problema (Problem) in GLPI, trattato una volta invece di N ticket identici.

Il guadagno è misurabile: il tasso di prevenzione è la percentuale di incidenti la cui prima registrazione è arrivata dal monitoraggio, non dall'utente. L'integrazione di Zabbix con GLPI è la via più diretta a questo livello.

Livello 2 - Self-service: pubblicare non è lo stesso che comparire

Qui si nasconde l'insidia che più spesso abbiamo visto uccidere il livello self-service: il team scrive decine di articoli e ciononostante il portale self-service non mostra nulla all'utente. In GLPI un articolo compare nella FAQ pubblica solo quando coincidono tre condizioni:

1. l'articolo è pubblicato (con una data di inizio validità, non in bozza);
2. è contrassegnato come visibile nella FAQ (il campo is_faq);
3. ha un destinatario che include il profilo self-service (o "tutti") - senza destinatario, l'articolo è visibile solo a chi lo ha creato.

Ne manca una delle tre e l'articolo esiste nel database ma è invisibile a chi ne ha bisogno. Aggiunga la visibilità della categoria: una categoria non contrassegnata come visibile nell'helpdesk non compare nel modulo di apertura, quindi l'utente non arriva nemmeno a servirsi da solo lì. Oltre agli articoli, questo livello include moduli guidati (reset password, richieste standardizzate) che risolvono o instradano senza intervento. Inizi la base di conoscenza dalle categorie che l'SQL sopra ha messo in cima, non dal manuale del prodotto dalla A alla Z.

Livello 3 - Risoluzione: instradamento per regola, non per e-mail

Ciò che non è stato prevenuto né autogestito deve raggiungere in fretta chi lo risolve - e arrivare nel posto giusto. Il motore qui sono le regole di business dei ticket (RuleTicket): assegnano gruppo, categoria, priorità e SLA in base a criteri (categoria, origine, parola nel titolo, richiedente). L'instradamento per regola è verificabile e riproducibile; l'instradamento per "inoltra l'e-mail a Tizio" non scala e sparisce quando Tizio va in ferie. La query seguente elenca le regole dei ticket attive nell'ordine in cui GLPI le esegue:

-- Regole di business del ticket (RuleTicket) attive, in ordine di esecuzione.
-- GLPI elabora per `ranking`; un'azione "interrompi elaborazione" su una
-- regola precedente impedisce alle successive di essere eseguite. Usare un utente in sola lettura.
SELECT ranking, name, `match` AS operador_criterios, is_active
FROM glpi_rules
WHERE sub_type = 'RuleTicket'
  AND is_active = 1
ORDER BY ranking;

L'ordine (colonna ranking) conta perché un'azione "interrompi elaborazione" ferma le regole successive. L'errore comune è creare una nuova regola in fondo alla coda aspettandosi che regoli la priorità, senza accorgersi che una regola precedente, con "interrompi elaborazione" attivo, ha già chiuso l'instradamento - la nuova non viene mai eseguita. I livelli L1/L2/L3 sono gruppi; l'escalation tra loro è regola più SLA per priorità, non una decisione manuale caso per caso.

L'errore che fa crollare qualsiasi imbuto: l'automazione che non scatta mai

Può costruire i tre livelli con cura e ciononostante non far accadere nulla da solo. Escalation dello SLA, invio di notifiche, chiusura automatica dei ticket risolti, avvisi - tutto questo in GLPI dipende dalle Azioni automatiche (CronTask), e vengono eseguite in modo affidabile solo quando un cron esterno del sistema operativo chiama GLPI. Nella modalità predefinita "GLPI" (attivazione tramite navigazione web), le azioni girano in modo irregolare, dipendono da qualcuno che apre l'interfaccia e si bloccano sotto carico. Il sintomo classico per cui ci chiamano: "lo SLA non fa escalation", "la notifica non arriva", "il ticket non si chiude da solo" - e la causa è quasi sempre la stessa. La riga seguente lo risolve (regoli il percorso alla radice del Suo GLPI e l'utente PHP):

# GLPI - azione automatica ESTERNA, ogni 1 minuto, come utente PHP.
# Senza questo, SLA/escalation, notifiche e chiusura automatica NON vengono eseguiti.
# Regola il percorso alla radice del tuo GLPI (GLPI 10 e 11 usano front/cron.php).
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Poi, in Configurazione > Azioni automatiche, cambi la modalità delle attività da "GLPI" a "CLI". Senza questo passaggio, buona parte dell'imbuto è decorativa.

Dal campo: l'imbuto che esisteva solo sulla carta

Assumendo la manutenzione di un ambiente già in produzione, abbiamo trovato lo scenario più comune di tutti: l'imbuto era disegnato sulla slide ma non nel sistema. La base di conoscenza aveva più di cento articoli - tutti salvati come bozza, nessuno contrassegnato come FAQ né con destinatario, così il portale self-service risultava vuoto per l'utente. Le regole di assegnazione esistevano, ma la terza aveva "interrompi elaborazione" attivo e inghiottiva metà dei ticket nel gruppo sbagliato. E il cron esterno non era mai stato configurato, quindi lo SLA non faceva escalation e la chiusura automatica era ferma - il backlog si gonfiava di ticket risolti che nessuno confermava. Abbiamo eseguito l'SQL di volume per categoria prima di toccare qualsiasi cosa: reset password e VPN pesavano per buona parte del totale. Abbiamo pubblicato e contrassegnato come FAQ una mezza dozzina di articoli di quelle due categorie, corretto l'ordine delle regole e attivato il cron esterno. In poche settimane il volume di quelle categorie è calato in modo visibile nello stesso report - non perché il problema sia sparito, ma perché ha smesso di diventare un ticket. L'imbuto non era nuovo; semplicemente non era mai uscito dalla carta.

Costruire l'imbuto in GLPI riguarda meno i plugin e più l'ordine: misurare il volume, instradare per regola, pubblicare davvero il self-service e assicurarsi che l'automazione scatti. La manutenzione GLPI di NexTool include esattamente questo disegno - dalla matrice delle categorie alle regole e al cron - e il monitoraggio mensile che mostra ogni livello ridurre la domanda che arriva al tecnico.

Revisionato dal team NexTool Solutions.