När kunden är beroende av att en digital tjänst fungerar behöver båda parter veta vad som händer när den inte gör det. Hur snabbt ska någon svara? När ska tjänsten fungera igen? Och hur följer ni upp leveransen? Ett tydligt SLA gör förväntningarna konkreta.
Vad är ett SLA-avtal?
Ett SLA, Service Level Agreement, är en överenskommelse om vilken servicenivå en leverantör ska hålla. För SaaS- och IT-tjänster kan det reglera tillgänglighet, supporttider, incidenthantering och vad som händer om leverantören inte når den avtalade nivån. På svenska används även begreppet servicenivåavtal.
SLA kan vara en bilaga till kundavtalet. Det behöver inte vara ett separat dokument, men villkoren ska vara möjliga att hitta, förstå och följa upp.
När behöver ett SaaS- eller IT-bolag ett SLA?
Ett SLA är särskilt användbart när avbrott påverkar kundens dagliga arbete, försäljning eller möjlighet att betjäna sina egna kunder. Det gäller exempelvis affärssystem, bokningsplattformar, driftstjänster och andra lösningar som används löpande.
Behovet påverkas av hur kritisk tjänsten är. En intern planeringstjänst som främst används under kontorstid kan behöva andra nivåer än en plattform där transaktioner sker dygnet runt.
Börja därför med kundens faktiska användning. Vad behöver fungera, när behöver det fungera och vilka konsekvenser får ett avbrott? Det ger en bättre grund än att välja en hög procentsats för att den ser bra ut i en offert.
Vad är skillnaden mellan kundavtal, SLA och supportavtal?
Dokumenten hänger ihop men fyller olika funktioner:
| Dokument | Huvudsaklig funktion |
|---|---|
| Kund- eller SaaS-avtal | Reglerar affären, användningsrätten, priset, ansvaret och avtalstiden. |
| SLA | Beskriver mätbara servicenivåer och hur avvikelser hanteras. |
| Supportavtal | Förklarar vilken hjälp som ingår, hur den beställs och vad som kostar extra. |
Undvik motstridiga besked. Om supportavtalet anger kontorstid och SLA lovar incidenthantering dygnet runt behöver det framgå hur åtagandena ska fungera tillsammans.
1. Definiera vad som ska vara tillgängligt
Formuleringen ”tjänsten ska vara tillgänglig” lämnar flera frågor obesvarade. Räcker det att startsidan går att öppna, eller måste kunden kunna genomföra en viss aktivitet?
Beskriv vilken funktion som mäts, var mätningen sker och vilken datakälla som används. Bestäm även hur delvisa fel ska bedömas. Ett system kan vara igång samtidigt som inloggning eller betalning inte fungerar.
Ett praktiskt arbetssätt är att utgå från några centrala användarflöden. Då blir det lättare att bedöma om tjänsten fungerar på det sätt kunden behöver.
2. Ange mätperiod och undantag
En tillgänglighetssiffra behöver alltid ett sammanhang. Ska den beräknas per kalendermånad, kvartal eller år? Avser den dygnets alla timmar eller bara en avtalad serviceperiod?
Räkneexempel: En månad med 30 dagar innehåller 43 200 minuter. Om hela månaden ingår i mätningen motsvarar 99,9 procents tillgänglighet högst 43,2 minuters otillgänglighet. Vid 99,5 procent blir motsvarande tid 216 minuter. Exemplet förutsätter att inga avbrott undantas.
Planerat underhåll kan behandlas separat, men ange då när det får ske, hur lång tid det får ta och hur kunden informeras. Även andra undantag behöver avgränsas. Ett generellt undantag för alla underleverantörsfel kan göra åtagandet svårt för kunden att värdera.
3. Skilj på svarstid och återställningstid
Begreppen beskriver olika saker:
- Svarstid: tiden tills leverantören ger en avtalad första respons.
- Tid till påbörjad hantering: tiden tills någon börjar arbeta med incidenten.
- Återställningstid: tiden tills tjänsten fungerar igen, eventuellt genom en tillfällig lösning.
- Tid till permanent rättning: tiden tills grundproblemet är åtgärdat.
Att svara inom en timme betyder alltså inte att felet är löst inom en timme. Beskriv också när klockan börjar gå och om tiden räknas under kontorstid eller dygnet runt. Ange vilka tider som är bindande åtaganden och vilka som är mål.
4. Prioritera incidenter utifrån påverkan
Alla fel kräver inte samma insats. En gemensam prioriteringsmodell gör det enklare att lägga resurserna rätt.
| Exempel på nivå | Exempel på påverkan | Fråga att reglera |
|---|---|---|
| Kritisk | En central funktion är helt utslagen utan fungerande alternativ. | Vem aktiverar hanteringen och hur ofta får kunden information? |
| Hög | En viktig funktion är kraftigt begränsad. | Vilken hantering gäller om det finns en tillfällig lösning? |
| Normal | En begränsad funktion fungerar fel men arbetet kan fortsätta. | Hur prioriteras rättningen? |
| Låg | Mindre avvikelse eller fråga med liten verksamhetspåverkan. | Hanteras detta som incident, supportfråga eller förbättringsförslag? |
Tabellen är ett exempel, inte en standard som passar alla tjänster. Kom överens om vem som sätter nivån och hur den kan ändras när ny information kommer fram.
5. Beskriv kundens medverkan
Leverantören kan behöva loggar, kontakt med en behörig person eller tillgång till en testmiljö för att felsöka. Skriv vad kunden ska bidra med och hur kommunikationen ska ske.
Om en tidsmätning får pausas i väntan på kundens medverkan behöver det vara tydligt när det är tillåtet. Dokumentera också varför hanteringen väntar och vad som krävs för att fortsätta.
6. Bestäm vad som händer när nivån inte uppnås
Servicekrediter innebär att kunden får en avtalad kreditering när vissa servicenivåer inte hålls. De är en möjlig avtalslösning, inte en automatisk följd av varje driftstopp.
Reglera hur krediten beräknas, vilken avgift den baseras på, eventuella tak och om kunden behöver begära den inom en viss tid. Förklara också hur den förhåller sig till skadestånd, uppsägning och andra rättigheter i huvudavtalet.
Återkommande avvikelser kan behöva hanteras genom en åtgärdsplan och särskild uppföljning. En kreditering löser inte kundens behov av en fungerande tjänst.
7. Gör SLA möjligt att följa upp
Ett SLA bör kunna användas av dem som arbetar med leveransen. Bestäm vem som tar fram rapporter, hur ofta uppföljning sker och hur parterna hanterar olika uppfattningar om mätresultaten.
Kontrollera även att era egna drift- och molnleverantörer stödjer kundlöftena. Om ni säljer support dygnet runt behöver bemanning, eskalering och kostnad fungera även utanför ordinarie arbetstid.
Vanliga frågor om SLA
Är 99,9 procents tillgänglighet alltid tillräckligt?
Nej. Det beror på tjänstens betydelse för kunden, mätperioden och undantagen. Bedöm även vilka funktioner som mäts och hur snabbt verksamheten kan återhämta sig efter ett avbrott.
Betyder support dygnet runt att alla fel löses direkt?
Nej. Öppettider, svarstider och tider för återställning är olika åtaganden och behöver beskrivas var för sig.
Måste alla SaaS-tjänster ha ett separat SLA?
Servicenivåer kan ingå direkt i kundvillkoren. En separat bilaga kan vara praktisk när åtagandena är mer omfattande eller skiljer sig mellan olika tjänstepaket.
Kan vi använda en SLA-mall?
Ett branschanpassat standardavtal kan ge en struktur. Nivåerna behöver fyllas i utifrån er tjänst, bemanning, mätning och de löften ni kan hålla.
Gör servicenivåerna tydliga från början
Swedish Software ger medlemmar tillgång till branschavtal och juridisk rådgivning kring avtalen. Det ger stöd när ni vill skapa tydliga överenskommelser med kunderna.
Läs om medlemskapet och bli medlem
Läs också:
Artikeln ger generell information och ersätter inte juridisk rådgivning i ett enskilt fall.