SLA-avtalet är det som avgör vad ni faktiskt får när något går fel, inte marknadsföringstexten på leverantörens hemsida. Ändå är det ofta den del av upphandlingen som får minst uppmärksamhet. Här är vad ni bör kontrollera innan ni skriver på.
Vad är ett SLA-avtal?
SLA (Service Level Agreement) är det avtal som definierar exakt vilken servicenivå ni köper, svarstider, åtgärdstider, tillgänglighet och vad som händer om leverantören inte lever upp till det utlovade.
Checklista , det här bör ingå
1. Svarstid vs åtgärdstid
Två helt olika saker som ofta blandas ihop, se vår fördjupande guide om vad ett SLA-avtal faktiskt innebär för en full genomgång av skillnaden. I en driftkontext är åtgärdstiden extra viktig att specificera per systemtyp: en kraschad databas kräver oftast en annan åtgärdstid än en enskild långsam tjänst.
2. Definierade allvarlighetsnivåer
Ett kritiskt driftstopp bör hanteras helt annorlunda än en mindre, icke-akut fråga. Ett bra SLA delar upp ärenden i nivåer (till exempel kritisk, hög, normal) med olika svars, och åtgärdstider för varje.
3. Tillgänglighetsgaranti (uptime)
Vanligtvis uttryckt i procent, till exempel 99,9 procent tillgänglighet. Kontrollera hur den mäts, över vilken period, och vad som räknas som planerat underhåll kontra oplanerat avbrott.
4. Ansvarsfördelning
Vad ingår, och vad ingår inte? Gråzoner mellan drift, hosting och applikationsansvar är en vanlig källa till konflikt när något går fel och ingen part vill ta ansvar.
5. Rapportering och uppföljning
Ni ska kunna se status, historik över incidenter och kommande åtgärder utan att behöva efterfråga det. Regelbunden rapportering bygger förtroende och gör det enkelt att följa upp att avtalet faktiskt hålls.
6. Backup- och återställningstider
Specifikt för IT-drift bör avtalet ange hur ofta backup tas, hur länge data sparas, och framför allt hur lång tid en faktisk återställning (restore) tar vid dataförlust, inte bara att backup görs. Det är återställningstiden som avgör hur länge verksamheten faktiskt står still vid en incident.
7. Konsekvenser vid avtalsbrott
Vad händer om leverantören inte når de utlovade nivåerna? Ett SLA utan konsekvenser vid avtalsbrott är i praktiken bara en avsiktsförklaring, inte ett bindande åtagande.
Vanliga fallgropar
- Avtal som bara nämner "hög tillgänglighet" utan konkreta siffror
- Ingen tydlig skillnad mellan svarstid och åtgärdstid
- Ansvarsgränser som inte är definierade mellan drift, hosting och applikation
- Ingen rapporteringsrutin, ni får bara veta när ni själva frågar
Techknight arbetar med tydliga SLA-nivåer för IT-drift och hosting, med transparent rapportering så att ni alltid har insyn i status, incidenter och nästa steg.
Vanliga frågor
Vad är skillnaden mellan svarstid och åtgärdstid i ett SLA?
Svarstid är hur snabbt leverantören bekräftar ärendet. Åtgärdstid är hur snabbt problemet faktiskt är löst. Ett avtal bör ange båda separat.
Vad betyder 99,9 procent tillgänglighet i praktiken?
Det motsvarar ungefär 8,7 timmars möjlig otillgänglighet per år. Kontrollera alltid hur måttet beräknas och vad som räknas som planerat underhåll.
Vad händer om leverantören inte uppfyller SLA:t?
Det bör vara definierat i avtalet, vanligtvis i form av kompensation eller rabatt på avgiften för perioden avtalsbrottet gäller. Ett SLA utan sådana konsekvenser är svårt att hålla leverantören ansvarig för.
Behöver mindre företag ett formellt SLA-avtal?
Ja. Oavsett storlek är ett tydligt SLA det som skyddar er när något går fel, det är ofta ännu viktigare för mindre företag som saknar egna resurser att hantera långa avbrott.
Vem ansvarar om ett fel uppstår mellan hosting och applikation?
Det ska vara tydligt definierat i avtalet innan något händer, annars riskerar ansvarsfrågan att bli en tvist mitt i ett pågående driftstopp.
Fler nyheter
Vill du veta mer?
Hör av dig så berättar vi mer om hur Techknight kan hjälpa er verksamhet.
Kontakta oss