L’SLA è il contenitore, l’SLA item è la regola

Un SLA in Dynamics 365 Customer Service è definito su una tabella (tipicamente case, ma le SLA moderne coprono anche conversation e tabelle Dataverse personalizzate) e di per sé non misura nulla: è l’involucro. La misura vera sta negli SLA item, uno o più righe figlie che l’SLA contiene. Ogni SLA item porta con sé quattro elementi indipendenti dagli altri item: la condizione di applicabilità (a quali record si applica: priorità alta, cliente con un certo entitlement, canale specifico), il KPI misurato, la finestra temporale con soglia di warning e di failure, e le azioni da eseguire.

Questo è il motivo per cui un singolo SLA può servire scenari diversi: se i clienti premium devono avere risposta in due ore e gli altri in otto, la risposta d’esame non è “due SLA”, ma un SLA con due SLA item e condizioni di applicabilità che si escludono a vicenda. Si creano SLA distinti quando cambia la tabella di destinazione o quando serve associarli a entitlement o contratti diversi.

KPI, orologio e condizioni

Il KPI è ciò che l’SLA item misura. Su case gli SLA KPI più comuni sono First Response By e Resolve By, ma il set non è chiuso: si possono definire SLA KPI personalizzati come record dedicati, purché esista un campo sulla tabella che li ospita. All’applicazione dell’SLA il sistema crea un record SLA KPI Instance per ciascun item applicabile: è lì che vivono lo stato (In Progress, Nearing Noncompliance, Succeeded, Noncompliant, Paused) e gli orari calcolati.

Tre parametri governano l’orologio. Applicable From indica il campo da cui parte il conteggio (Created On, la data di primo contatto, un campo custom). La success condition dice quando il KPI è soddisfatto e il conteggio si ferma con esito positivo. Le pause condition sospendono il conteggio quando il record entra in stati in cui l’attesa non è imputabile all’organizzazione — tipicamente in attesa di risposta dal cliente. Nelle SLA moderne le pause si configurano per SLA item; nelle SLA standard dipendono dagli stati di case impostati a livello di ambiente, differenza che l’esame usa volentieri. A questo si somma il calendario: la customer service schedule con il relativo holiday schedule determina se le ore contate sono lavorative o solari.

Warning action, success action, failure action e Power Automate

Ogni SLA item espone tre momenti in cui può accadere qualcosa. La warning action scatta all’avvicinarsi della scadenza, la failure action quando l’impegno è mancato, la success action quando la condizione di successo è soddisfatta in tempo. Nelle SLA moderne queste azioni sono implementate con Power Automate: il sistema genera flow collegati all’SLA item, ed è lì che si costruisce l’escalation reale — notifica in-app al supervisore, aggiornamento di un campo, riassegnazione a una queue, invio di un’e-mail, creazione di un task. Non serve (e non si deve) replicare la logica con regole custom sul record: la trigger condition è già l’SLA.

Il timer control mostra, non calcola

Il timer control è un componente di form che legge i valori dell’SLA KPI Instance (orario di warning, orario di failure, stato) e li rende come conto alla rovescia colorato per il representative nel Copilot Service workspace. È puramente presentazionale: non avvia il conteggio, non lo mette in pausa, non decide la non compliance. Se il timer non compare o mostra il valore sbagliato, la causa sta a monte — SLA non applicato, condizione di applicabilità non soddisfatta, Applicable From errato, KPI instance non creata — mai nel controllo in sé. Rimuovere il timer dal form non sospende alcun SLA.

Trappole tipiche d’esame

  • Tempi di risposta diversi per clienti premium e standard sulla stessa tabella → un solo SLA con più SLA item: ogni item ha la propria condizione di applicabilità; moltiplicare gli SLA è la risposta sbagliata.
  • Avvisare il supervisore 30 minuti prima della scadenza → warning action dell’SLA item con Power Automate: non una regola separata sul record e non la failure action, che scatta a impegno già mancato.
  • Il conteggio non deve correre mentre si attende il cliente → pause condition sull’SLA item (SLA moderna): chiudere e riaprire il case o togliere il timer dal form non sospende nulla.
  • Il timer sul form mostra il tempo sbagliato → verificare SLA KPI Instance, Applicable From e condizione di applicabilità: il timer control è una visualizzazione, non il motore di calcolo.
  • Clienti con contratti differenti → SLA associato all’entitlement, che prevale sul default SLA della tabella: il default vale solo dove non c’è un entitlement applicabile.
  • Escludere weekend e festività dal conteggio → customer service schedule con holiday schedule: senza calendario il KPI conta ore solari e fallisce nel fine settimana.