I Zendesk er Views mere end blot lister; de fungerer som operative dashboards og er centrale i det daglige arbejde. For agenter og team leads er Views et primært værktøj til at navigere, prioritere og håndtere den løbende strøm af kundehenvendelser. Ved at omsætte en stor mængde tickets til strukturerede, handlingsorienterede overblik understøtter Views et mere effektivt arbejde, hurtigere svartider og en høj servicekvalitet.
Hvad er Views, og hvorfor er de afgørende?
En View er en dynamisk, filtreret liste af tickets, der vises ud fra et sæt foruddefinerede kriterier. Kriterierne kan omfatte ticket-status og prioritet, tildelt agent, kundetype, specifikke tags eller om en SLA (Service Level Agreement) er i risiko for at blive overtrådt.
Styrken ved Views er evnen til at skabe fokus. I stedet for at blive mødt af alle tickets i systemet kan en agent starte med en View, der kun viser “Mine åbne tickets”. En team lead kan hurtigt få overblik over “Ikke-tildelte højprioritets tickets” eller “Tickets med risiko for SLA-brud”. Ved at opbygge målrettede dashboards sikres det, at den rette opgave præsenteres for den rette rolle på det rette tidspunkt.
Personlige vs. Delte Views: Den rette balance
Zendesk understøtter to typer Views, hver med sit formål og sine styrker. En hensigtsmæssig kombination af begge typer er central for en velfungerende supportorganisation.
Personlige Views: Skræddersyet til individuel effektivitet
Personlige Views er kun synlige for den agent, der har oprettet dem. De kan bruges til at optimere den enkeltes workflow.
- Kun synlige for agenten: Et personligt workspace, hvor filtre og layouts kan afprøves uden at påvirke andre.
- Personlige workflows: Mulighed for at arbejde i en foretrukken rækkefølge eller fokusere på bestemte opgavetyper på bestemte tidspunkter.
- Custom filtre: Mulighed for at samle tickets fra en specifik kunde eller tickets med et bestemt tag i én samlet visning.
Delte Views: Fundamentet for team-synkronisering
Delte Views er synlige for alle agenter i en bestemt gruppe eller for hele organisationen. De understøtter standardiserede processer og fælles overblik.
- Synlige for teamet: Alle med adgang ser samme overblik, hvilket er vigtigt for samarbejde og backup.
- Standard workflows: Delte Views definerer fælles arbejdsgange, fx sikrer en “Unassigned Tickets”-View, at nye henvendelser bliver samlet op.
- Konsistent oplevelse: Nye agenter kan onboardes hurtigere ved at anvende de samme standardiserede Views som resten af teamet, hvilket reducerer forvirring og sikrer ensartet ticket-håndtering.
Byggeblokkerne: Betingelser og Filtre
Hver View er opbygget af betingelser (conditions), som fungerer som regler for, hvilke tickets der inkluderes. Betingelser kan kombineres med logik:
- AND / ALL: Alle betingelser skal være opfyldt. Eksempel:
Status is OpenANDPriority is High. Viser kun tickets, der både er åbne og har høj prioritet. - OR / ANY: Mindst én betingelse skal være opfyldt. Eksempel:
Status is NewORStatus is Open. Viser tickets, der enten er nye eller åbne.
Beherskelse af denne logik gør det muligt at opbygge præcise og effektive Views.
Essentielle View-mønstre for effektivt arbejde
Nedenfor er en samling af almindelige og værdifulde View-mønstre, der kan implementeres for at optimere workflow.
1. Mine Tickets
Agentens primære indbakke. Denne View viser alt, der kræver agentens opmærksomhed.
Hvorfor er det vigtigt? Viewen fungerer som udgangspunkt for dagen og sikrer overblik over næste opgave.
Betingelser:
Tildelt er Mig
OG
Status er ikke "Lukket"
2. Ikke-tildelte Tickets
Teamets triage-kø. Her lander nye henvendelser, før de fordeles.
Hvorfor er det vigtigt? Sikrer, at ingen kundehenvendelser overses, og reducerer risikoen for, at tickets falder mellem stolene.
Betingelser:
Tildelt er Ingen
OG
Status er "Ny" eller "Åben"
3. Gruppens Tickets
Overblik over arbejde inden for et specifikt team.
Hvorfor er det vigtigt? Relevant for team leads til at overvåge samlet arbejdsbyrde og for agenter til at se, hvad kolleger arbejder på.
Betingelser:
Gruppe er "Teknisk Support"
OG
Status er ikke "Lukket"
4. Høj Prioritet
En View dedikeret til de mest presserende sager.
Hvorfor er det vigtigt? Understøtter prioritering af ressourcer til sager med størst forretningsmæssig eller kundemæssig betydning.
Betingelser:
Prioritet er "Haster" eller "Høj"
OG
Status er ikke "Lukket"
5. Risiko for SLA-brud
Proaktiv overvågning af tickets, der nærmer sig deadline for første svar.
Hvorfor er det vigtigt? Gør det muligt at handle før en SLA overtrædes og kan forbedre performance og kundetilfredshed.
Betingelser:
Status er "Åben"
OG
Første Svartid er Mindre end 1 time tilbage
6. Afventer Kunde
Viser tickets, hvor der er svaret, og hvor der afventes svar fra kunden.
Hvorfor er det vigtigt? Understøtter opfølgning på kunder, der ikke har svaret, og forebygger at sager går i stå.
Betingelser:
Status er "Afventer"
OG
Afventende Type er "Venter på Kunde"
7. Løst i dag
Overblik over dagens løste sager og kan anvendes til kvalitetssikring.
Hvorfor er det vigtigt? Relevant til daglige opfølgninger, team-møder og anerkendelse af udført arbejde.
Betingelser:
Status er "Løst"
OG
Løsningsdato er I dag
8. Forfaldne
En kritisk View, der viser tickets, hvor en SLA allerede er overtrådt.
Hvorfor er det vigtigt? Tickets i denne View kræver øjeblikkelig eskalering eller opmærksomhed fra en team lead for at begrænse konsekvenserne.
Betingelser:
Status er "Åben"
OG
Første Svartid SLA er Overtrådt
Avancerede Views: Når standard ikke er nok
Når det grundlæggende er på plads, kan mere sofistikerede Views bygges ved at kombinere flere logiske lag. Dette er særligt nyttigt til at identificere komplekse scenarier.
Eksempel: Højprioritets tickets fra VIP-kunder, der afventer support
Denne View identificerer vigtige kunder, hvor der er forsinkelse i svaret.
Betingelser:
Prioritet er "Høj" eller "Haster"
OG
(Organisation er "VIP-kunder" ELLER Requester er "vip_kunde_tag")
OG
Status er "Afventer"
OG
Afventende Type er "Venter på Support"
Eksemplet viser, hvordan AND/OR-logik kan kombineres, og hvordan felter som Organisation og Tags kan bruges til at skabe et specifikt og handlingsorienteret overblik.
Strategisk Organisering af jeres Views
En lang liste af Views kan hurtigt blive uoverskuelig, og derfor er logisk organisering vigtig. Views kan grupperes i sidebaren for at skabe en intuitiv navigationsstruktur.
For Agenter
En agents sidebar bør være handlingsorienteret.
- Min Indbakke
- Mine Åbne Tickets
- Mine Afventende Tickets
- Følg-up i dag
- Teamets Arbejde
- Ikke-tildelte Tickets (Support)
- Gruppens Tickets (Support)
- Prioritering
- Risiko for SLA-brud
- Høj Prioritet
For Team Leads
En team leads sidebar bør understøtte strategisk overblik.
- Team Performance
- Alle Åbne Tickets (Team)
- Forfaldne Tickets
- Løst i dag
- Triage & Fordeling
- Ikke-tildelte Tickets (alle grupper)
- Nye Tickets, der kræver eskalering
- Kvalitet & Opfølgning
- Nyligt Løste (til gennemgang)
- Afventer Kunde (> 3 dage)
Kunsten at Vælge Kolonner
Valg af kolonner i en View har stor betydning for anvendeligheden. For mange kolonner skaber støj, mens for få kan give utilstrækkelig kontekst.
Kernekolonner (Essentielle for de fleste Views)
- ID: Unikt ticketnummer, let at referere til.
- Emne: Hurtig identifikation af ticketens indhold.
- Anmoder: Hvem er kunden?
- Tildelt: Hvem ejer opgaven?
- Status: Hvor er sagen i processen?
- Prioritet: Hvor vigtig er den?
- Opdateret: Hvornår skete der sidst aktivitet? (kritisk for sortering).
Strategiske Kolonner (Tilføj baseret på formål)
- Gruppe: Relevant i Views, der dækker flere teams.
- Tags: Velegnet til at identificere projekter, kundetyper eller problemområder.
- SLA: Viser resterende tid eller status for en SLA; central i performance-orienterede Views.
- Oprettet: Nyttig til at se, hvor længe en sag har været åben.
- Brugerdefinerede Felter: Felter som “Kontonummer” eller “Produkttype” kan være relevante i specifikke Views.
Sortering: Prioritér det vigtigste først
Standard sortering er ofte efter “Opdateret”, men sortering bør tilpasses den enkelte Views formål.
- Sorter efter Prioritet (Descending): Sikrer, at de mest kritiske tickets ligger øverst. Kombineres ofte med sortering efter “Oprettet” (Ascending) for at håndtere de ældste højprioritets sager først.
- Sorter efter SLA (Ascending): I Views som “Risiko for SLA-brud” er dette den mest relevante sortering, så tickets tæt på deadline vises først.
- Sorter efter Oprettet (Ascending): I en “Ny Tickets”-View understøtter dette “First In, First Out” (FIFO), medmindre prioritet angiver andet.
Best Practices: Sørg for maksimal værdi
For at sikre, at Views forbliver et aktiv og ikke en byrde, kan følgende principper anvendes.
1. Hold Views fokuserede
En View bør have ét klart formål. En for bred View er sjældent handlingsorienteret.
- ✅ “Mine Åbne Tickets”
- ✅ “Ikke-tildelte Høj Prioritet”
- ❌ “Alle Tickets” (skaber overvældelse og er ikke handlingsorienteret)
2. Brug beskrivende navne
Navnet på en View bør tydeligt kommunikere indhold og formål.
- ✅ “SLA Risiko - Support Team”
- ✅ “Afventer Kunde - Fakturering”
- ❌ “View 1”
- ❌ “Tickets”
3. Begræns antallet af resultater
En View med flere hundrede åbne tickets kan være demotiverende og svær at navigere i. Hvis en View konsekvent viser over 100 tickets, kan den opdeles yderligere, fx i “Høj Prioritet” og “Normal Prioritet”. Et ofte hensigtsmæssigt niveau er 20–50 tickets for at bevare overblik.
4. Review og opdater regelmæssigt
Forretning og processer ændrer sig, og Views bør følge med.
- Er alle Views stadig relevante?
- Fungerer filtrene korrekt efter seneste ændringer i opsætningen?
- Er der nye workflows, der kræver en selvstændig View?
5. Standardiser og del
Identificér 5–7 kritiske Views for et team og opret dem som delte standard-Views. Dette understøtter konsistens, gør onboarding lettere og skaber en fælles forståelse af arbejdsgange.
Fejlfinding: Almindelige udfordringer og løsninger
Der kan opstå udfordringer, selv med god planlægning.
Problem: En View viser ikke de tickets, der forventes.
- Løsning: Gennemgå betingelserne én efter én. Er der en
AND, der burde være enOR? Er en værdi stavet forkert? Kontroller også ticketens status (fx om den er “Løst” i stedet for “Åben”).
Problem: En View er langsom at indlæse.
- Løsning: Mange eller komplekse betingelser kan belaste systemet. Forenkling kan hjælpe: Kan en betingelse fjernes? Anvendes
OR-logik på tværs af mange felter, hvilket kan være tungt?
Problem: En ticket forsvinder fra en View, uden at den er løst.
- Løsning: Dette skyldes typisk en betingelse i Viewen. Eksempel: Hvis der er
Status is not "Pending", og ticketen sættes til “Pending” af en automatisering, falder den uden for filteret. Kontroller ticketens detaljer for at se, hvilket felt der udløste ændringen.
Problem: Teamet ser forskellige resultater i en delt View.
- Løsning: Dette er usædvanligt, men kan skyldes forskellige tilladelser. Kontroller, at relevante agenter er medlem af den gruppe, Viewen er delt med. Kontroller også, om der er personlige filtre aktiveret i brugerens interface.
Kom godt i gang: Jeres næste skridt
Implementering af effektive Views er en løbende proces, men følgende trin kan bruges som udgangspunkt:
- Kortlæg workflow: Inddrag agenter og team leads. Hvilke trin gennemgår en ticket typisk? Hvor opstår flaskehalse? Hvilke informationer er nødvendige på hvert trin?
- Start med de essentielle Views: Implementér de 5–7 mest kritiske Views først, fx “Mine Tickets”, “Unassigned” og “SLA Breach Risk”, og få dem til at fungere stabilt.
- Organisér sidebaren: Strukturér Views logisk for både agenter og leads, så den rette View er let at finde.
- Uddan teamet: Sikr forståelse for, hvorfor Views er struktureret, som de er, og hvordan de anvendes effektivt.
- Iterér og forbedr: Aftal et fast interval (fx hvert kvartal) til gennemgang af Views: Er de stadig relevante, og hvad kan forbedres?
Ved at anvende Views som et strategisk værktøj kan supportoperationen understøttes i en mere proaktiv, organiseret og effektiv retning.