Approfondimenti

Service Level Agreement (SLA): cosa sono, perché contano e quali metriche devi guardare davvero

Se la tua azienda acquista connettività, VoIP, cloud o servizi data center, non compra soltanto “banda” o “spazio su un server”: compra affidabilità, tempi di risposta e supporto. Tutto questo si traduce in un documento chiave, il Service Level Agreement (SLA), che rende misurabile il livello di servizio che un service provider si impegna a garantire. Capire come funziona uno SLA è fondamentale per scegliere e valutare un fornitore, che si tratti di ISP, cloud, SaaS o servizi di manutenzione.

In questo articolo vediamo cos’è uno SLA, come si collegano SLO e KPI, quali metriche contano davvero (uptime, downtime, MTTR, tassi di errore, sicurezza) e come usare questi concetti per negoziare meglio i tuoi contratti di servizio. La base di tutto resta una rete stabile e ben dimensionata: per questo, quando si parla di SLA su VoIP o applicazioni critiche, la scelta della connettività aziendale diventa parte integrante della strategia.


Cos’è uno SLA (Service Level Agreement)

Definizione di SLA in parole semplici

Uno Service Level Agreement è un accordo contrattuale tra fornitore di servizi (service provider) e cliente (azienda, tenant, committente) che mette nero su bianco:

  • quali servizi sono coperti (es. accesso Internet, trunk VoIP, hosting/hosting in data center, assistenza IT);
  • quali livelli minimi di prestazione il provider si impegna a garantire (es. 99,9% di disponibilità mensile, risposta entro 30 minuti, risoluzione entro 4 ore);
  • come vengono misurati questi livelli (metriche, strumenti di monitoraggio, periodo di riferimento);
  • cosa succede in caso di mancato rispetto (penali, crediti di servizio, rimborsi, possibilità di recesso).

Diverse guide per provider e MSP sottolineano che lo SLA non è solo “marketing”, ma una base tecnica e operativa per misurare la qualità del servizio nel tempo, ad esempio elencando le principali metriche SLA per i servizi cloud.

SLA, SLO e KPI: come si collegano

Per non fare confusione è utile distinguere tre livelli:

  • SLA: è l’accordo complessivo, di natura legale/contrattuale, che descrive il servizio, i livelli di qualità richiesti, le responsabilità e le penali.
  • SLO (Service Level Objective): sono gli obiettivi numerici dentro lo SLA, ad esempio “uptime 99,9% su base mensile”, “tempo di risposta < 30 minuti”, “First Contact Resolution ≥ 80%”.
  • KPI (Key Performance Indicator): sono le metriche operative che monitori per capire se stai rispettando gli SLO (uptime reale del mese, MTTR medio, tasso di errori, CSAT, ecc.). Una spiegazione molto chiara della relazione tra questi tre elementi è quella che illustra la differenza tra KPI e SLA, includendo il ruolo degli SLO come ponte tra i due.

Dal punto di vista pratico, la scelta dei KPI non è neutra: l’articolo su metriche e KPI per il monitoraggio degli SLA mostra come combinare metriche tecniche (uptime, errori, tempi) con metriche di business (impatto sul cliente).


Tipologie di SLA: cliente, servizio, multilivello

SLA basati sul cliente

In uno SLA basato sul cliente, l’accordo viene costruito su misura per un singolo cliente o gruppo di clienti:

  • aziende enterprise con requisiti elevati (uptime alto, supporto 24/7, tempi di risposta stringenti);
  • clienti “critical” (es. sanità, fintech, logistica) con processi che non possono fermarsi.

Qui lo SLA riflette esigenze specifiche: ad esempio, tempi di ripristino più aggressivi per la sede principale rispetto alle sedi periferiche, oppure livelli diversi per connessioni primarie e linee di backup.

SLA basati sul servizio

Uno SLA basato sul servizio definisce livelli validi per tutti i clienti che usano quel servizio (es. un certo profilo di connettività business, un’offerta VoIP, un pacchetto di hosting). È un approccio tipico degli ISP e dei provider cloud:

  • il contratto di connettività indica uptime garantito, latenza massima, tempi medi di intervento;
  • il contratto di hosting definisce disponibilità dei server, tempi di risposta del supporto, finestre di manutenzione programmata.

SLA multilivello e piani di servizio

Gli SLA multilivello (multi‑tier) combinano livelli diversi per servizio, sede, dipartimento o priorità:

  • piani “Silver / Gold / Platinum” con uptime e MTTR differenti;
  • SLO diversi per servizi mission‑critical (ERP, VoIP contact center, piattaforme core) rispetto a servizi non critici;
  • integrazione di SLA di più provider (connettività, cloud, SaaS) in una “catena” complessiva di servizio [web:71].

Componenti chiave di uno SLA

Informazioni generali e descrizione dei servizi

A livello strutturale, ogni SLA dovrebbe esplicitare:

  • le parti coinvolte (fornitore e cliente);
  • l’oggetto del servizio (es. “accesso Internet simmetrico 1 Gbit/s per sede X”, “servizio VoIP con N numerazioni geografiche”);
  • la durata, l’ambito geografico e le eventuali dipendenze (es. alimentazione elettrica, carrier di trasporto, terze parti).

Ruoli, responsabilità e contatti

Lo SLA deve anche chiarire:

  • le responsabilità del provider (monitoraggio, manutenzione, gestione incidenti, comunicazione durante i down);
  • le responsabilità del cliente (uso corretto, accesso ai locali, gestione dei propri apparati, reperibilità dei referenti);
  • i contatti di escalation e i livelli gerarchici da coinvolgere se i problemi non si risolvono in tempi previsti.

Monitoraggio, reporting e manutenzione programmata

Una buona parte dello SLA riguarda come vengono misurati e comunicati i risultati:

  • quali KPI vengono monitorati (uptime, MTTR, tasso di errori, tasso di abbandono, sicurezza, soddisfazione cliente);
  • con quali strumenti (monitoraggio automatico, sistemi di ticketing, integrazioni con CRM/ERP);
  • come e quando vengono forniti report (mensili, trimestrali, dashboard in tempo reale, report PDF).

Le best practice sulle metriche SLA e il monitoraggio delle prestazioni ricordano anche di chiarire come vengono trattate le finestre di manutenzione programmata: spesso non vengono conteggiate nel downtime se sono annunciate con congruo preavviso.

Esclusioni, sicurezza, penali e indennizzi

  • Esclusioni: condizioni non coperte (es. guasti causati da apparecchiature del cliente, interventi non autorizzati, eventi di forza maggiore).
  • Sicurezza / cybersecurity: impegni su gestione delle vulnerabilità, aggiornamenti, incidenti di sicurezza, log e audit. Molte linee guida sulle metriche SLA per i servizi cloud includono la sicurezza tra le metriche da monitorare.
  • Ricorsi e penali: crediti di servizio, rimborsi, meccanismi di “earn back” se il provider recupera la performance.
  • Indennizzi: eventuali clausole che trasferiscono al provider specifici rischi e responsabilità per danni derivanti da disservizi o violazioni contrattuali.

KPI e metriche SLA da guardare (con esempi)

Disponibilità / uptime e downtime

La metrica più intuitiva è la disponibilità del servizio (uptime), che indica la percentuale di tempo in cui il servizio è operativo in un certo periodo. Una guida molto pratica alle metriche di uptime, SLA, SLO e MTTR mostra, ad esempio, che su un mese di 30 giorni:

  • 99% di uptime ≈ 7 ore e 12 minuti di downtime;
  • 99,5% di uptime ≈ 3 ore e 36 minuti;
  • 99,9% di uptime ≈ 43 minuti;
  • 99,99% di uptime ≈ 4 minuti e mezzo.

È importante capire che picchi di downtime concentrati nei momenti sbagliati (es. durante un lancio o orari di punta) possono avere un impatto molto maggiore di brevi interruzioni notturne, anche se la percentuale complessiva resta “buona”.

Tempi di risposta, risoluzione e MTTR

  • Tempo di risposta: quanto tempo passa tra la segnalazione di un problema (ticket o allarme) e la presa in carico da parte del supporto.
  • Tempo di risoluzione: quanto tempo serve per ripristinare il servizio.
  • MTTR (Mean Time To Recovery): la media dei tempi di ripristino su un certo periodo; molte analisi sulle metriche SLA per l’infrastruttura lo indicano come uno degli indicatori più importanti insieme a uptime e latenza.

Nei contratti per linee dati, VoIP o hosting, è comune differenziare SLO per guasti critici (servizio indisponibile) e problemi minori (degrado di prestazioni ma servizio ancora fruibile).

MRT e MOT in ambito facility/manutenzione

In scenari di facility management e manutenzione (impianti di rete, raffreddamento, energia, apparati in data center), sono utili anche metriche come:

  • MRT (Mean Response Time): tempo medio tra apertura del ticket e avvio effettivo dell’intervento;
  • MOT (Mean Operating Time): tempo operativo effettivo necessario per concludere l’intervento e chiudere il ticket.

Qualità del supporto: errori, FCR e abbandono

Oltre alla pura disponibilità, bisogna valutare la qualità del supporto:

  • Tasso di errore / failure rate: percentuale di richieste o rilasci che causano incidenti o disservizi.
  • First Call Resolution / First Contact Resolution: quota di problemi risolti al primo contatto con il supporto; nella pratica, guide sulle metriche SLA indicano valori target tra il 70% e l’85% per un service desk maturo.
  • Tasso di abbandono: percentuale di chiamate o ticket chiusi dal cliente prima di essere gestiti, utile per valutare capacità del contact center e dimensionamento del team.

Sicurezza e metriche di business

  • Sicurezza / cybersecurity: numero di incidenti di sicurezza, vulnerabilità note, patch applicate, tempi di risposta agli alert.
  • Soddisfazione cliente: CSAT, NPS e survey specifiche sui servizi coperti dallo SLA, come suggerito nelle linee guida su metriche e KPI per il monitoraggio SLA.
  • KPI di business: impatto su continuità operativa, produttività, ricavi e costi (es. ore di fermo produzione, impatto sulle vendite online, consumo di budget cloud).

SLA, SLO e KPI: tabella riassuntiva

Strumento Scopo Esempio
SLA Accordo contrattuale complessivo tra provider e cliente Contratto di connettività con uptime garantito, tempi di risposta definiti e penali per disservizi
SLO Obiettivo numerico specifico dentro lo SLA Uptime mensile 99,9%; risposta a ticket critici < 30 minuti; MTTR < 4 ore
KPI Metrica operativa usata per monitorare il rispetto degli SLO Uptime reale del mese, MTTR medio, % First Contact Resolution, CSAT, numero incidenti di sicurezza

Come usare gli SLA quando scegli un fornitore

Definire SLA realistici e negoziati

Uno SLA è utile solo se è realistico per il provider e rilevante per il cliente. Alcuni suggerimenti frequenti nelle guide sulle metriche SLA e il monitoraggio sono:

  • basare gli SLO su dati storici e capacità tecniche reali (non su promesse commerciali irraggiungibili);
  • limitarsi a pochi SLO chiave per ogni servizio, invece di decine di metriche inutili;
  • allineare gli orizzonti di misura al modo in cui il cliente usa davvero il servizio.

Strumenti digitali per monitorare SLA e KPI

Per servizi continuativi e distribuiti (linee dati, VoIP, infrastrutture IT, impianti) monitorare manualmente è impossibile. Per questo molti provider e clienti usano:

  • sistemi di monitoraggio uptime e alerting, che alimentano automaticamente i KPI su disponibilità, latenza e MTTR;
  • CMMS, CAFM, EAM per gestire asset e manutenzioni, strumenti spesso citati come essenziali per garantire compliance agli SLA in ambito facility/maintenance;
  • CRM / ERP integrati, che collegano dati tecnici (ticket, tempi, errori) a dati economici e di customer experience.

Conclusioni: perché gli SLA non sono solo “clausole legali”

Gli SLA non dovrebbero essere visti come semplice burocrazia contrattuale.

Gli SLA sono uno strumento operativo per allineare aspettative, misurare qualità e migliorare nel tempo i servizi di connettività, VoIP, data center e IT.

Capire le differenze, conoscere le metriche chiave e sapere come vengono monitorate ti permette di negoziare contratti più chiari e di scegliere fornitori davvero affidabili.

Prima ancora di guardare le cifre sugli SLA, vale la pena valutare la qualità tecnica della connettività e dell’infrastruttura. Solo una base di rete solida rende sensato parlare di percentuali di disponibilità e tempi di ripristino.

Da lì in poi, uno SLA ben scritto diventa il tuo strumento principale per tenere sotto controllo continuità operativa e performance nel tempo.

epiclink

Recent Posts

3CX Partner per soluzioni VoIP e Unified Communications

Affidati a Epiclink, 3CX Partner esperto. Integriamo VoIP, Data Center e connettività per la tua…

2 giorni ago

Data Center Milano: infrastruttura e servizi gestiti

Cerchi un Data Center a Milano? Scopri le soluzioni Epiclink: connettività carrier-neutral, sicurezza ISO e…

2 settimane ago

VoIP SIP e NAT: perché tipo di NAT e porte contano davvero per audio e stabilità

Nel mondo VoIP e SIP la qualità delle chiamate non dipende solo da banda e…

6 mesi ago

VoIP, SIP e protocollo SDP: come funziona davvero la negoziazione dei media

Quando si parla di VoIP (Voice over IP), molti pensano subito al protocollo SIP come…

7 mesi ago

Linea ISDN vs VoIP: differenze, vantaggi, costi e come gestire il passaggio

Linea ISDN vs VoIP: differenze, vantaggi, costi e come gestire il passaggio Per anni la…

7 mesi ago

Microsoft 365 vs Office 365 vs Windows 365: differenze, cosa includono e come scegliere per la tua azienda

Negli ultimi anni il catalogo Microsoft si è popolato di nomi molto simili: Office 365,…

7 mesi ago