NexTool Solutions

L'IA non sostituirà l'analista di supporto, ma l'analista che la usa bene sostituirà chi la ignora. In GLPI questo non è uno slogan: è un flusso che si configura, si misura e si regola. Nella manutenzione di service desk GLPI di clienti, abbiamo visto l'IA fallire in due modi - appiccicata senza misurazione (nessuno sa se ha aiutato) e usata con il pilota automatico (un suggerimento errato incollato direttamente nella soluzione). Questa guida mostra come rendere operativa l'IA nel quotidiano del ticket, con le query e la configurazione che eseguiamo sul campo.

Inizi misurando dove l'IA rende, non dove impressiona

L'errore comune è puntare l'IA sul ticket complesso e raro - quello che brilla nella demo - invece del ripetitivo ad alto volume, dove restituisce davvero tempo. Prima di collegare qualsiasi cosa, scopra dove si trova il volume e quanto costa. Questa query elenca le categorie con più ticket negli ultimi 90 giorni e il tempo medio fino alla risoluzione, i candidati a maggior ritorno per risposta assistita da IA, articolo di base di conoscenza e triage automatico:

-- Categorie a maggior volume e tempo medio di risoluzione (90 giorni).
-- solve_delay_stat e in secondi; /3600 converte in ore.
SELECT c.completename            AS categoria,
       COUNT(t.id)               AS ticket,
       ROUND(AVG(t.solve_delay_stat)/3600, 1) AS ore_per_risolvere
FROM glpi_tickets t
JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
  AND t.is_deleted = 0
  AND t.solvedate IS NOT NULL
GROUP BY t.itilcategories_id, c.completename
HAVING ticket >= 10
ORDER BY ticket DESC
LIMIT 15;

La cima di quell'elenco è la Sua mappa: sono gli argomenti dove un riassunto automatico, una bozza di risposta o un articolo della KB rendono di più. Una categoria ad alto volume e tempo di risoluzione elevato è dove l'IA come assistente allevia di più la coda; una categoria a basso volume e alta complessità resta lavoro umano - e provare ad automatizzarla è uno spreco.

Triage deterministico prima, IA dopo

La confusione più costosa che vediamo è chiedere all'IA ciò che le regole di business di GLPI già fanno meglio. Classificare la categoria, definire la priorità e assegnare il gruppo in base a un pattern su oggetto, richiedente o entità è compito delle regole di business dei ticket (RuleTicket): deterministico, verificabile e riproducibile. L'IA generativa entra in ciò che è sfumato e non deve essere riproducibile: riassumere un thread di 50 interazioni, abbozzare una risposta a partire dallo storico, individuare il tono del richiedente. Mescolare i due ruoli è all'origine di report di SLA che nessuno sa spiegare. La matrice che usiamo per decidere chi esegue cosa:

Non chiami mai l'IA in modo sincrono nel ciclo del ticket

Questa è la trappola che ci è costata più ore in manutenzione. Quando l'integrazione IA - o un qualsiasi webhook esterno - lancia una chiamata HTTP dentro l'hook di creazione o aggiornamento del ticket in modo sincrono, il salvataggio dell'analista resta bloccato ad aspettare la risposta dell'API esterna. Abbiamo visto il pulsante di salvataggio bloccarsi da 30 a 60 secondi perché un hook faceva la richiesta sul momento, e l'analista giurava che "GLPI è lento". L'arricchimento tramite IA deve essere asincrono: si mette in coda e si elabora fuori dal request, tramite il cron esterno di GLPI. E quel cron deve essere reale (modalità CLI/esterna), non l'innesco tramite visita di pagina:

# Cron esterno di GLPI (MODE_EXTERNAL) - esegue i task in coda,
# incluse notifiche e arricchimento asincrono.
# Esegui come utente del server web (www-data / apache), ogni minuto:
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

L'errore comune è lasciare i task automatici in modalità interna, innescata da chi carica una pagina. Senza visita, non gira nulla; sotto carico, un task lungo blocca lo stato e gli altri non vengono eseguiti. Imposti i task di GLPI in modalità CLI e garantisca il crontab qui sopra - altrimenti l'automazione "a volte funziona", che equivale a non funzionare.

Ciò che resta lavoro umano

L'IA abbozza; l'umano decide e firma. Diagnosticare un problema con variabili non documentate, negoziare con un utente frustrato, il giudizio se escalare o aggirare, il contesto politico che fissa la priorità reale - niente di tutto questo spetta all'IA. E c'è un dettaglio che solo chi opera coglie: il campo soluzione del ticket alimenta la base di conoscenza, che a sua volta alimenta il suggerimento successivo dell'IA. Incollare una risposta generata senza rivederla non è solo un errore isolato - entra nel patrimonio e torna amplificato nel suggerimento seguente. L'analista dell'era dell'IA è il revisore che impedisce a quel ciclo di degradare la qualità del servizio.

Le competenze tecniche che ora contano

1. Prompt con il contesto del ticket: citare l'oggetto, lo storico e l'errore esatto dà una risposta utile; un prompt generico dà testo generico.
2. Leggere e regolare RuleTicket: capire il triage deterministico che sostiene lo SLA vale più di qualsiasi trucco di IA.
3. Misurare con SQL: le query qui sopra dimostrano, con i numeri, dove l'IA ha reso e dove ha solo creato lavoro.
4. Curare la base di conoscenza: il suggerimento dell'IA è buono quanto la KB che lo alimenta; un articolo obsoleto diventa un suggerimento errato.
5. Rivedere prima di incollare: è Lei a firmare la soluzione, non l'IA. È la frontiera che definisce l'analista che aggiunge valore.

Vuole mettere l'IA al lavoro dentro GLPI in modo misurabile, con il modulo AI Assist che integra OpenAI GPT e Google Gemini nel ticket stesso? Scopra il servizio di manutenzione GLPI di NexTool e faccia rendere l'IA senza rompere ciò che già funziona.

Revisionato dal team NexTool Solutions.