Når nettet går ned, føles det som at hele virksomheden holder vejret. Ingen kan komme på mail, WiFi driller, printeren står stille, og salget kan ikke gennemføres. En it serviceaftale handler i bund og grund om at gøre den slags problemer til noget, der bliver håndteret hurtigt, målbart og uden diskussion.
Tænk på aftalen som virksomhedens brandalarm: Den forhindrer ikke, at der opstår røg, men den sikrer, at nogen reagerer, og at I ved, hvad der sker, mens det står på.
Her får I en konkret guide til, hvad aftalen bør indeholde, hvordan SLA-niveauer typisk bygges op (P1, P2, P3), hvilke faldgruber der går igen, og hvordan I forhandler jer frem til en aftale, der faktisk virker i hverdagen.
Hvad en it serviceaftale bør dække (og hvad der ofte bliver glemt)
Den største fejl er at købe “support” uden at definere, hvad support betyder hos jer. En god it serviceaftale starter med et klart scope, altså hvad der er med, og hvad der ikke er med.
I praksis bør aftalen som minimum beskrive:
- Supportkanaler: Telefon, mail, ticket-system, og hvornår de er åbne.
- On-site vs. remote: Hvornår kommer teknikeren ud, og hvornår løses det via fjernsupport?
- Netværk og WiFi: Drift, fejlsøgning, adgangspunkter, switch, firewall, gæstenet, og hvem der ejer ansvaret, hvis internetleverandøren fejler.
- Brugerudstyr: PC’er, printere, skærme, docking, og standardopsætning for nye medarbejdere.
- Microsoft 365 og identitet: Oprettelse af brugere, MFA, adgangsstyring, og licenshåndtering (ofte bundet op på et abonnement). Hvis I vil samle licenser og drift, kan det give mening at se på Microsoft 365-pakker med supportaftale.
- Backup og gendannelse: Hvor tit tages backup, hvor længe gemmes den, og hvor hurtigt kan I være kørende igen?
Det, der ofte bliver glemt, er “gråzonerne”: Hvem har ansvaret for tredjepartsudstyr (kassesystem, produktionsmaskiner, alarmsystem), og hvad sker der, når en opgave bliver til et projekt (ny WiFi-installation, flytning, større oprydning i rettigheder)? Her bør aftalen have en enkel regel: hvad der er inkluderet, og hvad der faktureres særskilt, samt hvordan det godkendes.
SLA og prioritet: konkrete P1/P2/P3-eksempler, der kan måles
SLA (Service Level Agreement) er hjertet i en it serviceaftale. Det er her, I aftaler svartider, løsningstider, og hvordan sager prioriteres. Uden en klar prioriteringsmodel ender alt som “haste”, og så er intet haster i praksis.
En enkel model med P1, P2 og P3 er ofte nok. Her er et realistisk eksempel, som passer til mange mindre og mellemstore virksomheder:
| Prioritet | Typisk situation | Forventet første respons | Typisk mål for løsning | Kommunikation |
|---|---|---|---|---|
| P1 Kritisk | Hele netværket/WiFi nede, mange kan ikke arbejde, produktion stop | 15-30 min (i åbningstid eller 24/7 hvis aftalt) | 4-8 timer | Opdatering hver 60 min |
| P2 Høj | En central funktion påvirket, fx mailproblemer for flere, VPN nede | 1-2 timer | 1-2 arbejdsdage | Opdatering 1-2 gange dagligt |
| P3 Normal | Enkeltbruger, printerdrift, opsætning, “irriterende men ikke stop” | 4-8 timer | 3-5 arbejdsdage | Opdatering ved statusændring |
To vigtige pointer:
- Prioritet handler om påvirkning og hast, ikke om hvem der ringer. Mange bruger en “impact x urgency”-tankegang (en prioriteringsmatrix), så P1 kun bruges, når forretningen reelt står stille. En god forklaring af prioriteringstankegangen findes i en incident priority matrix-guide.
- Mål skal være målbare. Skriv “første respons”, “workaround” og “endelig løsning” som tre forskellige ting. Det gør dialogen mere fair, især hvis fejlen ligger hos en leverandør.
Overvej også at få defineret servicevindue: Dækker aftalen kun 8-16, eller har I behov for aften og weekend? For en virksomhed med gæste-WiFi, butik eller døgnproduktion gør det en stor forskel.
Sikkerhed, GDPR og drift: sådan får I styr på ansvaret (ITIL og ISO 27001)
Når I bruger en ekstern partner til drift og support, rammer I næsten altid GDPR. Det kan være brugeroplysninger, e-mail, logfiler, backup, eller fjernadgang. Derfor bør en it serviceaftale hænge tæt sammen med en databehandleraftale (DPA), og I bør få det gjort konkret, ikke bare nævnt i en bisætning.
Det er især værd at få på plads:
- Adgangsstyring: Hvem får admin-adgang, hvordan gives den, og hvordan fjernes den ved jobskifte?
- Logning og sporbarhed: Kan I se, hvem der har gjort hvad, og hvornår?
- Underleverandører: Må leverandøren bruge andre (fx hosting), og hvordan godkendes det?
- Håndtering af brud: Hvornår får I besked, hvad er processen, og hvem gør hvad de første 2 timer?
Hvis I vil have et fælles sprog for “god drift”, er ITIL nyttigt som ramme for incident, change og problem management. Og hvis I har høje krav til sikkerhed (eller kunder der spørger), giver ISO 27001 et godt pejlemærke for kontroller og risikostyring. For en kort introduktion til sammenhængen mellem GDPR og ISO 27001 kan I læse en gennemgang af GDPR og ISO 27001.
Til sidst: Sørg for, at aftalen beskriver opsigelse og overgang. Hvordan får I jeres data ud, hvem hjælper med overdragelse, og hvad koster det? Her kan det også være relevant at læse betingelser for vores serviceaftaler, så forventninger til vilkår og ansvar er tydelige fra start.
Faldgruber, forhandlingspunkter og en tjekliste til indkøb eller fornyelse
De fleste konflikter kommer ikke af teknikken, men af uklare forventninger. Her er typiske faldgruber, der går igen:
- “Ubegrænset support” uden grænser: Hvad er support, og hvad er projektarbejde?
- SLA uden måling: Hvis I ikke får rapportering, kan I ikke se om aftalen holder.
- Ingen plan for WiFi og netværk: Hvis netværket er kritisk, skal det være et særskilt punkt, ikke en fodnote.
- Uklare roller ved leverandørfejl: Hvem ringer til internetudbyderen, og hvem følger op?
- Sikkerhed som “tilvalg”: MFA, patching og backup bør ikke være løse aftaler.
Når I forhandler, er der nogle punkter, der næsten altid giver værdi at få skrevet tydeligt ind:
- Definition af P1/P2/P3 og hvem der må eskalere til P1.
- Servicevindue (hverdage vs. 24/7) og tillæg for udenfor åbningstid.
- Response vs. løsning: I vil have begge dele, men de skal adskilles.
- Rapportering: Månedlig status med antal sager, svartider, og gentagne fejl.
- Standarder for ændringer: Hvornår kræver en change godkendelse, og hvordan dokumenteres den?
Hvis I vil læse mere om, hvad en SLA typisk indeholder, kan I bruge best practice-oversigt for SLA’er som inspiration til jeres kravliste.
Tjekliste til indkøb eller fornyelse
- Har vi et opdateret overblik over udstyr, brugere og kritiske systemer?
- Hvad er vores 3 mest kritiske scenarier (fx WiFi nede, mail nede, filadgang nede)?
- Er P1/P2/P3 defineret med eksempler, og passer tiderne til vores drift?
- Er netværk, WiFi og firewall klart inkluderet i scope?
- Får vi månedlig rapportering, og ved vi, hvad der måles på?
- Er der DPA på plads, inkl. underleverandører og brud-procedure?
- Er der en exit-plan (data, passwords, dokumentation, overdragelse)?
Mini-skabelon med centrale punkter (ikke juridisk rådgivning)
- Parter og kontaktveje (navne, akutnummer, eskalering)
- Scope (support, netværk/WiFi, Microsoft 365, backup, sikkerhed)
- SLA (P1/P2/P3, første respons, løsning, kommunikationsfrekvens)
- Servicevindue (åbningstid, vagtordning, on-site tider)
- Sikkerhed og GDPR (DPA, adgang, logning, brud, underleverandører)
- Rapportering (format, frekvens, KPI’er)
- Pris og afgrænsninger (inkluderet, ekstraarbejde, godkendelsesflow)
- Opsigelse og overgang (overdragelse, dataudlevering, dokumentation)
En god it serviceaftale er mest værd, når det brænder på
En it serviceaftale skal gøre hverdagen roligere, ikke mere uklar. Når scope, SLA og sikkerhed er skrevet tydeligt, får I hurtigere hjælp, færre overraskelser og bedre styr på netværk og WiFi, som ofte er det første der mærkes, når noget fejler.
Tag udgangspunkt i jeres drift, ikke i en standardpakke. Og få de svære punkter afklaret nu, så I slipper for diskussionen den dag, hvor alt står stille.
