Deskhero
Italiano
Inizia gratis

← Back to articles

Come automatizzare i promemoria SLA prima che diventino violazioni

Come automatizzare i promemoria SLA prima che diventino violazioni

I promemoria SLA automatizzati dovrebbero portare un ticket all'attenzione del team quando c'è ancora tempo per agire, per poi rendere impossibile non riconoscere un ticket oltre la scadenza. La configurazione corretta dipende dall'helpdesk. Alcune piattaforme offrono avvisi nativi per scadenze imminenti e violazioni, mentre un workflow personalizzato può richiedere controlli pianificati e passaggi di escalation espliciti.

Inizia dall'orologio, non dalla notifica:

  • Definisci obiettivi separati per la prima risposta e la risoluzione.
  • Decidi se gli obiettivi utilizzano il tempo di calendario o le ore lavorative.
  • Scegli quali stati del ticket mettono in pausa il timer della risoluzione.

Consiglio professionale: Testa ogni stato SLA con ticket di esempio prima di fare affidamento sugli avvisi in produzione. Includi casi con scadenza imminente, violazione, pausa, riassegnazione e già completati.

Punti chiave

Promemoria affidabili iniziano da scadenze precise. La tempistica degli avvisi, i destinatari e le procedure di escalation vengono dopo che la policy stessa è stata definita correttamente.

Punto Dettagli
Definisci entrambi i timer Tieni traccia separatamente della prima risposta e della risoluzione, perché terminano in corrispondenza di eventi diversi.
Rispetta l'orario lavorativo Usa un calendario lavorativo quando notti e fine settimana non devono consumare il tempo obiettivo.
Configura gli stati di pausa Metti in pausa l'obiettivo di risoluzione mentre il ticket è in attesa del cliente o di un'altra parte esterna.
Scegli con attenzione i destinatari Assicurati che gli avvisi di scadenza imminente e di violazione raggiungano qualcuno in grado di intervenire sul ticket.
Testa prima del rilascio Verifica scadenze, comportamento della pausa e consegna delle notifiche con ticket controllati.
Usa prima le funzionalità SLA native Un helpdesk con policy, calendari lavorativi, avvisi, filtri e report integrati evita un workflow di polling separato.

Documentazione autorevole e guide operative da consultare

Per un esempio specifico di piattaforma, consulta la documentazione di Jira sui follow-up automatizzati. Descrive sia regole pianificate sia un approccio basato sulle soglie SLA, includendo la raccomandazione di eseguire i test su un ambito di query ridotto prima di ampliarlo.

Indice

Creare l'automazione dei promemoria SLA passo dopo passo

Metti per iscritto esattamente cosa misura ogni SLA prima di configurare un avviso. Un obiettivo per la prima risposta e uno per la risoluzione sono timer diversi. Decidi quale evento del ticket avvia ciascun timer, quale evento lo completa e se la scadenza segue il tempo di calendario o un calendario lavorativo.

Quindi configura il percorso del promemoria.

  1. Definisci la policy. Associa gruppi e priorità agli obiettivi di prima risposta e risoluzione. Includi una policy generica per i ticket che non corrispondono a una regola più specifica.
  2. Imposta il calendario lavorativo. Aggiungi gli orari operativi e il fuso orario applicabili all'obiettivo. Se l'impegno è continuo, usa il tempo di calendario.
  3. Configura il comportamento della pausa. Seleziona gli stati che interrompono il timer della risoluzione mentre il team attende informazioni. Verifica se il timer della prima risposta può essere messo in pausa, perché molti sistemi lo gestiscono diversamente.
  4. Abilita le notifiche. Decidi chi riceve gli stati di scadenza imminente e violazione e quali canali supportati utilizzerà l'helpdesk.
  5. Aggiungi una risposta operativa. Documenta cosa dovrebbe fare il destinatario, ad esempio rispondere, modificare la priorità, riassegnare il ticket o coinvolgere un responsabile. La notifica e l'azione correttiva non devono necessariamente essere la stessa regola tecnica.

Se l'helpdesk non dispone di soglie SLA native, un workflow pianificato può esaminare i ticket aperti e confrontare le relative scadenze con l'ora corrente. Un esempio di polling ogni 15 minuti è documentato da LOW/CODE, ma l'intervallo appropriato dipende dall'obiettivo più breve, dai limiti API, dagli orari lavorativi e dal ritardo che il team può tollerare. Memorizza lo stato dell'avviso affinché le esecuzioni successive non inviino nuovamente la stessa notifica.

Scegliere soglie che non causino assuefazione agli avvisi

Un avviso utile lascia al destinatario tempo sufficiente per rispondere. Una soglia percentuale può funzionare in un sistema personalizzato, ma una finestra di avviso fissa è spesso più facile da comprendere tra policy con durate diverse.

  • Entro i tempi con ampio margine: Mantieni il ticket visibile nelle normali viste delle code senza inviare un avviso.
  • Scadenza imminente: Avvisa l'Utente o il gruppo responsabile mentre è ancora possibile rispettare l'obiettivo.
  • Violato: Contrassegna il ticket come oltre la scadenza e segui il processo di escalation documentato dal team.

Non copiare una soglia universale dell'80% senza controllare gli obiettivi sottostanti. Su un obiettivo di un'ora lascia 12 minuti, mentre su un obiettivo di tre giorni lascia più di mezza giornata. Misura quanto tempo operativo serve realmente al team per intervenire.

I promemoria ripetuti generano rapidamente rumore. Gli avvisi nativi dell'helpdesk dovrebbero essere inviati al cambio di stato, non a ogni aggiornamento della schermata. Un workflow di polling personalizzato dovrebbe registrare l'invio dell'avviso di scadenza imminente o violazione e reimpostare quello stato solo quando la policy riparte effettivamente.

Scegliere soglie che non causino assuefazione agli avvisi: diagramma riepilogativo

Cosa devono dire gli avvisi SLA e dove devono arrivare

Un avviso dovrebbe identificare il ticket, mostrare la scadenza e rendere chiara la risposta attesa. Evita di aggiungere dati del cliente di cui il destinatario non ha bisogno.

  • ID e link del ticket affinché il destinatario possa aprire la conversazione corretta.
  • Tipo di obiettivo, ad esempio prima risposta o risoluzione.
  • Scadenza o durata del ritardo in un fuso orario non ambiguo.
  • Stato, priorità, gruppo e assegnatario correnti quando questi campi influiscono sulla responsabilità.
  • Un'unica azione successiva, ad esempio rispondere, riassegnare il ticket o chiedere a un responsabile di esaminarlo.

Usa i canali che il team di supporto monitora già. Le notifiche nell'app e via email sono spesso sufficienti quando raggiungono in modo affidabile l'assegnatario o il gruppo responsabile. Se è necessario un sistema separato di paging o messaggistica, verifica che l'helpdesk supporti l'integrazione prima di progettare il processo basandoti su di essa.

Consiglio professionale: Mostra una scadenza precisa o un conto alla rovescia. Un orario concreto è più facile da stabilire come priorità rispetto a un avviso vago.

Cosa devono dire gli avvisi SLA e dove devono arrivare: diagramma riepilogativo

Mantenere precisi i timer SLA con gli stati di pausa

Un promemoria è affidabile quanto il suo timer. Gli obiettivi di risoluzione vengono comunemente messi in pausa mentre un ticket è in attesa del cliente, ma gli stati esatti dovrebbero riflettere il reale workflow del team.

  • Seleziona stati di pausa espliciti e documenta perché ciascuno interrompe il timer.
  • Riavvia il timer quando il ticket esce da uno stato di pausa.
  • Testa ticket che entrano ed escono da uno stato di pausa più di una volta.
  • Verifica se gli obiettivi di prima risposta e risoluzione seguono le stesse regole di pausa.

I calendari lavorativi risolvono un problema diverso. Escludono gli orari di chiusura dall'obiettivo stesso, mentre gli stati di pausa escludono il tempo in base allo stato del ticket. Configura e testa entrambi. Il fine settimana non dovrebbe consumare un obiettivo basato sulle ore lavorative, e un ticket feriale in attesa del cliente dovrebbe restare in pausa anche mentre il team è operativo.

Testare e ottimizzare prima di affidarsi all'automazione

Usa ticket controllati per testare l'intero ciclo di vita. I dati storici possono aiutare a identificare obiettivi realistici, ma un test sullo stato reale è migliore per verificare la consegna delle notifiche e le modifiche alle scadenze.

  1. Copri ogni policy. Crea un ticket di test per ogni combinazione di gruppo e priorità che può selezionare una policy SLA diversa.
  2. Usa obiettivi temporanei brevi. Conferma gli stati di scadenza imminente e violazione senza attendere ore o giorni, quindi ripristina i valori reali.
  3. Verifica gli stati di pausa. Metti in pausa e riavvia il timer della risoluzione e verifica che la scadenza cambi come previsto.
  4. Controlla i destinatari. Testa un ticket assegnato e uno non assegnato, così le persone corrette ricevono ogni notifica.
  5. Esamina il record. Verifica che il ticket mostri quale policy è stata applicata e quando ogni timer è stato rispettato o mancato.

Dopo il lancio, esamina gli avvisi errati e i passaggi di consegne mancati. Se gli avvisi sono precisi ma vengono comunque ignorati, il problema potrebbe riguardare la responsabilità o il personale, non la tempistica delle soglie.

Come Deskhero gestisce i promemoria SLA

Deskhero dispone di policy SLA dedicate. Sono separate dalle regole generali di automazione, che non sono pianificate né basate sul tempo.

  • I responsabili e gli amministratori possono ordinare le policy SLA in base ai gruppi e alle priorità dei ticket. La prima policy corrispondente stabilisce gli obiettivi di prima risposta e risoluzione.
  • Ogni policy può utilizzare un calendario lavorativo settimanale nominato con il proprio fuso orario oppure conteggiare il tempo di calendario.
  • Il timer della risoluzione si mette in pausa negli stati selezionati nell'area di lavoro. Il timer della prima risposta non si mette in pausa.
  • Deskhero contrassegna un ticket come a rischio durante gli ultimi 60 minuti prima della scadenza successiva e come violato dopo il superamento della scadenza.
  • Un controllo in background viene eseguito ogni cinque minuti e invia notifiche nell'app oltre a un riepilogo email all'assegnatario o, quando il ticket non è assegnato, ai membri del gruppo. Gli utenti possono controllare i canali di notifica SLA per gruppo.

L'elenco dei ticket include una colonna SLA e filtri SLA, il dashboard mette in evidenza i ticket a rischio e violati e la cronologia del ticket registra gli eventi relativi a policy e timer. Statistics offre viste sul rispetto degli SLA dopo l'attivazione del workflow.

Cosa monitorare quando gli avvisi sono attivi

La prima domanda è se i promemoria stanno prevenendo le violazioni. Confronta i ticket a rischio con il numero di quelli che in seguito non rispettano l'obiettivo, quindi esamina i casi che gli avvisi non hanno recuperato.

Monitora separatamente il rispetto degli obiettivi di prima risposta e di risoluzione. Esamina inoltre il numero di ticket attualmente in scadenza entro la finestra di avviso, il numero già violato e quali policy o combinazioni gruppo-priorità producono il maggior numero di mancate scadenze.

Affianca le percentuali al contesto operativo. Una percentuale complessiva elevata può nascondere una coda che viola ripetutamente gli SLA. Un calo improvviso può riflettere una modifica al calendario lavorativo, una priorità aggiunta di recente o una lacuna nella responsabilità, anziché un rallentamento del lavoro.

Gestire SLA sovrapposti senza collisioni tra gli avvisi

Un ticket può avere sia un obiettivo di prima risposta sia un obiettivo di risoluzione. Trattali come timer separati perché una risposta completa solo il primo. L'obiettivo di risoluzione continua fino a quando il ticket raggiunge l'evento che lo soddisfa.

L'interfaccia del ticket dovrebbe mostrare quale delle scadenze ancora aperte viene prima, mantenendo al contempo i dettagli di entrambi gli obiettivi. Anche filtri e report dovrebbero distinguere la prima risposta dalla risoluzione, così una metrica positiva non nasconde i problemi dell'altra.

Quando i clienti hanno impegni diversi, usa policy separate che corrispondano a campi stabili del ticket, come gruppo e priorità. Ordina le policy specifiche prima di quella generica, quindi testa un ticket rispetto a ogni combinazione significativa. Evita di inventare livelli contrattuali nascosti che gli Utenti non possono visualizzare o verificare nel ticket.

Essere pronti per gli audit quando gli SLA funzionano automaticamente

Conserva un registro della policy applicata, delle scadenze calcolate e del momento in cui ogni timer è stato rispettato o mancato. Se una modifica a gruppo, priorità o calendario comporta il ricalcolo di una scadenza, anche tale modifica dovrebbe essere tracciabile.

Documenta le modifiche alle policy al di fuori della casella di posta delle notifiche. Registra chi ha approvato la modifica, quando è entrata in vigore e se si applica ai ticket esistenti. In questo modo sarà più facile rispondere alle domande successive dei clienti e si eviteranno modifiche silenziose al significato di un report SLA.

Per le verifiche contrattuali, conferma il comportamento della piattaforma invece di presumere che ogni evento visibile sia un log di audit. La cronologia dei ticket di Deskhero registra l'applicazione della policy SLA e gli esiti dei timer, mentre l'area Statistics riporta il rispetto degli obiettivi. Le organizzazioni con requisiti formali di conservazione dovrebbero verificare che questi record soddisfino i propri obblighi.

Scrivere messaggi SLA per utenti, responsabili e clienti

Gli avvisi interni e gli aggiornamenti ai clienti hanno scopi diversi. Mantieni ciascuno concentrato su ciò che il destinatario può fare subito dopo.

Gli avvisi rivolti agli Utenti dovrebbero iniziare con il link del ticket, il tipo di obiettivo, la scadenza e l'azione immediata. Evita un paragrafo di contesto sulla policy quando l'Utente deve lavorare sul ticket.

Le revisioni rivolte ai responsabili dovrebbero mostrare gli schemi ricorrenti all'interno di un gruppo, una priorità o una policy. Un singolo ticket mancato richiede un'azione, mentre mancate scadenze ripetute richiedono una decisione sul personale o sul processo.

Le comunicazioni rivolte ai clienti dovrebbero essere precise e specifiche. Se il team prevede un ritardo, un aggiornamento verificato da una persona può indicare un momento realistico per il prossimo contatto. Non esporre etichette interne degli avvisi né promettere un tempo di risoluzione che il team non può garantire.

Collegare l'automazione SLA agli strumenti che già utilizzi

Inizia dalle funzioni SLA native quando coprono le policy, i calendari, gli stati di pausa, gli avvisi, i filtri e i report necessari. Le scadenze native restano generalmente allineate alle modifiche dei ticket in modo più affidabile rispetto a un foglio di calcolo parallelo.

Quando il supporto nativo è limitato, i team hanno utilizzato plugin della community e soluzioni alternative documentate nei forum. Esamina lo stato di manutenzione e la compatibilità con la versione prima di dipendere da questo approccio.

Un workflow separato può essere appropriato quando diversi sistemi devono alimentare un unico canale di escalation. Definisci prima la fonte ufficiale dei dati. Il calcolo duplicato degli SLA nell'helpdesk e nel livello di integrazione può produrre disallineamenti, soprattutto in relazione a fusi orari, orari lavorativi, stati di pausa e riassegnazioni.

Il punto di vista editoriale: l'avviso non è il punto, lo è l'azione

Una notifica di scadenza imminente è utile solo quando la responsabilità è chiara. Il destinatario ha bisogno dell'autorizzazione, del contesto e del tempo necessari per portare avanti il ticket.

La precisione del timer viene prima di tutto. Un calendario lavorativo o una configurazione della pausa errati producono avvisi sicuri di sé ma fuorvianti. Correggi il calcolo della scadenza prima di modificare il testo del messaggio o aggiungere canali.

Costruisci il sistema in quest'ordine: obiettivi della policy, calendari lavorativi, comportamento della pausa, destinatari delle notifiche, risposta operativa e report. Questa sequenza mantiene il promemoria legato a una scadenza compresa da tutti.

Attivare i promemoria SLA senza un progetto di migrazione

Deskhero si collega a Gmail o Microsoft 365 con sincronizzazione bidirezionale, così i team possono mantenere il proprio indirizzo di supporto esistente aggiungendo la gestione condivisa dei ticket e le policy SLA.

Deskhero

Configura gli obiettivi di prima risposta e risoluzione per gruppo e priorità, aggiungi un calendario lavorativo settimanale quando necessario e scegli quali stati mettono in pausa la risoluzione. Deskhero mostra quindi la prossima scadenza, mette in evidenza i ticket in scadenza entro un'ora, notifica gli Utenti responsabili e registra gli esiti SLA.

La prova gratuita di 30 giorni non richiede una carta di credito. Collega una casella email, configura un piccolo insieme di policy e testa l'intero ciclo di vita SLA prima di estendere la configurazione ad altri gruppi.

Fonti

FAQ

Qual è la differenza tra SLA, SLO e SLI?

Uno SLA è un impegno di servizio tra le parti. Uno SLO è un obiettivo relativo alle prestazioni di un servizio, spesso utilizzato internamente per rispettare tale impegno. Uno SLI è il valore misurato usato per valutare l'obiettivo.

Cosa si intende per avviso di violazione SLA?

Un avviso di violazione indica che una scadenza ancora aperta per la prima risposta o la risoluzione è stata superata. Un avviso di scadenza imminente è diverso, perché il team ha ancora tempo per rispettare l'obiettivo.

Cosa significa uno SLA di 4 ore?

Significa che l'azione indicata dalla policy, come la prima risposta o la risoluzione, deve essere completata entro quattro ore secondo il calcolo previsto dalla policy. Il timer può utilizzare il tempo di calendario o un calendario lavorativo.

In cosa differisce uno SLA da un KPI?

Uno SLA stabilisce un impegno di servizio. Un KPI misura le prestazioni e può essere utilizzato per monitorare numerosi obiettivi che non sono scadenze contrattuali.

Deskhero può automatizzare i promemoria SLA senza codice personalizzato?

Sì. Deskhero dispone di policy SLA integrate, una finestra fissa di avviso per le scadenze imminenti, rilevamento delle violazioni, notifiche nell'app e via email, filtri per i ticket, viste del dashboard e report SLA. Queste funzioni sono separate dalle regole generali di automazione.