6 klausuler til din B2B-SLA: tilgængelighed og bod

Et enkelt minuts nedetid kan koste millioner – ikke kun i tabt omsætning, men også i tillid og brandværdi. Alligevel gemmer mange B2B-aftaler sig bag løse formuleringer som “best effort” eller “høj oppetid”. Hvis dét lyder bekendt, er det måske på tide at støve din service level agreement (SLA) af.

I en tid hvor alt kører i skyen, og forretningskritiske systemer forventes at være online døgnet rundt, er præcise klausuler om tilgængelighed og bod ikke længere nice-to-have – de er hård valuta. Forhandler du som kunde eller leverandør uden et klart defineret ansvar for oppetid, risikerer du dyre konflikter, tabte kunder og uforudsete udgifter.

I denne artikel zoomer vi ind på seks essentielle SLA-klausuler, der sikrer, at alle parter ved præcis, hvad der måles på, hvordan det måles, og hvad der sker, når målene ikke nås. Fra krystalklare definitioner og SLO-procenter til konkrete beregningsmodeller for bod – vi giver dig de juridiske og kommercielle håndtag, der gør forskellen, når (ikke hvis) teknikken svigter.

Sæt dig godt til rette, og få styr på alt fra scope og vedligeholdelsesvinduer til økonomiske lofter og exit-planer. Din næste forhandling starter her.

Klausul 1: Scope og definitioner

Det første skridt i en robust B2B-SLA er at tegne en tyk streg omkring, hvad der rent faktisk omfattes. Uden et entydigt scope og et fælles begrebsapparat risikerer både kunde og leverandør at måle på forskellige ting – og dermed tale forbi hinanden, når boden skal gøres op.

1. Servicescope

SLA’en gælder alene de systemer, miljøer og geografiske regioner, der eksplicit er nævnt i kontrakten. Typisk specificeres:

• Applikationer: F.eks. produktions-API, web-portal og mobil-app.
• Miljøer: Produktionsmiljø (PROD); test- og udviklingsmiljøer er kun dækket, hvis de optræder særskilt.
• Regioner / datacentre: EU-Vest og US-Øst; back-up-regioner er kun omfattet ved fail-over.

Alt uden for dette scope (lokale install­ationer, tredjepartsintegrationer, kundens netværk m.m.) omfattes kun, hvis det er skrevet ind.

2. Centrale definitioner

Tilgængelighed

Den procentdel af en opgørelsesperiode hvor tjenesten er fuldt funktionsdygtig for slutbrugere. Udtrykkes f.eks. som 99,9 % pr. kalendermåned.

Nedetid

Enhver ubrudt periode på ≥ 1 minut hvor tjenesten ikke kan udføre sine kernefunktioner. Måles fra konstateret hændelse til fuld gendannelse.

Planlagt vedligehold

Forudvarslet vindue hvor tjenesten kan være utilgængelig uden at tælle som nedetid, forudsat varsling min. 5 arbejdsdage før.

Blackout-vindue

Perioder (fx lør 22:00 – søn 02:00 CET) hvor planlagt vedligehold altid må foretages, og hvor nedetid ikke medregnes.

Arbejdstid vs. 24/7

• Arbejdstid: Mandag-fredag 08:00-18:00 CET, ekskl. danske helligdage.
• 24/7: Alle timer året rundt; bruges til at beregne tilgængelighed for kritiske API’er.

Prioriteringsniveauer (P1 – P4)

• P1 Kritisk: Fuldt produktionsstop for alle brugere.
• P2 Høj: Væsentlig funktionsnedgang uden fuldt stop.
• P3 Medium: Begrænset påvirkning eller workaround mulig.
• P4 Lav: Kosmetiske fejl eller ønskede forbedringer.

3. Hvorfor er definitionerne vigtige?

Disse begreber danner referencepunkt for alle efterfølgende klausuler: målemetodik (Klausul 3), responstider (Klausul 4) og ikke mindst bods­beregning (Klausul 5). En entydig ordliste reducerer tvister og gør det muligt at køre automatiseret rapportering uden manuelle fortolkninger.

Klausul 2: Tilgængelighedsmål (SLA/SLO) og vedligeholdelsesvinduer

Når du specificerer selve tilgængelighedsmålet i SLA’en, bør du angive en konkret procent – typisk 99,9 % pr. kalendermåned – og knytte det til én entydig tidszone. I en dansk kontekst giver det bedst mening at måle i CET/CEST, så både leverandør og kunde følger samme ur, også når sommertid skifter.

Det skal tydeligt fremgå, at opgørelsesperioden er en hel måned på baggrund af 43.200 registrerede minutter (eller 44.640 i måneder med 31 dage). Al nedetid fratrækkes minut for minut, og tilgængeligheden beregnes som (totalt driftstid ÷ totalt minutter) × 100. Inkludér desuden, at den månedlige måling indgår i et rullende 12-måneders gennemsnit for at afdække langsigtede trends.

Fordi forskellige kundevendte dele har forskellige vigtigheder, kan det være nødvendigt at fastsætte SLO’er pr. komponent. Et API kan f.eks. have 99,95 %, mens selve administrations-portalen accepterer 99,5 %, og supportchatten måles på svar-SLA snarere end oppetid. Notér eksplicit, at manglende opfyldelse af én komponent tæller uafhængigt og kan udløse bod isoleret set.

Vedligehold er ofte den største fejlkilde i tilgængelighedsregnskabet, så aftalen skal beskrive både servicevinduer og varsling. Et almindeligt setup er at reservere søndag 00.00-06.00 CET til planlagt vedligehold, som på forhånd er undtaget fra tilgængelighedsberegningen. Al anden planlagt vedligehold kræver minimum syv kalenderdages skriftligt varsel til kundens driftskontakt, og kun godkendt vedligehold kan fratrækkes SLA-målingen. Fejlrettelser, der foretages akut uden for vinduet, tæller derimod som nedetid, medmindre kunden skriftligt samtykker.

Definér endelig en samlet vedligeholdelsesbudget – eksempelvis maksimalt otte planlagte timer pr. måned – og beskriv, at tid ud over dette budget automatisk opgøres som nedetid. Leverandøren bør forpligte sig til at publicere en månedlig tilgængelighedsrapport inden for fem arbejdsdage efter månedsskiftet, hvori både antal minutter, eventuelle servicevinduer og den faktiske SLA-score fremgår.

Med klare, målbare tilgængelighedsprocenter, faste vinduer og komponent-specifikke SLO’er eliminerer du tvivl om, hvad der måles, hvornår det måles, og hvornår der kan gøres bod gældende.

Klausul 3: Måling, datakilder og revision

For at et tilgængelighedsmål kan håndhæves, skal begge parter på forhånd vide hvordan der måles, hvilke kilder der benyttes, og hvem der har det sidste ord ved tvist. Klausulen bør som minimum omfatte følgende elementer:

1. Målemetoder
   SLA’en skal beskrive, at leverandøren foretager syntetisk overvågning fra minimum tre uafhængige globalt distribuerede probe-lokationer samt realbruger-målinger (RUM) baseret på faktisk trafik. Begge datasæt suppleres af server- og applikationslogs for end-to-end-sporing. Kombinationen begrænser risikoen for falske positiver – eksempelvis hvis et enkelt datacenter fejler, men brugerne stadig serviceres fra et andet.
2. Autoritativ datakilde ved uenighed
   Ved manglende overensstemmelse mellem kilder skal SLA’en pege én primær og én sekundær kilde ud:
   • Primær: Aggregated syntetisk uptime rapporteret af leverandørens overvågningsplatform (f.eks. Pingdom, Datadog Synthetics).
   • Sekundær: Kundens egne målinger eller tredjeparts RUM-rapporter, som kan fremlægges som dokumentation. Kun hvis den sekundære kilde kan påvise mere end 0,2 %-points afvigelse over opgørelsesperioden, udløser det revisionsret (se pkt. 5).
3. Registrering af nedetid
   Tidsstempling starter når den første af følgende begivenheder indtræder:
   • leverandørens overvågning registrerer “hard failure” på to uafhængige probe-lokationer samtidig, eller
   • kunden opretter en P1-ticket via den aftalte supportkanal og denne bekræftes af leverandøren.

   Nedetiden slutter, når overvågningen viser stabil drift i minimum fem på hinanden følgende målinger eller kunden bekræfter genopretning – hvad end der indtræffer først.

4. Rapportering og adgang til rådata
   Leverandøren stiller en månedlig SLA-rapport til rådighed senest den 5. kalenderdag efter et opgørelsesinterval. Rapporten indeholder:
   • samlet tilgængelighed (procent) pr. servicekomponent,
   • antal og varighed af hændelser fordelt på P1-P4,
   • planlagt vs. uplanlagt nedetid,
   • link til detaljeret hændelseslog samt eventuelle RCA-rapporter.

   På skriftlig anmodning fra kunden – maks. fire gange årligt – udleveres de underliggende råmålinger (CSV eller JSON) inden for ti arbejdsdage uden meromkostning.

5. Revisionsret
   Kunden har ret til én ekstern revision pr. rullende 12-månedersperiode med 30 dages varsel. Revisionen kan omfatte stikprøvevis validering af:
   • overvågnings- og alarmeringskonfiguration,
   • beføjelser til dataændringer i log- eller monitoreringssystemer,
   • integritet af rådata og beregningsformler.

   Leverandøren skal give adgang til systemer, dashboards og personale i rimeligt omfang. Opdages en afvigelse på over 0,1 %-points til ugunst for kunden, betaler leverandøren revisionsomkostningerne og korrigerer straks SLA-opgørelsen.

Ved at fastslå ovenstående undgår parterne “ord mod ord”-diskussioner om driftsstatistik og sikrer, at bodsberegninger i Klausul 5 hviler på verificérbare data.

Klausul 4: Hændelses- og eskalationshåndtering

En robust hændelses- og eskalationsmekanisme fungerer som SLA’ens sikkerhedsnet. Den skal:

Statusportaler og kommunikationskanaler

Alle hændelser registreres i et fælles ticket-system og offentliggøres i leverandørens statusportal, hvor kunder kan abonnere på notifikationer (e-mail, SMS, webhook). Ved P1/P2-hændelser aktiveres desuden en Bridge-Call eller War-Room-chat, så både kundens og leverandørens specialister kan samarbejde i realtid.

Eskalationsstige

1. NOC/service-desk (24/7) – initierer første respons.
2. Duty Manager / Incident Commander – senest 30 min. efter P1-hændelse.
3. Teknisk leder / Produktchef – ved risiko for SLA-brud.
4. Direktion / C-level – hvis P1 ikke er løst inden 4 timer, eller hvis der er gentagne månedlige brud.

Post-incident rapport (rca)

Senest 5 arbejdsdage efter lukning af en P1/P2-hændelse leverer leverandøren en Root Cause Analysis, som mindst dækker:

• Beskrivelse af grundårsag og bidragende faktorer
• Tidslinje fra detektion til endelig løsning
• Mid‐ og langsigtede korrigerende handlinger
• Foranstaltninger til at forhindre gentagelser
• Vurdering af eventuel bod og foreslået kreditbeløb

Rapporten gøres tilgængelig via statusportalen og underskrives af begge parter.

Shared raci-model

For at undgå gråzoner aftales en fælles RACI, fx:

• R (Responsible): Leverandørens Incident Commander
• A (Accountable): Leverandørens CTO
• C (Consulted): Kundens systemejer, leverandørens Support Lead
• I (Informed): Kundens brugere, eksterne tredjeparter

Modellen kan med fordel kobles direkte til tickettyperne, så roller og kontaktpunkter fremgår automatisk ved oprettelse af en hændelse.

Ved at formaliserer ovenstående parametre i SLA’en sikres hurtig reaktion, tydelig kommunikation og en klar læringssløjfe, der reducerer risikoen for fremtidige tilgængelighedsbrud.

Klausul 5: Bod, servicekreditter og økonomiske loft

Når tilgængelighedsmålet ikke opfyldes, skal bods- og kreditmekanismen aktiveres automatisk – uden at kunden først skal rejse et krav. Dermed understøttes princippet “you build it, you own it”, hvor leverandøren selv bærer omkostningen ved manglende leverancekvalitet. Følgende elementer bør være eksplicitte i klausulen:

1. Beregningsmodel
   Angiv om modellen er lineær (fx 2 % kredit pr. 0,1 % utilgængelighed under mål) eller trinvis (fx 5 % kredit ved første 0,1 %-point, 10 % ved næste osv.). Beskriv samtidig minimumstærskel (f.eks. først kreditering ved 5 minutters samlet nedetid) samt afrundingslogik (total nedetid måles i hele minutter).
2. Automatisk kreditering og udbetaling
   Kreditter godskrives næstkommende månedsfaktura senest på forfaldsdato. Kunden kan vælge kontant udbetaling, såfremt:
   • der ikke længere aftages abonnementstjenester, eller
   • den samlede kredit overstiger DKK 50.000.

   Eventuelle modregningsforbud fra leverandørens side er ugyldige.

3. Månedlige og årlige caps
   For at sikre proportionalitet sættes et loft, fx maks. 50 % af månedlig abonnementsbetaling pr. kalendermåned og maks. 200 % af årlig abonnementsbetaling pr. aftaleår. Caps gælder kun bod; andre misligholdelsesbeføjelser (fx erstatning) tæller ikke med i opgørelsen, medmindre parterne udtrykkeligt har aftalt et samlet total-cap.
4. Kumulation med øvrige misligholdelsesbeføjelser
   Bod er ikke eksklusiv afhjælpning. Kunden bevarer retten til:
   • naturalopfyldelse/afhjælpning,
   • erstatning for dokumenteret tab, samt
   • ophævelse ved væsentlig misligholdelse, jf. klausul 6.

   Eventuel dublering af kompensation trækkes dog fra, så kunden aldrig overkompenseres (ingen double dipping).

5. Gentagne eller systematiske brud
   Overskrides SLA’en tre eller flere måneder inden for en sammenhængende 12-månedersperiode, udløses forhøjet bod: satsen ganges med 1,5 for hvert yderligere brud samme år. Alternativt kan klausulen fastsætte en eskalation til fast månedlig malus, indtil leverandøren har leveret tre sammenhængende måneder i overensstemmelse med SLA-kravene.

Eksempel (lineær model): SLA 99,9 % pr. kalendermåned. Hver påbegyndt 0,05 %-point under målet udløser 1 % kredit af månedlig abonnementsbetaling. Ved målt 99,70 % tilgængelighed (0,20 %-point under målet) godskrives 4 % af månedsprisen, dog aldrig over 50 % samlet.

Afslutningsvis bør parterne aftale årlig genforhandling af bodsmodellen for at sikre, at incitamenterne fortsat er passende i forhold til tjenestens kritikalitet og markedsstandarder.

Klausul 6: Undtagelser, kundemedvirken og ophævelse ved gentagne brud

Klausulen fastslår først, at leverandørens tilgængelighedsforpligtelser ikke omfatter forhold, som ligger uden for rimelig kontrol. Undtagelserne dækker blandt andet force majeure-begivenheder som naturkatastrofer og myndighedspåbud; driftsforstyrrelser i eksterne backbone- eller teleudbydernet; hændelser udløst af kundens egne systemer, misbrug af API-nøgler eller manglende licenser; samt sikkerhedshændelser (fx DDoS-angreb eller zero-day exploits), når leverandøren har truffet branchestandardmæssige foranstaltninger. I sådanne tilfælde suspenderes SLA-målingen i den berørte periode.

For at SLA-målene kan opfyldes kræves kundemedvirken. Kunden skal give rettidig adgang til relevante miljøer, stille kompetente kontaktpersoner til rådighed på aftalte tidspunkter og implementere de minimumskonfigurationer, som leverandøren dokumenterer. Fejl eller forsinkelser, der skyldes kundens manglende medvirken, fraregnes både tilgængelighedsprocenter og responstider.

Hvis SLA-brud forekommer gentagne gange, defineres en tærskel for væsentlig misligholdelse. Typisk udløses denne, når samme kritiske komponent (P1 eller P2) ikke overholder sin SLO i tre sammenhængende måneder eller i fire måneder inden for en rullende 12-måneders periode. Der kan endvidere aftales særskilt tærskel, hvis den kumulerede bod når maksimum tre måneder i træk.

Når tærsklen nås, skal leverandøren straks præsentere en forpligtende genopretnings- og forebyggelsesplan. Manglende efterlevelse af planen inden for 30 dage giver kunden ret til hel eller delvis ophævelse uden yderligere varsel og uden at miste retten til allerede optjent bod.

Ved ophævelse iværksættes en aftalt exit-plan. Leverandøren forpligter sig til inden for 10 arbejdsdage at stille en komplet, struktureret datadump til rådighed i et åbent format (fx CSV, JSON eller SQL-dump), sikre fortsat driftsstøtte i op til 45 dage efter ophævelsesdatoen mod standard timepriser samt slette eller irreversibelt anonymisere alle kundedata senest 90 dage efter bekræftet modtagelse. Kunden har i samme periode ret til at anmode om datadokumentation, revisionsspor og krypteringsnøgler for at sikre en smidig overgang til ny leverandør eller intern drift.