Admin Pro Tip: Team-hierarki - Sådan Bygger Du Det Rigtigt – Available ApS

Et veldesignet team-hierarki i Zendesk er en central forudsætning for en effektiv supportorganisation. Det er ikke kun en øvelse i at organisere navne i lister; det er fundamentet for, hvordan sager flyder, hvordan performance måles, og hvordan supporten skaleres i takt med virksomhedens vækst. Et uhensigtsmæssigt hierarki skaber forvirring, flaskehalse og gør det vanskeligt at udtrække meningsfulde data. Et velfungerende hierarki skaber klarhed, effektivitet og giver de nødvendige rammer for at levere en stærk kundeoplevelse.
Erfaring fra mange Zendesk-instanser viser, at de samme fejl ofte gentages, og at der samtidig er tydelige mønstre for, hvad der fungerer, når opsætningen er korrekt. Artiklen samler disse erfaringer i en praktisk guide til at opbygge et team-hierarki, der fungerer nu og samtidig er robust nok til at vokse med organisationen. Fokus er på centrale beslutninger om Groups, Organizations og Light Agents samt konkrete eksempler og tjeklister til direkte anvendelse.

Fundamentet: Groups vs. Organizations - Hvornår Skal Hvad Bruges?

Dette er den mest grundlæggende og ofte misforståede del af Zendesk-hierarkiet. Forveksling mellem Groups og Organizations er årsag til mange hierarki-problemer. Skellet er dog enkelt, når princippet først er på plads.

Hvad er Groups?

Groups kan betragtes som den interne teamstruktur. De fungerer som “bokse”, hvor agenter placeres for at definere ansvarsområder og rute sager til de rette personer.

Formål: Intern organisering af agenter.
Anvendelse: Routing af sager, tildeling af ejerskab, arbejdsfordeling.
Synlighed: Kun synligt for agenter og administratorer i Zendesk. Kunder kan ikke se, hvilken group en sag tilhører.
Eksempler:
- Level 1 Support
- Level 2 Teknisk Support
- Billing Team
- Customer Success Managers
- Nordic Support
- Premium Support

En agent kan være medlem af flere grupper, men en sag kan kun tilhøre én group ad gangen (den group, som den tildelte agent tilhører). Dette er afgørende for routing og rapportering. Når en trigger eksempelvis siger “Tildel sag til ‘Level 2 Teknisk Support’”, peges der på en group.

Hvad er Organizations?

Organizations kan betragtes som den eksterne kundestruktur. De fungerer som “bokse”, hvor kunder (slutbrugere) typisk placeres ud fra den virksomhed, de arbejder for.

Formål: Gruppere eksterne kunder.
Anvendelse: Deling af sager mellem kolleger fra samme firma, organisationsspecifikke SLA’er, organisationsnoter.
Synlighed: Kunder kan se, at de er en del af en organisation, og kan se kollegers sager, hvis “delte sager” (shared tickets) er aktiveret.
Eksempler:
- ACME Corporation
- Globex Inc.
- Initech
- Premium Kunder
- Partnere

Når en slutbruger oprettes i Zendesk, kan vedkommende tildeles en organisation. Den vigtigste funktion er “shared tickets”: Hvis to kolleger fra ACME Corporation kontakter supporten, kan agenter se begge sager og forstå sammenhængen. Det reducerer risikoen for, at flere agenter arbejder på samme underliggende problem for samme firma uden at vide det.

Den Gyldne Regel: Groups = Internt, Organizations = Eksternt

Hvis én regel skal huskes, er det denne. Den er den hurtigste måde at afgøre, hvad der skal bruges i en given situation.

Egenskab	Groups	Organizations
Formål	Intern teamorganisering	Ekstern kundeorganisering
Hvem er der i?	Agenter	Slutbrugere (kunder)
Primær funktion	Routing og tildeling af sager	Deling af sager og SLA’er
Eksempel	“Teknisk Team”	“Microsoft”
Spørgsmål at stille	“Hvem skal arbejde på denne sag?”	“Hvem er kunden?”

En klassisk fejl er at oprette en group for hver kunde. Det skaber et uoverskueligt antal grupper, ingen agenter kan være medlem af alle, og routing bliver urealistisk. Til det formål skal Organizations anvendes. Omvendt er det en fejl at bruge Organizations til at definere interne teams, da agenter ikke kan tildeles til en organisation.

Light Agents - Et Skjult Værktøj (og Et Dobbeltkantet Værktøj)

Light Agents er en undervurderet og samtidig ofte misbrugt funktion i Zendesk. Korrekt anvendt er det et stærkt værktøj til at inddrage ekspertise uden at forstyrre sagsflowet. Forkert anvendt skaber det flaskehalse og uklarhed.

Hvad er en Light Agent?

En Light Agent er en brugertype med begrænset adgang. Light Agents kan:

Se sager, hvor de er CC’et.
Tilføje interne noter (private comments).
Redigere egne kommentarer.
Se og tilføje tags.

En Light Agent kan ikke:

Være tildelt en sag (assignee).
Redigere offentlige kommentarer, som ikke er skrevet af dem selv.
Bruge apps, der kræver redigeringstilladelser.
Følge sager (CC-funktionen anvendes i stedet).

Light Agents fungerer i praksis som bidragydere/konsulenter, ikke som ejere af sager.

Grønne Flag: Hvornår Light Agents Giver Mening

Light Agents anvendes ofte med succes i følgende scenarier:

Subject Matter Experts (SMEs): En seniorudvikler, der ikke skal håndtere daglig support, men skal bidrage med tekniske svar på komplekse fejlrapporter. I stedet for en fuld agent-licens CC’es vedkommende på den relevante sag. Svaret gives som intern note, og Tier 1-agenten formidler svaret til kunden.
Ledere og mellemledere: En teamleder, der ønsker gennemsigtighed i teamets sager uden at indgå i den daglige routing. Som Light Agent kan lederen følge med, tilføje vejledende noter og overvåge kvalitet uden at overtage sager fra køen.
Særlige roller: Personer fra jura, marketing eller salg, der lejlighedsvis skal se en sag eller give input. Der er ikke behov for fuld adgang, men der er behov for kontekst og mulighed for interne kommentarer.
Eksterne konsulenter: Ved samarbejde med freelance-udviklere eller eksterne konsulenter på et specifikt projekt kan Light Agent-adgang gives til relevante sager. Det giver nødvendig indsigt uden adgang til hele Zendesk.

Fællesnævneren er, at rollen skal bidrage med viden, ikke eje processen.

Røde Flag: Hvornår Light Agents Bør Undgås

Misbrug opstår typisk, når Light Agents anvendes som en billig erstatning for fulde agent-licenser.

Som primær kontakt: Produkt-specialister gøres til Light Agents, og en regel CC’er dem på alle sager om et bestemt produkt. Da Light Agents ikke kan tildeles sager, ender sager i “Pending” og venter på svar fra en person uden formelt ejerskab. Det skaber flaskehalse.
For at spare licensomkostninger: Der er behov for 10 agenter, men der købes 8 fulde licenser og 2 Light Agent-licenser. Resultatet er, at de to ikke kan tage sager fra køen, arbejdsbyrden fordeles skævt, ventetid øges, og fulde agenter frustreres. Hvis en person skal løse opgaver i køen, kræver det en fuld agent-licens.
Overforbrug: Hvis for mange interne roller er Light Agents, bliver ansvar uklart. En agent kan CC’e flere Light Agents, og det bliver utydeligt, hvem der forventes at svare. Antallet bør begrænses til de roller, hvor det er nødvendigt.

En Light Agent kan aldrig være den sidste person i en kæde. Rollen kan kun være bidragsyder. Arbejdsgange bør designes med dette som præmis.

Skill-Based Routing - Magi eller Mareridt?

Skill-based routing kan lyde som den optimale løsning: Hver sag sendes automatisk til den mest kvalificerede agent. I praksis kan det dog hurtigt udvikle sig til et administrativt mareridt, der gør systemet uoverskueligt og ineffektivt.

Hvad er Skill-Based Routing?

I Zendesk implementeres skill-based routing typisk via en kombination af:

Brugerdefinerede felter (Custom Fields): Et felt af typen “Multi-select” eller “Checkboxes” på agentens profil til valg af kompetencer (fx “Dansk”, “Engelsk”, “Billing”, “Teknisk”, “Produkt A”).
Triggers: En trigger, der kører ved indkommende sager, vurderer behov (fx via tags eller et andet brugerdefineret felt) og opdaterer sagen med et “skill”-tag.
Omnichannel Routing (hvis tilgængeligt): En mere avanceret funktion, der kan tage højde for agenters kapacitet og skills direkte i routing-motoren.

Når Det Virker: Simpelt og Tydeligt Defineret

Skill-based routing kan være effektivt, når opsætningen holdes enkel. Nøglen er få, brede og ikke-overlappende skills.

Godt eksempel: Sprog-routing

Skills: Dansk, Svensk, Engelsk.
Setup: En trigger tjekker sproget i indkommende e-mail eller chat. Hvis sproget er dansk, tilføjes tagget skill_dansk. En anden trigger ser skill_dansk og tildeler sagen til en agent i Level 1 Support-gruppen, der har Dansk som skill.
Hvorfor det virker: Skills er typisk eksklusive, brede og lette at administrere, og de løser et konkret problem.

Godt eksempel: Premium-routing

Skills: Premium Support.
Setup: Kunder fra organisationen “Premium Kunder” får automatisk tagget premium_support. En trigger sikrer, at sager med dette tag rutes til agenter i Premium Support-gruppen, som har Premium Support-skillen.
Hvorfor det virker: Skillen er binær og enkel at vedligeholde.

Rødt Flag: Kompleksitetens Fælde

Problemer opstår, når for mange skills kombineres (“kompleksitetsmatricen”).

Dårligt eksempel: Hyper-specifikke skills

Skills: Dansk, Engelsk, Svensk, Norsk, Billing, Teknisk Level 1, Teknisk Level 2, Produkt A, Produkt B, Produkt C, API Integration, Premium Support.
Setup: En trigger skal finde en agent med både Dansk, Teknisk Level 2 og Produkt B.
Hvorfor det bliver et mareridt:
1. Sager sidder fast: Hvis den eneste agent med kombinationen er fraværende, bliver sagen ikke tildelt og kan blive liggende i “Unassigned”.
2. Vedligeholdelse er urealistisk: Nye agenter kræver mange manuelle skill-tilføjelser. Rolleændringer kræver løbende opdateringer. Produkter, der udfases, kræver oprydning i skills og triggers. Det bliver en administrativ tidsbombe.
3. Rapportering bliver uoverskuelig: Performance for fx “Teknisk Level 2” bliver svær at isolere, hvis sager samtidig er opdelt på mange produkt-tags.

Anbefaling: Brug grupper til at definere primære ansvarsområder (fx Teknisk Level 2, Billing). Brug skill-based routing kun til 1-2 tværgående, brede kompetencer, typisk sprog. Hvis der er behov for at skelne mellem produkter, kan tags på sager og views til agenter anvendes i stedet. Det er mere fleksibelt og skalerbart.

Praktiske Eksempler: Fra Lille til Stor

Teori er nyttig, men følgende viser, hvordan opsætningen kan se ud i praksis på tværs af vækstfaser.

Eksempel 1: Den Lille Startup (10 agenter)

Mål: Simpelhed og hastighed. Undgå over-engineering.

Groups (2-3):
- Support: Hovedgruppe for 8 agenter, der håndterer alle førstegangshenvendelser.
- Engineering: 2 udviklere, der tildeles fejlrapporter og tekniske eskaleringer.
Organizations:
- Anvendes kun ved tydeligt B2B-fokus med få, store kunder. Ved B2C kan det springes over i starten, da administrationen ofte overstiger værdien.
Light Agents (1-2):
- CEO/CTO som Light Agent, så kritiske sager kan CC’es og følges uden deltagelse i den daglige kø.
Skill-Based Routing:
- Ikke nødvendigt. Anvend i stedet en trigger, der ruter alle sager til Support, og en anden trigger, der ruter sager med bug_report-tag til Engineering.

Hvorfor det virker: Opsætningen er minimal og tydelig. Rapportering er enkel: performance for Support samt antal bugs. Vedligeholdelse er let, og opsætningen kan skaleres moderat.

Eksempel 2: Den Mellemstore Virksomhed (50 agenter)

Mål: Struktur og specialisering. Fokus på effektivitet i større skala.

Groups (4-6):
- Nordic Tier 1: Første linje for danske, norske og svenske kunder.
- EMEA Tier 2: Specialiseret teknisk support for komplekse sager.
- Customer Success: Relationer med større kunder.
- Billing & Finance: Fakturerings- og betalingsspørgsmål.
Organizations:
- Centralt. Opret en organisation pr. B2B-kunde.
- Overvej tags eller brugerdefinerede felter til yderligere segmentering (fx Enterprise, SMB).
- Opsæt forskellige SLA’er baseret på organisationstype.
Light Agents (5-10):
- Product Managers til feedback og produktspørgsmål.
- Legal til godkendelse af svar på følsomme spørgsmål.
- Team Leads til indblik i teamets performance.
Skill-Based Routing:
- Sprog-routing giver mening. Opret en Language-skill på agenter (Dansk, Tysk, Fransk osv.) og brug triggers til at rute sager korrekt til Nordic Tier 1 baseret på sprog.

Hvorfor det virker: Strukturen afspejler specialisering, og ejerskab er tydeligt. Rapportering pr. team bliver meningsfuld, og performance kan vurderes på tværs af kundesegmenter.

Eksempel 3: Den Store Koncern (200+ agenter)

Mål: Skalerbarhed, global dækning og finmasket kontrol. Hierarkiet skal være robust og logisk.

Groups (15+):
- Geografisk og funktionelt struktureret, fx:
  - APAC Tier 1
  - Nordic Tier 1
  - DACH Tier 1
  - Global Tier 2 - Hardware
  - Global Tier 2 - Software
  - Global Premium Support
  - Strategic Accounts - CSMs
  - Billing EMEA
  - Billing APAC
Organizations:
- Helt centralt. Bruges til kundehierarkier, hvor en global kunde kan have en hovedorganisation med underorganisationer pr. land eller afdeling.
- SLA’er er komplekse og varierer efter kontrakter.
- “Shared tickets” er afgørende for håndtering af store, globale kunder.
Light Agents (20+):
- Anvendes på tværs af afdelinger (Legal, Marketing, Engineering, Product, Compliance) for ekspertinput uden at forstyrre sagsflowet.
Skill-Based Routing:
- Holdes fortsat enkel. Primært sprog-routing og identifikation af Premium Support-agenter. Øvrig specialisering håndteres via group-hierarkiet.

Hvorfor det virker: Opsætningen er stor, men logisk. Ansvar pr. group er tydeligt, routing er forudsigelig, og rapportering kan opdeles på regioner, produktlinjer og kundetyper uden at blive ubrugelig.

Almindelige Hierarki-Fejl og Løsninger

Følgende fejl går ofte igen, sammen med tilhørende måder at undgå dem på.

Fejl 1: “Organizations for Alt”

Problem: I en B2C-virksomhed oprettes en organisation for hver kunde “for at holde styr på dem”.
Konsekvens: Ingen reel fordel, da “shared tickets” ikke giver værdi. Det skaber tusindvis af unødvendige organisationer, gør administration af slutbrugere tung og gør meningsfulde SLA’er vanskelige.
Løsning: I B2C bør organisationsfeltet ikke anvendes. Segmentering kan i stedet ske via brugerdefinerede felter på slutbrugeren (fx Customer_Tier, Signup_Date). Organizations er primært relevant for B2B.

Fejl 2: “Den Enorme Gruppe”

Problem: Én gruppe, Support, med alle 50 agenter.
Konsekvens: Uklart ejerskab, vanskelig arbejdsfordeling og værdiløs rapportering, da performance ikke kan adskilles mellem nye og erfarne agenter. Hurtige agenter tager de lette sager, mens svære sager bliver liggende.
Løsning: Opdel gruppen. Selv ved ensartede opgaver kan opdeling ske efter erfaring (Tier 1, Tier 2) eller geografi (Support - EMEA, Support - APAC). Det forbedrer routing, arbejdsfordeling (fx round-robin i en gruppe) og rapportering.

Fejl 3: At Overse Light Agent-begrænsninger

Problem: En arbejdsgang sætter en sag i “Pending” og afventer svar fra en specifik person, der er oprettet som Light Agent.
Konsekvens: Arbejdsgangen bryder, da Light Agents ikke kan være assignee og derfor ikke kan “løse” sagen ved at tage ejerskab. Sagen kan blive i “Pending”, indtil en fuld agent griber ind.
Løsning: Workflows skal designes ud fra, hvad Light Agents kan og ikke kan. Hvis en rolle skal indgå i en formel godkendelsesproces, hvor en sag venter på input, kræver det en fuld agent-licens. Hvis input er uformelt, kan Light Agent anvendes, men en fuld agent skal eje sagen hele vejen.

Fejl 4: Agenter i For Mange Grupper

Problem: En agent er medlem af 10 grupper, fordi vedkommende “kan lidt af hvert”.
Konsekvens: Uklarhed for agenten, uklar routing (hvilke SLA’er og views gælder), samt utydelig rapportering. Performance spredes på tværs af mange teams og bliver svær at vurdere.
Løsning: En tommelfingerregel er medlemskab af 1-3 grupper: én primær og eventuelt 1-2 sekundære til specifikke formål (fx Escalations). For mange ansvarsområder kan indikere behov for at se på rollebeskrivelser frem for Zendesk-opsætningen.

Røde vs. Grønne Flag - Tjekliste

Tjeklisten kan bruges til at vurdere, om hierarkiet er ved at blive uoverskueligt, og om der er behov for en revidering.

Røde Flag: Advarselssignaler på et Uoverskueligt Hierarki

🚩 Mere end 10 aktive skills i skill-based routing-opsætningen.
🚩 “Support”-gruppen har mere end 20 agenter.
🚩 Agenter er medlem af 5 eller flere grupper.
🚩 Der er oprettet en organisation for hver kunde i en B2C-forretning.
🚩 Routing-logikken kræver, at en trigger finder en agent med 3 eller flere specifikke skills.
🚩 Light Agents bruges som erstatning for fulde agenter for at reducere omkostninger.
🚩 Det er ikke muligt at se, hvem der ejer en sag, ved at åbne den.
🚩 Nye agenter bruger en hel dag på at få grupper, skills og views sat korrekt op.
🚩 Der findes flere “omgåelses”-regler (fx manuelle tildelinger), fordi automatisk routing ikke fungerer.

Grønne Flag: Tegn på et Sundt og Skalerbart Hierarki

✅ Der findes en klar, skriftlig politik for, hvornår der oprettes en ny group vs. en ny organization.
✅ Hver group har et klart defineret formål og en ansvarlig leder.
✅ De fleste agenter er medlem af 1-2 grupper.
✅ Skill-based routing (hvis anvendt) består af 2-3 brede, ikke-overlappende skills (typisk sprog).
✅ Light Agents bruges til et begrænset antal veldefinerede konsulentroller.
✅ Det er enkelt at trække rapporter for performance pr. team/group.
✅ En ny agent kan forklare hierarkiet og sin rolle i det på under 5 minutter.
✅ Hierarkiet gennemgås og revideres én gang årligt (eller oftere ved hurtig vækst).
✅ Der er en klar og forudsigelig proces for, hvordan en sag bevæger sig fra oprettelse til lukning.

Et velfungerende team-hierarki er ikke en engangsopgave, men en løbende proces, der udvikler sig i takt med organisationen. Med klare principper for skellet mellem Groups og Organizations, en bevidst anvendelse af Light Agents og en sund skepsis over for overkompleksitet skabes et fundament, der understøtter stabil drift, skalerbarhed og en bedre oplevelse for kunderne.