Admin Pro Tip: Views - Dit Skjulte Superkort – Available ApS

I mange organisationer ses den samme udfordring: en kaotisk og uoverskuelig liste af views, som kun bruges sporadisk, og som gør agentarbejdet sværere frem for lettere. De mest velfungerende teams har typisk ikke hundredvis af views, men en håndfuld, der er skarpe, præcise og så effektive, at de fungerer som et GPS-kort for agenterne og guider direkte til de næste opgaver.
Et view er ikke kun en liste af tickets. Et velfungerende view understøtter en arbejdsproces. Det fungerer som en prioriteret opgaveliste, et værktøj til at identificere flaskehalse og et “superkort” til at navigere i den daglige strøm af kundehenvendelser. Artiklen samler viden om, hvordan views kan bygges, vedligeholdes og udnyttes til at gøre en Zendesk-instans mere overskuelig og effektiv.

Hvorfor Views er et af de vigtigste værktøjer

Før de konkrete tips gennemgås, er det centralt at fastslå, hvorfor views er fundamentale. Views opfattes ofte som en simpel søgefunktion, men den reelle styrke ligger i evnen til at forme adfærd og skabe fokus.

Når en agent logger ind, er views typisk det første, der vises. Views definerer dermed arbejdsdagen. En ustruktureret liste med hundredvis af tickets kan skabe overblikstab og ineffektivitet. Omvendt giver tre-fire tydeligt definerede og prioriterede lister et klart fokus.

Views er et primært værktøj til at:

Automatisere prioritering: I stedet for manuel vurdering af, hvilken ticket der er vigtigst, kan et view prioritere ud fra data.
Sikre konsistens: Et godt view understøtter, at agenter følger samme arbejdsgang og prioriterer ens.
Reducere kognitiv belastning: Agentens energi bruges på at løse kundens problem frem for at finde næste opgave.
Skabe transparens: Views giver et indblik i arbejdets flow, herunder hvor der opstår flaskehalse, og hvilke henvendelser der tager lang tid.

At mestre views er at mestre arbejdsgangen i Zendesk og er en direkte måde at påvirke agenters effektivitet og trivsel.

De 5 Views hver agent bør have

Der findes mange view-konfigurationer, fra meget få views til opsætninger med over 50. Erfaringen peger på en “gylden middelvej”. For de fleste teams udgør følgende fem views et solidt udgangspunkt, der dækker størstedelen af daglige behov.

1. Mine Åbne Tickets (Den Personlige Indbakke)

Dette view er kernen i agentens personlige ansvarsområde og giver et hurtigt overblik over tickets, som agenten arbejder på eller har ansvar for.

Formål: At vise alle tildelte, uløste tickets for den aktuelle bruger.
Byggevejledning:

Ticket | Status | Mindre end | Open
Ticket | Assignee | Er | Nuværende bruger
Sortering: Opdateret (stigende)

Pro Tip: En ekstra betingelse kan bruges til at filtrere spam eller test-tickets fra, f.eks.: Ticket | Tags | Indeholder ikke en af | spam, intern_test. Sorteringen Opdateret (stigende) er central, da den sikrer, at tickets med længst ventetid på opdatering ligger øverst, hvilket reducerer risikoen for glemte tickets.

2. Nye Uafhentede Tickets (Triage-køen)

Dette view fungerer som teamets indbakke, hvor nye henvendelser lander, før de tildeles en agent. Formålet er et fælles overblik og hurtig tildeling baseret på tilgængelighed eller ekspertise.

Formål: At vise alle nye, åbne tickets, der endnu ikke er blevet tildelt.
Byggevejledning:

Ticket | Status | Mindre end | Open
Ticket | Assignee | Er | - (Ingen)
Sortering: Oprettet (stigende)

Pro Tip: I større teams kan viewet opdeles yderligere, f.eks. efter kanal (“Nye E-mails” og “Nye Chats”). Et mere avanceret greb er at bruge makroer til automatisk at tilføje et tag ved tildeling (f.eks. tildelt_email_team) og derefter lave et view med Assignee: - OG Tags: Indeholder ikke en af: tildelt_email_team, tildelt_chat_team for at fange tickets, der ellers falder mellem to stole.

3. Tickets, der Venter på Mig (Opfølgningslisten)

Dette view understøtter proaktiv service ved at vise tickets, hvor der afventes svar fra kunden. Uden et sådant view er det let at miste overblikket over opfølgninger.

Formål: At vise alle tildelte tickets, der venter på svar fra kunden.
Byggevejledning:

Ticket | Status | Er | Pending
Ticket | Assignee | Er | Nuværende bruger
Sortering: Næste opfølgning (stigende)

Pro Tip: Feltet Næste opfølgning er afhængigt af “Solve”-makroer. Det anbefales, at alle “Solve” eller “Set to Pending”-makroer tilføjer en opfølgningsdato. Opfølgningsinterval kan variere efter ticket-type, f.eks. 3 dage for en simpel teknisk forespørgsel og 24 timer for en kompleks klagesag. Viewet hjælper med at undgå, at kunder efterlades uden opfølgning.

4. Køen (Den Dynamiske Arbejdsfordeling)

Dette er en mere avanceret version af “Nye Uafhentede Tickets”. Formålet er at vise tickets, der er klar til behandling af enhver ledig agent, og passer til en “tag den næste i rækken”-model.

Formål: At vise en prioriteret liste af tickets, der er klar til behandling, uanset om de er nye eller returneret fra en anden agent.
Byggevejledning:

Ticket | Status | Mindre end | Open
Ticket | Group | Er | [Dit gruppenavn]
Ticket | Assignee | Er | - (Ingen)
ELLER
Ticket | Status | Er | Open
Ticket | Group | Er | [Dit gruppenavn]
Ticket | Assignee | Er | Nuværende bruger
Sortering: Prioritet (faldende), derefter Oprettet (stigende)

Pro Tip: Viewet bruger “Enhver” (ANY)-logik til at kombinere to scenarier: nye tickets og tickets, der allerede er tildelt den aktuelle bruger. Sortering efter prioritet (hvis prioritering anvendes) og derefter oprettelsesdato sikrer, at de vigtigste og ældste tickets håndteres først. Viewet forudsætter en stærk praksis for at “låse” tickets under arbejde, så to agenter ikke starter på samme opgave.

5. Løst i Dag (Dagens Arbejde)

Dette view understøtter motivation og kvalitetssikring ved at give overblik over dagens løste tickets og et grundlag for gennemgang.

Formål: At vise alle tickets, der er blevet løst i dag.
Byggevejledning:

Ticket | Status | Er | Solved
Ticket | Updateret | Er | I dag
Ticket | Assignee | Er | Nuværende bruger
Sortering: Løst (faldende)

Pro Tip: Viewet kan bruges i daglige stand-ups til hurtig gennemgang og anerkendelse samt til stikprøvekontrol af kvaliteten i løsningerne (valg af makroer, tone m.m.).

Sådan bygges views, der faktisk bliver brugt

At have de rigtige views er én ting; at sikre adoption er en anden. Views, der ikke er skabt med brugerne for øje, risikerer at blive ignoreret. Følgende proces kan øge sandsynligheden for, at views bliver taget i brug.

Start med målet, ikke filtrene

En typisk fejl er at starte med filtre, f.eks. “vise alle tickets med tagget ‘faktura’”. I stedet bør udgangspunktet være: Hvilket problem løser viewet?

Dårligt mål: “Vise alle faktura-tickets.”
Godt mål: “Sikre, at alle faktura-relaterede henvendelser bliver besvaret inden for 2 timer.”

Når målet er klart, kan det oversættes til filtre. For målet ovenfor kan et view f.eks. vise:
Status < Open, Tags > Indeholder en af > faktura, betaling, fakturaspørgsmål, Group > Er > Fakturering, Opdateret > Mindre end | 2 timer siden.

Viewet fungerer dermed som et alarmpanel for tickets, der nærmer sig SLA-brud.

Tænk som en agent, ikke som en admin

Administratorer ser Zendesk i et overbliksperspektiv, mens agenter arbejder i konkrete opgaver. Et view skal give mening i agentens hverdag. Relevante spørgsmål til agenter kan være:

“Hvad er det første, der kigges efter ved login?”
“Hvad er den mest tidskrævende del af arbejdsdagen?”
“Hvilken type ticket er der størst risiko for at glemme?”

Svarene kan omsættes til views. Et eksempel er et view som “Escalerede til mig”, der automatisk viser tickets, hvor en tier 1-agent har brugt en specifik “Eskaler til Tier 2”-makro, og dermed reducerer manuelle søgninger.

Navngivning er en central del af arbejdet

Et uklart navn kan gøre et ellers godt view ubrugeligt. Navne bør være entydige, handlingsorienterede og korte.

Dårlige navne: “View 12”, “Nye ting”, “Urgent”, “Support”
Gode navne: “Mine åbne tickets”, “Venter på kunden”, “Nye chats - uafhentede”, “Følger op i dag”

En navngivningskonvention kan være:

Ejer: “Mine...” (personlig), “Team...” (fælles)
Handling/Status: “...åbne”, “...venter”, “...nye”, “...løste”
Kontekst (valgfrit): “...i dag”, “...høj prioritet”

Det gør det lettere at scanne view-listen og finde det relevante view uden gætteri.

Brug gruppering og sortering strategisk

Rækkefølgen i et view er lige så vigtig som filtreringen. Forkert sortering kan gøre et view ineffektivt.

Opdateret (stigende): Standard for mange arbejds-views; ældste aktivitet ligger øverst.
Oprettet (stigende): Velegnet til triage-køer (FIFO).
Prioritet (faldende): Relevant ved brug af prioritering; supplér med sekundær sortering (f.eks. Oprettet) som tie-breaker.
Gruppering: Kan være stærkt, men bør bruges med omtanke. Gruppering af “Mine åbne tickets” efter “Status” kan give mening, mens gruppering efter “Bruger” i en stor kø ofte skaber støj. Gruppering kan være nyttig til rapportering, f.eks. “Løst i dag” grupperet efter “Assignee”.

Iterér og indhent feedback

Et view er sjældent “færdigt”. Processer ændrer sig, og behov udvikler sig. En praktisk tilgang kan være:

Lav en udkast-version: Byg viewet ud fra en hypotese.
Præsenter for 1-2 agenter: “Der er lavet et udkast til et view, der skal hjælpe med [problem].”
Indsaml feedback: Er det for komplekst, mangler der tickets, eller er sorteringen forkert?
Justér og lancer: Rul ud til teamet med forklaring af formål og brug.
Evaluer efter 2 uger: Brug “View activity” til at se, om viewet anvendes. Hvis ikke, bør årsagen afklares (justering eller revurdering af behov).

Refresh-rate og performance: Hvordan optimeres?

Langsomme views reducerer produktivitet og får agenter til at undgå dem. Performance er en forudsætning.

Hvad er refresh-rate, og hvorfor gør det en forskel?

Refresh-rate er den tid, Zendesk bruger på at eksekvere forespørgslen og vise resultaterne. Den påvirkes af filterkompleksitet. Nogle filtre er typisk “dyre” (langsomme), fordi de kræver søgning i store mængder ikke-indekserede data:

Commenter: Særligt “Er ikke Nuværende bruger” kan være meget langsomt, da kommentarer skal gennemgås.
Organization: Filtre, der krydser organisationsdata, kan være langsomme i store instanser.
Custom fields: Kan være langsomme afhængigt af type, især dropdowns med mange muligheder eller tekstfelter.
“Indeholder ikke” (Does not contain): Ofte langsommere end “Indeholder” (Contains).

Hurtigere filtre er typisk baseret på simple, indekserede felter:

Status
Assignee
Group
Ticket ID
Tags (generelt hurtigt, men kan blive langsommere ved meget store mængder unikke tags)

Den gyldne regel: Mindre er mere

Hver betingelse gør viewet en smule langsommere. Hver ELLER (ANY) kan øge kompleksiteten markant. En praktisk regel er: Start så simpelt som muligt, og tilføj kun betingelser, der er nødvendige for viewets mål.

Et view for “Mine åbne tickets” kan nøjes med Status < Open og Assignee > Er > Nuværende bruger. Ekstra betingelser som Ticket | Type | Er | Spørgsmål kan gøre viewet langsommere og mindre fleksibelt. Ved behov kan agenten i stedet sortere eller filtrere inde i viewet.

Konkrete optimeringstips

Undgå Commenter-filtret: Brug i stedet Status > Er > Pending kombineret med Opdateret > Mindre end | [antal timer] siden for at finde tickets uden kundesvar.
Brug tags som “proxy”: I stedet for at filtrere på et komplekst custom field kan en makro tilføje et tag (f.eks. høj_prioritet), som der filtreres på via Tags.
Vær forsigtig med ALL/ENHVER (ANY): En kæde af ALL-betingelser er typisk hurtigere end en kæde af ENHVER-betingelser. Hold ANY-kæder korte.
Begræns tidsrammen: Rapport-views bør altid have en tidsbegrænsning (f.eks. Løst > Er > I sidste uge) for at undgå søgning i hele historikken.
Test performance: Byg og test viewet i en privat inkognito-fane, da caching ellers kan skjule reel load-tid.

Hvornår bør et view slettes?

View-hygiejne er vigtig. Over tid ophobes views, når projekter afsluttes og processer ændres. En stor view-liste skaber forvirring og skjuler de vigtigste views.

Tegn på et “dødt” view

Et view er typisk overflødigt, hvis et eller flere af følgende gælder:

Ingen brug i 30+ dage: “View activity” er en central indikator.
Viser konstant 0 resultater: Kan indikere ændrede processer eller for restriktive filtre.
Dobbeltarbejde: To views viser reelt det samme (f.eks. “Nye e-mails” og “Uafhentede e-mails”).
For specifikt: Views som “Tickets fra kunde X om produkt Y, der er tildelt agent Z” bliver hurtigt forældede og bør ofte erstattes af midlertidige søgninger.

Proces for “view-oprydning”

En kvartalsvis oprydning kan gennemføres sådan:

Kør “View activity”-rapporten: Eksportér data for de seneste 90 dage.
Identificér kandidater: Sortér efter antal visninger; 0–5 visninger er kandidater.
Analysér “tomme” views: Vurder views med 0 resultater over tid.
Kommunikér: Informér teamet om planlagt sletning og giv mulighed for indsigelser.
Udfør: Slet views uden indsigelser og afslut med en mere overskuelig view-liste.

Arkivering vs. sletning

Hvis et view indeholder kompleks logik, der muligvis skal bruges igen, kan det arkiveres:

Omdøb viewet til ARKIV: [Originalt navn].
Flyt det til en specifik view-gruppe kaldet “Arkiv”.

Efter et år i arkivet kan viewet slettes endeligt.

Almindelige view-fejl og hvordan de undgås

Selv erfarne administratorer kan ramme klassiske faldgruber. Nedenfor er de mest almindelige fejl og tilhørende løsninger.

Fejl #1: For mange betingelser

Symptom: 10+ betingelser med kombination af Status, Type, Priority, Tags, Group, Custom fields m.m.
Problem: Langsomt, skrøbeligt og svært at forstå, hvorfor tickets vises eller ikke vises.
Løsning: Start med 2–3 kernebetingelser og definér minimumskravet for listen. Ved behov kan kompleksitet opdeles i to mindre views.

Fejl #2: Modstridende betingelser

Symptom: Viewet er konstant tomt, selvom der forventes tickets.
Problem: Logisk umulige kombinationer, f.eks. Status = Solved OG Status = Open, eller Assignee = - (Ingen) OG Assignee = Nuværende bruger.
Løsning: Læs betingelserne højt som en sætning og vær særlig opmærksom ved blanding af ALL og ANY.

Fejl #3: Ignorering af “Alle” vs. “Enhver”

Symptom: Viewet viser for mange eller for få tickets.
Problem: “Alle” (ALL) kræver, at alle betingelser er opfyldt; “Enhver” (ANY) kræver, at mindst én er opfyldt. Forkert kombination giver fejlresultater.
Eksempel: Målet er at se alle nye tickets OG alle tickets, der venter på den aktuelle bruger.

Forkert: Status < Open (Alle) Assignee = Nuværende bruger (Alle) Assignee = - (Alle) → altid tomt.
Korrekt: (Status < Open OG Assignee = Nuværende bruger) ELLER (Status < Open OG Assignee = -)

I Zendesk bygges dette ved at lave to betingelsesblokke og vælge “Mød enhver af disse” (Meet ANY of these).
Løsning: Tænk i sætninger og brug mentale parenteser: “(A og B) ELLER (C og D)”.

Fejl #4: Dårlig sortering

Symptom: Agenter sorterer manuelt eller arbejder konsekvent på de forkerte tickets.
Problem: Standard-sortering matcher ikke viewets formål.
Løsning: Match sortering til formål:

Triage-kø: Oprettet (stigende)
Personlig arbejdskø: Opdateret (stigende)
Prioriteret kø: Prioritet (faldende), derefter Opdateret (stigende)
Opfølgningskø: Næste opfølgning (stigende)

Fejl #5: At glemme “Opdateret”-filtret

Symptom: Viewet viser gamle tickets eller tickets uden aktivitet i lang tid.
Problem: Filtrering kun på Status og Assignee uden tidsbegrænsning kan gøre viewet historisk tungt.
Løsning: Tilføj en tidsbegrænsning, medmindre formålet er at se alle tickets. For daglige views kan Opdateret > Mindre end | 30 dage siden være et relevant supplement for både relevans og performance.

Røde flag: Hundredvis af views, ingen bruger dem

En liste med 50, 100 eller 200+ views indikerer typisk kaos frem for avanceret opsætning.

Symptomer på “view inflation”

“Lad os lave et view til det” ved hvert mindre problem.
Personlige test-views, der aldrig slettes.
Navngivningskaos som “View 1”, “Kopi af Mine åbne”, “Test”, “NYT VIEW - LÆS!!!”.
Agenter bruger mere tid på at finde det rigtige view end på at besvare kunder.

Konsekvenser af rod

Dårlig performance: Mange komplekse, ubrugte views kan belaste systemet.
Forvirring og fejl: Forkerte views vælges, kritiske tickets overses, eller flere agenter arbejder på samme ticket.
Demotivation: En uoverskuelig arbejdsflade signalerer manglende struktur.
Administrationsbyrde: Vedligehold og fejlfinding bliver uoverskueligt, især når ændringer påvirker mange views.

Tiltag mod “view inflation”

Et centralt greb er disciplin, f.eks. en regel om, at for hvert nyt view, der oprettes, skal et andet arkiveres eller slettes. Derudover kan godkendelse af nye views formaliseres (f.eks. af et lille admin-team), med fokus på om behovet kan dækkes af eksisterende views, og hvorfor en ny liste er nødvendig.

Grønne flag: Få, veldesignede views, som alle bruger

Målet er en sund, effektiv og skalerbar Zendesk-opsætning.

Kendetegn ved en sund view-kultur

Kort liste: Typisk 5–8 aktive views pr. agent uden behov for scrolling.
Intuitive navne: Korte, præcise og handlingsorienterede.
Høj adoption: “View activity” viser daglig brug blandt de fleste agenter.
Klare formål: Hvert view har et unikt formål uden overlap.
Hurtig performance: Views loader typisk på under 2–3 sekunder.

Målinger for succes

Antal views pr. agent: Mål under 10.
Gennemsnitlig load-tid: Måles manuelt eller via agentfeedback; målet er “øjeblikkeligt”.
Agentfeedback: Spørgsmål som “Er views hjælpsomme?” og “Er der views, der mangler eller aldrig bruges?”
Færre glemte tickets: Følg metrikker som “First Reply Time” og antal genåbnede tickets; effektive views bør forbedre disse.

Eksempel: En “lean” view-struktur

En kerne-struktur, der ofte implementeres:

For alle agenter:

Mine Åbne: Personlig arbejdsliste.
Venter på Kunden: Personlig opfølgningsliste.
Team Kø: Fælles triage-kø for uafhentede tickets.
Løst i Dag: Kvalitetssikring og motivation.

For team leads/udvalgte agenter:
5. Unassigned (Hold øje): Triage-kø, der viser tickets, der har været uafhentede i mere end f.eks. 1 time (early warning).
6. Escalerede: Tickets, der er eskaleret til teamet.
7. Overholdt SLA: Tickets, der er ved at overskride SLA-mål.

Med denne struktur kan et team håndtere store ticketmængder med gennemsigtighed og kontrol, mens øvrige behov dækkes af midlertidige søgninger eller rapporter efter behov.

Konklusion: Fra kaos til klarhed

Views er et fundament i Zendesk og en central del af en effektiv kundeserviceoplevelse. Korrekt design skaber flow, fokus og effektivitet; forkert design skaber kaos, frustration og spildtid.

Erfaringen peger på, at nøglen ikke er kompleksitet, men klarhed og disciplin: fokus på agentens behov, tydelige mål for hvert view, simple og performante opsætninger samt løbende vedligehold og oprydning.

At mestre views er en værdifuld investering for Zendesk-administration, med tydelig effekt på både teamets trivsel og kundetilfredshed. Oprydning i view-listen og etablering af en stram, anvendelig struktur er et konkret skridt fra kaos til klarhed.