Mål kvaliteten af IT-support: 7 metrics der virker

Hvis jeres IT-support “overholder SLA”, men brugerne stadig står stille, betaler I for den forkerte kvalitet. Typisk måles der på reaktionstid, mens løsningstid, genåbninger og produktivitet ikke bliver styreret. Her får I en praktisk måde at lave måling af IT support, så I kan genforhandle, prioritere og reducere risiko.

• Skil reaktionstid fra løsningstid: kræv rapportering på begge dele, og brug løsningstid til at styre kapacitet og kompetencer.
• Stop “ping-pong” tickets: mål First Contact Resolution og sæt en minimumsgrænse (SDI Benchmarking Report 2025: 70–75%).
• Mål brugeroplevelsen, ikke kun oppetid: suppler SLA med XLA/DEX-signal, så I undgår “watermelon effect” (Forrester).
• Kobl support til compliance: tjek at jeres processer og tider kan understøtte NIS2’s 24-timers varslingskrav (ENISA).
• Brug Microsoft 365-data som facit: valider leverandørens rapport med Endpoint Analytics/produktivitetsmålinger (Microsoft).

Hvorfor “hvad er en god SLA” sjældent giver jer god support

En klassisk SLA siger ofte noget om reaktionstid (hvornår en sag bliver taget), men meget lidt om hvornår I kan arbejde igen. Det er her kvaliteten af IT-support reelt mærkes.

Forrester beskriver “watermelon effect”: rapporten er grøn (oppetid), men oplevelsen er rød (langsomme systemer, ustabile klienter, Teams der hakker). Hvis I kun måler på oppetid og svartid, belønner I den forkerte adfærd.

Beslutningsregel: Hvornår er jeres SLA for smal?

• Hvis I kan se grøn oppetid, men stadig får mange “det er langsomt”-sager.
• Hvis leverandøren kan “overholde” SLA ved at svare hurtigt, men løser sent.
• Hvis I ikke kan udpege top-3 årsager til gentagne incidents pr. måned.

Sådan måler I IT support kvalitet med 7 KPI’er

Brug KPI’erne her som minimum i jeres månedlige driftstatus. De dækker hastighed, løsningskvalitet, brugerindsats og risiko. Det gør det også lettere at sammenligne IT support svartider benchmark på en måde, der giver mening.

Metric	Hvad den afslører	Hvad I gør, hvis den er dårlig
1) Time to First Response (reaktionstid)	Om I bliver taget seriøst, og om supporten har bemanding	Segmentér SLA efter kritikalitet; kræv 24/7 for kritiske systemer, ikke for alt
2) Mean Time to Resolve (løsningstid)	Hvornår driften reelt er tilbage	Indfør “swarming”/2nd line tidligt; mål løsningstid pr. kategori
3) First Contact Resolution (FCR)	Om sager løses første gang eller bliver kastet rundt	Sæt mål: 70–75% som pejlemærke (SDI 2025); lav vidensartikler på top-10 issues
4) Reopen-rate (genåbninger)	Løses der “symptomer” i stedet for årsag?	Krav om RCA på gentagne incidents; luk kun når brugeren er valideret tilbage i drift
5) Customer Effort Score (indsats for at få hjælp)	Hvor svært det er at få løst et problem (HDI)	Fjern friktion: standardformularer, klare kategorier, selvbetjening til simple opgaver
6) Business Impact (tabt tid/omsætning)	Hvad supporten koster, når den ikke virker	Klassificér sager: “stopper produktion”, “stopper salg”, “irritation”; prioritér derefter
7) Security/Compliance handling time	Om I kan leve op til krav om håndtering og dokumentation	Indfør incident-runbook og logkrav; match processer til NIS2 og DPA-tilsyn

Før → Efter (1):
Før: “Svar inden for 1 time” bliver fejret, selv om sagen først er løst dagen efter.
Efter: I styrer på løsningstid + FCR. Resultatet er færre eskaleringer og mindre intern tid brugt på at rykke leverandøren.

Hvordan kobler I supportmåling til NIS2 og leverandørkrav?

NIS2 skærper kravene til håndtering og rapportering af væsentlige hændelser. ENISA’s guidelines peger på et 24-timers varslingskrav. Det betyder i praksis: jeres support-setup skal kunne opdage, klassificere og eskalere hurtigt nok — og kunne dokumentere det bagefter.

Tjek jeres kontrakt og drift for disse huller

• Åbningstid: gælder jeres SLA kun 8–16? Hvis ja, hvem tager sikkerhedshændelser udenfor?
• Definitioner: er “incident” tydeligt defineret (inkl. mistanke om kompromittering), eller bliver det til “almindelig support”?
• Eskalering: findes der en navngiven on-call og en tidsfrist for sikkerhedsvurdering?
• Logning: kan I udtrække ticket-historik som dokumentation til tilsyn (Datatilsynet) og intern audit?

Tjekliste: Sådan bygger I en månedlig rapport, der kan bruges til beslutninger

1. Fastlæg 4 sagsklasser (fx P1 stop, P2 kritisk, P3 generende, P4 request) og kræv at alle tickets kategoriseres ens.
2. Rapportér reaktionstid og løsningstid separat pr. klasse. En samlet gennemsnits-tid skjuler P1-problemer.
3. Lav en “Top 10 årsager”-liste (ikke top-10 symptomer). Kræv forslag til forebyggelse for hver.
4. Track genåbninger og gentagelser (samme bruger/samme fejl). Gentagelser = kendt problem uden permanent fix.
5. Mål brugerfriktion med 1 spørgsmål efter lukning: “Hvor nemt var det at få løst?” (Customer Effort Score, HDI).
6. Valider med Microsoft 365-data: brug Endpoint Analytics til at finde mønstre i klient-performance før/efter ændringer (Microsoft).
7. Bind det til økonomi: sæt en intern timekost og notér nedetid for P1/P2. Så kan CFO se business impact.

Før → Efter (2):
Før: “Færre tickets” bliver tolket som bedre support, men problemerne flytter bare til walk-ups, mails og interne teams.
Efter: I måler på Customer Effort + selvbetjeningsgrad. Færre tickets er kun en gevinst, hvis effort falder og løsningstider ikke stiger.

Fejl der koster jer penge, når I måler IT-support

• Kun at bruge gennemsnit: kræv median + 90-percentil for løsningstid, så “hale-sagerne” ikke skjules.
• At lade leverandøren definere alt: I skal eje kategorier, kritikalitet og hvad der tæller som “løst”.
• At ignorere miljøet: hvis endpoints og netværk ikke er standardiseret, bliver support uforudsigelig. Her hænger drift og Modern Workplace tæt sammen (se Microsoft 365).
• At måle uden handling: hver måned skal ende i 1–3 ændringer: patching, politik, automation, uddannelse eller leverandør-justering.

FAQ: Måling af IT support i praksis

Hvad er den vigtigste KPI for IT support kvalitet?

Løsningstid (MTTR) kombineret med genåbningsrate. Hurtig “lukning” uden varig løsning skaber flere henvendelser og mere spildtid.

Hvad er en god SLA for en SMB?

En god SLA er differentieret. P1 (stop) skal have kort reaktion og klar eskalering. P3/P4 kan godt have længere tider, hvis I får forebyggelse og stabilitet med i aftalen.

Hvad betyder First time fix rate, og hvad er et godt niveau?

First Contact Resolution (FCR) er andelen af sager, der bliver løst ved første kontakt uden at blive sendt rundt. SDI’s Benchmarking Report 2025 peger på ca. 70–75% som et sundt pejlemærke; under 60% tyder på “ping-pong”.

Hvordan undgår vi “watermelon effect” i vores support-rapportering?

Mål på brugeroplevelse og friktion, ikke kun oppetid. Brug fx Endpoint Analytics som modvægt til leverandørens driftstal og kræv en forklaring, når oplevelse og SLA ikke matcher.

Hvordan hænger NIS2 varslingskrav og IT-support sammen?

NIS2 stiller krav om hurtig varsling for væsentlige hændelser (ENISA peger på 24 timer). Det kræver et support-flow med 24/7 eskalering for sikkerhedshændelser, faste definitioner og dokumenterbare logs.

Hvilke spørgsmål skal vi stille vores IT-leverandør til næste QBR?

Start med: 1) Top-10 gentagne causes og permanent løsning, 2) FCR og hvorfor sager eskaleres, 3) 90-percentil løsningstid for P1/P2, 4) hvor mange sager genåbnes, 5) hvordan sikkerhedshændelser håndteres og dokumenteres.

Kan Microsoft 365 hjælpe med at måle supportkvalitet?

Ja. Microsoft peger på måling af slutbrugerperformance og produktivitet via bl.a. Endpoint Analytics/produktivitetsmålinger. Brug det til at spotte klient- og app-problemer, før de bliver til mange tickets.

Sådan går I i gang de næste 14 dage

1. Udvælg 1 måned af tickets og segmentér dem i P1–P4 med ens definitioner.
2. Beregn 7 KPI’er (reaktion, løsning, FCR, genåbninger, effort, impact, security handling) og lav en 1-sides rapport.
3. Find 3 gentagne årsager og beslut ét permanent fix pr. årsag (politik, automation, standardisering eller uddannelse).
4. Match sikkerhedsflow til 24-timers krav: hvem vurderer, hvem eskalerer, og hvordan logges det.
5. Genforhandl én ting i jeres aftale: fx rapporteringskrav, eskalering eller måltal for FCR/genåbninger.