SLA, calendario ed escalation

Le scadenze si configurano in «Settings → SLA». La pagina stessa ti dice in alto quando non c'è nessuna politica attiva. Una politica ha tre parti: un nome, le condizioni e gli obiettivi. Le politiche nuove vengono create inattive di proposito, così puoi finire di configurarle prima che facciano qualcosa.

Le condizioni sono «Team», «Priority», «Main category» e «Subcategory». Vuoto significa «Any», cioè «vale per tutto», non «non vale per niente». Se corrispondono più politiche, vince quella con il numero più basso in «Order»; è per questo che la politica più stretta sta in alto e quella generale sotto.

I due campi di categoria sono raggruppati per team, perché le categorie appartengono a un team — ma ti vengono offerte tutte, anche quelle di altri team. È voluto: in un passaggio il ticket cambia team, la categoria no. Un ticket che l'helpdesk ha passato al team di rete porta ancora la classificazione dell'helpdesk, e una politica può puntare proprio a quella. Dopo che hai scelto una categoria principale, il campo sotto offre solo le sottocategorie collegate a lei: una coppia che non può esistere su un ticket viene rifiutata al salvataggio.

Ogni politica ha due obiettivi. «Time to first response» finisce con la prima risposta pubblica di un agente: una conferma automatica e una nota interna, esplicitamente, non contano. «Time to resolution» finisce appena il ticket raggiunge uno stato che conta come risolto (quale sia lo imposti in «Settings → General → Status»). I due obiettivi hanno i loro minuti, il loro calendario e la loro reazione a uno sforamento.

Sul ticket le scadenze stanno a destra nella scheda «Details» e, sotto, «Show deadline history»: un registro che annota ogni passo — avviato, in pausa, ripreso, rispettato, mancato — ognuno con un motivo e il tempo di lavoro usato. Lo vedono solo gli agenti e gli amministratori; per i clienti non è consultabile.

Se più tardi qualcuno cambia la priorità o il team, l'orologio passa alla politica che allora corrisponde: il tempo di lavoro usato fino a quel punto viene chiuso con il vecchio calendario e, da lì in poi, valgono i nuovi valori. Se non corrisponde più nessuna politica, l'orologio finisce senza verdetto: non conta né come rispettato né come non rispettato.

Se alla creazione del ticket nessuna politica corrispondeva, l'orologio parte la prima volta che una politica corrisponde dopo una modifica, per esempio una priorità più alta. Conta da quel momento. L'orologio della prima risposta parte solo se nessuno ha ancora risposto.

Nuovi orologi nascono solo quando un ticket viene riaperto. Gli altri cambi di stato non creano nuovi orologi.

Un calendario dice quando l'orologio corre. Ha un nome, un fuso orario proprio e un numero qualsiasi di finestre per giorno della settimana: una pausa pranzo è semplicemente un giorno con due finestre. Una finestra può passare la mezzanotte; in quel caso accanto compare «ends next day».

Quale calendario vale per un team si imposta sul team («Settings → Teams»). Sul singolo obiettivo di una politica lo puoi scavalcare: «From the team» prende quello del team, oppure ne scegli un altro. È esattamente questo a produrre il caso abituale: i guasti contano a ogni ora, tutto il resto solo durante l'orario d'ufficio.

Viene contato il tempo che passa davvero dentro alla finestra, non la differenza tra le letture dell'orologio. Al cambio dell'ora legale questo fa differenza: un giorno 24/7 in ottobre ha 25 ore, un turno notturno dalle 22:00 alle 06:00 in primavera ne ha sette invece di otto. Una finestra d'ufficio dalle 09:00 alle 17:00 non è mai toccata, perché nell'UE il cambio avviene di notte.

Se non si trova nessun calendario con ore di apertura, non viene creata nessuna scadenza: meglio nessuna che una indovinata. Sul ticket compare una nota al posto di una data.

Sotto ogni calendario c'è l'elenco «Closed days». Un clic su «Import holidays (.ics)» accetta un file di calendario e poi comunica quattro numeri: quanti giorni sono stati acquisiti, quanti sostituiti, quanti illeggibili e quanti c'erano già. Puoi anche inserire singoli giorni a mano.

Il simbolo ↻ dopo un giorno significa «si ripete ogni anno». È corretto solo per le date fisse: il 3 ottobre cade sempre nella stessa data, il Venerdì Santo e il lunedì di Pentecoste dipendono dalla data della Pasqua e si spostano. Le feste mobili stanno quindi nell'elenco con la loro data concreta anno per anno — nell'immagine «Good Friday» senza il simbolo.

Un giorno di chiusura si mangia l'intera finestra di quel giorno, compresa la parte che si estende al giorno dopo. E quando un calendario non conosce nemmeno un giorno di chiusura per i prossimi dodici mesi, la pagina lo dice esplicitamente: altrimenti il sistema conta in silenzio attraverso i giorni festivi e produce scadenze sbagliate.

La discussione più frequente sulle scadenze è questa: il ticket aspetta da tre giorni la risposta del cliente e l'orologio continua comunque a correre. Per questo ogni obiettivo ha l'interruttore «Pause while waiting for the requester», singolarmente e non per tutta la politica.

Se stai aspettando lo decide lo stato: in «Settings → General → Status» ogni stato porta un contrassegno che dice se conta come «in attesa di chi ha fatto la richiesta». Con l'interruttore acceso, la scadenza riposa mentre il ticket sta in uno stato del genere. L'orologio da parete continua a correre: è per questo che l'elenco mostra «Paused» invece di un tempo residuo, e lo storico delle scadenze contiene «Paused» e «Resumed» con le rispettive ore. Il tempo di attesa non conta nemmeno se il ticket viene risolto direttamente da uno stato del genere.

Per la prima risposta di solito si lascia l'interruttore spento: la prima risposta la devi comunque, qualunque cosa si stia aspettando. Per la risoluzione di solito è acceso. L'immagine mostra esattamente questa configurazione.

Appena una politica è attiva, l'elenco dei ticket riceve la colonna «Deadline». Mostra il tempo residuo della prossima scadenza aperta («14h 53m»). Quando sul ticket non corre più nessuna scadenza, lì resta il verdetto: l'etichetta «In time» per una rispettata, il «Breached» rosso per una mancata. Un ticket senza nessun orologio riceve un trattino neutro, ed è voluto: un ticket precedente alla politica non è un fallimento.

Se non c'è nessuna politica attiva la colonna non c'è proprio: non resta lì vuota. Lo stesso vale per il filtro: in «Filter» la casella «Breached only» compare solo quando esistono scadenze.

Un ticket ha due orologi ma la colonna ha un solo posto: mostra la scadenza APERTA più urgente. Se la prima risposta è stata mancata e la risoluzione sta ancora correndo, la colonna mostra il tempo residuo della risoluzione con accanto un «!» rosso. Quel segno dice: su questo ticket una scadenza è già stata superata — ed è esattamente così che il filtro «Breached only» lo trova, perché chiede qualsiasi scadenza non rispettata, anche una finita da tempo. Quale delle due sia stata è scritto nel ticket stesso.

Ci puoi anche ordinare: sotto lo stesso titolo «Deadline» c'è un campo con «Due soonest first» e «Due latest first». I ticket senza orologio in corsa finiscono sempre in fondo: non sono i meno urgenti, semplicemente non sono interessati. L'ordinamento per scadenza ha la precedenza su quello per «Updated at»: nessun elenco può soddisfare due ordini insieme.

Per ogni obiettivo imposti in «When breached» che cosa succede a uno sforamento: «Record only» si limita a registrarlo, «Notify assignee and observers» manda un messaggio a chi ha il ticket e a chi lo osserva (non a tutto il team), «Hand over to another team» passa il ticket. Per il passaggio devi scegliere un team di destinazione: una politica senza di esso viene rifiutata al salvataggio, perché sembrerebbe configurata e non farebbe niente.

L'azione viene eseguita esattamente una volta per orologio. Senza quel fermo, un riavvio del server manderebbe di nuovo lo stesso messaggio. Il contrassegno di «già fatto» viene messo anche quando l'invio è fallito: un messaggio non arrivato è meglio di un ciclo che ne manda uno nuovo ogni minuto.

Lo sforamento stesso porta la data del momento in cui è scaduto, non quella del passaggio di controllo: altrimenti i report dipenderebbero dal ritmo del servizio di controllo. Ed è misurato sul tempo di lavoro usato: un orologio in pausa non può sforare, anche se la scadenza è passata da un pezzo.

Il passaggio riporta lo stato a «Open». Le righe della cronologia che lo riguardano sono interne; il cliente vede sul ticket solo il nuovo stato e il nuovo team.

In «Reports» scegli il periodo e premi «Generate report»: senza quel clic la pagina resta vuota. Il report contiene poi il blocco «Service level agreements» con una riga per obiettivo: rispettati, non rispettati, ancora in corso, tasso raggiunto e tempo medio usato.

Il conteggio avviene per obiettivo, non per ticket: lo dice anche la riga sotto la tabella. Un ticket con entrambi gli obiettivi compare quindi due volte, una per riga.

Il tasso raggiunto conta solo gli orologi già decisi. Quelli in corsa non appartengono al denominatore, altrimenti ogni SLA appena acceso sembrerebbe catastrofico all'inizio e migliorerebbe da solo. Se non c'è ancora nemmeno un orologio deciso, compare un trattino, non «0 %».

Se lavori con gli incidenti collettivi, c'è una riga in più, «Achieved without group incidents»: un solo incidente collettivo con cento ticket agganciati distorcerebbe altrimenti il tasso in entrambe le direzioni. Lascia fuori ogni ticket collegato a un incidente collettivo.

In questo blocco gli agenti vedono solo i propri team. Senza Professional il blocco compare solo se ci sono dati di scadenze di prima; in quel caso resta leggibile.