SLA nei contratti di assistenza: dal foglio Excel al gestionale

Quasi tutte le aziende di servizi hanno degli SLA nei contratti. Poche li rispettano in modo sistematico. Il problema non è la volontà: è che gli SLA restano scritti nel contratto e non entrano nel sistema che gestisce ticket, tecnici e priorità.

Un Service Level Agreement funziona solo se chi prende le decisioni operative (il dispatcher, il tecnico, il responsabile service) lo vede nel momento in cui serve: quando arriva la chiamata, quando si assegna l’intervento, quando si decide chi mandare e con quale urgenza.

Se per sapere che quel cliente ha un tempo di intervento garantito di 4 ore bisogna aprire un PDF o chiedere all’amministrazione, lo SLA è già un problema. E il problema non emerge subito: emerge quando il cliente contesta, quando arriva la penale, o quando al rinnovo chiede uno sconto perché “il servizio non è stato all’altezza”.

Cosa significa davvero gestire gli SLA

Lo SLA nei contratti di servizio tecnico non è una metrica astratta. È un impegno operativo misurabile che si traduce in tre parametri concreti:

Tempo di presa in carico. Quanto tempo passa tra la segnalazione del cliente e il momento in cui qualcuno se ne occupa. In molti contratti questo è il primo indicatore monitorato, perché è il più visibile al cliente.

Tempo di intervento on-site. Quanto tempo passa tra la segnalazione e la presenza del tecnico presso il cliente. Questo è il parametro più costoso da rispettare, perché dipende dalla disponibilità dei tecnici, dalla distanza e dalla pianificazione.

Tempo di risoluzione. Quanto tempo passa tra la segnalazione e la chiusura effettiva del problema. Include eventuali attese per ricambi, seconde visite, o interventi di specialisti.

Ogni contratto può avere combinazioni diverse di questi parametri, con soglie differenti per fasce di servizio (base, premium, gold, o come vengono chiamate internamente). Un’azienda con 200 contratti attivi può avere decine di combinazioni SLA in vigore contemporaneamente. Gestirle a mano è possibile finché i contratti sono pochi. Quando crescono, il rischio di errore cresce con loro.

Perché gli SLA si violano (anche nelle aziende organizzate)

Il motivo più frequente non è la negligenza. È la mancanza di visibilità nel momento decisionale.

Quando un ticket arriva al dispatcher, le informazioni critiche per assegnarlo correttamente sono almeno tre: di quale cliente si tratta, quale contratto ha attivo, e quali sono i suoi parametri SLA. Se queste informazioni non sono visibili nella stessa schermata del ticket, il dispatcher assegna in base all’esperienza, alla memoria, o all’ordine di arrivo. Funziona la maggior parte delle volte. Ma le violazioni SLA non si misurano sulla maggior parte delle volte: si misurano sulle eccezioni.

Il secondo motivo è l’assenza di escalation automatiche. Un ticket con SLA a 4 ore che resta in coda per 3 ore senza che nessuno riceva un avviso è un ticket che probabilmente sfora. L’escalation non serve a punire: serve a far emergere il problema prima che diventi una violazione.

Il terzo motivo è la disconnessione tra contratto e operatività. In molte aziende il contratto vive nell’amministrazione, il ticket vive nel service, il tecnico vive nell’app (o nel foglio carta). Se questi tre livelli non comunicano in tempo reale, lo SLA è un’aspirazione, non un parametro gestito.

SLA e dispatching: il punto in cui tutto si tiene insieme

Il dispatching è il momento in cui lo SLA smette di essere una clausola e diventa un vincolo operativo. Chi assegna i tecnici deve sapere, per ogni ticket aperto, quanto tempo resta prima che lo SLA venga violato.

Questo cambia radicalmente la logica di assegnazione. Non si tratta solo di mandare il tecnico più vicino o quello con l’agenda più libera. Si tratta di mandare il tecnico giusto nel tempo giusto, considerando che un cliente con SLA premium e 2 ore residue ha priorità su un cliente con SLA base e 8 ore residue, anche se il secondo ha chiamato prima.

Questo tipo di logica è gestibile a mente con 10 ticket al giorno. Con 50, 80 o 100 ticket al giorno diventa un collo di bottiglia. E il costo di una violazione SLA (penali contrattuali, perdita di fiducia, mancato rinnovo) è quasi sempre superiore al costo di una riorganizzazione del dispatching.

Il ragionamento vale in tutti i settori a service contract: nel Managed Print Services come nella manutenzione impianti industriali, nel vending come nell’antincendio. Il modello è identico: parco installato, contratto con livelli di servizio, tecnici sul territorio.

SLA e redditività: il collegamento che molti ignorano

C’è un aspetto degli SLA che raramente viene discusso: il loro impatto sulla redditività del contratto.

Un contratto con SLA aggressivi (intervento entro 4 ore, risoluzione entro 8) costa di più da servire rispetto a un contratto base. Se il prezzo del contratto non riflette questa differenza, l’azienda sta regalando margine. Ma per saperlo, serve poter confrontare il costo effettivo degli interventi (ore tecnico, trasferte, ricambi) con il valore del canone per fascia SLA.

Questo tipo di analisi è possibile solo quando il sistema che gestisce i ticket è lo stesso che gestisce i contratti e la fatturazione. Se i dati sono in tre sistemi diversi, il calcolo della redditività per fascia SLA richiede estrazioni manuali e incroci su Excel. Il che significa che si fa una volta l’anno, se va bene, invece che in continuo.

La conseguenza pratica: al momento del rinnovo, l’azienda non ha dati per negoziare. Non sa se quel contratto premium è profittevole o in perdita. Non sa se lo SLA a 4 ore si è tradotto in 15 interventi urgenti o in 2. Rinnova alle stesse condizioni o concede sconti senza base dati.

Come Radix+ gestisce gli SLA nei contratti di servizio

In Radix+ gli SLA non sono un modulo separato: sono un attributo del contratto che si propaga automaticamente a ogni ticket aperto su quel contratto. Questo significa che dal momento in cui il ticket viene creato, il sistema sa già quali tempi deve rispettare.

In concreto:

• SLA per fascia contrattuale: ogni contratto definisce i propri parametri di presa in carico, intervento e risoluzione. Contratti diversi sullo stesso cliente possono avere SLA diversi.
• Visibilità in tempo reale: il dispatcher vede, per ogni ticket aperto, il tempo residuo prima della violazione SLA. I ticket si ordinano automaticamente per urgenza contrattuale, non per ordine di arrivo.
• Escalation automatica: quando un ticket si avvicina alla soglia SLA senza essere stato preso in carico o assegnato, il sistema genera una notifica al livello superiore. Le regole di escalation sono configurabili per contratto.
• App tecnici: il tecnico sul campo vede i parametri SLA del ticket assegnato, insieme alla cronologia del dispositivo e alle condizioni contrattuali del cliente.
• Analisi della compliance SLA: la Business Intelligence di Radix+ permette di misurare la percentuale di rispetto SLA per tecnico, per cliente, per fascia contrattuale e per periodo. Questi dati alimentano direttamente le trattative di rinnovo.

Il punto non è avere una funzione che “gestisce gli SLA”. È che lo SLA vive dentro lo stesso sistema che gestisce il ticket, il contratto, il tecnico e la fattura. Questa è la logica della convergenza tra FSM, CMMS, contratti e fatturazione su cui Radix+ è costruito.

Se i tuoi SLA oggi vivono nei contratti ma non nel sistema che gestisce i ticket e i tecnici, il problema non è di volontà ma di architettura. Contattaci per valutare come portare i parametri contrattuali dentro il flusso operativo.