Når IT’en driller, er det sjældent “bare en lille ting” for den, der sidder fast lige nu.
I denne artikel får du en praktisk guide til, hvad der typisk kan løses med fjernsupport (remote) versus on-site support, og hvordan du hurtigt afgør, hvilken vej der er smartest. Du får også en enkel beslutningsmodel, konkrete eksempler fra hverdagen og en metode til at organisere henvendelser, så fejlretning går hurtigere — både for brugere og IT.
Definition: Remote IT-support er hjælp, hvor en tekniker fejlsøger og løser problemer via internetforbindelse (f.eks. via en fjernstyringsklient eller M365-adminværktøjer). Det betyder noget, fordi mange problemer kan afklares og løses på minutter uden ventetid på kørsel — men ikke alt kan og bør løses remote.
Remote vs on-site: den korte tommelfingerregel
Som udgangspunkt er remote bedst, når problemet handler om software, adgang, indstillinger eller konti. On-site er bedst, når problemet handler om fysisk infrastruktur, kabler, hardware eller forhold i lokalet (wifi-dækning, støj, placering).
Tommelfingerregel: Hvis du kan beskrive problemet uden at pege på en fysisk dims, kan det ofte løses remote. Hvis du skal kigge på lys i en switch, mærke varme i en router eller flytte et kabel, er det ofte on-site.
Mini-konklusion: Start remote, hvis du er i tvivl — men skift hurtigt til on-site, når tegnene peger på fysisk fejlkilde.
Hvad kan typisk løses remote? (hurtige wins)
Remote support er stærk, fordi teknikeren kan arbejde parallelt: tjekke logs, admin-porte, rettigheder og klientopsætning uden at forstyrre andre. I praksis ser jeg, at en stor del af “hverdags-IT” kan klares remote, især i Microsoft 365-miljøer.
Softwarefejl og applikationer
Eksempler på opgaver, der ofte kan løses remote:
- Programmer der crasher, fryser eller opdaterer forkert (Office, Teams, browser, ERP-klienter).
- Printere der “forsvinder” i Windows, eller driverkonflikter efter opdateringer.
- Fejl i VPN-klienter og fjernskrivebord (RDP), hvor konfiguration eller certifikater driller.
- Performance-problemer pga. opstartsprogrammer, diskplads eller defekte brugerprofiler.
Mini-konklusion: Hvis problemet kan gentages på skærmen, kan det ofte løses remote med det samme.
M365, adgang og identitet
Microsoft 365 er designet til central administration, så mange adgangs- og konfigurationsopgaver er oplagte remote:
- Nulstilling af adgangskoder, låste konti og MFA-problemer.
- Rettigheder til SharePoint/OneDrive, Teams-medlemskaber og delingspolitikker.
- Opsætning af nye brugere, licenser og mailbokse.
- Fejl i Outlook (autodiscover, profiler, cache), eller manglende synkronisering.
Et konkret eksempel: En bruger “mister” adgang til en Teams-kanal. Det kan skyldes, at vedkommende er fjernet fra en M365-gruppe, at gæsteadgang er ændret, eller at der er en policy-konflikt. Remote kan man typisk afklare årsagen på 5–15 minutter, hvis man har de rigtige oplysninger (brugernavn, kanalnavn, tidspunkt og fejlbesked).
Hvad kræver typisk on-site? (når hænder og kabler er nødvendige)
On-site support handler ikke om, at remote er “dårligt” — men om at visse ting kræver fysisk adgang, måling eller udskiftning. Særligt netværk og hardware er områder, hvor en tekniker på stedet kan spare timer i fejlsøgning.
Netværk, wifi og kabling
Typiske on-site opgaver:
- Wifi-dækning og roaming-problemer: måling af signal, kanalstøj og placering af access points.
- Patchpaneler, defekte netværkskabler, løse stik og forkert mærkning.
- Switch-fejl, PoE-udfordringer (f.eks. IP-telefoner/access points der ikke får strøm).
- Fejlsøgning på internetlinje sammen med udbyder (lys i fiberboks, gateway, fysisk terminering).
En klassiker: “Internettet er ustabilt.” Remote kan man se, at forbindelsen dropper, men on-site kan man hurtigt finde den reelle årsag: et klemt kabel under en dør, en billig switch uden loop-beskyttelse eller et access point placeret bag metalreoler. Den type fejl kan være usynlig i software, men tydelig i rummet.
Hardware, opsætning og udskiftning
On-site er ofte nødvendigt ved:
- Defekte diske, RAM-fejl, overophedning, eller maskiner der ikke booter.
- Opsætning af nye arbejdsstationer, dockingstationer, skærme og mødelokaleudstyr.
- Fysisk installation af printere, scannere og label-printere i produktion/lagre.
- Server- og rackarbejde, UPS, kabelføring og strømforhold.
Mini-konklusion: Når du skal udskifte, flytte, måle eller mærke noget fysisk, er on-site næsten altid hurtigst i sidste ende.
En enkel beslutningsmodel: 5 spørgsmål der afgør retningen
Du behøver ikke være IT-ekspert for at vælge rigtigt. Brug denne model, som jeg ofte lærer brugere og kontoransvarlige:
- Er det én person eller alle? Hvis alle er ramt (internet, Teams, printer), peger det mod netværk eller central service.
- Er problemet knyttet til et bestemt sted? Hvis det kun sker i mødelokalet eller i lagerhallen, peger det mod wifi/udstyr on-site.
- Kan du logge ind? Hvis ikke, er det ofte identitet/adgang (remote) — med mindre netværket er nede.
- Er der en fysisk indikator? Blinkende røde lamper, ingen strøm, knæk i kabel: on-site.
- Kan problemet reproduceres nu? Hvis ja, kan remote typisk diagnosticere hurtigt; hvis nej, skal man indsamle data (tidsstempler, logniveau, skærmbilleder).
Praktisk regel: Start med at afklare “én vs alle” og “sted vs ikke-sted”. Det skærer typisk 50% af gætteriet væk.
Sådan får du hjælp på minutter (og undgår ping-pong)
Den hurtigste support opstår, når henvendelsen indeholder præcis de informationer, teknikeren ellers skal bruge tid på at spørge efter. Hvis du vil gøre det nemt at få hjælp hurtigt, kan du samle henvendelser ét sted og bruge et fast format. Mange vælger at kombinere tickets til planlagte opgaver med chat/telefon til akutte stopklodser.
Hvis du har brug for, at en tekniker kan hoppe på med det samme, kan du bruge fjernsupport til virksomheder som en direkte vej til hurtig fejlsøgning, især på M365, adgang og klientproblemer.
Skabelon til en “god” IT-henvendelse
Brug denne korte tjekliste (den kan copy/pastes i en ticket):
- Hvad forsøger du at gøre? (f.eks. “åbne vedhæftet i Outlook”)
- Hvad sker der i stedet? (fejlbesked ordret eller screenshot)
- Hvornår startede det? (tidspunkt og om det var efter opdatering/ændring)
- Hvem er ramt? (kun mig, teamet, hele virksomheden)
- Hvor sker det? (kontor, hjemmearbejde, bestemt lokale)
- Hvad har du prøvet? (genstart, andet netværk, browser, ny profil)
Mini-konklusion: En henvendelse med kontekst, tidspunkt og fejltekst bliver ofte løst i første forsøg.
Sådan prioriterer du: incident vs service request
For at det går hurtigt i praksis, skal du skelne mellem to typer:
- Incident (driftstop): Noget der virkede før, men er gået i stykker nu (internet nede, mail kan ikke sendes, bruger låst ude).
- Service request (ønske): Noget du vil have sat op eller ændret (ny bruger, adgang til mappe, ny printer, nyt mødelokaleudstyr).
Incident bør have en fast kanal og kort responstid. Requests kan samles og løses i batches, så man undgår konstant kontekstskift.
Hvad koster remote vs on-site typisk — og hvad bestemmer prisen?
Pris afhænger af aftaleform, kompleksitet og hvor godt sagen er beskrevet. Men i mange virksomheder bliver den reelle forskel drevet af spildtid: kørsel, ventetid på adgang, manglende oplysninger og gentagne forsøg.
Som en grov sammenligning: Remote kan ofte starte inden for få minutter og løser mange standardproblemer på 10–30 minutter. On-site indeholder typisk transport og “setup-tid” og giver bedst mening, når der alligevel skal måles, flyttes eller udskiftes udstyr.
Best practice: Brug remote til triage (hurtig afklaring) og send on-site, når der er tydelige fysiske tegn, eller når remote-fejlsøgning rammer en mur.
Typiske fejl og faldgruber (og hvordan du undgår dem)
Her er de mønstre, der igen og igen forlænger supporttiden unødigt:
- Uklare symptomer: “Det virker ikke” uden fejltekst eller eksempel. Løsning: få én konkret handling og én konkret fejl.
- Ingen tidsstempel: Uden “kl. 10:42” er logs svære at bruge. Løsning: skriv tidspunkt og tidszone ved fjernarbejde.
- Blandet kanal-kaos: Samme problem meldes i mail, chat og telefon. Løsning: én primær kanal pr. sag og reference-ID.
- For tidlig hardware-udskiftning: Man køber nyt, før man ved om fejlen er kabel/driver/policy. Løsning: remote triage + on-site verifikation.
- Lokale “fixes” uden dokumentation: En medarbejder ændrer netværksudstyr, men noterer det ikke. Løsning: ændringslog og enkel dokumentation.
Mini-konklusion: De fleste forsinkelser skyldes proces og information — ikke teknisk sværhedsgrad.
Organisér henvendelser, så IT faktisk kan være hurtige
Hurtig support er et system, ikke et heroisk øjeblik. Når du har 20–200 brugere, bliver struktur vigtigere end “at kende en, der kan fikse det”.
Lav en enkel support-opsætning med klare regler
En praktisk opsætning, der virker i mange små og mellemstore virksomheder:
- Én indgang til ikke-akutte sager (ticket/mailformular) og én indgang til akutte driftstop (telefon/chat).
- Standardfelter i ticket: bruger, enhed, lokation, hastighed (kritisk/høj/normal), fejltekst, tidspunkt.
- Fast triage 2–4 gange dagligt (eller løbende ved aftale), så småting ikke vokser.
- Vidensbase med 10–20 korte guides (MFA, printer, Teams-lyd, “rydd cache”, adgang til SharePoint).
Det lyder simpelt, men effekten er stor: færre afbrydelser, hurtigere løsningstid og bedre overblik over gentagne problemer (som ofte peger på en underliggende årsag, f.eks. dårlig wifi i et område).
Brug “niveauer” uden at gøre det tungt
Du behøver ikke et stort ITIL-setup, men en let opdeling hjælper:
- Niveau 1: Hurtige standardfixes (password, MFA, standardprogrammer, basale fejl).
- Niveau 2: Dybere fejlsøgning (netværksanalyse, policies, rettigheder, performance).
- Niveau 3: Leverandører/specialister (ISP-fejl, komplekse systemer, hardware-RMA).
Praktisk pointe: Når du ved, hvilket niveau sagen er på, kan du også forvente korrekt tidsramme og næste skridt.
Eksempler: sådan vælger du rigtigt i konkrete situationer
Her er nogle typiske scenarier og den hurtigste tilgang:
- “Outlook spørger hele tiden om adgangskode”: Start remote (profil, cache, MFA, token, licens, autodiscover).
- “Teams-møde kan ikke bruge mikrofon i mødelokalet”: Start remote hvis det er brugerens pc; gå on-site hvis det er møderumsudstyr/AV, kabler eller specifikt lokale.
- “Printeren på lageret udskriver blanke sider”: Remote kan tjekke kø/driver; on-site hvis det er toner/tromle, papirbane eller fysisk fejl.
- “Wifi er langsomt i den ene ende af kontoret”: On-site (måling, kanalplan, AP-placering). Remote kan kun bekræfte symptomerne.
Mini-konklusion: De bedste resultater kommer, når du kombinerer remote diagnose med on-site handling, hvor det giver mening.
Bedste praksis: få mere stabil drift med små greb
Hvis du vil reducere antallet af supportsager (ikke bare løse dem), så fokuser på de områder, der typisk skaber gentagne problemer:
- Standardisér enheder (færre PC-modeller og dockingtyper giver færre drivervarianter).
- Hold styr på identitet (MFA, conditional access og tydelige processer ved onboarding/offboarding).
- Overvåg det vigtigste (internet, wifi, centrale services) så du opdager fejl før brugerne.
- Dokumentér netværket (simple netværksskitser, mærkning af porte, liste over udstyr og placering).
- Planlæg opdateringer (Windows/Office) så du undgår “alle opdaterer mandag kl. 9”.
Bundlinje: Remote løser meget hurtigt, on-site løser det fysiske effektivt — men den største tidsbesparelse kommer, når henvendelser er velbeskrevne, og miljøet er standardiseret og dokumenteret.
