Configurazione moduli
SLA
Impegni temporali su ticket e attività — misuri, monitori ed effettui escalation quando i lead time rischiano di rompersi.
Aggiornato il 23 gen 2026
Configurazione · Moduli · 4.4
Un SLA (Service Level Agreement) è un impegno temporale su un ticket o un’attività. Il modulo SLA cattura ciò che promette, a quali casi si applica e traccia se l’impegno viene rispettato — con un timer che scorre solo durante l’orario lavorativo.
Perché è importante per il business
"Promesse non misurabili"
Time-to-first-response e time-to-resolution resi espliciti — rendicontabili mensilmente.
"L'attesa del cliente conta"
Le condizioni mettono in pausa il timer in stati specifici — misurazione equa.
"Il cronometro continua fuori orario"
Il calendario si aggancia allo SLA → il timer scorre solo durante l'orario lavorativo.
"Escalation troppo tardiva"
Sequenza di notifiche sulla percentuale dello SLA → reminder, manager, gruppo direttivo automaticamente.
Quattro aspetti di ogni SLA
| Aspetto | Cosa imposta |
|---|---|
| Classe | Time to first response o time to resolution. Due diverse strategie di misurazione. |
| Criteri | Quando si applica lo SLA: organizzazione, classificazione, priorità, tipologia (ticket/task), template, tipo. |
| Tempo target | Lead time massimo consentito in ore/minuti + il calendario che definisce l'orario lavorativo. |
| Condizioni | Quando il timer parte, va in pausa o si ferma (es. lo stato "In attesa del cliente" mette in pausa). |
La combinazione classe + criteri è univoca — creare la stessa configurazione due volte genera un errore.
Due classi di SLA
Time to first response
Quanto velocemente qualcuno risponde al ticket? Si ferma non appena viene dato il primo follow-up.
Time to resolution
Quanto velocemente viene risolto? Si ferma allo stato di completamento.
Comportamento al cambiamento
Quando qualcosa cambia su un ticket (organizzazione, priorità, classificazione), Gfacility verifica di nuovo se uno SLA corrisponde. Un nuovo SLA diventa attivo, oppure uno esistente viene nascosto se nessun criterio combacia più.
Quando cambia la configurazione stessa dello SLA, gli SLA già attivi restano intatti — il vecchio continua a scorrere fino alla chiusura del ticket. Solo se cambia qualcosa sul ticket Gfacility rivaluterà.
Quali decisioni dovrà prendere?
Quali bande di priorità?
Critica · alta · normale · bassa — ognuna con il proprio target. Troppe bande = complessità inutile.
Orario lavorativo vs 24/7?
Quale calendario aggancia? Un calendario per team di servizio di solito basta.
Quali stati mettono in pausa?
"In attesa del cliente", "In sospeso" — altrimenti le attese esterne continuano a contare e si rompe ingiustamente.
SLA su ticket o su attività?
Entrambi è possibile, ma scelga per caso d'uso — altrimenti rendiconta due volte.