Hvordan opstiller man en SLA med en dansk leverandør?

Forberedelse: Afklar behov, tjenester og ansvar

SLA og driftsaftale dækker to forskellige ting, og begge skal med i aftalen med den danske leverandør. Driftsaftalen beskriver, hvad leverandøren udfører: overvågning, backup, opdateringer og support. SLA'en beskriver, hvor godt det sker: svartider, oppetid og konsekvenser ved brud. Uden SLA mangler driftsaftalen målepunkter; uden driftsaftale mangler SLA'en indhold. Begynd derfor med at liste de tjenester, leverandøren skal levere, og opdel dem i kategorier, der kan måles. Formalize opdeler fx serviceniveauet i fire kategorier: hændelser, tekniske fejl eller mistanke herom, generel support og generel vedligeholdelse.

Afklar ansvaret for grænsefladerne, før I forhandler tal. Underleverandører er almindelige, og Formalize skriver i sin SLA, at selskabet kan bruge underleverandører, men fortsat er ansvarlig for deres udførelse, som hvis Formalize selv havde løst opgaven. Samme SLA har den modsatrettede situation: Ligger årsagen til en kritisk hændelse hos en tredjeparts underleverandør - herunder hosting-, infrastruktur- eller kritiske tjenesteudbydere - suspenderes og/eller forlænges SLA-tiden. Den klausul afgør, hvem der betaler, når fejlen ligger uden for leverandørens egen drift, og den bør læses, inden aftalen underskrives.

Opstil forretningskonsekvensen, før I vælger serviceniveau. Regn på, hvad en times nedetid koster for jeres ordreflow eller produktion, og gang tallet op. Den beregning afgør, om 99,9 % er nok, eller om et højere niveau er pengene værd. Notér samtidig, hvilke processer der afhænger af leverandøren, og hvilke opgaver jeres egne folk stadig løser internt, så SLA'en kun dækker de tjenester, I ikke selv kan levere.

Fastlæg målbare serviceniveauer

Oppetid opgives i procent, men procenten bliver først konkret, når den regnes om til nedetid. På et helt år svarer 99 % til ca. 87,6 timers nedetid (ca. 7,3 timer pr. måned), 99,9 % til ca. 8,7 timer (ca. 43 minutter pr. måned) og 99,99 % til ca. 52 minutter (ca. 4 minutter pr. måned). 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 omkring 8 timer ekstra oppetid. I hostingbranchen betyder 99,9 % oppetid maksimalt 8,76 timers nedetid pr. år, mens premium-hosting garanterer 99,99 %, svarende til under 53 minutter årligt. Formalize bruger i sin egen SLA en tilgængelighed på mindst 99,75 % målt på årsbasis fra aftalens startdato.

En oppetidsprocent er værdiløs, hvis den ikke siger, om den gælder 24/7 eller kun i arbejdstiden, og om planlagt vedligehold trækkes fra (kilde: N-able, 2025). Kræv derfor begge dele nedskrevet. Den danske minimumsliste er: oppetid, fx 99,9 % målt pr. måned, og en beskrivelse af, hvordan den beregnes; servicevindue og undtagelser, dvs. planlagt vedligehold, force majeure og fejl uden for leverandørens ansvar. Uden de tre oplysninger kan to parter måle samme hændelse og nå hver sit tal.

Skil responstid og løsningstid ad i aftalen. Responstid er tiden til første menneskelige kvittering; løsningstid er tiden, til driften er genoprettet, og den skal knyttes til den enkelte prioritet. Et svar på 15 minutter siger intet om, hvornår systemet kører igen - leverandøren kan kigge på sagen i timevis uden at bryde aftalen. Garantér derfor både responstid og løsningstid, fx 15 minutters responstid og 1-4 timers løsningstid for P1-sager. Formalize-eksemplet viser samme mønster: For en kritisk hændelse er responstiden 0,5 time og løsningstiden 4 timer.

Definér prioriteter fra P1 til P4

De fleste IT-SLA'er prioriterer efter forretningspåvirkning. En typisk dansk model: P1 (kritisk) dækker hele virksomheden nede, svartid 15-30 minutter; P2 (høj) dækker en afdeling eller et kernesystem, der er ramt, svartid 1-2 timer; P3 (normal) dækker en enkelt bruger, hvor arbejdet kan fortsætte, svartid 4-8 timer; P4 (lav) dækker ønsker, ændringer og spørgsmål, svartid 1-3 arbejdsdage. Tallene varierer fra aftale til aftale, men prioriteterne skal være defineret på forhånd, så en nedbrudt server ikke havner i samme kø som et printerspørgsmål.

Prioriteringsniveauerne skal have konkrete eksempler, så kunde og leverandør klassificerer samme hændelse ens. Formalize definerer fx »Kritisk« som en enkelt begivenhed eller en række sammenhængende begivenheder, som Formalize ikke har planlagt, og som kompromitterer sikkerheden i netværket og informationssystemerne og skader tilgængeligheden, autenticiteten, integriteten eller fortroligheden af data eller af de tjenester, leverandøren leverer - dvs. at systemet ikke kan tilgås eller indlæses. Som eksempel nævnes »Jeg kan ikke logge ind på admin-panelet«. Den slags definition er langt stærkere end overskriften »kritisk« alene.

Antallet af niveauer er ikke fast. Auto IT's SLA-eksempel bruger høj, mellem og lav prioritet og angiver responstider på 2 timer for høj prioritet og 8 timer for mellem prioritet. Uanset antallet bør aftalen fastlægge, hvem der må sætte prioriteten, og hvad der sker, hvis parterne er uenige, så klassificeringen ikke bliver en forhandling midt under en hændelse.

Aftal måling, overvågning og rapportering

Overvågningsprocessen skal stå i aftalen og beskrive, hvordan serviceniveauerne overvåges: hvilke datatyper der indsamles, hvor ofte, og hvordan de gøres tilgængelige for kunden. Rapporteringsdelen skal svare på, hvordan og hvor ofte kunden får dokumentation for, at niveauerne overholdes. En typisk aftale har månedlig rapportering og en responstid på inden for 4 timer på kritiske henvendelser; uden en aftalt rapporteringskadence findes ingen fast rytme at holde leverandøren op på.

Suppler grønne lamper med tal, der viser, om brugerne faktisk kan arbejde. Mål MTTR og FCR; et dashboard med grønne indikatorer betyder ikke, at medarbejderne kan løse deres opgaver. Saml samtidig datagrundlaget for oppetidsmålingen: Skal den gælde 24/7 eller kun i arbejdstiden, og trækkes planlagt vedligehold fra eller ej? Begge dele skal nedskrives, uanset hvilket overvågningsværktøj der bruges.

Fastlæg, hvem der ejer data og dokumentation, og hvad der sker, når samarbejdet slutter. I den type aftaler bør SLA'en definere kommunikationskanaler og -frekvens, ejerskab af data og kreativer samt hvad der sker ved kontraktens ophør, herunder overlevering af konti, adgange og dokumentation. Er leverandøren omfattet af NIS2-reglerne, skal vedkommende kunne levere early warning inden for 24 timer og en fuld rapport inden for 72 timer. Rapportformat, modtager og frist bør skrives ind i aftalen frem for at blive aftalt undervejs.

SLA-målinger: Hovedindikatorer og krav

Eskalering og ansvar

Aftalen skal indeholde eskalationsveje: hvem der kontaktes, hvis en sag ikke løses inden for aftalt tid, og hvornår ledelsen involveres. Uden navne, roller og kontaktoplysninger bliver eskaleringen en mundtlig aftale mellem to personer - og den forsvinder, når en af dem skifter job.

Sæt eskaleringen i procent af SLA-tiden i stedet for på den absolutte frist. 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). Det giver tid til at tilkalde flere ressourcer eller informere forretningen, inden fristen overskrides.

Kontaktkanalen bør defineres pr. prioritet. Formalize bruger fx e-mail som kanal for kritiske hændelser med 0,5 times responstid - og så skal e-mailen overvåges i det tidsrum. Aftalen bør også fastlægge rækkefølgen af oplysninger, der skal med, når en sag rapporteres, hvilket tidsrum sagen undersøges i, og hvornår den skal være løst. Eskaleringsvejen skal gå videre end den primære leverandør: Er der underleverandører inde over, skal det fremgå, hvem der eskalerer til dem, og hvordan suspension eller forlængelse af SLA-tiden håndteres, hvis årsagen ligger hos en tredjepart.

Konsekvenser ved brud: bod, service credits og incitamenter

Sanktioner ved brud er en fast del af SLA'en og består typisk af bod eller kompensation. En SLA uden konsekvenser er reelt kun en hensigtserklæring. Sanktionen er derfor det punkt, der afgør, om de øvrige tal overholdes i praksis.

Levering uden for eller under de fastsatte krav udløser normalt økonomisk kompensation eller en reduktion i entrepriseprisen. Refusionen sættes typisk op som en trin-for-trin-model, hvor den stiger, jo større afstanden er mellem leveringen og SLA-kravet. Vær opmærksom på størrelsesforholdet: Mange virksomheder oplever, at refusionerne ikke dækker de opfattede omkostninger ved leverancer uden for SLA. Som alternativ til økonomisk kompensation kan kunden kræve, at serviceudbyderen anvender det tilsvarende beløb i stedet for at udbetale det.

Krediteringen skal ske automatisk. Service credits »på anmodning« bliver aldrig udløst; kræv derfor automatisk kreditering ved brud, når bruddet kan dokumenteres i den månedlige rapport. Kompensation kan også være rabatter eller credits, og aftalen bør indeholde både sanktioner ved manglende overholdelse og incitamenter ved opfyldelse eller overopfyldelse af målene. Skriv beregningsgrundlaget ind - hvilken måling, hvilken periode og hvilken sats - så krediteringen kan efterprøves uden forhandling.

Vigtige konsekvenser ved brud på SLA – sanktioner vs. incitamenter

Undgå faldgruber i sproget

Det er afgørende, at SLA'en er entydig og ikke kan tolkes i flere retninger. Formuleringer som »så hurtigt som muligt«, »tilstrækkeligt«, »i det omfang det er nødvendigt«, »kan«, »bør«, »osv.« og »mv.« er klassiske faldgruber og bør undgås for at undgå misforståelser. Erstat dem med tal, navne på systemer og angivelse af, hvem der gør hvad.

Forskellen er reelt forskellen mellem et løfte og en forpligtelse. Uden en SLA er »hurtig support« og »stabil drift« bare løfter; med en SLA bliver de forpligtelser, kunden kan holde leverandøren op på. Jo mere specifik SLA'en er, desto lettere er samarbejdet at evaluere objektivt. Læs derfor aftalen igennem, og markér hvert sted, hvor en sætning ikke kan efterprøves mod en rapport.

Grænsetilfælde skal navngives lige så præcist som hovedforpligtelsen: planlagt vedligehold, force majeure og fejl uden for leverandørens ansvar er de undtagelser, der oftest bliver stridspunktet. Det gælder også formuleringer om tredjeparter. Står der fx, at SLA-tiden suspenderes eller forlænges, når årsagen ligger hos en underleverandør, skal det fremgå, hvordan det dokumenteres, og hvem der afgør det. Ellers ender undtagelsen med at definere aftalen.

Fra aftale til drift: Implementering og løbende evaluering

Få styr på ikrafttræden og varighed. Formalize skriver, at SLA'en træder i kraft, når begge parter har underskrevet både SLA og aftale, og at den forbliver gyldig, indtil den erstattes af en revideret skriftlig aftale godkendt af de kontraherende parter, eller indtil aftalen opsiges. Den formulering giver en fast revisionsvej i stedet for en stiltiende forlængelse af et dokument, ingen længere læser.

I driften skal kontaktkanaler og ansvar være fastlagt fra dag ét. Kunden skal vide, hvilke kontaktoplysninger en sag rapporteres til, og hvilke oplysninger der skal med i hvilken rækkefølge, så sagsbehandlingen kan starte med det samme. Servicedesken bør arbejde med aftalte svartider på P1 til P4 og rapportere dem månedligt, så rapporterne - ikke indtryk fra de seneste uger - kan ligge til grund for evalueringen.

Evaluer samarbejdet på KPI'er, ikke på mavefornemmelse, og brug tallene som grundlag for at genforhandle. En aftale med servicebeskrivelse, målbare servicemål, respons- og løsningstider, eskaleringsprocedurer og kompensation er lettere at evaluere objektivt end en aftale, der kun lover et serviceniveau i overskrifter. Aftalen er da også udbredt: Ifølge en undersøgelse fra IT-Branchen har 78 % af danske virksomheder med over 50 ansatte en SLA med mindst én af deres IT- eller marketingleverandører. Revisionen bør derfor være en planlagt begivenhed - fx ved den månedlige rapportering eller den årlige kontraktgennemgang - hvor niveauer, undtagelser og sanktioner vurderes mod virksomhedens nuværende behov.