Crea un tracker SLA che calcoli le scadenze dei ticket, metta in pausa i timer per le risposte dei clienti e segnali le violazioni del servizio per team.
I team delle operations clienti raramente non rispettano un SLA perché qualcuno ignora una data. Le scadenze cambiano, i ticket passano da una persona all'altra e le risposte dei clienti possono sospendere il lavoro per giorni. Un foglio di calcolo con una sola colonna per la scadenza non regge, a meno che qualcuno non lo aggiorni dopo ogni modifica.
Il primo problema nasce dal trattare ogni obiettivo SLA come un'unica scadenza. Il target della prima risposta misura la rapidità con cui un agente prende in carico una nuova richiesta. Il target di risoluzione misura il tempo concesso al team per risolverla. Un ticket può rispettare il target di risposta in 15 minuti e non rispettare quello di risoluzione tre giorni dopo. Una sola scadenza non mostra quale impegno è stato disatteso.
La responsabilità crea un altro problema. Un agente può rispondere, uno specialista può indagare e un responsabile può approvare la soluzione. Se nessuno è responsabile del timer SLA attivo, ciascuno può pensare che lo stia controllando qualcun altro. Il ticket resta in coda finché il tempo non scade.
Immagina un problema di accesso a un account segnalato alle 10:00. L'agente risponde alle 10:12, rispettando un target di risposta di 30 minuti, poi alle 10:20 chiede uno screenshot. Il cliente risponde il pomeriggio seguente. Se il tracker conta quel periodo di attesa nel target di risoluzione, attribuisce al supporto un tempo che non poteva utilizzare. Se mette in pausa il timer ma non lo riavvia, il risultato è sbagliato nella direzione opposta.
Un tracker dovrebbe offrire a ogni ticket un unico record operativo condiviso: responsabile, team, priorità, scadenze di risposta e risoluzione, stato del timer, motivo della pausa e storico delle modifiche. Gli agenti possono così concentrarsi sul lavoro vicino alla violazione, mentre i responsabili possono individuare i ritardi dovuti a personale insufficiente, passaggi di consegne o attese del cliente.
I fogli gestiti manualmente possono funzionare per una coda piccola e stabile. Quando le scadenze dipendono da priorità, orari lavorativi, riassegnazioni e pause, il tracker ha bisogno di regole coerenti.
Ogni ticket deve contenere informazioni sufficienti per spiegare chi ne è responsabile, quale impegno si applica e se il timer deve continuare a scorrere. Parti dalle basi: cliente o account, priorità, team assegnato, responsabile del ticket e stato attuale.
Aggiungi poi i campi che regolano la scadenza:
Tieni separati la prima risposta e la risoluzione completa. Un team può promettere una prima risposta entro quattro ore lavorative, ma avere due giorni lavorativi per risolvere il problema. Un'unica scadenza permette a una conferma rapida di nascondere un ticket ancora irrisolto.
Non chiedere agli agenti di selezionare manualmente «violato». Calcola lo stato in base all'ora attuale, alla scadenza, allo stato del ticket e alle pause valide. Per esempio, un ticket viola il suo SLA di risoluzione quando la scadenza è passata, il ticket è ancora aperto e il timer è attivo.
AppMaster può concentrare questa logica in un unico punto. Il suo Data Designer permette di modellare i campi dei ticket, mentre un Business Process visuale può calcolare le scadenze e lo stato di violazione ogni volta che un agente crea o aggiorna un ticket.
Regole chiare rendono equi i risultati SLA. Definisci il target per ogni categoria di ticket prima di creare formule o report. In caso contrario, due agenti possono gestire la stessa richiesta in modo diverso e il conteggio delle violazioni perde significato.
La maggior parte dei team varia i target in base a priorità, piano del cliente e tipo di richiesta. Mantieni ridotta la prima versione. Per esempio, gli incidenti urgenti in produzione potrebbero richiedere una prima risposta entro un'ora, i problemi di accesso dei clienti con piano a pagamento entro quattro ore lavorative e le domande ordinarie entro due giorni lavorativi.
Scrivi ogni regola in un linguaggio semplice. «Un problema di fatturazione ad alta priorità per un cliente premium richiede una prima risposta entro due ore lavorative» indica esattamente quali dati archiviare: priorità, piano, tipo di richiesta, ora di creazione e ora della prima risposta.
Decidi se i target devono funzionare 24 ore su 24 oppure solo durante l'orario di supporto. Se il supporto opera dal lunedì al venerdì, dalle 9:00 alle 17:00, un ticket ricevuto venerdì alle 16:30 con un target di due ore dovrebbe scadere lunedì alle 10:30, non venerdì sera.
Documenta giorni lavorativi, orari di supporto, fuso orario, festività ed eventuali calendari separati per gli incidenti 24/7. Quando possibile, usa un calendario nominato per ogni policy. I team con clienti in paesi diversi possono aver bisogno di calendari regionali, ma creare un calendario per ogni cliente genera manutenzione inutile.
Stabilisci con precisione quando parte il timer. I nuovi ticket spesso iniziano quando il sistema li riceve. Per i ticket riaperti serve una regola separata: continuare con il tempo rimanente, riavviare il timer originale o iniziare un nuovo target. Scegli un metodo e applicalo in modo coerente.
Affida le modifiche alle policy a una persona o a un piccolo gruppo. Gli agenti possono correggere i dati dei ticket, ma non dovrebbero cambiare le scadenze per eliminare una violazione. Salva la versione della policy in ogni record e registra le eccezioni approvate con motivo e data.
Un'app AppMaster può mantenere le policy in un'unica area amministrativa e applicare la regola corrispondente quando un ticket entra nel sistema. In questo modo sostituisce formule separate nei fogli di calcolo con un unico timer coerente.
Mantieni la prima versione abbastanza semplice da permettere a un responsabile delle operations di esaminare un ticket e capire perché la scadenza è cambiata.
Inizia con una tabella dei ticket che contenga ID, oggetto, cliente, priorità, stato, ora di creazione, ora della prima risposta, ora di risoluzione, scadenze, responsabile assegnato e team responsabile. Ogni ticket dovrebbe avere un unico responsabile e un unico team attuali, anche quando vi commentano più persone.
Crea record separati per team e policy SLA. Un record del team può contenere il nome e il calendario degli orari lavorativi. Ogni policy dovrebbe indicare quali ticket copre, i target di risposta e risoluzione, il tipo di timer e se l'attesa del cliente mette in pausa il timer.
Aggiungi un record delle festività con data, team o sede interessati e una breve etichetta. Archivia tutti i timestamp usando un unico fuso orario coerente, di solito UTC, e mostra l'ora locale nell'interfaccia quando serve. Mescolare i fusi orari causa errori nei weekend e nei passaggi all'ora legale.
Conserva lo storico degli stati invece di sovrascrivere il passato. Ogni voce dovrebbe contenere ID del ticket, stato precedente e nuovo stato, ora dell'evento e persona o regola che ha effettuato la modifica. Registra eventi come «In attesa del cliente», «Il cliente ha risposto», «Assegnato» e «Risolto».
Questo storico spiega le variazioni delle scadenze. Se una scadenza passa da martedì mattina a martedì pomeriggio, un responsabile può vedere che il team ha sospeso lo SLA per tre ore mentre attendeva il cliente. Il Data Designer visuale di AppMaster può modellare questi record correlati, mentre il suo Business Process Editor può aggiornare le scadenze dopo i cambiamenti di stato.
Avvia il timer a partire da un evento chiaro, per esempio quando il sistema riceve un ticket di supporto. Non farlo partire quando qualcuno apre il ticket per caso. Salva l'orario di inizio, così ogni calcolo successivo usa lo stesso punto di riferimento.
Seleziona poi la policy SLA corrispondente in base a piano del cliente, tipo di ticket, priorità o area geografica. Calcola quindi la scadenza:
Gli orari lavorativi rendono il calcolo meno ovvio di quanto sembri. Se uno SLA di quattro ore inizia alle 16:00 e il supporto opera dalle 9:00 alle 17:00, quel giorno resta un'ora. Il ticket scade a mezzogiorno del giorno lavorativo successivo, non alle 20:00.
Quando cambia la priorità di un ticket, conserva l'orario di inizio originale e applica la regola di escalation documentata. Alcuni team applicano il target urgente dall'inizio originale, altri fanno partire un nuovo target quando il ticket viene portato a una priorità maggiore. Entrambi gli approcci possono funzionare, se tutti li applicano allo stesso modo.
Mostra sia la scadenza esatta sia il tempo rimanente. Etichette come «2 h 15 min rimanenti», «scade tra 1 giorno» e «in ritardo di 35 min» aiutano gli agenti a scorrere una coda più rapidamente dei semplici timestamp. Usa uno stato neutro per i ticket nei tempi, un avviso vicino alla scadenza e uno stato di violazione chiaro dopo il superamento del termine.
Metti in pausa il timer solo quando il team non può far avanzare il ticket senza il cliente. I motivi comuni includono attesa di informazioni, conferma, accesso, approvazione o file. Un ritardo interno, come l'attesa di un collega, non dovrebbe mettere in pausa lo SLA.
Usa un insieme breve e chiaro di stati:
Quando un agente seleziona uno di questi stati, salva l'ora esatta e il motivo della pausa. Registra anche il messaggio o l'evento con cui è stata richiesta la risposta del cliente. I supervisori potranno così verificare che la pausa fosse giustificata.
Quando il cliente risponde, riavvia il timer all'ora della risposta. Aggiungi il periodo di attesa al tempo totale in pausa, quindi ricalcola il tempo rimanente secondo le regole degli orari lavorativi. Un'attesa del cliente di 90 minuti sposta la scadenza di 90 minuti, tenendo conto degli orari di chiusura.
Mostra il tempo in pausa nella vista del ticket. Gli agenti devono sapere se un ticket è rimasto in attesa per 15 minuti o per tre giorni, e i supervisori devono poter individuare i ticket che tornano ripetutamente in uno stato di attesa.
Limita i motivi di pausa a quelli consentiti dalla policy SLA. Richiedi un evento di richiesta al cliente prima di accettare una pausa. In AppMaster, un Business Process può controllare il nuovo stato, salvare l'ora di inizio della pausa e rifiutare le modifiche non valide prima di aggiornare il record SLA.
Un'email automatica del tipo «abbiamo ricevuto il tuo messaggio» non dovrebbe riavviare il timer. Usa un messaggio in entrata del cliente o una risposta confermata dall'agente e conserva tutto lo storico della pausa nel ticket.
Un cliente invia martedì alle 10:00 una domanda sulla fatturazione: «Perché la mia fattura mostra due addebiti?». Il tracker crea il ticket B-184, lo assegna al Supporto e applica la policy SLA per la fatturazione. Il team ha quattro ore lavorative per dare una prima risposta utile e otto ore lavorative per la risoluzione.
Il supporto opera dal lunedì al venerdì, dalle 9:00 alle 17:00. Alle 10:35 un agente conferma che il team sta controllando l'account. Il timer della prima risposta si ferma dopo 35 minuti, lasciando 3 ore e 25 minuti. Il ticket rispetta il target della prima risposta.
Alle 11:00 l'agente ha bisogno del numero della fattura e imposta il ticket su «In attesa del cliente». Il timer della risoluzione si mette in pausa dopo un'ora di lavoro effettivo. Il tracker salva l'inizio e il motivo della pausa.
Il cliente risponde alle 15:30. Il tracker aggiunge alla scadenza le 4 ore e 30 minuti di pausa. La scadenza originale della risoluzione era martedì alle 18:00, quindi la scadenza modificata diventa mercoledì alle 14:30, dopo aver trasferito il tempo rimanente al giorno lavorativo successivo.
Un agente risolve il problema mercoledì alle 15:10. Il ticket è in ritardo di 40 minuti. Viene conteggiato come una risoluzione oltre la scadenza per il Supporto, mentre la prima risposta resta puntuale.
Un report sulle violazioni dovrebbe mostrare chiaramente la distinzione: il Supporto ha ricevuto un ticket di fatturazione, ha rispettato il target della prima risposta, ha mancato quello di risoluzione di 40 minuti e ha trascorso 4 ore e 30 minuti in attesa del cliente. La sola anzianità del ticket racconterebbe una storia sbagliata.
Un ticket viola lo SLA quando la scadenza passa prima che venga eseguita l'azione richiesta. Usa la scadenza modificata dopo le pause valide per l'attesa del cliente.
Tieni separati i ticket aperti oltre la scadenza da quelli risolti in ritardo. I ticket aperti oltre la scadenza richiedono attenzione immediata. Quelli risolti in ritardo appartengono ai report sulle prestazioni. Unirli nasconde il lavoro urgente e rende il report più difficile da usare.
Per ogni periodo, raggruppa i risultati per il team che possedeva il ticket quando è scaduto il termine. Filtra per policy, priorità e intervallo di date. Un team di fatturazione con una policy di risposta entro quattro ore non dovrebbe essere confrontato direttamente con un team di escalation tecnica che ha due giorni lavorativi per la risoluzione.
Usa i conteggi insieme alle percentuali:
Un tasso di violazione del 50% ha un significato diverso se deriva da un ticket in ritardo su due invece che da 50 ticket in ritardo su 100. Esamina l'andamento insieme ai dettagli dei ticket. Violazioni frequenti sui ticket ad alta priorità possono indicare problemi nelle regole di escalation o nei passaggi di consegne, non necessariamente un carico di lavoro generale eccessivo.
Un report utile permette al responsabile di aprire l'elenco dei ticket in ritardo, vedere policy e priorità e controllare chi era responsabile al momento della violazione. Deve aiutare a esaminare il lavoro da correggere, non premiare i team perché chiudono i ticket troppo presto.
Gli agenti hanno bisogno di un elenco operativo breve, non di un report pieno di ticket vecchi. Ogni ticket aperto dovrebbe mostrare responsabile, team, priorità, scadenza, stato del timer e tempo rimanente. Registra immediatamente i cambiamenti di responsabilità quando un ticket passa da un team all'altro.
Usa etichette semplici per i timer. «Attivo» significa che il team è responsabile della prossima azione. «In pausa - in attesa del cliente» significa che il timer è fermo. Mostra separatamente il tempo attivo e quello in pausa, così gli utenti possono capire perché un ticket è rimasto aperto per diversi giorni.
Una vista per agenti può includere ticket in scadenza nelle prossime quattro ore, ticket oltre la scadenza, ticket in attesa di risposta del cliente e ticket riassegnati oggi. Invia avvisi prima della scadenza. Un target di risposta di quattro ore richiede promemoria più anticipati rispetto a un target di risoluzione di tre giorni.
I responsabili hanno bisogno di una vista diversa. Un report settimanale può raggruppare i ticket oltre la scadenza per team e mostrare numero di violazioni, percentuale rispettata, tempo medio di ritardo e ticket ancora aperti dopo la scadenza. Includi responsabile e ultimo aggiornamento per ogni elemento oltre la scadenza.
Conserva un record di audit per le modifiche alle policy. Se il team operations cambia un target da otto a 12 ore, registra chi ha effettuato la modifica, quando e quali nuovi ticket usano la regola. I risultati storici devono conservare la regola applicata quando è iniziato ciascun ticket.
AppMaster permette ai team di creare viste web separate per agenti e responsabili, mantenendo gli stessi dati dei ticket e le stesse regole di business alla base di entrambe.
Anche grafici ordinati possono raccontare la storia sbagliata quando le regole sottostanti non sono corrette.
Non calcolare usando le ore di calendario quando l'accordo promette ore lavorative. Un ticket aperto venerdì alle 16:30 con un target di risposta di otto ore lavorative non viola lo SLA sabato alle 00:30. Conta solo le ore lavorative e le festività definite nella policy.
Presta la stessa attenzione alle pause. Lo stato «in attesa del cliente» dovrebbe mettere in pausa uno SLA solo quando il team ha inviato una richiesta chiara e non può procedere senza una risposta. Mettere in pausa ogni ticket con quell'etichetta nasconde ritardi imputabili al team.
Conserva le date che spiegano ogni risultato: scadenza originale, policy usata, ogni ora di inizio e fine della pausa, motivo della pausa, scadenza modificata, ora di risoluzione e persona che ha chiuso il ticket. Senza questo storico, nessuno può verificare perché un ticket è risultato puntuale.
Usa una sola regola di responsabilità nei report per team. Se il Supporto riassegna un ticket alla Fatturazione, non contare la stessa violazione per entrambi i team. Puoi attribuire il risultato al team che possedeva il ticket quando è scaduto il termine e riportare separatamente i passaggi di consegne.
Richiedi un timestamp di risoluzione prima di chiudere un ticket. Uno stato chiuso non dimostra quando è terminato il lavoro. Per esempio, se un ticket passa dal Supporto alla Fatturazione alle 14:00 e viola lo SLA alle 15:00, la Fatturazione è responsabile della violazione secondo la regola della responsabilità al momento della violazione. Il report può comunque mostrare il precedente passaggio dal Supporto senza aggiungere una seconda violazione.
Rivedi ogni policy SLA prima che gli agenti si affidino al tracker. Ogni policy deve avere un target chiaro, come una prima risposta entro quattro ore o una risoluzione entro due giorni lavorativi, e il calendario applicabile. Imposta una policy predefinita per i ticket che non corrispondono a una regola basata su cliente, piano o priorità.
Testa i casi con tempistiche problematiche, non solo quelli ordinari:
Confronta i totali della dashboard con l'elenco dei ticket alla base. Se un report dice che il Team A ha 12 violazioni, filtra i record e contale. In questo modo puoi individuare ticket duplicati, assegnazioni di team mancanti e ticket riaperti conteggiati due volte.
Imposta le regole di accesso prima del rilascio. Gli agenti dovrebbero aggiornare i ticket che gestiscono, i responsabili hanno bisogno dei report del team e gli amministratori dovrebbero controllare le impostazioni delle policy. In AppMaster, testa ogni ruolo con un account separato, così un responsabile non dovrà avere accesso da amministratore per consultare i report sulle violazioni SLA.
Comincia con un tipo di ticket e una policy SLA. Un team di supporto potrebbe iniziare con richieste standard via email e un target di prima risposta entro 24 ore. È sufficiente per testare scadenze, pause approvate e record delle violazioni.
Chiedi ad alcuni addetti alle operations clienti di eseguire ticket reali nel flusso di lavoro, includendo un caso normale, un caso in attesa del cliente e una scadenza mancata. Raccogli feedback specifici. Gli agenti potrebbero aver bisogno di stati distinti per l'attesa del cliente e quella di un altro team. I responsabili potrebbero scoprire che un'etichetta generica come «in pausa» nasconde troppe informazioni.
Quando un foglio di calcolo limita il processo, crea il tracker come applicazione no-code in AppMaster. Puoi creare moduli per i ticket, definire la logica dei timer nel Business Process Editor visuale e fornire dashboard separate ad agenti e responsabili. AppMaster può generare backend, applicazione web e app mobile nativa quando il tracker deve funzionare oltre un semplice foglio condiviso.
All'inizio mantieni essenziali i report: ticket aperti, ticket vicini alla violazione, ticket in pausa e violazioni per team. Confronta alcune scadenze con verifiche manuali, esamina i ticket violati e i relativi periodi di pausa e modifica una regola alla volta prima di ripetere i test. Quando il personale avrà fiducia nei calcoli, aggiungi un altro tipo di ticket o una policy per la priorità e ripeti gli stessi controlli.
Perché dovrei monitorare separatamente la prima risposta e la risoluzione?Gestisci la prima risposta e la risoluzione come impegni separati. Una conferma rapida può rispettare il target di risposta, mentre il ticket non raggiunge comunque la scadenza prevista per la risoluzione.
Quando dovrebbe iniziare un timer SLA?Avvia il timer quando il sistema riceve il ticket, quindi applica la policy SLA corrispondente a priorità, piano, tipo o area geografica. Salva l'orario di inizio, così tutti gli aggiornamenti successivi useranno lo stesso punto di riferimento.
Come si calcolano le scadenze SLA durante l'orario lavorativo?Conta solo le ore di supporto incluse nella policy. Per esempio, se il supporto chiude alle 17:00 e un target di due ore inizia alle 16:30, i 90 minuti rimanenti passano al giorno lavorativo successivo.
Quando può un team mettere in pausa un timer SLA?Metti in pausa il timer solo quando al team serve qualcosa dal cliente per poter continuare, come accesso, approvazione, file o informazioni richieste. Non mettere in pausa il timer per code interne, passaggi di consegne o ritardi dovuti al personale.
Cosa dovrebbe succedere quando un cliente risponde a un ticket in pausa?Registra l'ora di inizio della pausa, un motivo preciso e la richiesta al cliente che l'ha causata. Quando il cliente invia una risposta utile, riavvia il timer e conserva lo storico completo della pausa nel ticket.
Quale team è responsabile di una violazione SLA dopo il trasferimento di un ticket?Assegna a ogni ticket un unico responsabile attuale e un unico team responsabile. Nei report per team, attribuisci la violazione al team che possedeva il ticket quando è scaduto il termine, indicando separatamente i passaggi di consegne precedenti.
Cosa dovrebbero vedere gli agenti in un tracker SLA?Mostra la scadenza esatta, il tempo rimanente, lo stato del timer, il responsabile, il team e la priorità. Gli agenti traggono vantaggio anche da code separate per i ticket in scadenza, oltre la scadenza e in attesa del cliente.
Quali metriche SLA dovrebbero riportare i responsabili?Tieni separati i ticket aperti oltre la scadenza da quelli risolti in ritardo. Riporta il totale dei ticket SLA, le risoluzioni puntuali, i ticket aperti oltre la scadenza, le risoluzioni tardive e il tasso di violazione. Consenti poi ai responsabili di aprire i record dei ticket alla base dei dati.
Come si testa un tracker SLA prima del lancio?Testa i ticket creati vicino all'orario di chiusura, prima di weekend e festività, dopo un'attesa del cliente e durante un trasferimento tra team. Chiudi inoltre un ticket dopo la scadenza e verifica che il tracker registri una sola violazione con la policy corretta.
È possibile creare un tracker SLA senza scrivere codice?Sì. AppMaster permette di modellare ticket, policy, team, festività e storico degli stati nel suo Data Designer. Puoi usare i Business Process visuali per calcolare le scadenze, gestire le pause approvate e creare viste separate per agenti e responsabili usando gli stessi dati.
14 lug 2026
9 min
13 lug 202610 min
08 lug 202611 minSperimenta con AppMaster con un piano gratuito.
Quando sarai pronto potrai scegliere l'abbonamento appropriato.
