Hvis I kun måler, hvor hurtigt supporten svarer, ender I let med en servicedesk, der virker “hurtig”, men som stadig efterlader folk frustrerede. Det svarer lidt til at måle en mekaniker på, hvor hurtigt bilen kommer ind på liften, ikke på om den faktisk kører godt bagefter.

Gode it-support nøgletal handler om mere end fart. De skal vise, om brugerne får løst deres problemer første gang, om sagerne kommer tilbage, og om I får styr på de ting, der langsomt bygger sig op (som gamle tickets og gentagne netværksfejl).

Her får I 7 nøgletal med konkrete formler, plus en enkel måde at sætte mål pr. supportniveau og undgå “KPI-spil”.

Før du måler: definér hvad “god support” betyder hos jer

Start med at aftale rammerne, ellers bliver tallene hurtigt støj. Afklar især tre ting:

For det første, hvad er en incident (fejl eller nedbrud) vs. en service request (bestilling, adgang, ny bruger, nyt udstyr). De to typer har forskellige forventninger. Et WiFi-nedbrud skal håndteres anderledes end “kan I opsætte en ny printer?”.

For det andet, brug et simpelt prioritetssprog (P1, P2, P3). P1 kan være “produktionen står” eller “hele skolen er offline”, P3 kan være “en enkelt bruger har et problem”.

Når I har de tre ting på plads, kan I måle uden at sammenligne æbler og pærer.

De 7 it-support nøgletal der viser kvalitet

Det her er kernen: 7 målinger, der tilsammen siger noget om både oplevelse, stabilitet og effektivitet.

1) Responstid og løsningstid (TTFR + MTTR), to stopure, to historier

TTFR (Time to First Response) = (sum tid fra ticket oprettes til første svar) / (antal tickets).
MTTR (Mean Time to Resolve/Repair) = (sum løsningstid for lukkede incidents) / (antal lukkede incidents).

TTFR måler tryghed og forventningsstyring. MTTR måler, hvornår problemet reelt er væk. Hvis I kun jagter lav TTFR, kan supporten “svare hurtigt” uden at rykke sagen.

2) Løst ved første kontakt (FCR)

FCR% (First Contact Resolution) = (tickets løst ved første kontakt / alle tickets) × 100.

FCR er en stærk kvalitetsindikator i L1. Den viser, om standardproblemer (password, printer, simpel netværksadgang) faktisk bliver lukket rigtigt, uden pingpong.

3) Genåbningsrate (Reopen rate)

Reopen rate% = (genåbnede tickets / lukkede tickets) × 100.

Reopen rate afslører “hurtige lukninger”. En lav MTTR ser flot ud, men hvis sagerne kommer igen dagen efter, betaler I prisen i driftstid og irritation.

4) SLA-overholdelse (SLA compliance)

SLA compliance% = (tickets der overholder SLA / tickets med SLA) × 100.

SLA er god disciplin, men den skal være realistisk og knyttet til prioritet. Overvej også at måle på 90-percentilen (p90), så enkelte ekstreme sager ikke skjuler mønstre.

5) Kundetilfredshed (CSAT)

CSAT% = (positive svar / alle besvarelser) × 100, eller brug en 1 til 5 score som gennemsnit.

CSAT er jeres “virkelighedstjek”. Den fanger tonens betydning, klar kommunikation og om brugeren føler sig taget seriøst, også når løsningen tager tid.

6) Alder på backlog (Backlog age)

Backlog age = median alder (i dage) på åbne tickets, målt fra oprettelse til i dag.

Backlog size kan svinge, men backlog age afslører, om noget rådner i bunden. Gamle tickets er ofte dem, der skaber små daglige gener, især på netværk og udstyr.

7) Ticket deflection og selvhjælp (Self-service deflection)

Deflection% = (løste henvendelser via selvhjælp uden ticket / totale henvendelser) × 100.

Det kræver lidt opsætning at måle, men det er guld værd. Hvis I fx laver en kort guide til “WiFi på gæstenet” eller “nulstil printkø”, kan deflection vise, om den faktisk hjælper, og om supporten får frigivet tid til de svære sager.

Vil I sætte nøgletal op omkring SLA’er på en måde, der giver mening for brugerne, kan den her guide være nyttig som baggrund: guide til bedre IT SLA’er.

Eksempel på KPI-mål for L1, L2 og L3 (og hvorfor de bør variere)

Mål skal passe til både sværhedsgrad og hvem der løser sagen. Her er et praktisk udgangspunkt, som I kan justere efter åbningstid, antal lokationer og hvor meget der kræver on-site hjælp.

Supportniveau	Typiske tickets	TTFR-mål	MTTR-mål (incidents)	Kvalitets-guardrails
L1	Adgang, printer, standard WiFi-klient, “hvordan gør jeg”	10-30 min	2-8 timer (P2-P3)	FCR 60-80%, Reopen < 5%
L2	Netværksfejl, driftproblemer, gentagne udfald, server/backup-fejl	30-60 min	4-24 timer	Reopen < 8%, tydelig årsag i notater
L3	Komplekse ændringer, leverandørsager, større fejl, sikkerhed	60-120 min	aftalt pr. sag	Statusopdatering fast cadence, CSAT følges tæt

Sæt også mål pr. ticket-type. Et “WiFi nede i hele bygningen” bør have stram TTFR og en tydelig eskaleringsregel til L2 hurtigt, mens “ny medarbejder skal have adgang” måles bedre på SLA-overholdelse og fejlfrie leverancer (ingen manglende rettigheder dag 1).

Undgå KPI-spild, og gør rapporten let at bruge

Goodhart’s law i praksis: Når et tal bliver et mål i sig selv, bliver det nemt at manipulere. Eksemplerne er klassiske: tickets lukkes for tidligt for at få lav MTTR, eller man sender et “vi kigger på det” for at få lav TTFR.

Tre enkle måder at undgå det på:

• Kombinér målinger: Sæt fx TTFR sammen med CSAT og Reopen rate, så hastighed ikke vinder over kvalitet.
• Brug guardrails: Hvis FCR stiger, men Reopen også stiger, er det et rødt flag.
• Kig på stikprøver: 10 tilfældige sager pr. måned, vurderet på klarhed, løsning og kommunikation, giver ofte mere end endnu et dashboard.

Tjekliste til implementering

• Aftal ticket-typer, prioritet og L1/L2/L3 i én side.
• Vælg 7 nøgletal og skriv præcis formel og datakilde.
• Sæt mål pr. niveau og pr. prioritet (P1-P3).
• Byg 2 guardrails ind (fx Reopen og CSAT).
• Kør 1 måned som baseline, justér derefter.

Mini-skabelon til månedlig KPI-rapport

Sektion	Hvad I viser	Tal	Kommentar/tiltag
Volume	Nye tickets, lukkede, eskalerede
Hastighed	TTFR (gennemsnit + p90), MTTR
Kvalitet	FCR%, Reopen rate%
Oplevelse	CSAT% eller score
Kø-sundhed	Backlog age (median)
Selvbetjening	Deflection%

Når I måler rigtigt, får I ikke bare en “hurtig” support, I får en support, der føles tryg, løser problemerne første gang og holder netværk og drift stabile. Det er det, der kan mærkes i hverdagen, og det er det, tallene skal afspejle.