Admin Pro Tip: Performance - Hvorfor er Zendesk Langsom?

Performance er et af de mest undervurderede, men kritisk vigtige, aspekter af en velfungerende Zendesk-instans. En langsom platform kan frustrere agenter, øge håndteringstiden og i sidste ende påvirke kundeoplevelsen negativt. Performance-udfordringer har sjældent én enkelt årsag; typisk skyldes de en kombination af datamængder, konfiguration og brugsmønstre. Det er derfor sjældent udelukkende et Zendesk-problem.
Artiklen gennemgår de mest almindelige årsager til langsom performance i Zendesk, metoder til at identificere årsagerne samt bedste praksis til at holde systemet hurtigt.

De almindelige syndere: Hvorfor Zendesk føles langsomt

Før problemet kan løses, skal årsagen forstås. Der findes en række tilbagevendende årsager, som ofte er involveret, når agenter oplever, at Zendesk er langsomt.

For mange data i views

Dette er en af de mest almindelige årsager. Et view, der returnerer tusindvis af tickets, kan give markant langsommere indlæsning. Hver gang en agent åbner viewet, eller viewet opdateres automatisk, skal Zendesk hente store datamængder, og browseren skal gengive dem.

• Klassisk eksempel: Et view med navnet “Alle Uafsluttede Tickets”, uden tidsbegrænsning, der viser alle åbne, ventende og afventende tickets i hele systemets levetid. Over tid kan viewet vokse til 10.000+ tickets.
• Hvorfor det er et problem: Hver kolonne i et view (brugerdefinerede felter, kommentarer, tags) kræver databaseforespørgsler. Når antallet af tickets ganges med antallet af kolonner, opstår et meget stort antal datapunkter, der skal hentes og behandles samtidigt.

Komplekse makroer og automatiseringer

Makroer og automatiseringer er centrale funktioner i Zendesk, men kan påvirke performance, når de bliver for tunge. En makro, der udfører mange handlinger (fx opdatering af flere brugerdefinerede felter, notifikationer til webhooks og interne notifikationer), kan tage betydelig tid at eksekvere.

• Den usynlige forsinkelse: Når en agent kører en tung makro, kan der opstå forsinkelse, mens Zendesk behandler handlingerne i baggrunden. Ventetiden kan opleves som systemlangsomhed.
• Automatiseringer i kæder: En automatisering, der opdaterer en ticket, kan udløse andre automatiseringer. Disse kædereaktioner kan skabe uventede forsinkelser og i værste fald timeouts.

Tredjeparts-apps og integrationer

Zendesk Marketplace kan være en stor hjælp, men hver installeret app tilføjer kode til Zendesk-instansen. En dårligt kodet eller ressourcekrævende app kan påvirke performance, især i agentinterfacet.

• Apps i ticket-view: Mange apps indlæser data i sidepanelet for hver ticket. Hvis en app henter data fra et eksternt, langsomt API ved hver åbning, kan det bremse oplevelsen.
• Webhooks og integrationer: Integrationer, der løbende sender data frem og tilbage, kan skabe konstant baggrundsbelastning. Hvis et eksternt system er langsomt, kan Zendesk føles langsomt, når der afventes svar.

Dårligt optimerede Explore-rapporter

Explore er et stærkt værktøj, men kan belaste databasen. Komplekse rapporter, der kører på store datamængder, kan være langsomme at åbne og kan samtidig påvirke den generelle performance for Zendesk-kontoen.

• “Slow queries”: Når en rapport tager mere end et par minutter at køre, kan den klassificeres som en “slow query”. Disse forespørgsler kan binde ressourcer og påvirke andre dele af systemet.
• For mange beregnede metrikker: En rapport med mange komplekse Calculated Metrics tager typisk længere tid at generere end en rapport med simple standardmetrikker.

Agent-adfærd og værktøjsbrug

I nogle tilfælde skyldes oplevet langsomhed brugsmønstre frem for systemkonfiguration.

• For mange åbne tabs: Mange åbne Zendesk-faner (fx 20+) kan give langsomhed, da hver fane kører egne processer og opdateringer, som belaster browser og forbindelsen til Zendesk.
• Dårlige søgevaner: Bred søgning i hele systemet, frem for effektiv brug af views og filtre, kan være ressourcekrævende.

Browser-problemer og lokale faktorer

Det lokale miljø bør altid undersøges.

• Forældet browser: Ældre browserversioner kan have dårlig ydeevne med moderne webapplikationer som Zendesk.
• Browser-udvidelser: Ad-blockers eller andre udvidelser kan konflikte med Zendesk-scripts og gøre siden langsommere.
• Netværksproblemer: Langsom eller ustabil internetforbindelse hos den enkelte agent er en klassisk og ofte overset årsag.

Jagten på de langsomme forespørgsler: Dyk ned i Explore

Explore er ikke kun til rapportering, men også et centralt værktøj til at diagnosticere performance-problemer relateret til dataspørgsler. Zendesk stiller funktionalitet til rådighed, der kan identificere rapporter, som belaster systemet mest.

Hvad er en “Slow Query”?

En “slow query” er en rapportforespørgsel, der tager usædvanligt lang tid at eksekvere i Zendesk-databasen. Zendesk overvåger dette internt, og hvis en forespørgsel tager for lang tid, kan den blive de-prioriteret eller afbrudt for at beskytte den generelle stabilitet. Mange slow queries er et tydeligt advarselstegn for administrationen.

Find langsomme rapporter i Explore

Processen kræver admin-adgang til Explore.

Trin 1: Gå til rapport-historik

1. Naviger til Zendesk Explore.
2. Klik på rapportsymbolet (øverst til venstre) for at åbne rapportbiblioteket.
3. Find den rapport, der mistænkes for at være langsom (eller en vilkårlig rapport for at se funktionen).
4. Klik på de tre prikker (...) ved siden af rapportens navn, og vælg Report history.

Trin 2: Filtrer efter kørselstid
I Report history vises, hvornår rapporten er kørt, af hvem, og hvor lang tid den tog.

1. Klik på filter-ikonet (tragten) øverst til højre i listen.
2. Find feltet Execution time (eller tilsvarende; navnet kan variere).
3. Indstil et filter, så kun kørsler over fx 60 sekunder vises.

Trin 3: Analyser årsagerne
Listen viser de tidspunkter, hvor rapporten har været langsom. Metoden kan anvendes på centrale dashboards og rapporter, især dem med store datamængder eller komplekse beregninger, for at identificere de største belastninger.

Praktisk eksempel: En meget langsom førstegangs-svar-rapport

En rapport, der skulle vise “Gennemsnitlig tid til første svar (FCR) pr. agent”, var opbygget således:

• Dataset: Support
• Måling: CALC - Avg first reply time (hrs) (kompleks beregnet metrik)
• Række: Ticket assignee
• Filter: Ticket created - Previous 12 months

Udfordringen var, at “Previous 12 months” på en stor konto kunne betyde hundredtusindvis af tickets. Den beregnede metrik var i forvejen tung, og kombinationen med den store datamængde gjorde, at rapporten konsekvent tog 5–10 minutter at indlæse. Rapporten var næsten ubrugelig og belastede systemet ved hver opdatering af dashboardet.

Løsningen var at indsnævre tidsrammen. Filteret blev ændret til “Previous 3 months”, og der blev oprettet separate, mindre rapporter til historisk analyse. Herefter kørte rapporten på under 10 sekunder.

Sådan optimeres Explore-forespørgsler

Når langsomme rapporter er identificeret, kan følgende optimeringer anvendes:

• Indsnævr tidsrummet: Den mest effektive metode. En rapport for “sidste 7 dage” er næsten altid hurtigere end “sidste 12 måneder”. Et standard tidsfilter på dashboards (fx “sidste 30 dage”) kan overvejes.
• Reducer antallet af rækker/kolonner: En rapport med mange rækker (fx 50 agenter) er tungere end en med få (fx 5). Data kan evt. grupperes på højere niveau, fx efter gruppe i stedet for agent.
• Forenkle beregnede metrikker: Gennemgå CALC-metrikker. Undgå indlejrede IF-sætninger og kompleks logik, hvor det er muligt. I nogle tilfælde er to enklere metrikker bedre end én kompleks.
• Brug attributter i stedet for metrikker til filtrering: Filtrering på fx status bør ske via Ticket status-attributten frem for at oprette en metrik og filtrere på den. Attributfiltre er generelt hurtigere.

Views der dræber performance: Den skjulte fjende

Hvor Explore-rapporter kan belaste systemet i baggrunden, skaber langsomme views en direkte og vedvarende frustration i agenternes daglige arbejde. Optimering af views er ofte den hurtigste vej til mærkbare forbedringer.

Problemet med “Alle Uafsluttede Tickets”

Denne type view er en typisk performance-belastning. Et view med fx 15 kolonner og 8.000 tickets kræver omfattende sortering og rendering. Ved sortering efter en kolonne skal Zendesk sortere alle rækker, og ved scrolling skal browseren håndtere en meget stor HTML-tabel.

Erfaring: Der ses tilfælde, hvor et enkelt tungt view gør hele agentfanen i Zendesk “sløv”, også ved arbejde i andre views.

Dynamisk indhold og for mange kolonner

Jo flere kolonner et view har, desto mere data skal hentes og gengives. Kolonner med dynamisk indhold er særligt tunge:

• Brugerdefinerede dropdown-felter: Kræver ekstra opslag for at vise valgt værdi.
• Beregninger i view-navnet: Brug af {{ticket.ticket_field_...}} i view-navnet kan tvinge systemet til beregninger for hver ticket.
• Rich content-felter: Felter med lange tekster eller billeder bør undgås i views.

Brugerdefinerede felter i views

Hvert brugerdefineret felt i et view kan udløse ekstra databaseforespørgsler. Et view med mange brugerdefinerede felter er derfor markant langsommere end et view med standardfelter. Relevansen bør vurderes: Er informationen nødvendig i oversigten, eller kan den findes ved at åbne ticketen?

Best practices for hurtige views

Følgende tjekliste kan anvendes til at skabe hurtigere views:

• Hold det simpelt: Brug færrest mulige kolonner, og vis kun det nødvendige for at identificere og prioritere næste ticket.
• Brug filtre effektivt: Erstat brede views med specialiserede views, fx:
  • “Mine Nye Tickets” (tildelt, status: ny)
  • “Mine Åbne Tickets - Overdue” (tildelt, status: åben, overdue: ja)
  • “Uafsluttede Tickets - Sidste 7 Dage” (status: åben/ventende, oprettet: > 7 dage siden)
• Limitér antal rækker: En view med 100 tickets er hurtigere end en med 10.000. Filtre kan bruges til at indsnævre arbejdet.
• Undgå sortering på tunge kolonner: Sortering efter “Opdateret” eller “Oprettet” er typisk hurtig. Sortering efter komplekse brugerdefinerede felter kan være langsom.
• Gennemgå views regelmæssigt: Kvartalsvis gennemgang kan afdække views, der ikke længere bruges, eller som er blevet for store. Unødvendige views kan slettes for at reducere kompleksitet.

Vær proaktiv, ikke reaktiv: Checks der forhindrer katastrofer

Den bedste håndtering af performance-problemer er at forebygge dem. Proaktive checks kan indbygges i faste rutiner.

Månedlig performance-audit

En fast, månedlig “performance-audit” kan gennemføres uden at være omfattende:

1. Explore-tjek: Anvend “slow query”-filtre i Explore. Er nye rapporter blevet langsomme?
2. View-tjek: Sorter views efter antal tickets. Er nogle views vokset markant? Kan de indsnævres med tidsfiltre?
3. App-tjek: Gå til Admin Center > Apps > Zendesk Support apps. Apps, der ikke længere bruges, kan deaktiveres og fjernes.

Overvågning af nye apps og integrationer

Før installation af nye apps i produktion bør centrale spørgsmål afklares:

• Hvad gør appen præcist?
• Henter den data fra eksterne kilder, og hvor ofte?
• Nævner anmeldelser performance-problemer?
• Kan appen testes i et sandkassemiljø (sandbox) først?

Der kan anvendes en praksis, hvor nye apps testes i sandbox i en uge, mens load-tider og fejl i browserens konsol overvåges.

Gennemgang af automatiseringer og triggere

Automatiseringer og triggere kan blive forældede eller ineffektive. En gennemgang hver 6. måned kan omfatte:

• Er nogle blevet overflødige efter procesændringer?
• Kører nogle unødvendigt ofte (fx trigger på “Alle ticket-opdateringer”, men kun relevant for “Nye tickets”)?
• Kan rækkefølgen af betingelser optimeres? Zendesk evaluerer betingelser fra top til bund; de mest specifikke og sandsynlige betingelser bør placeres først.

Agent-feedback er værdifuld

En enkel kanal til feedback om performance kan etableres, fx en Slack-kanal eller et dedikeret felt i en intern feedbackformular. Ved meldinger om langsomhed kan følgende afklares:

• Hvornår opstod det?
• Hvilken handling blev forsøgt udført?
• Hvilket view/dashboard var åbent?
• Er det testet i en anden browser eller en inkognito-fane?

Oplysningerne kan være afgørende for at diagnosticere årsagen.

Opsæt advarsler på Explore-ydelse

Ved adgang til Zendesk API’er eller mere avancerede overvågningsværktøjer kan der opsættes advarsler, hvis en bestemt Explore-rapport bruger mere end fx 120 sekunder. Dette er en avanceret metode, men kan være en effektiv proaktiv tilgang.

Mål det, der kan styres: Effektiv performance-måling

Optimering kræver måling. En systematisk tilgang gør det muligt at dokumentere forbedringer og identificere problemer.

Kvalitative vs. kvantitative målinger

Der kan skelnes mellem:

• Kvantitative: Objektive tal, fx hvor mange sekunder et view tager at indlæse, eller hvor lang tid en rapport tager at køre.
• Kvalitative: Agenternes oplevelse af hastighed og friktion. Subjektivt, men ofte afgørende.

En effektiv performance-strategi kombinerer begge.

Kvantitative værktøjer og metrikker

1. Explore-kørselstider
Report history er det primære værktøj. Tal kan logges månedligt i et simpelt regneark for de vigtigste rapporter for at opdage stigninger over tid.

2. Browser Developer Tools (Network-tab)
Et gratis og kraftfuldt værktøj i moderne browsere.

• Fremgangsmåde:
  1. Åbn Zendesk i Chrome eller Firefox.
  2. Åbn Developer Tools (F12 eller Ctrl+Shift+I / Cmd+Opt+I).
  3. Gå til fanen Network.
  4. Aktivér Disable cache for en fair test.
  5. Genindlæs siden (Ctrl+R eller F5).
  6. Vent til siden er færdig med at indlæse.
• Fokusområder:
  • Waterfall: Viser hvornår filer og API-kald hentes. Et langt, tyndt “vandfald” kan indikere mange sekventielle kald.
  • Time-kolonnen: Sortér for at finde de langsomste kald. Det kan være kald til tickets.json eller til tredjeparts-apps.
  • Total tid: Nederst vises samlet tid og datamængde. Dette kan bruges som baseline før og efter optimering.

3. Zendesk’s indbyggede værktøjer
Zendesk udbygger løbende overvågning. Admin Center > Objects and rules > Audits kan i nogle tilfælde indeholde performance-relaterede hændelser.

Kvalitative målinger: Agent-oplevelsen

Agenternes oplevelse bør indgå aktivt:

• Regelmæssige tjek-ins: Teamleads eller superbrugere kan spørges, om hastigheden opleves stabil, og om specifikke views er langsomme.
• Anonyme surveys: Kvartalsvise surveys kan indeholde spørgsmål som “På en skala fra 1-5, hvor hurtig opleves Zendesk?” og “Er der specifikke handlinger, der føles langsomme?”

Etabler en performance-baseline

Uden en baseline er det vanskeligt at vurdere udvikling. Load-tid for det mest brugte view og det vigtigste dashboard kan måles via Network-tab og noteres. Ved ændringer (fx fjernelse af en app eller optimering af et view) kan der måles igen for at dokumentere effekten, fx at load-tiden for “Mine Nye Tickets” er reduceret med 40%.

Røde flag: Når systemet er langsomt, og ingen ved hvorfor

Ved pludselige performance-problemer er det vigtigt at arbejde systematisk. Følgende scenarier er typiske:

• 🚩 Pludselig, global langsomhed for alle agenter:

  • Mistænkte: Nylig udrulning (ny app, ny trigger), generel Zendesk-serviceforstyrrelse (tjek status.zendesk.com) eller internt netværksproblem.
  • Handling: Tjek Zendesk-status med det samme. Rul seneste ændring tilbage. Indhent præcist tidspunkt for start fra agenter.

• 🚩 Kun én agent er ramt:

  • Mistænkte: Lokalt problem (browser, cache, udvidelser, netværk).
  • Handling: Test i inkognito-fane, anden browser eller anden computer. Hvis det virker, er det lokalt. Ryd cache og deaktiver udvidelser.

• 🚩 Langsomhed opstår på specifikke tidspunkter (fx kl. 9 hver morgen):

  • Mistænkte: Planlagte opgaver, der belaster systemet (massivt import-script, tidsbaseret automatisering der rammer mange tickets, eller eksternt system der synkroniserer på samme tidspunkt).
  • Handling: Gennemgå planlagte opgaver og tidsbaserede automatiseringer. Vurder om timingen matcher.

• 🚩 Kun én specifik side/view er langsom:

  • Mistænkte: Specifik konfiguration (tung view, kompleks makro eller app, der kun loader på den side).
  • Handling: Brug Network-tab på den specifikke side for at identificere langsomme kald. Fjern kolonner fra viewet én ad gangen for at isolere årsagen.

• 🚩 Ingen ændringer er foretaget, men det er blevet langsommere over tid:

  • Mistænkte: Organisk vækst i datamængder. Views og rapporter bliver gradvist større og langsommere.
  • Handling: Indikerer behov for performance-audit. Gennemgå de største views og rapporter og indsnævr med tidsfiltre.

Grønne flag: Tegn på et hurtigt og velfungerende system

Succes kan kendes på følgende tegn:

• ✅ Konsistente og forudsigelige load-tider: Tickets åbner på 2–3 sekunder uanset tidspunkt, uden uventede “hængninger”.
• ✅ Proaktiv optimering er en del af kulturen: Performance drøftes før det bliver et problem, og indgår i løbende drift.
• ✅ Klare ejerskaber for performance: Det er tydeligt, hvem der kontaktes ved langsomhed, og der findes en klar proces for indberetning og undersøgelse.
• ✅ Få eller ingen klager over hastighed: Hastighed er ikke et tilbagevendende dagligt emne.
• ✅ Dashboards og rapporter er responsive: Centrale dashboards kan åbnes og opdateres på under 30 sekunder.
• ✅ Nye værktøjer evalueres for performance: Performance-impact vurderes tidligt ved nye apps og ændringer.

Konklusion: Performance er en rejse, ikke en destination

En højtydende Zendesk-instans opnås og vedligeholdes gennem løbende arbejde. Ved at forstå de typiske årsager, anvende de rette værktøjer til diagnosticering og indbygge proaktive checks i rutinerne kan performance-arbejdet flyttes fra reaktiv fejlhåndtering til kontrolleret drift.

Hver millisekund, der spares for en agent, kan bruges på at hjælpe en kunde. En hurtig platform kan bidrage til mere tilfredse agenter, kortere løsningstider og en bedre kundeoplevelse.