Admin Pro Tip: Tags - Kaos eller Klarhed?

Tags i Zendesk kan være en uundværlig støtte til data, automatisering og struktur. Tags kan også udvikle sig til et område præget af inkonsistens, forældede oplysninger og forvirring. Erfaring viser alt fra velorganiserede tag-strukturer til uoverskuelige opsætninger, hvor selv erfarne agenter har svært ved at navigere.
Spørgsmålet er ikke, om tags skal bruges, men hvordan de bruges. En svag tag-strategi kan være værre end ingen strategi, fordi den skaber en falsk oplevelse af kontrol og resulterer i upålidelige data. En stærk tag-strategi er derimod et af de mest effektive værktøjer i administrationen af Zendesk.

Denne artikel fungerer som en guide til at skabe kontrol over tags. Fokus er på erfaringer, typiske fejl og strategier, der fungerer i praksis, med målet om at gøre tags til et fundament for klarhed frem for en kilde til kaos.

Del 1: Fundamentet - En tag-strategi der faktisk virker

Før navngivning og oprydning bør formålet afklares: Hvorfor eksisterer hvert enkelt tag i Zendesk? Hvis formålet ikke kan forklares for alle tags, indikerer det et problem.

En effektiv tag-strategi bygger på et klart formål. De fleste tags kan typisk opdeles i tre primære kategorier:

1. Rapporterings-tags

Disse tags er datatags, der primært bruges til indsigt i Explore. De kan besvare spørgsmål som:

• Hvor mange henvendelser handler om et specifikt produkt?
• Hvilke typer fejl rapporteres oftest?
• Hvor kommer kundefeedback fra?
• Hvad er den primære årsag til, at en sag eskaleres?

Eksempler: produkt_x, produkt_y, bug_ui, bug_backend, feature_request, feedback_survey, escalation_billing

Disse tags understøtter målrettede dashboards, der kan bruges til beslutningsgrundlag. Produktteams kan bruge dem til rene, kvantificerbare data om kundernes oplevelser.

2. Automatiserings-tags

Disse tags fungerer som interne signaler og bruges til at få triggers, automations og views til at fungere korrekt. De bruges sjældent til rapportering i sig selv, men er afgørende for workflow.

Eksempler: awaiting_customer_reply, high_priority_flag, needs_manager_review, auto_closed, follow_up_required

Når en trigger tilføjer awaiting_customer_reply, kan en automation 72 timer senere kontrollere tagget og sende en påmindelse. Når en agent tilføjer needs_manager_review, kan et view filtrere sager, så en teamleder kan se dem. Disse tags understøtter effektiv workflow-styring.

3. Identifikations-tags

Disse tags markerer en sag med en specifik, ofte midlertidig, status eller identitet. De kombinerer typisk elementer fra rapportering og automatisering og bruges ofte til at fremhæve sager, der kræver særlig opmærksomhed.

Eksempler: vip_customer, legal_hold, press_inquiry, contract_renewal

Disse tags kan sikre, at sager med særlig betydning ikke overses. De kan udløse specifikke SLA’er, notificere bestemte grupper eller sikre, at særligt erfarne agenter håndterer sagerne.

Eksempel: Fra kaos til klarhed

Før (kaos):
En agent modtager en sag om en fejl i login-funktionen og tilføjer tilfældigt et af disse tags: login_error, login_problem, bug_login, fejl_log_ind.

• Problem: Ved rapportering på “login-fejl” skal der søges på fire forskellige tags. Data bliver spredte og upålidelige.

Efter (klarhed):
Der er defineret en klar strategi: Alle fejl tagges med bug_ efterfulgt af kategori. Agenten tilføjer bug_authentication.

• Løsning: Der kan nu laves en præcis rapport i Explore ved at filtrere på bug_authentication. Det er også muligt at lave en overordnet rapport for alle bug_* tags. Data bliver rene, konsistente og anvendelige.

Anbefaling: Start med at definere formålet med tags. Opret et simpelt dokument, der beskriver de tre kategorier, og begynd at gruppere eksisterende tags. Det synliggør hurtigt tags, der ikke passer ind, og som derfor er oplagte kandidater til fjernelse.

Del 2: Paradokset - Hvorfor færre tags er bedre end flere

En udbredt fejl er antagelsen om, at flere tags giver mere data og mere værdi. I praksis falder værdien af tag-systemet for hvert unødvendigt tag, der tilføjes.

Informations-overload for agenter

En ny agent kan møde en sag, hvor relevante tags skal vælges fra en dropdown med 200 muligheder. Typiske konsekvenser:

• Paralyse: Agenten bliver usikker og springer tags over eller vælger det første, der virker relevant.
• Fejl: Agenten vælger et forkert tag, fordi forskellen mellem fx bug_critical og bug_urgent er uklar.
• Innovations-død: En god idé til et nyt tag opgives, fordi processen opleves som tung.

Når tag-systemet bliver overvældende, falder kvaliteten af brugen, og data mister værdi.

"Tag-udvanding": Når alt er specielt, er intet specielt

Hvis der findes et tag til enhver tænkelig situation, mister de vigtigste tags deres signalværdi.

Eksempel på udvanding:

• God praksis: bug_critical, bug_high, bug_medium, bug_low
• Dårlig praksis: bug_critical_login, bug_critical_payment, bug_critical_dashboard, bug_high_login, bug_high_payment... osv.

I det dårlige eksempel opstår mange tags for at beskrive noget, få tags kunne dække. Hvis en ny kritisk fejl opstår i en funktion uden et eksisterende tag, skal der afventes oprettelse af et nyt tag. I det gode eksempel kan agenten bruge bug_critical og eventuelt supplere med et mere specifikt tag for funktionen, hvis nødvendigt (fx feature_login).

Kernen er, at tags bør være brede nok til fleksibilitet og specifikke nok til at være meningsfulde. En praktisk regel er at starte bredt og kun specialisere, når det er nødvendigt.

Vedligeholdelsesmæssigt mareridt

Hvert tag kræver dokumentation, vedligeholdelse og på sigt oprydning.

• Flere tags = mere komplekse views
• Flere tags = mere komplekse triggers
• Flere tags = sværere at lave rene rapporter
• Flere tags = større risiko for “zombie tags” (mere om dette senere)

Oprydning i tag-systemer, der er vokset ukontrolleret over flere år, kan kræve omfattende manuel indsats i tusindvis af sager. En stram tilgang fra start reducerer tidsforbrug senere.

Anbefaling: Anvend en minimalistisk tilgang. Ved overvejelse af et nyt tag bør der spørges:

• Kan behovet dækkes med et eksisterende tag?
• Hvis ikke: Er tagget nødvendigt for forretningen?

Ved tvivl bør tagget ikke oprettes.

Del 3: Arkitekturen - Naming conventions der holder

En navngivningskonvention er afgørende for et stabilt tag-system over tid, især når nye agenter tilføjes. Målet er at gøre tags forudsigelige.

Principper for gode navne

1. Konsistens: Vælg en standard og anvend den konsekvent. Hvis underscore (_) bruges som separator, bør bindestreg (-) og mellemrum undgås.
2. Lowercase: Brug små bogstaver. Zendesk behandler Bug og bug som samme tag, men standardisering reducerer tvivl.
3. Ingen mellemrum eller specialtegn: Tags med mellemrum (fx login problem) kan skabe problemer i API-kald og gøre søgning besværlig. Brug bogstaver (a-z) og underscores.
4. Beskrivende, men korte: Tagget skal være forståeligt uden at være unødigt langt. bug_authentication er mere hensigtsmæssigt end problem_with_logging_in.

Anbefalet model: kategori_underkategori_værdi

Modellen skaber en hierarkisk struktur:

• Kategori: Overordnet emne (fx bug, feature, feedback, task)
• Underkategori (valgfri): Yderligere specifikation (fx ui, backend, billing, authentication)
• Værdi (valgfri): Prioritet, status eller anden relevant værdi (fx high, low, pending, completed)

Praktiske eksempler på naming conventions

For fejl (bugs):

• bug_critical (kritisk fejl, der påvirker mange)
• bug_ui_login (UI-fejl i login-modulet)
• bug_backend_payment (backend-fejl i betalingsgatewayen)
• bug_minor (mindre fejl med lav prioritet)

For produktfeedback:

• feature_request (generel anmodning om ny funktion)
• feature_request_dashboard (anmodning relateret til dashboard)
• feedback_usability (feedback om brugervenlighed)
• feedback_performance (feedback om hastighed/ydeevne)

For interne opgaver:

• task_research (sagen kræver research før svar)
• task_follow_up (opfølgning på kunden senere)
• task_escalation_product (sagen eskaleret til produktteam)

Brug af præfikser til gruppering

Præfikser som bug_, feature_ og task_ gør det lettere at finde tags i Zendesks tag-dropdown, hvor tags grupperes alfabetisk. Agenten kan begynde at skrive bug_ for hurtigt at se relevante muligheder.

Det understøtter også rapportering, da Explore kan filtrere på tags, der starter med bug_, for et samlet overblik.

Anbefaling: Definér navngivningskonventionen før ændringer i Zendesk. Inddrag relevante interessenter (agenter, teamledere, produktteams), dokumentér konventionen centralt (fx intern wiki), og gør den til en del af onboarding for nye agenter.

Del 4: Oprydningen - Sådan findes og fjernes "zombie tags"

Et “zombie tag” er et tag, der stadig findes i systemet, men ikke længere bruges aktivt. Det kan være knyttet til gamle, lukkede sager og fortsætter med at skabe støj og kompleksitet. Identifikation og oprydning er en central del af tag-hygiejne.

Metode 1: Zendesk Explore rapportering (den smarte metode)

Den mest effektive metode er at bygge en rapport, der viser alle tags og antallet af sager, de er anvendt på.

1. Opret en ny rapport i Explore.
2. Vælg datasættet: Support: Tickets.
3. I Metrics: Tilføj COUNT(Tickets).
4. I Attributes: Tilføj Ticket tags.
5. Filtrer (valgfrit, men anbefalet): Filtrer på Ticket status for kun at inkludere Solved og Closed, da zombie tags ofte findes her.

Rapporten viser alle tags og samlet antal sager, de er brugt på. Sortér fra laveste til højeste. Tags med meget få sager (fx 1–5) er typiske zombie-kandidater.

Pro-tip: Tilføj filter for Ticket created - Date for kun at se tags brugt inden for de seneste 6–12 måneder. Tags, der ikke er brugt det seneste år, er ofte zombie tags.

Metode 2: Manuel søgning (for den modige)

Hvis Explore ikke er tilgængeligt, eller instansen er lille, kan processen udføres manuelt.

1. Gå til Admin Center > Objects and rules > Tags.
2. Gennemgå listen og identificér tags med fejl, dårlig stavning eller tags, der ikke genkendes.
3. Ved et kandidat-tag, fx loggin_error, kan avanceret søgning i Zendesk Support bruges til at se anvendelse: tags:loggin_error.

Metoden er mere tidskrævende og mindre præcis, men kan give et hurtigt overblik over omfanget.

Processen for at fjerne et tag

Sletning af et tag bør ikke ske uden forberedelse, da det kan påvirke historiske data og eksisterende regler. Følgende proces anbefales:

1. Analyser: Bekræft via Explore, at tagget er et zombie tag. Kontrollér om tagget bruges i aktive triggers eller automations.
2. Beslut: Vurder om tagget er en stavefejl af et eksisterende tag, eller om det er ubrugeligt.
3. Hvis det er en stavefejl:
   • Identificér det korrekte tag.
   • Brug en masseopdatering (bulk update) til at finde sager med det forkerte tag og erstatte det med det korrekte.
   • Når tagget ikke længere bruges på sager, kan det slettes fra tag-listen.
4. Hvis det er et ubrugeligt tag:
   • Vurdér om der nogensinde bliver behov for rapportering på tagget. Hvis svaret er et tydeligt “nej”, kan sletning overvejes.
   • ADVARSEL: Når et tag slettes fra listen, fjernes det permanent fra alle sager. Ved tvivl bør tagget bevares. Et harmløst zombie tag er bedre end at slette vigtig historisk data.
   • Ved sletning bør det dokumenteres, hvilket tag der blev slettet og hvornår.

En fast, tilbagevendende “tag-oprydningsdag” hvert kvartal kan holde systemet rent og velfungerende.

Del 5: Faldgruberne - Almindelige tag-fejl og hvordan de undgås

Selv med en god strategi opstår fejl. Nedenfor er de mest almindelige fejl og tilhørende forebyggelse.

Fejl #1: Dobbelt-op og variationer

Agenter opretter nye tags, fordi eksisterende tags ikke findes hurtigt, eller fordi små variationer opstår.

• Eksempler: bug, bugs, fejl, error
• Problem: Data fragmenteres, og rapporter bliver ufuldstændige.
• Løsning: En stram navngivningskonvention og uddannelse. Der bør være ét korrekt tag pr. begreb. Prefikser gør tags lettere at finde. Det kan overvejes at begrænse, hvem der kan oprette nye tags (styres i Admin Center under “Agents”).

Fejl #2: For specifikke tags

Hyper-specifikke tags skaber støj og giver sjældent værdi.

• Eksempel: bug_customer_cannot_reset_password_after_3_attempts
• Problem: Tagget er typisk ubrugeligt til rapportering og bruges sandsynligvis kun én gang.
• Løsning: Træn en bredere kategorisering. I eksemplet kan bug_authentication og eventuelt password_reset være tilstrækkeligt. Mere specifik kontekst kan skrives i en intern note.

Fejl #3: Brug af tags som noter

Tags er til klassificering og data, ikke til sætninger.

• Eksempel: customer_is_very_upgraded_and_wants_refund
• Problem: Tagget kan ikke bruges effektivt til rapportering eller automatisering.
• Løsning: Brug separate tags pr. information, fx vip_customer, refund_request. Detaljeret kontekst hører hjemme i kommentarer eller interne noter.

Fejl #4: Manglende dokumentation og uddannelse

En tag-strategi fungerer ikke, hvis den ikke er kendt.

• Problem: Agenter gætter, opretter egne tags, og systemet glider gradvist tilbage mod kaos.
• Løsning:
  1. Dokumentation: Opret en enkel, tilgængelig guide (wiki-side, Confluence-side, Google Doc) der beskriver:
     • Formålet med tags
     • De tre kategorier
     • Navngivningskonventionen med mange eksempler
     • En liste over godkendte tags
  2. Uddannelse: Gennemgå tag-guiden i onboarding for nye agenter. Afhold korte opfriskningsmøder ved større ændringer.
  3. Ejerskab: Udpeg en “Tag Champion” pr. team, som kan støtte kolleger i at følge retningslinjerne.

Del 6: Røde flag vs. grønne flag

Symptomer kan gøre det lettere at vurdere tag-systemets sundhed.

Røde flag: Tegn på tag-anarki

Hvis flere af følgende genkendes, er der behov for en indsats:

• Over 100 unikke tags: Medmindre organisationen er meget stor med komplekse behov, kan det indikere manglende kontrol.
• Agenter klager over at finde tags: Hvis det er svært at bruge, bliver det ikke brugt korrekt.
• Explore-rapporter giver mærkelige resultater: Hvis data manuelt skal samles fra bug, bugs og fejl, er systemet brudt.
• Tags med stavefejl eller mellemrum: Fx loggin problem, bug_ui, bug-ui, hvilket indikerer manglende standarder.
• Uklarhed om ejerskab og betydning: Ingen ved, hvem der oprettede et tag, eller hvad det betyder.
• Nye agenter kan oprette tags uden vejledning: Øger risikoen for ukontrolleret vækst.

Grønne flag: Tegn på en sund tag-kultur

Følgende indikerer en velfungerende praksis:

• Formålet med tags kan forklares af alle: Fra nye agenter til ledelse.
• Tag-listen er kort, overskuelig og velorganiseret: Understøttet af præfikser og en klar konvention.
• Komplekse og præcise Explore-rapporter kan bygges hurtigt: Data er rene og konsistente.
• Agenter foreslår proaktivt forbedringer: Engagementet er højt, fordi værdien er tydelig.
• Central, let tilgængelig dokumentation findes: Og placeringen er kendt.
• Fast proces for godkendelse og oprettelse af nye tags: Sikrer, at kun nødvendige tags tilføjes.

Konklusion: Næste skridt mod tag-klarhed

Tags er ikke kun en teknisk detalje i Zendesk. Et velordnet tag-system understøtter bedre data, smartere automatiseringer, mere effektive agenter og i sidste ende gladere kunder.

Kontrol over tags kan virke omfattende, men processen kan begynde i det små.

Næste skridt: Gå til tag-listen i Zendesk og udvælg de 10 mest brugte tags. Vurder dem ud fra følgende:

1. Har taggene et klart formål (rapportering, automatisering, identifikation)?
2. Følger taggene en ensartet navngivningskonvention?
3. Er taggene for brede, for specifikke eller passende afgrænsede?

Øvelsen giver et hurtigt billede af nuværende niveau og et tydeligt udgangspunkt for at definere strategi og igangsætte en gradvis forbedring, så tag-systemet bevæger sig fra kaos til klarhed.