SLA for små bureauer: svartider, oppetid og det med småt

Kort svar: En SLA for et lille webbureau skal love tre ting – og kun ting, I kan holde: en svartid inden for jeres åbningstid (fx reaktion inden 4 arbejdstimer, akutte sager først), en proces for akutte hændelser (hvad der tæller som „nede“, og hvad der sker først), og en oppetid, der højst matcher jeres hosting-lags garanti. Resten er det med småt: undtagelser, kompensation med loft og en klar grænse for, hvad aftalen dækker. En lille, holdbar SLA er mere værd end en imponerende, I bryder i februar.

Fagligt gennemgået: 2. oktober 2026

„Har I en SLA?“ er et spørgsmål, der kan få små bureauer til at svede – enten fordi svaret er nej, eller fordi svaret er et dokument, der lover døgnvagt, som ingen i firmaet har. Begge dele kan koste kunder: større driftskunder kræver ofte en SLA, før de skriver under.

Den gode nyhed er, at en troværdig SLA for et lille team hverken behøver at være lang eller indviklet. Den skal være ærlig om, hvad I kan, og præcis om, hvad der sker, når noget går galt. Artiklen er ikke juridisk rådgivning; lad en rådgiver gennemgå den endelige aftaletekst.

Hvad en SLA er – og ikke er

En SLA (Service Level Agreement) er et løfte om serviceniveau: hvor hurtigt I reagerer, hvad der sker ved akutte hændelser, og hvad kunden får, hvis løftet brydes. Den er ikke en liste over opgaver – det står i vedligeholdelsesaftalen – og den er ikke en garanti for, at intet går galt.

Den forskel er vigtig at få sagt til kunden: SLA’en handler om, hvad der sker, når noget går galt. Kunder køber ikke fejlfrihed – det tror ingen på. De køber vished om reaktionen.

Svartider, et lille team kan holde

Skeln mellem to spor:

• Normale henvendelser: reaktion inden fx 4–8 arbejdstimer og løsning efter aftale. Lov reaktionstid, aldrig løsningstid – du ved ikke, hvor dybt et problem stikker, før du har set det.
• Akutte hændelser (sitet er nede, checkout virker ikke, sitet er kompromitteret): reaktion hurtigst muligt og inden fx 1–2 timer i åbningstiden.

Definér åbningstiden ærligt. Et team på to skal ikke love 24/7; lov i stedet „hverdage 8–16, akut-mail overvåges til 21“, hvis det er sandheden. Kører I uden vagtordning, så læn jer op ad automatik: uptime-overvågning, der alarmerer, og et hosting-lag med egen døgnbemanding dækker en stor del af natten.

Prioritet	Eksempel	Reaktionstid (eksempel)	Hvad I lover
Akut	Sitet er nede, checkout fejler, hacket site	Inden 1–2 timer i åbningstiden	At gå i gang og give status
Høj	Formular sender ikke, vigtig funktion fejler	Inden 4 arbejdstimer	Diagnose og plan
Normal	Spørgsmål, mindre fejl, ændringsønsker	Inden 1–2 arbejdsdage	Svar og aftale om løsning

Tallene i tabellen er eksempler, ikke en standard. Vælg niveauer, I kan holde i jeres travleste uge – ikke i jeres roligste.

Oppetid: lov aldrig mere end jeres hosting-lag

Reglen er enkel: jeres oppetidsgaranti kan aldrig være højere end den, jeres hosting-lag giver jer. I kan ikke love 99,99 %, hvis serveren under jer lover 99,9 %. Tjek jeres hostingudbyders vilkår, og giv højst samme niveau videre – gerne med luft til varslet vedligehold.

Undgå procenttal, I ikke selv måler. Hav jeres egen uafhængige overvågning, så diskussionen „var sitet nede?“ afgøres af data og ikke af hukommelse. Og undtag udtrykkeligt nedetid, kunden selv forårsager – plugins, der installeres uden om jer, er ikke jeres SLA-brud. Læs mere om begrebet i hvad er uptime-garanti på hosting?

Husk, hvad procenterne betyder i praksis. 99,9 % oppetid over en måned på 30 dage svarer til cirka 43 minutters tilladt nedetid; 99,5 % svarer til cirka 3 timer og 36 minutter. Skriv også, om målingen sker pr. måned eller pr. år, og om varslet vedligehold tæller med.

Det med småt

Fire klausuler skal med:

1. Definitioner: hvad tæller som „nede“ – hele sitet, checkout, login? Et langsomt galleri er ikke akut.
2. Undtagelser: kundens egne ændringer, tredjepartstjenester (betalingsgateway, fragt-API), force majeure og varslet vedligehold.
3. Kompensation: kredit på næste faktura ved brud, med et loft (fx højst én måneds driftsbetaling). Påtag jer ikke ansvar for kundens tabte omsætning – den risiko hører hjemme i kundens forsikring og bør afgrænses i aftalen.
4. Måling og rapport: hvor oppetid og svartider aflæses, og at de rapporteres i månedsrapporten.

Hold hele dokumentet på én til to sider. En SLA, kunden faktisk læser, forebygger flere konflikter end en, der imponerer i skuffen.

Akutprocessen: de første 30 minutter

Et svartidsløfte er kun troværdigt, hvis der står en proces bag. Skriv den ned, så alle i teamet gør det samme:

1. Bekræft hændelsen: er sitet nede for alle, eller kun for én bruger?
2. Giv kunden en første besked med det samme: „vi har set det, vi undersøger, næste status kl. X“.
3. Tjek de oplagte lag: hosting-status, seneste ændringer, overvågningens log.
4. Eskalér til hostingudbyderen, hvis fejlen ligger i server eller netværk.
5. Log tidspunkter undervejs – de bruges i rapporten og i en eventuel kompensation.

Processen hænger sammen med jeres nedbrudsplan og eskalationsplan. Ved sikkerhedshændelser gælder en udvidet proces – se sikkerhedshændelse på et kundesite.

Opbygning af en SLA på én side

Brug denne rækkefølge som udgangspunkt, og tilpas indholdet til jeres egen forretning:

1. Omfang: hvilke sites og hvilke tjenester aftalen dækker – og hvad den ikke dækker.
2. Åbningstid og kontaktkanaler: hvornår I svarer, og hvor kunden skal henvende sig. Én kanal til akutte sager gør det nemt at holde svartiden.
3. Prioriteter og reaktionstider: tabellen ovenfor i jeres egen version.
4. Oppetid og måling: procent, måleperiode, måleværktøj og hvad der tæller som nedetid.
5. Undtagelser: kundens egne ændringer, tredjepartstjenester, varslet vedligehold og force majeure.
6. Kompensation: kredit, loft og hvordan kunden gør krav gældende (fx inden 30 dage).
7. Kundens forpligtelser: at melde fejl via den aftalte kanal, give adgang, når det er nødvendigt, og ikke installere plugins uden om aftalen.
8. Revision: hvornår aftalen gennemgås igen, fx én gang om året.

Punktet om kundens forpligtelser bliver ofte glemt, men det er det, der gør aftalen gensidig. En SLA, hvor kun bureauet har pligter, inviterer til diskussion, hver gang kunden selv har lavet ændringer.

SLA som salgsværktøj

Læg SLA’en i den øverste driftspakke, og lad den være forskellen, der begrunder prisen: samme opgaver, men garanteret reaktion. For webshops og bookingtunge sites er netop den vished ofte grunden til at vælge den større pakke.

For jer er det en grund til at bygge fundamentet, så løftet er billigt at holde: standardiseret opsætning, overvågning og et hosting-lag med support døgnet rundt. Hos Hostious er der dansk support 24/7 på WordPress- og WooCommerce-hosting – men jeres SLA over for kunden skal stadig bygge på det, I selv kan levere og dokumentere.

Vigtigt: Kopiér ikke en SLA-skabelon fra et stort bureau eller en hostingudbyder. Deres tal bygger på vagtordninger og bemanding, som et lille team sjældent har. Start med det, I kan holde i dag, og hæv niveauet, når I har data for, at det holder.

Læs også

• Hub: For bureauer og freelancere
• Vedligeholdelsesaftalen: hvad den skal indeholde
• Prissætning af drift
• Uptime-overvågning: værktøjer, intervaller og alarmer
• Bureau hosting til WordPress og WooCommerce
• WordPress hosting hos Hostious – dansk support 24/7, daglig backup og staging fra WP StartUp

Ofte stillede spørgsmål om SLA for webbureauer

Skal et lille bureau overhovedet tilbyde en SLA?

Ja, hvis I vil have de større driftskunder – mange kræver den. Men lov kun, hvad I kan holde: svartid i åbningstiden og en klar akutproces er bedre end et 24/7-løfte, I bryder.

Hvilken oppetid kan jeg garantere?

Højst den, jeres hosting-lag garanterer jer. Hav egen overvågning, så tallet kan dokumenteres, og undtag nedetid forårsaget af kundens egne ændringer.

Hvad skal kompensationen være ved SLA-brud?

Typisk kredit på næste faktura med et loft, fx højst én måneds driftsbetaling. Afgræns ansvaret for kundens tabte omsætning i aftalen; den risiko hører til kundens forsikring.

Hvad er forskellen på reaktionstid og løsningstid?

Reaktionstid er, hvor hurtigt I går i gang og giver kunden besked. Løsningstid er, hvornår fejlen er rettet. Lov reaktionstid, fordi I ikke kender problemets omfang, før I har set det.