Che cos'è un Service Level Agreement (SLA) per le soluzioni SaaS?

Quando si tratta di valutare le maggiori minacce alle entrate e alla reputazione di un'azienda, è facile concentrarsi su risposte ovvie come concorrenti del settore o un servizio clienti scadente, che costa alle aziende circa 75 miliardi di dollari ogni anno.

Ma una minaccia che viene costantemente trascurata?

Tempi di inattività del Software as a Service (SaaS).

Entro la fine del 2021, la forza lavoro americana avrà installato circa 380 milioni di soluzioni SaaS, il che significa che la stragrande maggioranza delle aziende dovrà affrontare gravi perdite di entrate se il proprio software aziendale si guasta o subisce interruzioni.

Dopotutto, i loro clienti non saranno in grado di effettuare ordini, accedere al sito Web dell'azienda, connettersi ai rappresentanti dei clienti tramite telefono o persino ricevere annunci pubblicitari automatizzati.

Gli studi dimostrano che le piccole imprese sono spesso colpite in modo sproporzionato dai tempi di inattività SaaS, con oltre il 37% che segnala una perdita di clienti e il 26% che riporta perdite di entrate comprese tra $ 10.000 e $ 20.000 all'ora a causa di guasti del sistema.

Per proteggere le aziende e i profitti dalle conseguenze dei tempi di inattività, è necessario disporre di un accordo sul livello di servizio (SLA) tra un provider SaaS e l'azienda che utilizza il software.

Ma cos'è uno SLA e cosa dovrebbe includere uno con un provider SaaS?

Continuate a leggere per scoprirlo.

Sommario

• Che cos'è un accordo sul livello di servizio per SaaS?
• Cosa dovrebbe includere uno SLA SaaS?
• Best practice per gli SLA SaaS
• I vantaggi di uno SLA
• Domande frequenti sul contratto di servizio

Che cos'è un accordo sul livello di servizio per SaaS?

Un esempio di un processo di sviluppo SLA. (Fonte immagine)

Prima di entrare nei dettagli, rispondiamo innanzitutto alla domanda di base: "Cos'è un accordo sul livello di servizio?"

Nel mondo SaaS aziendale, un Service Level Agreement, spesso indicato semplicemente come "Accordo SaaS", è un documento legale e un contratto che definisce chiaramente sia ciò che il prodotto del fornitore SaaS fornirà sia ciò che il cliente si aspetta di ricevere dal fornitore SaaS .

Si noti che lo SLA può essere un documento autonomo o esistere come parte di un contatto fornitore SaaS più ampio.

Tutti i diversi tipi di soluzioni SaaS, comprese le soluzioni CPaaS come le piattaforme VoIP aziendali e gli strumenti di conferenza Web , dovrebbero offrire un Service Level Agreement al fine di proteggere sia il cliente che il provider.

Parleremo più avanti in modo più dettagliato di quali metriche SLA dovrebbero essere incluse in un accordo, ma in generale includeranno informazioni relative a:

• I servizi e le capacità specifici forniti dallo strumento
• Modalità di misurazione della qualità di tali servizi
• Tempo di attività garantito del software
• Fatturazione
• Sicurezza e conformità
• Le sanzioni da imporre al provider SaaS in caso di mancato rispetto delle garanzie
• Esclusioni per le quali il provider non dovrà pagare penali o essere in alcun modo responsabile della manutenzione del software per errore dell'utente, ecc.

Cosa dovrebbe includere uno SLA SaaS?

Un esempio della sezione del tempo di risposta di uno SLA. (Fonte immagine)

Gli SLA SaaS sono composti da due elementi principali: contratti di servizio e gestione del servizio.

I contratti di servizio (a volte chiamati garanzie) si riferiscono alle caratteristiche e funzionalità specifiche che il software fornisce all'utente finale.

Ad esempio, la sezione dei contratti di servizio di un PBX cloud SLA garantirebbe che la piattaforma di cloud computing offra funzionalità come chiamate locali illimitate, registrazione delle chiamate, chiamate in conferenza, ecc.

La gestione del servizio riguarda il modo in cui verrà misurato il livello di servizio per garantire il rispetto degli accordi di servizio. Descriverà le metriche per misurare la qualità del servizio, le procedure di risoluzione delle controversie e di escalation e i processi di segnalazione.

Di seguito, daremo un'occhiata più da vicino agli elementi più specifici di uno SLA per i sistemi SaaS.

Tempo di attività garantito

Il tempo di attività garantito di una soluzione SaaS delinea la percentuale di tempo in cui il software funzionerà correttamente, rimarrà online e aderirà con successo agli standard di servizio chiariti nello SLA.

Sebbene lo standard del settore sia un tempo di attività garantito del 99,9% (il che significa che il tempo di inattività del software è solo dello 0,1%) la maggior parte dei fornitori di software oggi offre un tempo di attività del 99,99%.

Questa è la parte più importante dell'accordo, poiché nessuno degli altri aspetti dello SLA può essere soddisfatto se lo strumento non funziona nemmeno correttamente.

L'accordo definisce anche come viene misurata la quantità di fermo macchina.

Questo calcolatore online consente di determinare facilmente la durata dei tempi di inattività consentiti ai sensi dell'accordo SLA. Ad esempio, un tempo di attività del 99,99% significa che ogni anno sono accettabili solo 52 minuti e 36 secondi di inattività ai sensi dello SLA.

Il "tempo di inattività" dovrebbe iniziare nel momento in cui il software va offline o smette di essere in grado di soddisfare le garanzie delineate nello SLA.

Metriche delle prestazioni e KPI

Una volta definiti i contratti di servizio (tempo di attività, caratteristiche+funzionalità, ecc.), è il momento di determinare le metriche e i KPI che utilizzerai come benchmark per misurare la qualità del servizio.

Sebbene alcuni desiderino includere il maggior numero possibile di punti dati specifici, requisiti minimi, processi di gestione e funzionalità durante la stesura dello SLA, è molto più efficace determinare quali metriche sono i migliori indicatori di successo.

Mantieni le aspettative alte, ma anche realistiche ed eque. Le aziende che utilizzano il SaaS dovrebbero concentrarsi sulle metriche che sono in linea con i loro obiettivi di business.

Ricorda, più requisiti e livelli di servizio più elevati richiedono questi utenti finali, più fornitori SaaS vorranno addebitare i loro servizi.

Dopotutto, gli SLA devono proteggere entrambe le parti.

Quando sviluppi le metriche, sii il più specifico possibile. Ad esempio, invece di richiedere un "tempo di attività elevato", definirlo un "tempo di attività minimo del 99,999%".

Lo SLA copre anche i tassi di errore accettabili (tassi di difetto), un numero massimo di problemi di sicurezza mensili e persino obiettivi di prestazioni specifici come un numero prestabilito di lead mensili o un aumento percentuale dei tassi di risoluzione della prima chiamata .

Infine, considera la metodologia utilizzata per monitorare e valutare questi KPI e livelli di prestazioni.

Il provider probabilmente vorrà offrire le proprie valutazioni delle prestazioni che i clienti possono visualizzare in un portale online. Sebbene siano ancora preziose, queste valutazioni favoriranno senza dubbio il fornitore e cercheranno "scappatoie" nei risultati dello SLA.

Di conseguenza, i clienti potrebbero voler investire in strumenti di terze parti o revisori di standard di servizio per garantire che le loro esigenze siano veramente soddisfatte.

Tempi di risposta e requisiti di disponibilità del supporto

I tempi di risposta definiscono la quantità di tempo che il fornitore/cliente ha a disposizione per rispondere a un problema di erogazione del servizio e per risolverlo.

Quando si delineano i tempi di risposta richiesti, i clienti dovrebbero dare la priorità a problemi di supporto specifici e sviluppare il periodo di tempo in cui i problemi del servizio clienti dovrebbero essere affrontati e risolti.

"Priorità 1" sarebbe probabilmente una perdita completa del servizio, mentre "Priorità 2" potrebbe essere la perdita di una caratteristica/funzione specifica e così via. Maggiore è la priorità, minore dovrebbe essere il tempo necessario per rispondere.

Ad esempio, se si verifica una perdita completa delle prestazioni del servizio e l'intero sistema va offline, il provider dovrebbe rispondere entro 30 minuti o un'ora, con un tempo di risoluzione target di 8 ore.

Oltre ai tempi di risposta, l'accordo dovrebbe anche definire chiaramente i requisiti di assistenza clienti che il fornitore deve offrire: i canali di assistenza specifici che il fornitore deve offrire.

I requisiti di supporto comuni potrebbero includere:

• Servizio di assistenza e assistenza 24 ore su 24, 7 giorni su 7
• Un responsabile del successo dei clienti dedicato
• Assistenza telefonica prioritaria
• Supporto omnicanale
• Supporto e-mail
• Supporto per chat dal vivo

Sanzioni ed esclusioni

La sezione sanzioni ed esclusioni delinea cosa accadrà se il cliente o il fornitore non soddisfa le garanzie o non soddisfa gli standard di prestazione definiti dallo SLA.

Mentre i clienti possono pensare che questa sezione generalmente li avvantaggia, la realtà è che esiste altrettanto per proteggere il fornitore.

I fornitori di solito preferiscono che esistano sanzioni sotto forma di crediti di servizio, il che significa che dedurranno una percentuale della fattura o forniranno funzionalità/servizi gratuiti per un determinato periodo di tempo se non rispettano le linee guida SLA.

Per un esempio dettagliato di come vengono calcolati i crediti di servizio, dai un'occhiata a questo esempio di SLA Dynatrace .

Sebbene questa sia una buona soluzione se il cliente è soddisfatto della qualità complessiva del provider, non servirà molto se è chiaro che il software non può soddisfare le esigenze dell'azienda.

Invece, i clienti chiederanno spesso rimborsi.

Oltre a queste sanzioni, questa sezione delineerà anche le esclusioni, cose che il fornitore non è responsabile di fornire o pagare quando la colpa è del cliente.

Ad esempio, se il software è andato offline perché il cliente non ha fornito le informazioni di fatturazione corrette, il provider non sarà ritenuto responsabile.

Questa sezione può includere anche la clausola di indennizzo, che delinea le responsabilità e le limitazioni legali di entrambe le parti in caso di causa.

Privacy e sicurezza

Questa sezione dovrebbe discutere le misure di sicurezza messe in atto, nonché la protezione dei dati e la privacy. (Si noti che nella maggior parte dei casi, un'informativa sulla privacy più lunga è inclusa nell'accordo SaaS generale.

Assicurati che sia disponibile un linguaggio chiaro in merito alla proprietà dei dati, nonché alle modalità con cui tali dati vengono trasferiti e archiviati.

Delineare le restrizioni di accesso ai dati, per quanto tempo i dati possono essere archiviati e che entrambe le parti comprendano come l'altra potrebbe utilizzare i propri dati.

Questo è anche il luogo per coprire la crittografia dei dati, la conformità HIPAA , i requisiti normativi e la risposta a qualsiasi tipo di violazione dei dati o minaccia alla sicurezza.

Struttura dei prezzi e della fatturazione

Lo SLA dovrebbe anche avere una sezione sulle strutture dei prezzi e della fatturazione.

Questo dovrebbe definire il costo per utente, la durata del contratto, la frequenza di fatturazione (mensile, annuale, trimestrale, ecc.) e la ripartizione specifica dei costi dei servizi.

Assicurati che la sezione distingua tra il costo dei servizi mensili/annuali e le tariffe una tantum di installazione/impostazione.

Richiedi una ripartizione riga per riga di costi e commissioni e assicurati che ciascuno possa essere spiegato chiaramente. Vanno eliminati o chiariti un linguaggio vago come " spese di servizio ".

Questo è anche il punto in cui dovrebbero essere discusse le spese di risoluzione anticipata/cancellazione.

Definire cosa costituisce una risoluzione anticipata, la tariffa esatta e delineare le circostanze in cui la tariffa di risoluzione verrebbe revocata (ad esempio, i clienti hanno il diritto di recedere se lo strumento SaaS non ha fornito i servizi garantiti nello SLA.)

Infine, assicurati che ci sia spazio per la rinegoziazione dei prezzi una volta scaduto il contratto iniziale ed evita un programma di rinnovo automatico.

Best practice per gli SLA SaaS

(Fonte immagine)

Al fine di garantire che le aziende e i fornitori diano e ricevano il massimo livello di gestione del servizio possibile, seguire l'elenco delle migliori pratiche riportato di seguito.

• Rivedere e aggiornare uno SLA quando l'azienda deve cambiare, se viene aggiornato un piano attuale, se i carichi di lavoro dell'azienda sono cambiati o quando gli standard del settore si sono evoluti
• Assicurati che i KPI SLA e la documentazione siano sviluppati sia dal cliente che dal fornitore, non l'uno o l'altro
• Crea obiettivi di performance realistici
• Includere le revisioni dei documenti richieste dopo un determinato periodo di tempo
• Esamina esempi e modelli di accordi SLA SaaS
• Assicurati che lo SLA sia realizzato per adattarsi a qualsiasi normativa di sicurezza e conformità specifica del settore a cui un'azienda deve aderire
• Prendi in considerazione l'idea di offrire un periodo di grazia 60-120 in cui le sanzioni non verranno applicate come parte di una curva di apprendimento (questo spesso porta a un prezzo più competitivo)

I vantaggi di uno SLA

Gli SLA offrono numerosi vantaggi sia al fornitore che al cliente, tra cui una maggiore responsabilità, protezione legale e una migliore qualità complessiva del servizio.

Ciò significa una maggiore disponibilità del servizio, un flusso di lavoro ininterrotto e un fornitore di servizi IT meno stressato.

Ora che sai di più sugli SLA, è ora di iniziare a esplorare i provider SaaS.

Se la tua azienda ha bisogno di una soluzione CRM , di uno strumento di telecomunicazione, di una piattaforma per conferenze Web compatibile con il tuo provider di servizi Internet o di un software per call center, le nostre tabelle interattive dei principali fornitori SaaS analizzano le funzionalità, i prezzi, i piani e l'esperienza utente per aiutarti a giusta scelta.

Domande frequenti sul contratto di servizio

Di seguito, abbiamo risposto ad alcune delle principali domande frequenti sugli SLA.