Admin Pro Tip: Automationer - Power User vs. Power Failure

I Zendesk er automationer et centralt værktøj til at skabe et mere selvkørende support-setup, hvor sager bliver routet, prioriteret og håndteret med minimal manuel indsats. En velfungerende automation er typisk usynlig, effektiv og reducerer både klik og manuelle fejl. Der er dog en fin grænse mellem et elegant setup og et komplekst, uforudsigeligt system, som ingen ønsker at ændre i.
Grænsen er kompleksitet. Det ses ofte, at en administrator med gode intentioner bygger en “super-automation”, der forsøger at håndtere alt fra kundens VIP-status til hvilken måned sagen blev oprettet i. I starten fungerer det godt, men når undtagelserne begynder at opstå, udvikler automationen sig hurtigt til en labyrint af betingelser, “hvis-så-ellers”-logik og tags, som kun den oprindelige opsætter kan afkode. Når den person er fraværende eller forlader organisationen, efterlades en sort boks, der kan begynde at opføre sig uforudsigeligt.

Denne artikel samler centrale erfaringer, bedste praksis og konkrete råd til at bygge, teste og vedligeholde automationer, der skaber værdi frem for driftssmerter.

Når automationer bliver for komplekse

Hvornår går en automation fra at være smart til at være risikabel? Det handler mindre om antallet af betingelser og mere om logikkens gennemsigtighed og den løbende vedligeholdelsesbyrde. Kompleksitet opstår typisk, når en automation forsøger at løse for mange opgaver, eller når logikken afhænger af for mange skjulte variabler.

Tegn på en over-kompleks automation

• Flere end 5-7 betingelser: Selvom Zendesk teknisk tillader flere, er det ofte et tegn på, at logikken bør opdeles. Når der skal scrolles for at se alle betingelser, bliver overblikket hurtigt dårligt.
• Afhængighed af obskure custom fields: En automation, der kun fungerer, fordi et specifikt custom field med et kryptisk navn som cf_internal_prio_2b er sat til “Ja”, er sårbar. Hvis en ny agent ikke kender feltets betydning, kan automationen stoppe med at virke efter hensigten.
• Logik, der kun findes i én persons hoved: Hvis der kræves et flowchart for at forklare automationen, er den typisk for kompleks. Logikken bør kunne læses lineært fra top til bund.
• Konstante undtagelser: Hvis der løbende opdages nye edge cases, som kræver endnu en “ELLER”-betingelse, er det ofte et tegn på, at grundantagelsen er forkert, og at automationen bør opdeles i flere, mere specialiserede regler.

Et praktisk eksempel: “Super-Routeren”

Forestil en automation, der skal tildele sager, og som ser sådan ud (forenklet):

Betingelser:

• Ticket | Status | Er | Ny
• Ticket | Indhold | Indeholder | "haster"
• Ticket | Indhold | Indeholder | "VIP-kunde"
• Ticket | Selskab | Er | "ACME Corp"
• Ticket | Custom field | Kunde-type | Er | "Enterprise"
• Ticket | Via | Er | "Webformular"
• Ticket | Emne | Indeholder | "Faktura"

Handlinger:

• Tilføj tags: haster, vip, enterprise, faktura
• Ændr prioritet til Høj
• Tildel til "Specialist-teamet"
• Notifikation til Slack-kanalen #critical-alerts

Udfordringen er, at kombinationerne hurtigt bliver uoverskuelige: Hvad hvis en VIP-kunde sender en hastesag om en faktura via e-mail? Hvad hvis en Enterprise-kunde, der ikke er VIP, sender en ikke-hastende anmodning? Logikken bliver hurtigt en stor mængde “hvis-så-ellers”-scenarier.

Bedre tilgang: Opdel logikken

1. Automation 1 (Tagging): Kører én gang for at tilføje relevante tags baseret på ord og kundetype. HVIS "VIP-kunde" ELLER Selskab = "ACME Corp" SÅ Tilføj tag: vip.
2. Automation 2 (Prioritering): Kører lidt senere. HVIS Tag: haster ELLER Tag: vip SÆT Prioritet til Høj.
3. Trigger (Routing): Bruger tags til at rute sagen til korrekt team. HVIS Ticket er Oprettet OG Tag: vip SÅ Tildel til "Specialist-teamet".

Når hver regel har ét ansvar, bliver fejlsøgning og vedligeholdelse enklere, og nye administratorer kan hurtigere forstå sammenhængen.

Sandbox-testing: Undgå fejl i produktion

At bygge automationer direkte i produktionsmiljøet indebærer høj risiko. En sandbox fungerer som et sikkert miljø til at eksperimentere, fejle og justere uden påvirkning af kunder og agenter.

Der bør være en konsekvent praksis: Ingen ny eller væsentligt ændret automation sættes i produktion, før den er grundigt testet i sandbox.

En systematisk tilgang til sandbox-testing

En god test er en disciplineret proces og ikke blot “at prøve det af”.

Trin 1: Klon virkeligheden

Sandboxen er mest nyttig, når den afspejler produktion. Før test bør relevante elementer være på plads:

• Brugere og organisationer: Eksportér en liste over centrale brugere, VIP-kunder og agentgrupper, og opret dem i sandboxen. Sørg for en blanding af brugertyper (end-user, agent, admin).
• Custom fields: Alle custom fields, som automationen interagerer med, skal findes i sandboxen med samme dropdown-værdier.
• Makroer og views: Hvis automationen skal spille sammen med en makro (fx ved at sætte et tag, som en makro reagerer på), skal makroen også være til stede.
• Andre relaterede automationer/triggere: Hvis den nye automation skal køre efter en trigger, skal triggeren også være aktiv og testet i sandboxen.

Trin 2: Definér test cases (vigtigste trin)

Der skal tænkes som en, der forsøger at bryde automationen. Opret en tjekliste med både positive og negative scenarier.

Test Case ID	Beskrivelse	Forventet resultat	Faktisk resultat	Status
TC-01	Ny ticket fra VIP-kunde via webformular	Ticket får tag vip, prioritet Høj, tildelt Team A
TC-02	Ny ticket fra almindelig kunde via e-mail	Ingen ændringer fra denne automation
TC-03	Ny ticket med ordet "haster" i emnet	Ticket får tag haster, prioritet Høj
TC-04	Ny ticket fra VIP-kunde med "haster" i emnet	Ticket får tags vip og haster, prioritet Høj, tildelt Team A
TC-05	Ny ticket, men custom field "Kunde-type" er tomt	Automationen kører ikke, da en betingelse ikke er opfyldt
TC-06	Ticket opdateres af agent 1 time efter oprettelse	Intet sker (automationen kører kun på "Ny" status)
TC-07	Ny ticket fra en bruger, der er slettet i systemet (edge case)	Automationen fejler elegant eller ignorerer ticketen

Gennemgå hvert punkt, observer resultatet i sandboxen, og notér det i tabellen. Hvis “Faktisk resultat” ikke matcher “Forventet resultat”, er en fejl identificeret, før den rammer produktion.

Trin 3: Test “hvad nu hvis”-scenarier

Udvid testene ud over standardcases:

• Hvad nu hvis en agent manuelt ændrer prioriteten lige efter, at automationen har sat den? Skal en anden automation sætte den tilbage?
• Hvad nu hvis en nødvendig betingelse, fx et custom field, mangler? Skal automationen fejle stille, eller skal der sendes en notifikation til en admin?
• Hvad nu hvis to modsatrettede automationer er aktive samtidigt? (se afsnittet om almindelige fejl).

Trin 4: Dokumentér og godkend

Når alle test cases er grønne, bør automationens formål, begrundelse og ejerskab dokumenteres. En kollega eller teamleder bør gennemgå test-case-tabellen og logikken som godkendelse. Et ekstra sæt øjne fanger ofte fejl, der overses.

Først herefter kan automationen replikere i produktion, betingelse for betingelse og handling for handling.

Debugging af automationer der ikke virker

Selv med omhyggelig test kan en automation, der har fungeret i måneder, pludselig fejle. En sag, der skulle være tildelt, ender i “Unassigned”. En systematisk tilgang reducerer risikoen for fejlfinding, der skaber nye problemer.

Den systematiske fejlfindingsproces

1. Start med det basale (de enkle tjek):

   • Er den aktiv? Er “Active” slået til? En ændring kan utilsigtet deaktivere en automation.
   • Tjek kørselstidspunktet: Kører den “When ticket is created”, “When ticket is updated” eller på en tidsplan (fx “Hourly”)? Den kan være sat til at køre på et andet tidspunkt end forventet.
   • Execution Log: Gå til Admin > Automations og klik på “Executions” for den relevante automation. Her ses seneste kørsel og antal behandlede sager. Hvis der står “0 tickets matched”, peger det på betingelserne.

2. Isolér problemet med Ticket Inspector:

   • Find en konkret sag, der burde have matchet automationen, men ikke gjorde det.
   • Åbn sagen og brug “Ticket Inspector” (eller de tre prikker > “Apps” > “Ticket Inspector”, hvis tilgængeligt). Værktøjet viser den præcise tilstand for felter, tags og værdier på det relevante tidspunkt.
   • Gennemgå betingelserne én for én og sammenlign med Ticket Inspector:
     • Betingelse: Ticket | Status | Er | Ny. Inspector viser: Status: Open. En trigger eller anden automation har ændret status, før automationen nåede at køre.
     • Betingelse: Ticket | Custom field | Kunde-type | Er | "Enterprise". Inspector viser: Kunde-type: (blank). Feltet blev ikke udfyldt.

3. “Kommenter ud”-metoden:
   Ved mange betingelser kan den skyldige være svær at finde. Redigér automationen:

   • Deaktivér den nederste halvdel af betingelserne.
   • Gem og test med en ny sag i sandbox (eller afvent næste sag, hvis nødvendigt).
   • Hvis den nu kører, ligger fejlen i den del, der blev deaktiveret.
   • Gentag ved at deaktivere halvdelen af de resterende betingelser, indtil den konkrete betingelse er isoleret.

4. Tjek for “race conditions”:
   Zendesk har en fast rækkefølge: Webhooks -> Triggers -> Automationer.

   • En trigger kører straks, når en sag oprettes eller opdateres.
   • En automation kører med en forsinkelse (typisk 5-10 minutter) på en tidsplan.
   • Problem: En trigger kan ændre sagen, så automationens betingelser ikke længere er opfyldt.
   • Eksempel:
     • Automation: HVIS Status er Ny OG Tag: vip SÆT Prioritet til Høj.
     • Trigger: HVIS Ticket er Oprettet SÆT Status til Åben.
     • Resultat: Triggeren kører først og sætter status til “Åben”. Senere kører automationen, ser at status ikke er “Ny”, og gør ingenting.
   • Løsning: Justér betingelsen til HVIS Status er mindre end Løst OG Tag: vip... eller flyt logikken til en trigger i stedet.

Fallback-strategier når automationer fejler

Selv veldesignede og testede automationer kan fejle, fx ved nedetid, ændringer i Zendesk eller uforudsete arbejdsgange. Et robust setup inkluderer sikkerhedsnet.

Proaktive fallbacks: Tidligt advarselssystem

Strategierne her er designet til at fange fejl, før de bliver store.

• “Safety Net”-views: Opret views, der fanger sager, som “falder gennem sprækkerne”.

  • Eksempel 1 (Unassigned Tickets): Status < Løst, Tildelt: (ikke tildelt), Opdateret for mere end 1 time siden. Fanger sager, der burde være blevet tildelt af routing, men ikke blev det.
  • Eksempel 2 (SLA Breach Imminent): Status: Ny, Åben, Afventer, SLA: Overtrædet inden for 1 time. Fanger sager, hvor SLA-automation kan være fejlet.
  • Eksempel 3 (Stuck in a Loop): Status: Afventer, Opdateret af: (en specifik webhook-bruger), Opdateringer: > 10. Kan indikere en løkke mellem webhook og automation.

• Notifikationer på safety nets: Et view har kun værdi, hvis nogen reagerer på det.

  • Brug en trigger: HVIS Ticket opdateres OG Ticket er i "Safety Net" view SÅ Send e-mail til "admin-team@virksomhed.dk".
  • Brug en app som “Observe” eller integrér med Slack, så der sendes en besked, når en sag lander i et safety-net-view.

Reaktive fallbacks: Nødplan

Hvis en automation har fejlet over længere tid (fx i en weekend), er der behov for en plan for oprydning.

• Foruddefineret “Bulk Action”-plan: Hav en skriftlig procedure for manuel udbedring.

  • Eksempel: “Routing-automationen fejlede fra fredag kl. 17 til søndag kl. 20.
    1. Gå til view ‘Unassigned Tickets - Weekend Failure’.
    2. Filtrér på tickets oprettet i tidsperioden.
    3. Vælg alle tickets.
    4. Anvend makroen ‘Bulk Assign - Post Mortem’, der tildeler tickets baseret på brand og sprog.
    5. Anvend makroen ‘Bulk SLA Set - Post Mortem’, der sætter den korrekte SLA-mål.”
  • En fast plan reducerer panik og inkonsistente manuelle rettelser.

• Manuel overstyring som bevidst designvalg: Agenter skal kunne udføre de handlinger, som automationer normalt udfører. Hvis en automation tildeler en sag, skal teams være synlige, og manuel tildeling skal være mulig. Hvis en automation sætter prioritet, skal prioriteten kunne ændres. Et setup bør ikke være så låst, at en fejl lammer arbejdsgangen.

Almindelige automation-fejl og hvordan de undgås

De samme fejltyper går ofte igen. Nedenfor er typiske faldgruber og måder at undgå dem på.

Fejl 1: “Execution Limbo” – forkert betingelseslogik

Problem: Der vælges forkert mellem “Check all conditions” og “Check any condition”, hvilket kan få en automation til aldrig at køre eller at køre på alt.

• Eksempel: En automation skal køre, hvis en sag enten er fra en VIP-kunde ELLER har ordet “haster” i emnet. Hvis der ikke skiftes til “Check any condition”, kører automationen kun, hvis sagen er fra en VIP-kunde OG har “haster” i emnet.
• Undgåelse: Læs betingelseslogikken højt før der gemmes: “Kør HVIS A OG B OG C …” eller “Kør HVIS A ELLER B ELLER C …”.

Fejl 2: “The Race Condition” – automationer der modarbejder hinanden

Problem: To automationer (eller en trigger og en automation) har modstridende mål og “kæmper” om samme sag.

• Eksempel:
  • Automation A: HVIS Tag: vip SÆT Prioritet til Høj.
  • Automation B: HVIS Selskab: "Standard Corp" SÆT Prioritet til Normal.
  • En VIP-kunde fra “Standard Corp” skriver. Automation A sætter prioritet til Høj. Senere kører Automation B og sætter den tilbage til Normal.
• Undgåelse: Vær bevidst om rækkefølge og styring via tags. Automation A kan tilføje tagget prio_set_by_vip. Automation B kan tilføje betingelsen: ... OG Tag: prio_set_by_vip | Er ikke | sat.

Fejl 3: “The Update Trap” – uendelig løkke

Problem: En automation opdaterer en sag, hvilket udløser en trigger, som igen får automationen til at køre, gentagne gange.

• Eksempel:
  • Automation: HVIS Status er Ny OG Opdateret for mere end 60 minutter siden SÆT Status til Åben OG Tilføj tag: auto_stale.
  • Trigger: HVIS Ticket opdateres OG Tag: auto_stale er sat SÅ Send intern notifikation.
  • Når automationen tilføjer auto_stale, er det en opdatering, som kan udløse triggeren. Afhængigt af betingelser kan det også medføre gentagne automation-kørsler.
• Undgåelse: Brug “stop-the-loop”-logik ved at tilføje et tag, som automationen selv tjekker:
  • Rettet automation: HVIS Status er Ny OG Opdateret for mere end 60 minutter siden OG Tag: auto_stale | Er ikke | sat SÆT Status til Åben OG Tilføj tag: auto_stale.
  • Når tagget er sat, kører automationen ikke igen på samme sag.

Fejl 4: “Time Zone Troubles”

Problem: Tidsbaserede betingelser i automationer kører i Zendesk-kontoens tidszone, ikke i den enkelte agents eller kundes tidszone.

• Eksempel: Et team i Danmark (GMT+1) og et team i USA (GMT-7). En automation: HVIS Ticket er oprettet efter kl. 17:00 SÆT Tildelt til "Natteholdet". For USA-teamet er kl. 17:00 midt på dagen, men for systemet er det aften, og sager routes forkert.
• Undgåelse: Vær eksplicit i betingelser. Undgå tidspunkter på tværs af teams, hvis muligt. Brug i stedet tags eller andre markeringer, som agenter kan sætte, eller basér det på “business hours”, som kan konfigureres pr. schedule.

Røde flag: automationer ingen kan forklare

Dette er de mest risikable automationer, fordi de også er et organisatorisk problem: viden er låst til én person eller forsvundet over tid.

Rødt flag 1: “Det har altid været sådan”

En erfaren agent kan ikke forklare, hvorfor sager fra “XYZ Inc” automatisk tildeles “Team B” og får tagget legacy_process, og undlader at ændre noget af frygt for at bryde systemet.

Dette indikerer typisk manglende ejer, manglende dokumentation og manglende aktuel forretningsbegrundelse. Det er ofte en rest fra en tidligere proces.

Handling: Sæt en “sunset”-dato. Deaktivér midlertidigt i en lavtrafikperiode (fx en weekend) og observer konsekvenserne. Hvis intet påvirkes, kan automationen slettes. Hvis noget påvirkes, er formålet identificeret og kan dokumenteres, hvorefter en bedre version kan bygges.

Rødt flag 2: Den hemmelige opsætning

Én person har bygget alle komplekse automationer, og ingen andre tør ændre dem. Ved problemer er det kun denne person, der kan løse dem.

Det udgør en væsentlig forretningsrisiko ved sygdom, ferie eller fratrædelse.

Handling: Videndeling skal indgå som en del af driften. Gennemfør en “automation-audit”, hvor hver automation gennemgås med en anden admin eller teamleder. Dokumentér i et fælles dokument (Confluence, Notion, Google Docs) med:

• Formål
• Ejer
• Betingelser (i klartekst)
• Handlinger (i klartekst)
• Relaterede automationer/triggere

Rødt flag 3: Konstant tilpasning

En automation kræver nye undtagelser eller nye “hvis-så”-led hver anden uge.

Det er ofte et tegn på en forkert grundantagelse. I stedet for flere lapper bør det vurderes, om automationen bør eksistere i sin nuværende form, eller om den bør opdeles.

Handling: Gå tilbage til udgangspunktet og identificér det underliggende behov bag undtagelserne. Ofte er løsningen to eller tre mindre, specialiserede automationer i stedet for én stor.

Grønne flag: simpelt og testet automation-setup

Et sundt setup har typisk følgende kendetegn.

Grønt flag 1: Ejer og dokumentation

Hver automation har en navngiven ejer (en person, ikke kun “Admin-teamet”) og en kort, præcis beskrivelse af formålet, skrevet så en ny agent kan forstå den.

Eksempel på beskrivelse: “Ejer: [Navn]. Formål: Sætter SLA-mål til ‘Første Svar - 8 timer’ for alle nye tickets fra enterprise-kunder, så de bliver fanget af SLA-målinger.”

Grønt flag 2: Single Responsibility Principle

Hver automation udfører én opgave: tildeling, prioritering eller notifikation. Den forsøger ikke at løse flere formål samtidigt. Det gør test, fejlsøgning og vedligeholdelse enklere.

Grønt flag 3: Forudsigelige navne og tags

Der anvendes en klar og konsekvent navngivningskonvention:

• Automationer: auto_routing_, auto_sla_, auto_cleanup_
• Triggere: trigger_notify_, trigger_tag_
• Tags: vip_customer, high_priority, needs_followup, billing_issue

Når et tag eller en automation ses, er formålet tydeligt uden at åbne logikken.

Grønt flag 4: Integration i onboarding

Nye agenter får en introduktion til de 5-10 vigtigste automationer og triggere, der påvirker daglig drift. Eksempelvis: Når en sag tildeles “Fakturering”, kører en automation, som notificerer regnskab, hvilket forklarer, hvorfor manuel e-mail ikke er nødvendig.

Grønt flag 5: Regelmæssig oprydning (automation audit)

Der er en fast, kvartalsvis “Automation Audit” i kalenderen, hvor aktive automationer gennemgås med fokus på:

• Om de stadig er relevante
• Om deaktiverede automationer kan slettes
• Om nogen er blevet for komplekse og bør opdeles
• Om nogen mangler ejer og skal tildeles

Dette reducerer digitalt rod og hjælper med at holde setup’et effektivt og forudsigeligt.

Konklusion: Fra Power Failure til Power User

At mestre Zendesk-automationer handler ikke om at bygge de mest komplekse regler, men om at bygge de mest pålidelige og forudsigelige. Styrken ligger i enkelhed, klarhed og robusthed.

Med sandbox-testing, sikkerhedsnet, systematisk fejlsøgning og fokus på gennemsigtighed kan automationer udvikles fra en potentiel “Power Failure” til en stabil, værdifuld motor i support-organisationen. Målet er et setup, der fungerer konsekvent i hverdagen og understøtter agenternes arbejde med høj kvalitet i kundeservice.