NexTool Solutions

Un sondaggio di soddisfazione a cui nessuno risponde non produce alcuna decisione. Questa guida mostra come GLPI attiva, memorizza e misura davvero il sondaggio di soddisfazione - da quale colonna proviene ogni impostazione, perché a volte semplicemente non viene inviato, e cosa facciamo nella gestione degli ambienti dei clienti per sollevare il tasso di risposta da terra.

Dove si configura il sondaggio (e perché è per entità)

Al contrario di ciò che molti cercano, il sondaggio di soddisfazione in GLPI non è un interruttore globale: si configura per entità, in Amministrazione > Entità > (selezioni l'entità) > scheda Assistenza. Ogni campo della schermata scrive in una colonna della tabella glpi_entities, e il valore può essere ereditato dall'entità superiore. Conoscere la colonna dietro ogni campo è ciò che permette di diagnosticare via SQL quando l'interfaccia "dice" che è tutto a posto.

Il campo Configurazione con valore -2 (eredita) è la trappola silenziosa: una sotto-entità può sembrare attiva mentre in realtà eredita "nessun sondaggio" dalla radice. Le versioni recenti hanno portato la stessa meccanica ai Cambiamenti, in colonne equivalenti con il suffisso _change.

Il vero innesco: la chiusura + il cron, non la soluzione

Qui sta la causa numero 1 di "il sondaggio non parte". Il sondaggio non nasce quando il ticket è risolto (stato 5, Risolto); nasce quando il ticket è chiuso (stato 6, Chiuso) e, anche allora, solo quando l'attività cron createinquest viene eseguita e sorteggia quel ticket entro la inquest_rate. Due prerequisiti indipendenti:

1. Il ticket deve chiudersi. Se la chiusura automatica è spenta e i tecnici si limitano a "risolvere", i ticket restano Risolto per sempre e non viene generato alcun sondaggio. La chiusura automatica è il campo autoclose_delay dell'entità stessa.
2. Il cron deve girare in modalità esterna. L'attività createinquest genera i sondaggi dei ticket chiusi. In modalità interna viene eseguita solo quando qualcuno carica una pagina - nelle entità a basso traffico può passare giorni senza girare.

È stato esattamente questo il caso in un ambiente che abbiamo preso in carico: il sondaggio era "attivato" da mesi e il database non conteneva una sola risposta. Non era il modello né la percentuale. createinquest era in modalità interna (mode = 1) su un GLPI a basso traffico, quindi il cron praticamente non scattava mai; e, per peggiorare, la chiusura automatica era spenta, quindi quasi nulla raggiungeva lo stato Chiuso. Abbiamo attivato il cron esterno del sistema operativo e regolato autoclose_delay: i sondaggi hanno iniziato a essere generati lo stesso giorno. Da allora, controllare questi due punti è diventato una voce fissa del nostro runbook ogni volta che prendiamo in carico un GLPI.

Il cron esterno è una riga nel crontab del sistema, eseguita con l'utente di PHP:

# /etc/cron.d/glpi - cron esterno di GLPI (utente PHP-FPM)
# 1 esecuzione al minuto; elabora TUTTE le attività in modalità esterna,
# inclusa "createinquest" (generazione dei sondaggi di soddisfazione).
* * * * *  apache  /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

E la diagnosi diretta nel database conferma se l'attività è attiva e quando è stata eseguita l'ultima volta:

-- Stato dell'attività che genera i sondaggi (usare un utente in sola lettura)
-- state: 0=disabilitata 1=in attesa 2=in esecuzione
-- mode:  1=interno (gira al caricamento pagina)  2=esterno (cron del SO)
-- frequency: intervallo in secondi (predefinito 86400 = 1 giorno)
SELECT name, state, mode, frequency,
       lastrun,
       DATE_ADD(lastrun, INTERVAL frequency SECOND) AS prossima_prevista
FROM glpi_crontasks
WHERE name = 'createinquest';

Il modello di notifica

Con il sondaggio generato, è la notifica a invitare l'utente. La personalizzi in Configurazione > Notifiche > Modelli di notifica, nel modello legato all'evento di soddisfazione del Ticket. I tag utili:

• ##ticket.urlsatisfaction## - link diretto e autenticato al sondaggio (il più importante).
• ##ticket.id## e ##ticket.title## - riferimento perché l'utente ricordi l'intervento.
• ##satisfaction.text## / ##satisfaction.type## - testo e tipo del sondaggio.

L'errore comune qui è curare un'e-mail lunga: più testo prima del link, minore la conversione. Una riga di contesto, il link e basta.

Misurare davvero il tasso di risposta

La media onesta di risposta ai sondaggi via e-mail si colloca nella fascia del 10% al 20%; considerare il 30% come "scarso" è irrealistico. Tutte le risposte vivono in glpi_ticketsatisfactions, una riga per sondaggio generato. Quando non è stata risposta, date_answered è nullo - è così che si separa "inviato" da "risposto":

-- Tasso di risposta e media (ultimi 90 giorni), utente in sola lettura
-- type: 1=interno (stelle)  2=esterno (URL)
-- satisfaction: 0 a 5; date_answered nullo = non ancora risposto
SELECT
    COUNT(*)                                                   AS generati,
    SUM(date_answered IS NOT NULL)                            AS risposti,
    ROUND(100 * SUM(date_answered IS NOT NULL) / COUNT(*), 1) AS tasso_risposta_pct,
    ROUND(AVG(CASE WHEN date_answered IS NOT NULL
                   THEN satisfaction END), 2)                 AS media_0a5
FROM glpi_ticketsatisfactions
WHERE date_begin >= DATE_SUB(CURDATE(), INTERVAL 90 DAY);

Noti che la media considera solo chi ha risposto. Calcolare la media su tutte le righe (valori nulli inclusi) sporca il numero ed è stata un'altra distorsione che abbiamo già corretto in un report cliente.

Sollevare il tasso di risposta da terra

Una configurazione corretta è un prerequisito; il volume di risposte è un'altra battaglia. Ciò che funziona nella pratica:

• Bloccare nuovi ticket fino alla risposta con il modulo Pending Survey: l'utente ritrova il sondaggio in sospeso quando prova ad aprire il ticket successivo. È ciò che sposta di più l'ago.
• Ridurre l'inquest_delay per generare il sondaggio vicino alla chiusura, mentre l'intervento è ancora fresco nella memoria.
• Notificare tramite un altro canale oltre all'e-mail, ad esempio via WhatsApp.
• Mantenerlo semplice: 1 voto e 1 commento facoltativo. Un sondaggio lungo abbatte la conversione.

Un tranello dell'inquest_rate: il sorteggio avviene al momento del cron e non è retroattivo. Scendere dal 100% al 30% non "annulla" i sondaggi già generati, e rialzarlo non recupera i ticket già passati - la filigrana max_closedate avanza solo in avanti.

Serve una soddisfazione che misura davvero, con un cron affidabile e un tasso di risposta sano? Il supporto GLPI di NexTool prende in carico la configurazione, il monitoraggio del cron e i report mensili per la Sua operatività. Scopra il servizio di supporto e manutenzione.

Revisionato dal team NexTool Solutions.