Le policy SLA nell'assistenza clienti, spiegate

Un service level agreement (SLA) è una promessa su quanto velocemente risponderai alle richieste e le risolverai. Una policy SLA è il modo in cui il tuo helpdesk fa rispettare quella promessa su ogni ticket. La maggior parte delle policy ha le stesse parti:

• Condizioni: a quali ticket si applica la policy, per esempio in base a cliente, canale o tipo di richiesta
• Obiettivi: limiti di tempo per la prima risposta, le risposte successive e la risoluzione, di solito impostati per priorità
• Orari: se il conteggio usa ore lavorative o ore di calendario
• Regole di pausa: quali stati fermano il conteggio
• Azioni in caso di violazione: promemoria prima che un obiettivo venga mancato ed escalation dopo

Quando hai più policy, l'ordine conta. Zendesk esegue prima i trigger, poi confronta il ticket con le sue policy SLA dall'alto verso il basso e applica la prima le cui condizioni sono soddisfatte. Metti le policy specifiche, come quella per i clienti enterprise, sopra quelle generiche. Zendesk richiede inoltre che la priorità del ticket sia impostata nel campo priorità di sistema predefinito; un campo priorità personalizzato non farà corrispondere una policy.

Zendesk definisce il next reply time come il tempo tra il commento del cliente senza risposta più vecchio e il successivo commento pubblico di un agente. Offre anche una metrica di aggiornamento periodico, che misura il tempo tra i commenti pubblici degli agenti. Per la risoluzione, Zendesk ha tre metriche e consiglia di sceglierne una sola per policy: requester wait time (tempo in New, Open e On-hold), agent work time (tempo in New e Open) e total resolution time (l'intero ciclo di vita, dalla creazione fino alla risoluzione del ticket).

Freshdesk imposta gli obiettivi di first response, every response e resolution per priorità all'interno di ogni policy SLA. In Jira Service Management ogni SLA è un timer con un nome: definisci quando parte, si mette in pausa e si ferma, poi aggiungi obiettivi che usano JQL per scegliere le richieste a cui si applicano, con target di tempo scritti come 4h 30m.

Le ore lavorative contano solo il tempo all'interno del tuo orario di lavoro; le ore di calendario contano ogni ora di ogni giorno. Zendesk ti permette di scegliere ore lavorative o di calendario per ogni priorità all'interno di una policy. Freshdesk chiede se ogni SLA debba usare l'orario lavorativo che hai impostato o le ore di calendario (24x7). Jira Service Management associa a ogni obiettivo un calendario, con fuso orario, giorni e orari lavorativi e festività.

Un obiettivo di 4 ore lavorative su un ticket creato venerdì sera tardi potrebbe scadere solo lunedì. È corretto verso il tuo team, ma non corrisponde a ciò che vive il cliente, quindi usa le ore di calendario per ogni priorità in cui prometti una copertura 24 ore su 24.

Le pause sono l'altra metà. Il tempo passato ad aspettare il cliente di solito non dovrebbe contare contro di te, e ogni strumento lo gestisce in modo diverso:

• Zendesk: il requester wait time si mette in pausa in Pending; l'agent work time in Pending e On-hold; il total resolution time non si mette in pausa con nessun cambio di stato finché il ticket non è risolto.
• Freshdesk: lo stato Pending mette in pausa i timer SLA e puoi disattivare il timer SLA per qualsiasi stato, compresi quelli personalizzati come Waiting on Third Party. I ticket con il timer disattivato risultano On Hold e, quando il cliente risponde, il ticket torna in Open e il conteggio riprende.
• Jira Service Management: uno SLA può avere condizioni di pausa, per esempio mentre aspetti la risposta del cliente, oltre alle condizioni di avvio e arresto.

Uno SLA è utile solo se qualcuno interviene prima che venga mancato. Imposta un avviso prima della scadenza e un'escalation dopo:

• Zendesk: crea un'automazione con la condizione Hours until next SLA breach per avvisare un team o una persona quando un ticket è vicino alla violazione. Le automazioni girano una volta all'ora, quindi l'avviso può arrivare fino a un'ora prima o dopo la soglia, mai nel momento esatto. Nell'esempio di Zendesk, la stessa automazione aggiunge un tag così si attiva una sola volta per ticket.
• Freshdesk: ogni policy SLA può inviare promemoria agli agenti da 5 minuti a 4 ore prima della scadenza di un obiettivo di prima risposta o di risoluzione, e fare escalation quando un obiettivo viene violato verso l'agente assegnato o altre persone che scegli, come un team lead. Entrambi si impostano in Admin > Workflows > SLA Policies.
• Qualsiasi strumento: invia gli avvisi di violazione dove il tuo team guarda davvero, come un canale Slack, e non solo via email.

• Zendesk: crea policy SLA con condizioni e obiettivi per priorità, scegli ore lavorative o di calendario per ogni priorità e ordina l'elenco in modo che le policy specifiche vengano prima. Aggiungi un'automazione per gli avvisi di violazione imminente.
• Freshdesk: in Admin > Workflows > SLA Policies, imposta per priorità gli obiettivi di first response, every response e resolution, scegli ore lavorative o di calendario, poi aggiungi promemoria ed escalation. Decidi nelle impostazioni degli stati dei ticket quali stati disattivano il timer SLA.
• Jira Service Management: crea ogni SLA con condizioni di avvio, pausa e arresto. Più condizioni di avvio funzionano in OR e lo SLA si ferma non appena si verifica una qualsiasi condizione di arresto. Poi aggiungi obiettivi che selezionano le richieste con JQL, imposta un target di tempo e scegli un calendario.

Qualunque sia lo strumento, inizia con una policy e poche priorità, falla girare per qualche settimana, poi confronta i tempi reali di prima risposta e di risoluzione con gli obiettivi prima di renderli più stringenti.

TascaLab configura automazioni legate agli SLA su Zendesk, Freshdesk e Jira: routing che imposta la priorità così si applica la policy giusta, avvisi di violazione su Slack e report SLA pianificati. I prezzi una tantum pertinenti sono Ticket Routing & Categorization (690 €), Automated Reports (620 €) e Custom Automation (da 1070 €). I progetti includono documentazione di base, 30 giorni di supporto dopo il lancio e nessun costo nascosto, e la maggior parte richiede 1–3 settimane. Inizia con una call di Health Check gratuita di 30 minuti.