SLA software: cos'è, come funziona e cosa pretendere

Hai appena firmato un contratto con una software house. Il prodotto va in produzione, ma dopo due settimane il sistema è down per tre ore durante l'orario di punta. Chi è responsabile? Quanto tempo hanno per risolvere? E tu hai diritto a un rimborso? Se nel contratto non c'è un SLA software ben scritto, la risposta è: dipende da come la vede il fornitore.

Un Service Level Agreement — comunemente chiamato SLA — è il documento (o la sezione del contratto) che definisce in modo preciso le garanzie di servizio che il fornitore si impegna a rispettare. Tempi di risposta, uptime garantito, procedure di escalation, penali. È lo strumento che trasforma le promesse verbali in obblighi misurabili.

In questa guida vediamo cos'è esattamente un SLA software, quali sono i parametri che contano davvero, come leggerlo senza essere uno sviluppatore e — soprattutto — cosa pretendere prima di firmare.

Cos'è un SLA software: definizione semplice

SLA è l'acronimo di Service Level Agreement, che in italiano si traduce con accordo sul livello di servizio. È un contratto (o un allegato al contratto principale) in cui fornitore e cliente definiscono insieme i parametri minimi di qualità, disponibilità e supporto che il servizio deve garantire.

Nel contesto dello sviluppo software, l'SLA entra in gioco principalmente in due momenti:

• Durante la fase di manutenzione e supporto: quando il software è già in produzione e devi sapere in quanto tempo il fornitore interviene in caso di bug o disservizi.
• Per i servizi cloud e infrastrutturali: hosting, server, database — dove l'uptime è critico e ogni minuto di inattività ha un costo reale per il tuo business.

Senza un SLA, tutto si regge sulla fiducia e sull'interpretazione. Con un SLA scritto e firmato, hai numeri precisi su cui fare leva.

I parametri chiave di un SLA software

Non tutti gli SLA sono uguali. Alcuni sono generici e quasi inutili ("ci impegniamo a rispondere in tempi ragionevoli"), altri sono dettagliati e davvero tutelanti. Ecco i parametri che contano:

Uptime e disponibilità

L'uptime è la percentuale di tempo in cui il sistema è operativo e raggiungibile. Si esprime in percentuale su base annua o mensile. I valori più comuni:

• 99% uptime = circa 87 ore di downtime ammesse all'anno. Troppo per la maggior parte dei business.
• 99,9% uptime (i famosi "tre nove") = circa 8,7 ore all'anno. Accettabile per molte applicazioni.
• 99,95% uptime = circa 4,4 ore all'anno. Standard per applicazioni business-critical.
• 99,99% uptime (i "quattro nove") = circa 52 minuti all'anno. Si avvicina alla continuità totale, ma ha costi significativi.

Il numero sembra piccolo, ma la differenza tra 99% e 99,9% è enorme in termini di ore di disservizio. Chiedi sempre a quale livello di uptime si impegna il tuo fornitore, su quale finestra temporale lo misura, e cosa succede se non viene rispettato.

Tempi di risposta e risoluzione (RTO e RPO)

Due acronimi fondamentali che ogni SLA software serio deve specificare:

• RTO (Recovery Time Objective): quanto tempo massimo passa tra la segnalazione del problema e il ripristino del servizio. Es: "RTO di 4 ore per incidenti critici".
• RPO (Recovery Point Objective): a quanto risale l'ultimo dato recuperabile in caso di perdita. Es: "RPO di 1 ora" significa che al massimo perdi un'ora di dati.

Questi due parametri sono critici se gestisci dati sensibili (e-commerce, gestionali, piattaforme con pagamenti). Non accettare un SLA che li omette.

Priorità e classificazione degli incidenti

Un buon SLA software classifica i problemi per gravità e associa a ciascuna categoria un tempo di risposta diverso. Un esempio tipico:

• P1 – Critico: sistema non raggiungibile, perdita di dati in corso. Risposta entro 1 ora, risoluzione entro 4 ore.
• P2 – Alta priorità: funzionalità core compromessa ma sistema parzialmente operativo. Risposta entro 4 ore, risoluzione entro 24 ore.
• P3 – Media priorità: funzionalità secondaria non funzionante, workaround disponibile. Risposta entro 1 giorno lavorativo.
• P4 – Bassa priorità: bug minore o richiesta di miglioramento. Gestito nel normale backlog.

Se nel tuo SLA non c'è questa classificazione, aggiungerla dovrebbe essere la tua prima richiesta al fornitore.

Penali e crediti di servizio

Un SLA senza penali è una dichiarazione di intenti, non un impegno vincolante. Le penali (o service credit) stabiliscono cosa ottieni in cambio se il fornitore non rispetta le garanzie. In genere si esprimono come crediti sulle fatture future o riduzioni del canone mensile proporzionali al tempo di disservizio.

Attenzione: molti SLA standard prevedono penali molto basse o con un tetto massimo (es: "massimo il 10% del canone mensile"). Negozia prima di firmare, specialmente se il software è mission-critical per il tuo business.

Se stai valutando un SLA software per il tuo progetto, possiamo aiutarti a capire cosa chiedere e come negoziarlo: contattaci dalla sidebar per una consulenza gratuita.

SLA software: quando serve davvero

Non tutti i progetti software hanno bisogno dello stesso livello di SLA. Ecco una mappa pratica:

Quando l'SLA è indispensabile

• Hai un e-commerce attivo: ogni ora di downtime è vendite perse.
• Gestisci dati sensibili di clienti o pazienti (sanità, finance, HR).
• La tua operatività dipende dal software (gestionale, CRM, piattaforma di servizi).
• Hai un contratto di assistenza mensile con la software house.
• Il tuo prodotto ha SLA verso i tuoi stessi clienti (es: piattaforma B2B).

Quando un SLA semplice può bastare

• Sito web istituzionale senza transazioni critiche.
• MVP in fase di validazione con utenti limitati.
• Tool interno usato solo in orari d'ufficio.

Anche in questi casi, avere almeno un impegno scritto sui tempi di risposta ti protegge da situazioni spiacevoli. Meglio un SLA leggero che nessun SLA.

Gli errori più comuni quando si valuta un SLA

Negli anni abbiamo visto imprenditori firmare SLA che sembravano ottimi ma si sono rivelati quasi inutili al momento del bisogno. Ecco gli errori più frequenti:

1. Accettare percentuali di uptime senza capire le esclusioni

Quasi tutti gli SLA escludono dal calcolo dell'uptime le manutenzioni programmate, i problemi causati da terze parti (es: AWS down) e i "casi di forza maggiore". Leggi sempre la sezione esclusioni: può svuotare di significato anche un uptime del 99,9%.

2. Non definire la finestra di misurazione

Un uptime del 99,9% mensile equivale a circa 44 minuti di downtime al mese. Ma se quei 44 minuti cadono tutti il venerdì sera durante il tuo picco di traffico, il danno è enorme. Chiedi se si può specificare una finestra di servizio garantita (es: "dalle 08:00 alle 22:00 nei giorni feriali").

3. Confondere "tempo di risposta" con "tempo di risoluzione"

Il fornitore può rispondere al ticket in 30 minuti ma impiegare 3 giorni a risolvere. Sono due metriche distinte. Assicurati che l'SLA le separi chiaramente e fissi limiti su entrambe.

4. Non prevedere un canale di escalation

Cosa succede se il tuo referente abituale è in ferie e hai un P1 in corso? Un buon SLA software deve prevedere un percorso di escalation chiaro: chi contattare, come, e con quale urgenza.

5. Dimenticare i backup

L'SLA dovrebbe specificare con quale frequenza vengono eseguiti i backup, dove vengono conservati e in quanto tempo possono essere ripristinati. È una delle prime domande da fare, ma raramente viene inclusa spontaneamente.

Checklist: cosa deve contenere un SLA software ben fatto

Prima di firmare qualsiasi contratto di manutenzione o assistenza, verifica che l'SLA includa tutti questi punti:

1. Percentuale di uptime garantita con finestra temporale specificata
2. Definizione di downtime: cosa conta come "sistema non disponibile"
3. Esclusioni: cosa non rientra nelle garanzie (manutenzione programmata, terze parti, forza maggiore)
4. Classificazione degli incidenti per priorità (P1-P4 o equivalente)
5. Tempi di risposta e risoluzione per ogni livello di priorità
6. RTO e RPO in caso di disaster recovery
7. Frequenza e policy dei backup
8. Canale di segnalazione: ticket, email, telefono, chat
9. Percorso di escalation con contatti nominativi
10. Penali o service credit in caso di mancato rispetto
11. Modalità di misurazione e reportistica: chi monitora, con quale tool, con quale frequenza vengono condivisi i report
12. Durata e rinnovo dell'accordo

Se il tuo fornitore non è disposto a mettere per iscritto anche solo la metà di questi punti, è un segnale da non ignorare.

Come negoziare un SLA con la tua software house

Molte software house hanno un template di SLA standard che propongono a tutti i clienti. Non è detto che faccia al caso tuo. Alcune indicazioni pratiche per la negoziazione:

Parti dai tuoi rischi reali. Prima di sederti al tavolo, calcola quanto ti costa un'ora di downtime. Se il tuo e-commerce genera 500€/ora, un SLA con RTO di 8 ore ti espone a 4.000€ di perdita potenziale. Usare questi numeri rende la negoziazione molto più concreta.

Non fermarti al prezzo del canone. Un SLA più stringente spesso comporta costi aggiuntivi (reperibilità H24, infrastrutture ridondanti). Valuta il costo in proporzione al rischio che copre, non in assoluto.

Chiedi referenze su come gestiscono gli incidenti. Un buon fornitore ha un processo collaudato e ti mostrerà come funziona. Diffida di chi ti rassicura solo a parole.

Rivedi l'SLA ogni anno. Il tuo business cresce, il software evolve, i requisiti cambiano. Un SLA firmato tre anni fa potrebbe non coprire le funzionalità aggiunte nel frattempo. Inserisci una clausola di revisione periodica.

Conclusione

Un SLA software non è burocrazia: è la misura concreta di quanto il tuo fornitore si fida del proprio lavoro. Un partner serio non ha problemi a firmare garanzie precise su uptime, tempi di risposta e recovery. Anzi, te le propone lui.

Se invece il fornitore glissa, rimanda o propone formule vaghe, hai una risposta importante sulla qualità del servizio che ti aspetta. Prendila sul serio prima di firmare, non dopo il primo incidente.

Hai bisogno di supporto per valutare o negoziare un SLA per il tuo progetto? Scrivici: trovi il form di contatto qui a destra. Analizziamo insieme il contratto e ti diciamo cosa manca.