Admin Pro Tip: Custom Fields - Sådan Undgår Du "Field Sprawl"

Ved optimering af Zendesk-instanser opstår der ofte et tilbagevendende fænomen på tværs af virksomhedsstørrelser og brancher: "Field Sprawl". Det er den stille, gradvise vækst i brugerdefinerede felter (custom fields), som over tid kan forvandle en ellers overskuelig ticket-formular til et uoverskueligt setup. Det starter typisk med gode intentioner: "Der er behov for ét felt mere til at spore X" eller "Kan der tilføjes en dropdown til Y?". Over tid kan resultatet blive en formular, der er så lang, at der skal scrolles for at finde basale oplysninger, og en rapportering præget af tomme eller irrelevante data.
Artiklen fungerer som en guide til at genvinde kontrollen gennem erfaringer, strategier og konkrete værktøjer til at identificere, prioritere og rydde op i custom fields. Målet er både at fjerne unødvendige felter og at etablere en kultur og proces, der sikrer, at hvert felt i Zendesk har et klart formål og en aktiv rolle i supportprocesserne.

Når Nok er Nok - Hvor Mange Fields er for Mange?

Der findes ikke et magisk tal for, hvornår antallet af felter bliver et problem. Grænsen handler ikke om et bestemt antal, men om oplevelsen af, hvornår felterne begynder at gøre mere skade end gavn.

Der er dog en række tydelige symptomer på et "Field Sprawl"-problem:

• Agent-forvirring: Hvis agenter ofte spørger "Hvad skal der stå i dette felt?" eller "Hvorfor er feltet vigtigt?", er det et tydeligt advarselssignal. En god ticket-formular bør være intuitiv og guide agenten frem for at skabe usikkerhed.
• Performance-problemer: Mange felter, især komplekse felter med mange afhængigheder, kan gøre ticket-visningen langsommere. Når en ticket åbnes, skal Zendesk hente og rendere alle felter, hvilket kan mærkes ved store mængder.
• Rapporterings-mareridt: I Explore kan der opstå en meget lang liste af felter, hvor mange er tomme, indeholder meningsløse data eller duplikerer information fra andre felter. Det gør relevante datapunkter sværere at finde og øger risikoen for fejl i rapporter.
• Vedligeholdelsesbyrde: Ved procesændringer skal mange felter gennemgås for at opdatere beskrivelser, dropdown-værdier eller afhængigheder, hvilket er tidskrævende og øger risikoen for fejl.

En praktisk tommelfingerregel er "foldereglen": Kan en agent se alle de essentielle felter, der skal udfyldes for at løse en standardsag, uden at skulle scrolle på en gennemsnitlig skærm? Hvis svaret er nej, er der et problem. Det gælder felter, der er synlige som standard (ikke felter, der kun vises under specifikke betingelser). Hvis der skal ledes efter information, går effektivitet tabt.

Det centrale er at finde balancen. For få felter kan give manglende kontekst, mens for mange felter skaber støj og friktion. "Field Sprawl" er den gradvise forskydning fra balance til støj.

Sådan Prioriteres Hvilke Fields der Faktisk Bruges

Identifikation af overflødige felter kræver en systematisk tilgang. Det er sjældent tilstrækkeligt at vurdere ud fra en liste alene. En kombination af kvantitativ dataanalyse og kvalitativ feedback giver det bedste beslutningsgrundlag.

Trin 1: Dataindsamling og Analyse

Zendesk Explore er et centralt værktøj til at få indsigt i, hvordan felter bruges (eller ikke bruges).

1. Opret en rapport for hvert felt: For hvert custom field, der skal undersøges, oprettes en simpel Explore-rapport, som tæller antallet af tickets, hvor feltet har en værdi.
2. Identificer "spøgelsesfelter": Felter sorteres efter, hvor ofte de udfyldes. Felter, der er tomme i 95%+ af alle tickets, er primære kandidater til fjernelse, da de typisk skaber støj uden at tilføre værdi.
3. Kig efter "single-value" felter: Et dropdown-felt, hvor én værdi udgør 99% af alle valg, er et advarselssignal. Det kan indikere, at feltet er overflødigt, eller at formålet bør revurderes. Det kan også pege på en standardværdi, der bør indgå i processen frem for et manuelt valg.
4. Analyser felter med fri tekst: Felter som "Beskrivelse af problem" kan være relevante, mens et felt som "Yderligere Info" kan blive en opsamlingsplads for ustrukturerede data. En tekstanalyse kan afdække mønstre. Hvis der ofte skrives det samme, kan det indikere, at feltet bør konverteres til et dropdown-felt med foruddefinerede valg.

Trin 2: Kategorisering af Fields

Når data er indsamlet, kategoriseres hvert felt. En enkel fire-kasses model kan anvendes:

• Kritisk for Drift: Felter, der er essentielle for workflow. Uden disse kan en sag ikke løses, eskaleres eller routes korrekt. Eksempler: "Kunde-ID", "Ordrenummer", "Problemtype". Felterne bør bevares, optimeres og placeres lettilgængeligt.
• Vigtig for Rapportering: Felter, der ikke nødvendigvis bruges direkte i løsningen, men som er afgørende for forretningsindsigt. Eksempler: "Årsag til henvendelse", "Løsningstype", "Berørt produkt". Felterne bør bevares, og der bør sikres høj datakvalitet samt forståelse for, hvorfor de skal udfyldes.
• Nyttig for Kontekst: Felter, der giver ekstra information i specifikke situationer, men ikke er kritiske for de fleste sager. Eksempler: "Link til intern wiki-side", "Specifik softwareversion". Felterne er gode kandidater til at blive gjort betingede (se næste afsnit) eller skjult fra standardvisningen.
• Forældet/Ubrugt: Felter, der ifølge analyse og feedback ikke bruges, eller som er blevet overflødige efter procesændringer. Felterne bør fjernes.

Trin 3: Den Svære Beslutning - At Fjerne Fields

Sletning af et felt kan opleves som en stor beslutning. En anbefalet tilgang er at følge en "deprecation"-proces før sletning.

1. Skjul feltet: Feltet skjules først fra alle agent-views og ticket-formularer, så det ikke længere er synligt for brugere.
2. Observer i en periode: Feltet holdes skjult i 2-4 uger. Feedback fra agenter monitoreres, fx "Felt X kan ikke findes længere, og det bruges til [specifik use case]". Hvis der ikke opstår behov, er feltet tættere på at kunne slettes.
3. Kommuniker: Inden sletning sendes en besked i en relevant kanal (fx Slack eller Teams) om planlagt sletning af ubrugte felter. Felterne oplistes, og der gives en sidste mulighed for indsigelser.
4. Slet: Hvis der ikke kommer indsigelser, kan feltet slettes. Data i feltet fjernes, men når det er konstateret, at feltet ikke blev brugt, vurderes risikoen som acceptabel.

Processen reducerer risikoen for at påvirke skjulte, men vigtige processer, og skaber samtidig tillid, fordi agenter inddrages.

Field Dependencies - Sådan Holdes Logikken Simpel

Field dependencies (betingede felter) er et stærkt værktøj i Zendesk, der kan vise eller skjule felter baseret på værdien i et andet felt. Brugt korrekt kan det reducere "Field Sprawl" markant og guide agenten gennem en logisk proces. Brugt forkert kan det skabe et uoverskueligt net af logik.

Styrken ved Simpel Logik

Et eksempel på enkel og effektiv logik:

• Felt 1 (Dropdown): Problemtype

  • Værdi A: "Teknisk Fejl"
  • Værdi B: "Fakturaspørgsmål"
  • Værdi C: "Andet"

• Dependency:

  • Hvis "Problemtype" er "Teknisk Fejl", vis feltet "Produkt" (dropdown) og "Fejlbesked" (tekstfelt).
  • Hvis "Problemtype" er "Fakturaspørgsmål", vis feltet "Ordrenummer" (tekstfelt).
  • Hvis "Problemtype" er "Andet", vis feltet "Beskrivelse" (tekstfelt).

Dette giver flere fordele:

1. Reduceret støj: Kun relevante felter vises for den konkrete henvendelse.
2. Guidet proces: Agenten guides til at indsamle de relevante oplysninger.
3. Højere datakvalitet: Dropdowns giver strukturerede data, som er lettere at rapportere på.

Dette er et grønt flag: En klar afhængighed med et tydeligt formål.

Faldgruberne - Når Logikken Bliver et Spindelvæv

Udfordringer opstår, når afhængigheder bygges oven på afhængigheder.

Eksempel på dårlig logik:

• Hvis "Problemtype" er "Teknisk Fejl", vis "Produkt".
• Hvis "Produkt" er "Software X", vis "Version".
• Hvis "Version" er "v2.0", vis "Modul".
• Hvis "Modul" er "Fakturering", vis "Fejlkode".
• ...og så videre.

Hvorfor er dette problematisk?

• Uoverskueligt: Logikken er vanskelig at vedligeholde og fejlsøge. Ændringer ét sted kan give uforudsete konsekvenser længere nede i kæden.
• Forvirrende for agenten: Overblikket kan gå tabt. Et forkert valg tidligt kan kræve, at processen startes forfra.
• Skjulte felter: Ticket-formularen kan ende med mange felter, hvor størstedelen er skjult det meste af tiden, hvilket skaber administrativt rod.

En tommelfingerregel for afhængigheder er: Maksimalt to niveauer. Et felt afhænger af et andet, men sjældent af et tredje. Hvis der er behov for mere kompleks logik, kan det overvejes, om det kan løses på anden måde, fx med forskellige ticket-formularer til forskellige formål eller med makroer, der udfylder felter baseret på valg.

Rødt flag: En afhængighedskæde på mere end to niveauer, eller en ticket-formular, hvor mere end halvdelen af felterne er skjult som standard.

Cleanup-Strategi for Ubrugte Fields

En "big bang"-oprydning kan være risikabel. En mere kontrolleret og bæredygtig tilgang er at etablere en løbende cleanup-strategi.

Forberedelse: Lav en Backup og en Plan

Før ændringer gennemføres, bør der ligge en plan.

1. Dokumenter nuværende tilstand: Udarbejd en liste over alle custom fields, inkl. feltnavn, felttype, formål (hvis kendt) og hvor feltet bruges (views, formularer, triggers). Et simpelt regneark er velegnet.
2. Kommuniker intentionen: Informér team og relevante stakeholders om, at custom fields gennemgås og optimeres for at forbedre effektiviteten, samt hvorfor det er vigtigt. Det skaber opbakning.
3. Afsæt tid: Opgaven løses sjældent på en eftermiddag. Der bør afsættes dedikeret tid over flere uger.

Eksekvering: Deprecation Før Sletning

"Deprecation" er en sikker tilgang. En køreplan kan se sådan ud:

1. Fase 1: Identifikation (Uge 1)

   • Brug Explore-metoden til at identificere kandidater til fjernelse.
   • Afhold workshops med agent-teams for at indsamle kvalitativ feedback, fx: "Hvilke felter bruges aldrig?" og "Hvilke felter er forvirrende?".
   • Opdater regnearket med fund og kategorisér felterne (Kritisk, Rapportering, Kontekst, Forældet).

2. Fase 2: Skjulning og Observation (Uge 2-5)

   • Gå til "Ticket Fields" i Zendesk Admin.
   • For felter i kategorierne "Kontekst" og "Forældet" fjernes markeringen ved "Visible to agents".
   • Dette skjuler feltet fra views og formularer. Bemærk: Hvis feltet er obligatorisk, skal det først fjernes fra relevante formularer, før det kan skjules.
   • Observer og indsaml feedback. Hvis felter efterspørges, afklares årsagen. Feltet kan evt. flyttes til en anden kategori, eller undtagelsen kan håndteres på anden måde.

3. Fase 3: Endelig Godkendelse og Sletning (Uge 6)

   • Gennemgå listen igen. Felter, der ikke er blevet efterspurgt, er klar til sletning.
   • Send en endelig notifikation, fx: "Som tidligere kommunikeret slettes nu følgende felter, da de ikke har været brugt de sidste uger: [liste]". Angiv en deadline for indsigelser (fx 24 timer).
   • Slet felterne permanent.

Automatisering og Vedligeholdelse

Oprydning er ikke en engangsopgave. For at forhindre, at "Field Sprawl" vender tilbage, bør der etableres en fremadrettet proces.

• Kvartalsvis review: Planlæg et fast kvartalsvist review af felter med samme metode. Det kræver typisk mindre tid, når det udføres løbende.
• Opret en "Field Request"-proces: Gør det tydeligt, hvordan nye felter anmodes. En enkel proces kan inkludere et skema, hvor behovet begrundes:
  1. Hvad er formålet med feltet?
  2. Hvilken proces forbedres?
  3. Hvem skal bruge data (agenter, ledelse osv.)?
  4. Hvilken felttype skal anvendes (dropdown, tekst osv.)?
  5. Findes der allerede et felt, der kan bruges?

Processen understøtter en vurdering af nødvendighed og giver et bedre grundlag for at godkende eller afvise anmodningen.

Almindelige Field-Fejl og Hvordan Man Undgår Dem

De samme fejl ses ofte igen og igen. Nedenfor er de mest almindelige faldgruber samt måder at undgå dem på.

Fejl 1: Dårlig Navngivning

• Symptomer: Feltnavne som "Info", "Data", "Custom Field 12345", "Dropdown 2", hvor formålet ikke er tydeligt.
• Konsekvens: Uklarhed om, hvad der skal udfyldes, og data bliver ubrugelige til rapportering.
• Løsning: Etabler en navngivningskonvention. En anvendelig model er [Kategori] - [Specifik Formål]. Eksempler: [Kunde] - Kundenummer, [Produkt] - Model, [Intern] - Eskaleringsårsag. Konsistens er afgørende.

Fejl 2: Forkert Field Type

• Symptomer: Brug af et tekstfelt til data, der burde være struktureret (fx at skrive "Høj", "Mellem", "Lav" i et prioriteringsfelt i stedet for at vælge det).
• Konsekvens: Lav datakvalitet og vanskelig rapportering pga. mange variationer af samme værdi ("Høj", "høj", "høj prioritet", "Høj!").
• Løsning: Vurder datatypen før oprettelse af feltet:
  • Brug Dropdown til et fast antal valg.
  • Brug Multi-select til flere valg fra en fast liste.
  • Brug Checkbox til ja/nej-spørgsmål.
  • Brug Text kun til unik, ustruktureret information som serienumre eller kommentarer.

Fejl 3: Manglende Dokumentation

• Symptomer: Tre forskellige agenter giver tre forskellige forklaringer på, hvad et felt betyder.
• Konsekvens: Inkonsekvent brug, forkerte data og forvirring.
• Løsning: Opret et centralt "Field Dictionary", fx i en intern wiki (Confluence, Notion osv.) eller et Google Sheet. For hvert felt dokumenteres:
  • Feltnavn
  • Formål (kort og præcist)
  • Hvem der er ansvarlig for at udfylde feltet
  • Hvad værdier betyder (især for dropdowns)
  • Eksempler på korrekt brug

Fejl 4: At Ignorere Standardfelter

• Symptomer: Oprettelse af custom felter som "Prioritet" eller "Status", selvom Zendesk allerede har standardfelter til dette.
• Konsekvens: Duplikerede data, forvirring om hvilket felt der er korrekt, samt problemer med integrationer og automatiseringer, der forventer standardfelter.
• Løsning: Kend standardfelterne. Zendesk har indbygget logik i felter som Type, Priority, Status, Group, Assignee. Processer bør så vidt muligt tilpasses til standardfelter, før der oprettes custom felter med samme funktion.

Fejl 5: At Gøre Fields Obligatoriske Uden Grund

• Symptomer: Ticket-formularer med mange obligatoriske felter, hvor en stor del ikke er relevante for størstedelen af henvendelser.
• Konsekvens: Agentfrustration og "garbage data". Når et irrelevant felt skal udfyldes, ender værdier ofte som "N/A" eller tilfældige indtastninger.
• Løsning: Vurder strengt, hvilke felter der reelt skal være obligatoriske. Kun felter, der er kritiske for, at en sag kan eksistere, bør være obligatoriske på tværs. For øvrige felter kan betingede felter anvendes, eller felterne kan gøres valgfrie.

Røde Flag vs. Grønne Flag - Hurtig Tjekliste

Nedenstående tjekliste kan bruges til at vurdere sundhedstilstanden i en Zendesk-instans.

Røde Flag: Advarselssignaler der Kræver Handling

• Over 100 custom fields: Et stærkt tegn på "Field Sprawl".
• Klager over rodet og lang ticket-formular: Feedback fra agenter er central, da formularen bruges dagligt.
• Manglende forklaring på felters formål: Hvis formålet er uklart, er feltet typisk også uden værdi.
• Explore-rapporter med mange tomme kolonner: Spild af plads og mental energi.
• Komplekse, indlejrede afhængigheder: Skaber høj vedligeholdelsesrisiko.
• Ingen proces for godkendelse af nye felter: Felter oprettes ad hoc uden styring.

Grønne Flag: Tegn på en Veldrevet Zendesk-instans

• Færre end 30-40 custom fields med tydeligt formål: Kvalitet frem for kvantitet.
• Korte, rene og intuitive ticket-formularer: Nødvendige felter kan findes med det samme.
• Tilgængelig dokumentation (fx "Field Dictionary"): Gennemsigtighed understøtter ensartet brug.
• Hurtig og præcis rapportering: Relevante og veldefinerede datapunkter gør rapportering mere effektiv.
• Simple, effektive field dependencies: Irrelevante felter skjules, og agenten guides.
• Formel proces for anmodning og godkendelse af nye felter: Begrundelse for nødvendighed indgår.

Kontrol med custom fields er en løbende opgave og en værdifuld investering for Zendesk-administration. Det handler ikke kun om oprydning, men om at skabe et fundament for effektivitet, klarhed og datadrevet beslutningstagning. En proaktiv og systematisk tilgang kan omdanne Zendesk fra et uoverskueligt lager af ubrugte data til et skarpt og effektivt værktøj, der understøtter både agenter og forretning.