Når printeren strejker fem minutter før et kundemøde, eller når mailen pludselig ikke sender, er “vi ringer lige til ham, der kan IT” en fristende løsning. Problemet er bare, at den tilgang ofte fungerer lige indtil den dag, hvor den ikke gør.
I denne artikel får du en praktisk og fagligt funderet gennemgang af forskellen på ad hoc hjælp og fast IT-support: responstid, prioritering, dokumentation og ikke mindst hvordan du undgår at hele driften bliver personafhængig. Du får også en enkel model for supportniveauer (akut/drift/projekt) samt en konkret tjekliste til at vælge leverandør.
Kort definition: Ad hoc IT-hjælp er uplanlagt assistance, du bestiller efter behov, typisk pr. time og uden faste aftaler. Fast IT-support er en løbende aftale med defineret responstid, prioritering, proces og dokumentation. Det betyder noget, fordi IT-fejl sjældent er “bare en lille ting” i praksis: de stopper arbejdet, skaber usikkerhed og koster tid, der sjældent bliver målt.
Ad hoc hjælp vs fast IT-support: den grundlæggende forskel
Ad hoc er ofte drevet af situationen: noget er gået galt, og man har brug for en hurtig hånd. Fast IT-support er drevet af systematik: man planlægger for fejl, ændringer og vedligehold, så problemer forebygges eller løses ensartet.
En nyttig tommelfingerregel fra praksis: Ad hoc passer nogenlunde, hvis IT kun er “hjælpeværktøj”. Fast support bliver hurtigt nødvendigt, hvis IT er en del af din leverance, din drift eller din compliance.
Mini-konklusion: Ad hoc kan være billigst på regningen i dag, men fast support er ofte billigst i tabt tid og risiko over tid.
Responstid og tilgængelighed: når “hurtigt” skal kunne måles
Det mest synlige skel er responstid. Ved ad hoc afhænger “hurtigt” af, om personen har tid, telefonen er tændt, og om opgaven er interessant nok til at blive taget nu. Ved fast support bør responstid være defineret og målbart.
Typiske responstider i praksis
I mange små og mellemstore virksomheder ser jeg ofte disse mønstre:
- Ad hoc: “Vi vender tilbage i løbet af dagen” (reelt alt fra 15 minutter til 3 dage, afhængigt af travlhed).
- Fast support (basis): svar inden for 1–4 arbejdstimer på driftskritiske sager.
- Fast support (udvidet): svar inden for 15–60 minutter på kritiske hændelser, ofte med vagtordning.
Tilgængelighed er ikke det samme som løsningstid
En leverandør kan godt svare hurtigt, men stadig bruge lang tid på at løse problemet, hvis der mangler adgang, overblik eller dokumentation. Derfor bør du se på både reaktionstid og forventet tid til løsning for forskellige sagstyper.
Mini-konklusion: Kræv klare servicemål, men husk at hurtig respons uden forberedelse sjældent giver hurtig løsning.
Prioritering: hvem kommer først, og hvorfor?
Ved ad hoc ender prioritering ofte som “hvem råber højest” eller “hvem ringede først”. Det kan føles fair, men i drift er det sjældent effektivt. Ved fast IT-support bør prioritering være baseret på konsekvens og forretningskritikalitet.
En enkel model for supportniveauer: akut, drift og projekt
For at undgå at alt bliver behandlet som en brand, kan du bruge en enkel 3-niveaus model:
- Akut: Stop i produktion/drift. Eksempel: hele virksomheden er uden internet, mail er nede, eller et ransomware-alarm-signal. Mål: hurtig triage, afgrænsning og midlertidig løsning.
- Drift: Løbende fejl og brugerhenvendelser. Eksempel: én medarbejder kan ikke logge på, printer fejler, Teams-enheder virker ikke. Mål: stabil drift, standardløsninger og gentagelighed.
- Projekt: Planlagte ændringer og forbedringer. Eksempel: migrering til Microsoft 365, netværksopgradering, nyt ERP-integrationsflow. Mål: scope, tidsplan, test og dokumenteret overlevering.
Nøglen er at definere, at projektopgaver ikke “sniger sig ind” i driften via små ad hoc-ønsker. Det er her, mange virksomheder mister overblikket.
Prioritering med impact: et konkret eksempel
To tickets tikker ind samtidig: “direktørens skærm flimrer” og “lageret kan ikke printe fragtlabels”. Med ad hoc kan direktørens problem få forrang. Med en moden supportmodel prioriteres lageret, fordi det stopper forsendelser og skaber direkte omsætningstab.
Mini-konklusion: God IT-support handler mindre om hierarki og mere om impact.
Dokumentation: forskellen på at løse problemer og at lære af dem
Ad hoc løsninger er ofte mundtlige: “Jeg fik det til at virke.” Fast support bør bygge på dokumentation, så virksomheden bliver mindre sårbar og mere effektiv over tid.
Hvad bør dokumenteres som minimum?
- Bruger- og systemændringer (hvem, hvad, hvornår, hvorfor).
- Netværks- og systemoversigt (internet, firewall, switches, Wi-Fi, servere, cloud-tjenester).
- Adgange og ejerskab (hvem ejer Microsoft 365, domæne, backup, licenser).
- Standarder for pc-opsætning og software (så nye medarbejdere kan onboardes hurtigt).
- Historik på tilbagevendende fejl (så man kan fjerne årsagen, ikke kun symptomet).
Dokumentation er ikke bureaukrati for bureaukratiets skyld. Den sparer tid i hver eneste fejlretning og gør det muligt at udskifte personer uden at starte forfra.
Mini-konklusion: Hvis ingen kan se, hvad der er gjort, kan ingen bygge videre på det.
Hvad du bør kræve af support (uanset om du vælger ad hoc eller fast)
Hvis du vil undgå den klassiske situation, hvor “det hele bor i hovedet på én”, skal du stille tydelige krav til processer, ejerskab og gennemsigtighed. For mange virksomheder er det her skiftet fra tilfældig hjælp til professionel drift starter.
Et godt sted at begynde er at sammenligne, hvordan forskellige leverandører arbejder med IT-support til virksomheder i praksis: hvordan tickets håndteres, hvad der dokumenteres, og hvordan de sikrer kontinuitet, når en tekniker er syg eller på ferie.
Kernekrav, der typisk gør den største forskel
- En ticket-proces (mail/portal/telefon) med sagsnummer og status.
- Prioriteringsregler koblet til akut/drift/projekt.
- Adgangsstyring med klare ejere og sporbarhed.
- Dokumentation som du som kunde kan få udleveret ved behov.
- Rapportering (fx månedlig oversigt over sager, gentagelser og anbefalinger).
Hvad koster det, og hvordan sammenligner man fair?
Ad hoc prissættes typisk pr. time. Fast support prissættes ofte pr. bruger, pr. enhed eller som en fast månedlig aftale med inkluderet tid og tydelige rammer. Det svære er, at ad hoc ser billigere ud, hvis du kun kigger på timeprisen.
En mere retvisende sammenligning er at måle “total omkostning ved nedetid” i grove træk: Hvis en fejl rammer fem personer i én time, er det fem arbejdstimer tabt. Med en intern timeløn (inkl. overhead) på fx 400–700 kr. er det 2.000–3.500 kr. i tabt produktivitet, før vi overhovedet taler stress, forsinkelser eller kundepåvirkning. Her giver faste responstider og proaktiv drift ofte mening.
Mini-konklusion: Sammenlign ikke kun pris pr. time, men pris pr. afbrudt arbejdsdag.
Sådan undgår du, at alt afhænger af én person internt
Personafhængighed opstår typisk, når én medarbejder både er “superbruger”, indkøber, adgangsadministrator og uofficiel IT-chef. Det kan fungere i en periode, men det skaber en enkelt fejlkilde: ferie, sygdom, opsigelse eller bare for mange andre opgaver.
Praktiske greb, der reducerer risikoen hurtigt
- Opret en fælles IT-mail/kanal til henvendelser, så viden ikke ligger i private indbakker.
- Saml licenser og ejerskab: domæne, Microsoft 365, backup og antivirus bør have mindst to administratorer.
- Indfør en “break-glass”-konto med stærk kontrol (til kritiske situationer) og logning.
- Standardisér pc-opsætning og softwarepakker, så support ikke bliver håndarbejde hver gang.
- Læg grunddokumentation i et fælles system (ikke i et Word-dokument på en enkelt pc).
Hvis du arbejder med en ekstern leverandør, så aftal fra start, at dokumentation og adgangsoversigt opdateres løbende. Ellers flytter du bare personafhængigheden fra en intern medarbejder til en ekstern konsulent.
Mini-konklusion: Kontinuitet kræver, at viden ligger i systemer og processer, ikke i mennesker.
Almindelige faldgruber ved ad hoc og fast support (og hvordan du undgår dem)
Både ad hoc og faste aftaler kan fejle, hvis rammen er uklar. Her er de mest almindelige fejl, jeg ser i praksis, og hvordan du kan forebygge dem.
Faldgruber ved ad hoc hjælp
- Ingen kø: Alt bliver “nu”, og intet bliver færdigt ordentligt. Løsning: brug tickets, selv ved ad hoc.
- Skjulte bindinger: Passwords, licenser og opsætninger ligger hos leverandøren. Løsning: kræv ejerskab og dokumentation.
- Lappeløsninger: Problemer vender tilbage, fordi årsagen ikke fjernes. Løsning: afsæt tid til root cause på gentagelser.
Faldgruber ved fast IT-support
- Uklart scope: Hvad er inkluderet, og hvad er projekt? Løsning: definer akut/drift/projekt skriftligt.
- “Alt er standard”: Leverandøren tager ikke højde for din forretning. Løsning: kræv en onboarding med miljøgennemgang.
- Målinger uden værdi: Rapporterer kun antal sager, ikke mønstre. Løsning: efterspørg forslag til forbedringer baseret på data.
Mini-konklusion: De bedste aftaler er ikke dem med flest sider, men dem med færrest overraskelser.
Tjekliste: sådan vælger du den rigtige IT-supportleverandør
Brug tjeklisten her som et konkret beslutningsværktøj, uanset om du vil købe fast support eller bare professionalisere din ad hoc hjælp. Den kan også bruges som kravliste i et tilbudsmateriale.
- Responstid og åbningstid: Hvilke tider dækkes, og hvad er mål for akut vs drift?
- Prioriteringsmodel: Har de en tydelig model (akut/drift/projekt), og følger de den i praksis?
- Ticketing og historik: Får du sagsnumre, status og mulighed for at se historik?
- Dokumentation: Hvad dokumenteres, hvor ligger det, og kan du få det udleveret ved samarbejdets ophør?
- Sikkerhed og adgangsstyring: Hvordan håndterer de admin-rettigheder, MFA, logning og offboarding?
- Onboarding: Laver de en miljøgennemgang (netværk, backup, licenser, kritiske systemer) før de lover “hurtig support”?
- Kompetencebredde: Kan de dække både klienter, netværk og cloud, eller skal de “ringe videre” hver gang?
- Rapportering og forbedringsforslag: Får du indsigter om gentagelser, risici og anbefalede tiltag?
Hvis du vil være ekstra skarp, så bed om et eksempel på en anonymiseret månedsrapport og et eksempel på dokumentation fra en kunde: det afslører hurtigt, om processerne er reelle eller bare fine ord.
Mini-konklusion: En god leverandør kan forklare, hvordan de arbejder, uden at du skal gætte dig til resten.
Hvornår giver det mening at skifte fra ad hoc til fast support?
Der er ikke én magisk grænse, men der er tydelige signaler. Hvis du kan nikke genkendende til flere af punkterne her, er du typisk forbi “ad hoc fungerer fint”-fasen:
- Du oplever tilbagevendende driftsstop eller de samme fejl igen og igen.
- Nye medarbejdere tager for lang tid at onboarde, fordi opsætning er manuel.
- Ingen kan med sikkerhed forklare, hvem der ejer hvilke licenser og adgange.
- IT-opgaver afbryder nøglepersoner i deres kernearbejde flere gange om ugen.
- Der er krav fra kunder eller branche (fx logning, backup, adgangsstyring) som du skal kunne dokumentere.
Et pragmatisk kompromis kan være en basis fast supportaftale til drift og sikkerhed, kombineret med projektarbejde efter behov. Så får du både stabilitet og fleksibilitet.
Mini-konklusion: Skift handler sjældent om “mere IT” og oftere om mere ro, forudsigelighed og mindre risiko.