De fleste SLA’er ser ens ud på papiret: “99,9 % oppetid” og “svar inden for 15 minutter”. Men når serveren står, opdager mange SMV’er, at aftalen ikke lover, hvornår tingene virker igen. En stærk SLA til din IT-leverandør skal binde både responstid, løsningstid, bod og NIS2-krav sammen. Her får du de konkrete tal og krav, du skal have på plads inden næste kontraktforhandling.

Key takeaways

• Oppetid alene siger intet. Kræv at det defineres 24/7 eller i arbejdstid, og at planlagt vedligehold står sort på hvidt.
• Løsningstid er vigtigere end responstid. Et hurtigt svar redder ikke forretningen — en garanteret P1-løsningstid på 1-4 timer gør.
• Bod skal være automatisk. Service credits “på anmodning” bliver aldrig udløst. Kræv automatisk kreditering ved brud.
• NIS2 ændrer spillet. Din leverandør skal kunne levere early warning inden for 24 timer og fuld rapport inden for 72 timer.
• Mål på MTTR og FCR. Grønne lamper i et dashboard betyder ikke, at dine medarbejdere kan arbejde.

Hvad koster 99,9 % oppetid reelt i nedetid?

Procenter lyder ens, men forskellen er stor, når du regner den om til minutter og kroner. Her er den simple matematik for et helt år:

Oppetid	Tilladt nedetid pr. år	Pr. måned
99 %	ca. 87,6 timer	ca. 7,3 timer
99,9 %	ca. 8,7 timer	ca. 43 minutter
99,99 %	ca. 52 minutter	ca. 4 minutter

Springet fra 99 % til 99,9 % fjerner næsten 80 timers nedetid. Springet fra 99,9 % til 99,99 % koster ofte markant mere i redundans og bemanding — og giver kun 8 timer ekstra oppetid. Regn på det: Hvad koster én times nedetid for jeres ordreflow eller produktion? Ganger du det op, kan du se, om 99,99 % er pengene værd, eller om 99,9 % rækker.

Bemærk fælden: En oppetidsprocent er værdiløs, hvis den ikke definerer, om den gælder 24/7 eller kun i arbejdstiden — og om planlagt vedligehold trækkes fra (kilde: N-able, 2025). Kræv at begge dele står skrevet ned.

Hvorfor responstid uden løsningstid er en fælde

Mange kontrakter lover “svar inden for 15 minutter”. Det lyder betryggende, men et svar er bare en kvittering. Det siger intet om, hvornår systemet kører igen.

Før: SLA’en garanterer 15 minutters responstid, men intet om resolution. Leverandøren “kigger på det” i timevis, mens I taber omsætning — uden at bryde aftalen.

Efter: SLA’en garanterer både 15 minutters responstid og 1-4 timers løsningstid for P1-sager. Nu er der en tydelig deadline for, hvornår driften skal være genoprettet (kilde: TechPro Comp).

Kræv derfor tre ting adskilt i aftalen:

• Responstid: Tid til første menneskelige kvittering.
• Løsningstid (resolution): Tid til driften er genoprettet — bundet til prioritet.
• Prioritetsniveauer (P1-P4): Klar definition af, hvad der er kritisk, og hvad der kan vente.

Bed også om eskaleringstriggere: En velkørende leverandør eskalerer automatisk ved 66 % og 85 % af SLA-tiden, så en sag ikke bryder aftalen i stilhed (kilde: NOCDOC, 2026).

Hvad dækker 1., 2. og 3. level support egentlig?

Support-niveauer nævnes ofte uden at blive forklaret. Kort fortalt:

• 1. level: Service desk. Nulstilling af adgangskoder, kendte fejl, brugerspørgsmål. Her løses de fleste sager hurtigt.
• 2. level: Teknikere med dybere adgang. Server-, netværks- og applikationsfejl, der kræver konfiguration.
• 3. level: Specialister og leverandørkontakt. Komplekse fejl i Azure, Microsoft 365 eller sikkerhedshændelser.

Det interessante tal er First Contact Resolution (FCR) — hvor stor en andel af sager, der løses i 1. level uden eskalering. Høj FCR betyder hurtigere hverdag for dine medarbejdere. Bed om at få eskaleringstider mellem niveauerne skrevet ind, så en sag ikke ligger og venter mellem to teams.

Sådan sikrer NIS2 kravene i din SLA

Sikkerhed er rykket fra “best effort” til fast SLA-krav. Med NIS2 kan din leverandørs incident response direkte afgøre, om din virksomhed står imod et tilsyn.

NIS2 kræver, at signifikante hændelser meldes med early warning inden for 24 timer og en fuld rapport inden for 72 timer (kilde: ENISA/NIS2-direktivet). Kan din leverandør ikke levere de tidsrammer, kan du ikke overholde loven. Punktum.

Skriv derfor disse sikkerheds-SLA’er eksplicit ind:

• Incident notification: Din leverandør varsler dig hurtigt nok til, at du kan nå 24-timers fristen.
• Sikkerhedspatching: Faste frister for kritiske patches — fx 48 timer for kritiske sårbarheder.
• Data recovery: Garanteret genoprettelsestid (RTO) og hvor gammelt data må være (RPO).

Læs mere om, hvordan compliance og drift hænger sammen under it-sikkerhed og compliance.

Tjekliste: 8 krav til din SLA før du skriver under

1. Oppetid med definition. Gælder tallet 24/7 eller i arbejdstid? Er planlagt vedligehold ekskluderet? Kig efter et konkret servicevindue.
2. Responstid pr. prioritet. Fx 15 min. for P1. Kig efter, at det er en menneskelig kvittering, ikke en auto-mail.
3. Løsningstid pr. prioritet. Fx 1-4 timer for P1. Kig efter, at resolution er adskilt fra response.
4. Automatiske service credits. Kig efter, at bod udløses automatisk — ikke “på anmodning”.
5. NIS2 incident response. 24/72-timers rapportering. Kig efter varslingskæden til dig.
6. Måltal. MTTR, FCR og SLA-brud-rate rapporteres månedligt. Kig efter gennemsigtighed.
7. Eskaleringstriggere. Auto-eskalering ved 66 % og 85 % af SLA-tiden.
8. Undtagelser. Læs klausuler om force majeure og vedligehold. Kig efter, at de ikke udhuler garantien.

Hvordan bør bod ved SLA-brud struktureres?

Bod skal gøre ondt på leverandøren, ellers ændrer det ikke adfærd. Den klassiske fælde er service credits, der kun udbetales “på anmodning” — de bliver aldrig krævet i praksis.

Før: Bod udløses kun, hvis du selv opdager bruddet og sender en anmodning. Realiteten: Det sker aldrig, og leverandøren betaler intet.

Efter: Bod krediteres automatisk på næste faktura ved dokumenteret brud — fx 5-20 % af den månedlige fee afhængigt af alvor (kilde: Digacore). Nu er incitamentet flyttet det rigtige sted hen.

Tydelige SLA’er kan i sig selv reducere de årlige IT-omkostninger med op til 24 %, fordi færre sager eskalerer og driften bliver forudsigelig (kilde: Netguru).

Fra SLA til XLA: Måler du det rigtige?

En server kan have grønt lys, mens dine medarbejdere ikke kan logge på. Derfor bevæger flere sig mod XLA — Experience Level Agreements — der måler den reelle brugeroplevelse frem for kun serverstatus (kilde: Gartner).

Du behøver ikke droppe din SLA. Suppler den med to enkle mål: brugertilfredshed (CSAT) efter løste sager og login-/svartider på de systemer, folk faktisk bruger. Så ser du, om driften virker for mennesker — ikke kun for maskiner.

Samme logik gælder AI. Når leverandøren bruger AI-service desk til at løse 40-60 % flere sager automatisk, bør en del af den gevinst afspejles i din pris eller dine SLA-mål (kilde: sa.global, 2026). Spørg konkret ind til det ved næste forhandling.

FAQ om SLA til IT-leverandør

Hvad er forskellen på responstid og løsningstid i en SLA?

Responstid er tiden til leverandøren kvitterer for din sag. Løsningstid er tiden til driften er genoprettet. Kræv altid begge dele — en hurtig kvittering hjælper ikke, hvis systemet står i timevis.

Hvilken oppetid bør en SMV kræve?

Tommelfingerregel: 99,9 % rækker for de fleste kontormiljøer og giver ca. 8,7 timers tilladt nedetid om året. Kræv 99,99 % kun for systemer, hvor hver times nedetid koster mere, end den ekstra redundans koster.

Hvad skal en SLA indeholde for at leve op til NIS2?

Den skal sikre, at du kan sende early warning til myndighederne inden for 24 timer og fuld rapport inden for 72 timer. Det kræver en varslingskæde fra leverandøren til dig plus faste frister for sikkerhedspatching og data recovery.

Hvordan sikrer jeg, at bod ved SLA-brud faktisk udbetales?

Kræv automatiske service credits, der krediteres på fakturaen ved dokumenteret brud — typisk 5-20 % af den månedlige fee. Undgå formuleringer med “på anmodning”, da de sjældent udløser noget.

Hvad betyder 1., 2. og 3. level support?

1. level er service desk med hurtige, kendte sager. 2. level er teknikere med server- og netværksadgang. 3. level er specialister til komplekse fejl i fx Azure eller sikkerhedshændelser. Bed om eskaleringstider mellem niveauerne.

Hvilke måltal er vigtigere end oppetid?

MTTR (gennemsnitlig løsningstid), FCR (andel løst ved første kontakt) og SLA-brud-rate. De viser den reelle kvalitet bedre end en oppetidsprocent. Kræv månedlig rapportering på dem.

Bør AI-automatisering påvirke min SLA?

Ja. Når leverandøren løser flere sager automatisk, bliver driften billigere for dem. Bed om, at en del af gevinsten afspejles i pris eller i skarpere løsningstider ved næste forhandling.

Sådan kommer du videre — konkrete skridt

1. Find din nuværende SLA og marker, hvor der står oppetid, responstid og løsningstid — og hvor der ikke gør.
2. Regn én times nedetid om til kroner for dine vigtigste systemer. Brug tallet til at vælge mellem 99,9 % og 99,99 %.
3. Tjek, om bod er automatisk eller “på anmodning”. Er den på anmodning, skal den genforhandles.
4. Kortlæg NIS2-varslingskæden: Kan din leverandør nå 24/72-timers fristerne? Ellers dumper du et tilsyn.
5. Bed om de seneste tre måneders MTTR, FCR og SLA-brud-rate. Får du dem ikke, mangler du gennemsigtighed.
6. Book et uforpligtende SLA-tjek og få hullerne dokumenteret, inden du forlænger kontrakten.