CONTRATTI IT: COSA DEVE ESSERCI IN UNO SLA SERIO

Prova a rileggere il contratto di assistenza informatica che hai firmato per la tua azienda. Non l'offerta commerciale, non la brochure: il contratto vero, quello con le clausole. Nella maggior parte dei casi trovi frasi come "interverremo tempestivamente" o "garantiamo la massima efficienza". Suonano bene, ma non significano nulla in termini contrattuali: non sono misurabili, non sono verificabili, e in caso di disservizio non ti danno alcuna leva.

Uno SLA (Service Level Agreement) serio fa esattamente il contrario: trasforma le promesse generiche in numeri, tempi e responsabilità scritte nero su bianco. Non è burocrazia inutile: è lo strumento che decide se, quando il server si blocca un venerdì pomeriggio, la tua azienda riparte in due ore o resta ferma per due giorni.

COS'È UNO SLA E PERCHÉ NON È LO STESSO DI UN CONTRATTO GENERICO

Un contratto di assistenza informatica generico descrive cosa viene fornito: manutenzione, supporto, gestione della rete. Uno SLA descrive come e in quanto tempo quel servizio viene erogato, con parametri misurabili e conseguenze definite se quei parametri non vengono rispettati.

La differenza pratica è enorme. "Ti aiutiamo quando hai un problema" non è uno SLA. "In caso di guasto bloccante, rispondiamo entro 1 ora lavorativa e interveniamo entro 4 ore" lo è. Il secondo lo puoi verificare, il primo no.

I TRE PARAMETRI CHE OGNI SLA DOVREBBE DEFINIRE

Ogni SLA ben scritto ruota attorno a tre metriche fondamentali. Se il tuo contratto non le definisce con precisione per ciascuna tipologia di guasto, non stai firmando uno SLA: stai firmando una dichiarazione di intenti.

Tempo di risposta e tempo di risoluzione non sono la stessa cosa

È l'equivoco più comune quando si legge un contratto IT senza esperienza tecnica. Il tempo di risposta è quanto ci mette il fornitore a farsi vivo: un tecnico apre il ticket, lo classifica, magari chiama per capire la situazione. Il tempo di risoluzione è quanto ci mette a chiudere davvero il problema.

Un fornitore può rispettare perfettamente un tempo di risposta di 30 minuti e comunque lasciarti fermo per due giorni, se il contratto non specifica anche il tempo di risoluzione. Sono due numeri diversi, e devono comparire entrambi, per ogni livello di priorità.

LE PRIORITÀ: NON TUTTI I GUASTI SONO UGUALI

Uno SLA maturo non promette lo stesso tempo di intervento per un mouse che non funziona e per un server di produzione bloccato. Classifica i guasti per priorità e assegna a ciascuna tempi diversi. Ecco una struttura tipica, a titolo di esempio, di come dovrebbe essere articolata (i numeri concreti vanno negoziati caso per caso in base alle esigenze della tua azienda):

Priorità	Descrizione tipica	Tempo di risposta	Tempo di risoluzione
Critica	Server, rete o gestionale bloccati, attività aziendale ferma	Entro 1 ora lavorativa	Entro 4 ore lavorative
Alta	Malfunzionamento grave ma con soluzioni temporanee disponibili	Entro 2-4 ore lavorative	Entro 1 giorno lavorativo
Media	Problema che rallenta ma non blocca l'operatività	Entro 1 giorno lavorativo	Entro 3 giorni lavorativi
Bassa	Richieste di configurazione, miglioramenti, domande	Entro 2 giorni lavorativi	Concordato caso per caso

Se il tuo contratto attuale non distingue le priorità in questo modo, hai un problema concreto: un guasto critico rischia di essere gestito con la stessa urgenza di una richiesta di configurazione minore, semplicemente perché è arrivata prima in coda.

COSA DEVE ESSERE SCRITTO NERO SU BIANCO

Oltre a tempi e priorità, uno SLA completo dovrebbe definire per iscritto anche questi elementi:

1. Orari di copertura: assistenza solo in orario d'ufficio, oppure copertura estesa o 24/7 per i sistemi critici.
2. Canali di apertura ticket: telefono, email, portale dedicato, e quale canale ha priorità in caso di emergenza.
3. Classificazione delle priorità: come descritto sopra, con criteri chiari per stabilire cosa è "critico" e cosa no.
4. Escalation: cosa succede se i tempi concordati non vengono rispettati. Chi viene coinvolto, con quali tempistiche aggiuntive.
5. Penali o compensazioni: uno SLA senza alcuna conseguenza in caso di mancato rispetto è, di fatto, solo una linea guida interna del fornitore.
6. Esclusioni esplicite: hardware fuori garanzia, software di terze parti non gestito, danni causati da uso improprio.
7. Reportistica periodica: un riepilogo degli interventi, dei ticket aperti e chiusi, utile anche per capire se il numero di guasti sta aumentando nel tempo.
8. Referente dedicato: una persona o un team identificabile, non una casella email generica che risponde "quando può".
9. Durata, rinnovo e recesso: condizioni chiare per uscire dal contratto, senza vincoli sproporzionati.
10. Portabilità dei dati: cosa succede a backup, configurazioni e credenziali se decidi di cambiare fornitore.

LE CLAUSOLE CAPESTRO DA RICONOSCERE PRIMA DI FIRMARE

Alcune formulazioni, in apparenza innocue, servono soprattutto a proteggere il fornitore piuttosto che il cliente. Vale la pena imparare a riconoscerle:

• "Tempi indicativi" o "salvo imprevisti": qualsiasi numero seguito da questa formula non è più un impegno vincolante.
• "Best effort" senza definizione: l'espressione è legittima solo se accompagnata da un tempo massimo comunque garantito.
• Rinnovo tacito con preavviso lunghissimo: contratti che si rinnovano automaticamente e richiedono disdetta con 6 mesi di anticipo riducono di fatto la tua libertà di cambiare fornitore anche se insoddisfatto.
• Nessuna clausola su GDPR e trattamento dati: chi gestisce i tuoi sistemi tratta anche dati personali. Un contratto IT serio include o richiama un accordo sul trattamento dati coerente con il GDPR, che prevede responsabilità precise e sanzioni severe in caso di violazioni.
• SLA "uguale per tutti" senza distinzione di priorità: come visto sopra, è il primo segnale di un contratto scritto per sembrare completo più che per esserlo davvero.

PERCHÉ IL MODELLO DI CONTRATTO INFLUENZA GLI INCENTIVI

Un aspetto spesso sottovalutato: il modo in cui viene fatturata l'assistenza cambia gli incentivi del fornitore. In un contratto a consumo (si paga per ogni intervento), il fornitore guadagna quando qualcosa si rompe. In un contratto a canone fisso come il nostro servizio di assistenza flat, il fornitore guadagna mantenendo i sistemi stabili, perché ogni guasto è un costo per lui, non un ricavo aggiuntivo.

Questo non significa che un canone flat sostituisca automaticamente uno SLA scritto bene: significa che, in un modello flat, gli interessi di cliente e fornitore tendono ad allinearsi verso la prevenzione, il che rende più facile negoziare tempi di risposta stringenti senza discussioni su ogni singolo intervento fatturato a parte.

CHECKLIST: DOMANDE DA FARE PRIMA DI FIRMARE UNO SLA

Prima di sottoscrivere (o rinnovare) un contratto di assistenza IT, verifica di avere risposte chiare a queste domande:

• ☐ Il contratto distingue almeno 3-4 livelli di priorità dei guasti?
• ☐ Per ogni priorità sono indicati sia il tempo di risposta sia il tempo di risoluzione?
• ☐ Sono specificati gli orari di copertura (ufficio, esteso, 24/7)?
• ☐ È previsto un meccanismo di escalation se i tempi non vengono rispettati?
• ☐ Sono previste penali o compensazioni concrete in caso di inadempienza?
• ☐ Le esclusioni (cosa non è coperto) sono elencate esplicitamente?
• ☐ Esiste un referente identificabile, non solo un ticket generico?
• ☐ Sono chiare le condizioni di recesso e la portabilità di dati e credenziali?
• ☐ Il contratto richiama in modo esplicito gli obblighi in materia di trattamento dati e GDPR?

Se hai risposto "no" o "non lo so" a più di due domande, è il momento di chiedere una revisione al tuo fornitore attuale, o quantomeno di farti spiegare per iscritto ciò che oggi è solo verbale.