Per ordinare i ticket IT servono impatto, urgenza, proprietario e prossimo aggiornamento. Ecco una procedura con esempi per evitare priorità assegnate a voce. Nel percorso della guida ITSM per piccole aziende questa tappa produce una coda unica e tre casi di priorità verificati. Il referente interno non deve diventare il tecnico di tutto: deve aiutare a rendere leggibile il problema e a farlo prendere in carico. 1. Definire un punto di ingresso Scegli un canale tracciabile per le segnalazioni e una regola per i casi urgenti. Anche una telefonata che avvia un intervento deve lasciare una registrazione. La pratica di incident management descritta da PeopleCert è orientata al ripristino del servizio: il ticket deve aiutare quel risultato. Campi minimi: servizio, sintomo, utenti coinvolti, inizio osservato, alternativa disponibile, contatto e referente dell'attività. Evita credenziali o dati riservati negli allegati; raccogli soltanto evidenze pertinenti. 2. Separare impatto e urgenza L'impatto descrive quanto lavoro è coinvolto. L'urgenza descrive quanto tempo hai prima che la conseguenza diventi rilevante. Non coincide con quanto insistentemente qualcuno chiede aiuto. Per l'esercizio usa tre priorità interne da concordare: P1: servizio essenziale fermo, attività imminente e nessuna alternativa praticabile. P2: servizio degradato o gruppo bloccato, con un'alternativa temporanea. P3: problema limitato o richiesta pianificabile, senza un blocco immediato. Queste categorie sono un modello di lavoro, non tempi universali di assistenza. Associa obiettivi di presa in carico compatibili con orari e accordi effettivi del supporto. 3. Applicare i criteri a tre casi Il gestionale è fermo per tutti e le spedizioni iniziano fra un'ora: nel modello è P1. Assegna subito un referente e informa chi coordina le attività operative. Una stampante non funziona ma è disponibile quella del reparto vicino: nel modello può essere P2 o P3, secondo il lavoro realmente coinvolto. Registra l'alternativa invece di lasciare la priorità dipendere dal titolo "stampante guasta". Una persona chiede un secondo monitor per la settimana successiva: è una richiesta da valutare e pianificare, non un incidente con servizio da ripristinare. Il request fulfillment aiuta a separare i percorsi. 4. Rendere visibile la prossima azione Ogni ticket aperto deve avere proprietario, stato, prossima azione e prossimo aggiornamento. "In lavorazione" senza una scadenza di comunicazione lascia il richiedente nell'incertezza. Esempio: il tecnico attende il fornitore del gestionale. Scrivi chi lo ha contattato, cosa manca e quando verrà aggiornato il referente. Attesa non significa abbandono del ticket. 5. Chiudere con un esito verificato Conferma che l'attività sia tornata possibile e registra ciò che è stato fatto. Se una soluzione temporanea ripristina il servizio, distinguila dall'intervento definitivo e collega l'attività successiva. Tre episodi analoghi meritano una verifica della causa, seguendo il problem management. Il risultato è una coda che il team sa leggere senza spiegazioni a voce. Collega i ticket all'inventario, usa il registro dei cambiamenti per gli interventi e prepara il monitoraggio con avvisi assegnati per le segnalazioni automatiche.