Configurazione moduli
Ticket
Il cuore del service management, ticket, incidenti, richieste. I template definiscono quali domande compaiono, i tipi collegano workflow e SLA, il routing trova il gruppo di lavoro corretto.
Aggiornato il 18 mag 2026
Configurazione · Moduli · 4.9
Il modulo Ticket è il motore dietro a ogni segnalazione, incidenti, richieste di servizio, domande alla knowledge base, richieste di modifica. Tre oggetti lavorano insieme: il tipo di ticket definisce workflow e SLA, il template del ticket decide quali domande vede il richiedente e il routing lo consegna al gruppo di lavoro corretto.
Perché è importante per il business
"I ticket restano fermi"
SLA per tipo di ticket + regole di escalation, nessuno può "dimenticarli".
"Il richiedente dimentica metà delle informazioni"
Il template del ticket impone i campi obbligatori prima della creazione.
"Il ticket arriva al team sbagliato"
Regola di routing su categoria/sede/asset, assegnazione automatica al gruppo di lavoro.
"Gli stati non dicono nulla"
Workflow per tipo di ticket, "In lavorazione · In attesa del cliente · Pronto per revisione · Chiuso", niente più generico "aperto".
I tre oggetti di configurazione
Tipo di ticket
Categoria del ticket: Incidente · Richiesta di servizio · Cambiamento · Domanda di conoscenza · Reclamo. Definisce il workflow (vedi Building Blocks → Workflow) e lo SLA.
Template del ticket
Quali domande vengono poste al richiedente, esempi: "Laptop rotto" chiede l'asset tag, "Problema in sala riunioni" chiede la sala. Riduce il testo libero.
Regole di routing
Condizione → gruppo di lavoro. "Categoria = hardware IT → gruppo IT-L1". Componibili con un fallback.
Campi standard di un ticket
| Campo | A cosa serve |
|---|---|
| Titolo e descrizione | La domanda o il problema. L'AI li usa per generare suggerimenti. |
| Richiedente / creatore | Chi ha creato il ticket. Può essere diverso dall'utente finale (es. la reception lo apre per conto di qualcun altro). |
| Tipo di ticket | Definisce workflow e SLA. |
| Classificazione | Categorizzazione gerarchica (vedi Building Blocks → Classificazioni). |
| Priorità | Impatto × urgenza (matrice) oppure impostata liberamente, concordata in 4.6. |
| Gruppo di lavoro / operatore | Chi prende in carico. Derivato tramite routing o impostato esplicitamente. |
| CI / sede correlata | Quale asset o sala è coinvolta dal ticket. |
| Stato e contatore SLA | Stato dal workflow; lo SLA mostra il tempo residuo e si mette in pausa su "In attesa del cliente". |
| Allegati e comunicazioni | Screenshot, foto, thread email, tutti sulla stessa timeline. |
Quali decisioni dovrà prendere?
Quali tipi di ticket distingue?
Resti contenuto, da 3 a 6 tipi. Troppi = nessuno sceglie correttamente.
Template guidato o libero?
Template prima per flussi specifici (laptop rotto, richiesta badge). Input libero per "altro" con routing sulla classificazione.
Chi imposta la priorità?
Il richiedente (rapido, ma tendenza a "tutto è P1") o in automatico tramite matrice (strutturato, richiede formazione).
L'utente finale può chiudere il proprio ticket?
Va bene per le richieste di servizio; per gli incidenti di solito spetta all'operatore, così si mantiene il controllo sulle metriche di tempo di risoluzione.