Admin Pro Tip: Simpelhed er Nøglen – Din Guide til et Overskueligt Zendesk – Available ApS

I arbejdet med Zendesk opstår der ofte et mønster, selv i velorganiserede supportteams: stigende kompleksitet. I begyndelsen er opsætningen typisk enkel med få triggers, et par views og en tydelig logik. Når virksomheden vokser, kommer nye produkter, teams og processer til, og den oprindeligt simple opsætning kan udvikle sig til et uoverskueligt net af regler, som ingen længere har fuldt overblik over.
Dette er ikke kun et æstetisk problem, men en direkte risiko for effektivitet, medarbejdertilfredshed og i sidste ende kundeoplevelsen. Et komplekst system skaber tvivl, fejl og frustration. Derfor anvendes et enkelt, men effektivt princip: 3-sekunders reglen. Den fungerer som rettesnor i Zendesks automatiseringsunivers og danner grundlag for strategierne i denne artikel.

3-sekunders reglen: Et praktisk kompas

Kernen er en tommelfingerregel til at vurdere sundheden i en Zendesk-opsætning:

Hvis en administrator ikke kan forklare præcis, hvorfor en specifik ticket ender i en bestemt gruppe, med en bestemt prioritet og under en bestemt SLA-aftale – på under 3 sekunder – er opsætningen for kompleks.

Tre sekunder svarer omtrent til den tid, det tager for en erfaren agent at stille spørgsmålet: “Hvorfor havnede denne billet her?”. Svaret bør være intuitivt og øjeblikkeligt. Hvis forklaringen kræver gennemgang af mange aktive triggers for at finde årsagen, arbejder teamet reelt for systemet i stedet for omvendt. Agenternes tillid til systemet er afgørende; når den forsvinder, erstattes effektivitet af manuelle tjek og usikkerhed.

Et komplekst setup fører typisk til:

Fejlplacering af tickets: Tickets ender hos forkerte teams, hvilket forsinker løsning og skaber intern frustration.
Inkonsistent prioritering: Vigtige sager overses, mens mindre kritiske sager får uforholdsmæssig opmærksomhed, hvilket påvirker kunderelationer.
Forringet datakvalitet: Uklar logik gør data om ticket-typer og årsager upålidelige og reducerer værdien af rapportering.
Langsom onboarding: Nye agenter bruger lang tid på at forstå uskrevne regler, hvilket øger træningsomkostninger og forsinker produktivitet.
Administrator-flaskehals: Spørgsmål om routing og logik samler sig hos én person, der muligvis kender svaret, hvilket skaber en kritisk afhængighed.

Røde flag: Advarselssignaler på et komplekst setup

Følgende tegn indikerer typisk, at kompleksiteten er blevet for høj. Hvis et eller flere punkter genkendes, bør opsætningen gennemgås.

❌ Mere end 20 aktive triggers: Ikke en hård grænse, men en stærk indikator. Over dette niveau bliver det vanskeligt at overskue kaskadeeffekter mellem triggers, og hver ny trigger øger kompleksiteten markant.
❌ Triggers med 10+ betingelser (conditions): Mange “AND/OR”-betingelser tyder på, at én trigger forsøger at løse for mange opgaver. Det gør triggeren skrøbelig og vanskelig at fejlfinde, og små ændringer kan give utilsigtede konsekvenser.
❌ Modstridende actions i forskellige triggers: Eksempelvis når én trigger sætter prioritet til “Høj”, mens en anden senere sætter den til “Lav”. Resultatet bliver uforudsigeligt og afhænger af rækkefølgen.
❌ Ingen eller forældet dokumentation: Hvis logikken kun findes i hovedet på én administrator (eller slet ingen steder), er der høj risiko ved fravær eller medarbejderskifte. Dokumentation er en forsikring mod videnstab.
❌ Ingen kan forklare flowet: Hvis agenter giver tavshed eller modstridende svar på, hvordan prioritet bestemmes, er processerne reelt brudt sammen. Systemet bør være så logisk, at flowet kan forklares af alle.
❌ Over-afhængighed af manuelle workarounds: Hvis agenter ofte kompenserer for automatiseringer med manuelle tags eller huskeregler, fungerer automatiseringssystemet ikke efter hensigten.

Grønne flag: Kendetegn ved et sundt setup

Følgende tegn indikerer et velfungerende, enkelt og effektivt Zendesk-miljø:

✅ Klar, dokumenteret og let tilgængelig logik: Teamet ved, hvor forklaringer på “hvorfor” findes (fx intern Guide-artikel, Confluence eller delt dokument), og logikken er beskrevet i et forståeligt sprog.
✅ Logisk og gennemtænkt trigger-rækkefølge: Der er forståelse for, at triggers eksekveres fra top til bund, og rækkefølgen er bevidst designet for at undgå konflikter. Kategorisering og navngivning kan understøtte dette, fx “00-Global”, “01-Routing”, “02-Prioritering”.
✅ Testede og validerede workflows: Nye triggers og automations testes grundigt i sandbox med test-scenarier, så flowet opfører sig som forventet.
✅ Alle kan forklare flowet: Både nye og erfarne agenter kan give en kort og præcis forklaring på, hvordan en ticket bevæger sig gennem systemet.
✅ Proaktiv oprydning: Der er faste rutiner for at gennemgå og deaktivere ubrugte views, macros og tags, så systemet forbliver overskueligt.

Strategier til at forenkle Zendesk

Hvis flere røde flag genkendes, kan følgende strategier anvendes til at genvinde overblik og reducere kompleksitet.

1. Konsolider lignende triggers

Mange komplekse opsætninger indeholder triggers, der grundlæggende gør det samme med små variationer.

Problem: Tre separate triggers:
1. Trigger A: Sætter prioritet til “Høj”, hvis emne indeholder “kritisk fejl”.
2. Trigger B: Sætter prioritet til “Høj”, hvis emne indeholder “urgent bug”.
3. Trigger C: Sætter prioritet til “Høj” og tilføjer tag escalation, hvis emne indeholder “produktion nede”.
Løsning: Kombinér til én mere robust trigger med “Meets any of the following” (OR):
- Ny trigger: Ticket | Subject | Contains | "kritisk fejl" OR Ticket | Subject | Contains | "urgent bug" OR Ticket | Subject | Contains | "produktion nede".
- Actions:
  - Priority | High
  - Add tags | escalation (tagget kan tilføjes uden skade, selv om det oprindeligt kun var relevant for ét scenarie)

Dette reducerer antallet af triggers og samler logikken ét sted.

Nuancer og forsigtighedsprincipper: Konsolidering bør ske med omtanke, især hvis triggers har forskellige actions. Hvis én trigger sender en notifikation, og en anden ikke gør, kan en sammenlægning skabe unødig støj. I sådanne tilfælde kan brugerdefinerede felter anvendes til at styre logikken.

2. Brug brugerdefinerede felter (custom fields) strategisk

Tags er velegnede til fleksibel mærkning, men er en dårlig erstatning for strukturerede data.

Problem: En kompleks kombination af tags bruges til at definere ticket-type, fx bug_frontend, bug_backend, feature_request_billing. Det gør views og rapporter sværere, fordi der skal filtreres på flere tags samtidig.
Løsning: Opret et dropdown-brugerdefineret felt kaldet “Ticket Type” med valgmuligheder som:
- Bug - Frontend
- Bug - Backend
- Feature Request - Billing
- ...osv.

Herefter kan der filtreres direkte på Ticket Type: Bug - Frontend i views og rapporter. Det reducerer behovet for at håndtere komplekse tag-kombinationer i triggers og views. Tags kan fortsat bruges til ad-hoc-kategorisering og midlertidig markering.

Typer af felter og deres anvendelse:

Dropdown: Til kategorisering med gensidigt udelukkende valg (fx land, produkt, ticket-type).
Multi-select: Når en ticket kan tilhøre flere kategorier (fx berørte produkter).
Checkbox: Simpel ja/nej-logik (fx “Kræver opfølgning”, “Kontaktet kunden”).
Tekst: Bør undgås til automatisering pga. risiko for stavefejl; anvendes i stedet til at indsamle specifikke data fra agenter.

3. Dokumentér alt – men gør det brugbart

Dokumentation kan virke omfattende, men bliver håndterbar med faste vaner og en enkel struktur.

Hvor: Vælg et centralt sted med adgang for alle. En intern Zendesk Guide er velegnet, da den er tæt på systemet og søgbar.
Hvordan: Brug en enkel skabelon for hver trigger/automation:
- Navn: Trigger - Routing - Tilføj til Fakturering-team
- Formål: Kort beskrivelse af, hvad triggeren opnår
- Betingelser: Liste over de vigtigste betingelser
- Handlinger: Liste over de handlinger, der udføres
- Noter: Undtagelser, afhængigheder af andre triggers eller kontaktperson ved spørgsmål

Pro-tip: I triggerens “Description”-felt i Zendesk kan der indsættes et direkte link til dokumentationen, så den altid er tæt på.

4. Indfør regelmæssig gennemgang og oprydning

En Zendesk-opsætning er et levende system, der kræver vedligeholdelse. En kvartalsvis “Zendesk Health Check” kan anvendes.

Gennemgå aktive triggers: Brug Zendesk Explore til at identificere triggers, der ikke er blevet udløst de seneste 90 dage, og overvej at deaktivere dem.
Tjek for ubrugte views og macros: Ryd op i agenternes brugerflade for at reducere støj og forvirring.
Analyser tags: Identificér stavefejl (fx urgnet i stedet for urgent) og tags, der kun bruges på få tickets. Overvej at fusionere eller slette dem.
Evaluer SLA’er: Vurder om SLA-politikker fortsat er relevante og retfærdige, og om de matcher teamstruktur og kundeforventninger.

Fejlfinding i praksis: Almindelige scenarier

Selv i velfungerende systemer opstår der spørgsmål. Følgende fremgangsmåder kan anvendes.

Scenarie 1: “Min billet forsvandt!”

En agent kan ikke finde en ticket, som vides at være oprettet.

Tjek viewet “All unsolved tickets”: Viewet viser alle uløste tickets uanset gruppe eller tildeling. Er ticketen synlig her?
Tjek trigger-logik: Gennemgå dokumentationen. Findes der en trigger, der flytter tickets til en bestemt gruppe eller et bestemt view baseret på emne eller anden betingelse?
Søg på tags: Søg i “All unsolved tickets” efter tags, der kan være tilføjet automatisk. Ticketen kan være endt i et “Arkiv”-view pga. et tag.

Scenarie 2: “Hvorfor blev denne prioritet ændret?”

En ticket, der var “Normal”, er pludselig “Høj”.

Find relevant trigger: Gå til trigger-listen og brug Ctrl+F (eller Cmd+F) til at søge efter handlingen “Priority: High”.
Analyser betingelserne: Gennemgå triggers, der sætter prioritet til “Høj”, og vurder hvilke der kan matche ticketen (emne, besked, brugerfelt osv.).
Tjek rækkefølgen: Den sidste trigger, der kører, vinder. Findes der en trigger længere nede, der overskriver en tidligere? Dette indikerer ofte behov for justering af rækkefølgen.

Best practices fra praktisk erfaring

Følgende tilgange anvendes ofte for at holde opsætningen enkel og robust:

Start simpelt: Nye processer bør begynde med den simplest mulige automatisering. Det er lettere at tilføje kompleksitet senere end at fjerne den.
Brug navngivningskonventioner: Navne på triggers, automations og views bør beskrive funktion og rækkefølge, fx 01-Trigger - Routing - [Team], 02-Automation - SLA - Follow-up, View - Open - [Team] - Unassigned. Det gør dem lettere at finde og forstå.
Deaktivér, slet ikke: Ved tvivl kan en trigger deaktiveres i stedet for at blive slettet. Omdøb fx til ZZZ-DEACTIVATED - [Originalt navn] og lad den stå i en måned. Hvis ingen savner den, kan den slettes.
Arbejd i sandbox: Nye ændringer bør testes i sandbox før produktion. Test-scenarier bør afspejle virkelige situationer, og en agent kan inddrages i testen.
Forstå at rækkefølgen er afgørende: Triggers kører i den rækkefølge, de står på listen. Automations kører hver time, også i rækkefølge. “Stopper”-triggers (fx triggers, der lukker en ticket) bør placeres øverst, hvis andre triggers ikke skal køre på ticketen.

Konklusion: Simpelhed er styrke

Forenkling af en Zendesk-opsætning er sjældent en opgave, der afsluttes på én eftermiddag. Det er en løbende disciplin og en bevidst prioritering af klarhed frem for kompleksitet. En enkel opsætning er lettere at skalere, lettere at onboarde nye medarbejdere i og understøtter en mere konsistent og hurtig service.

3-sekunders reglen kan anvendes som fast pejlemærke. Ved tilføjelse af nye regler bør det vurderes, om logikken kan forklares på under tre sekunder. Hvis ikke, er det et signal om at tage et skridt tilbage og finde en enklere løsning.

Et simpelt Zendesk understøtter lavere træningsomkostninger, højere medarbejdertilfredshed og bedre kundeoplevelser. Simpelhed kan dermed fungere som en vedvarende styrke i driften.