Gå til hovedindhold

Business Rules - Trigger order & conditions

Opdateret

At arbejde effektivt med Zendesk Support handler ikke kun om at besvare henvendelser, men også om at opbygge et intelligent og selvkørende system. Kernen i dette system er Business Rules – reglerne, der styrer, hvad der sker med en sag fra oprettelse til lukning. Forståelse af disse regler, herunder rækkefølge og betingelser for triggers, er afgørende for at undgå konflikter, uventet adfærd og sikre en stabil arbejdsgang.

Hjertet i Zendesk Support: Hvad er Business Rules?

Business Rules er det logiske fundament, som et Zendesk-setup hviler på. Reglerne definerer, hvordan Zendesk evaluerer og udfører automatiserede handlinger og understøtter konsistens, effektivitet og korrekt routing.

De primære typer af Business Rules i Zendesk er:

  • Triggers: Reagerer på øjeblikkelige hændelser (events), såsom oprettelse af en sag eller en opdatering. Dette er de mest aktive og grundlæggende regler.
  • Automations: Kører på en tidsplan (typisk hver time) og tjekker for sager, der opfylder bestemte kriterier over en længere periode (f.eks. “hvis en sag har været åben i 24 timer”).
  • Macros: Foruddefinerede sæt af handlinger, som agenter manuelt kan anvende på en sag med et enkelt klik for at spare tid og sikre ensartethed.

Artiklen fokuserer på triggers, da deres øjeblikkelige natur og evalueringsrækkefølge ofte er årsag til de mest komplekse udfordringer.

Den afgørende rækkefølge: Hvordan Zendesk evaluerer triggers

En central del af trigger-logik er rækkefølgen. Zendesk evaluerer ikke alle triggers; evalueringen stopper, så snart der findes et match. Dette princip er afgørende for at designe forudsigelige workflows.

Zendesk evaluerer triggers i den rækkefølge, de er listet under Admin > Business Rules > Triggers (fra top til bund). Tre grundprincipper:

  1. Første match vinder: Når en sag opfylder betingelserne (conditions) i en trigger, udføres handlingerne (actions), og evalueringen stopper. Triggers længere nede på listen bliver ikke evalueret for den pågældende sag.
  2. Rækkefølgen er afgørende: Placeringen af en trigger er derfor lige så vigtig som indholdet. Vigtige og specifikke triggers bør placeres øverst.
  3. Ingen dublet-eksekvering: En trigger kører maksimalt én gang pr. hændelse for en given sag. En trigger, der reagerer på “Ticket is Created”, kan eksempelvis kun køre én gang ved oprettelse.

Eksempel i praksis:
Forestil følgende to triggers:

  1. Trigger A (placeret øverst):
    • Condition: Ticket | Subject | Contains | "Haster"
    • Action: Ticket | Priority | High
  2. Trigger B (placeret under Trigger A):
    • Condition: Ticket | Group | Is | "Support"
    • Action: Ticket | Priority | Normal

Når en kunde med emnet “Haster: Mit system er nede” opretter en sag i “Support”-gruppen, vil kun Trigger A køre. Sagen får høj prioritet, og evalueringen stopper. Trigger B ignoreres, selvom betingelsen også er opfyldt. Hvis rækkefølgen var omvendt, ville Trigger B køre først, sætte prioriteten til “Normal”, og Trigger A ville ikke blive evalueret.

Byggestenene i logik: Condition evaluation

Betingelserne (conditions) i en trigger er de logiske tests, der afgør, om en trigger skal køre. Betingelser kan kombineres for at opnå den ønskede logik.

AND-logik (alle betingelser skal være opfyldt)

Standardlogikken er, at alle betingelser i en trigger skal være sande, før triggeren matcher.

Status | Is | Open
AND
Priority | Is | High
AND
Group | Is | Second Line Support

I eksemplet skal sagen være åben, have høj prioritet og være tildelt gruppen “Second Line Support”. Hvis én betingelse er falsk, matcher triggeren ikke.

OR-logik (mindst én betingelse skal være opfyldt)

Ved at bruge “Add another condition” og vælge “Meet ANY of the following” kan OR-logik opsættes. Her skal kun én betingelse være sand.

Tag | Is Present | "vip"
OR
Custom field: Customer Tier | Is | "Premium"
OR
Organization | Is | "Strategic Partner"

Hvis en sag enten har “vip”-tagget, er fra en “Premium”-kunde eller tilhører en “Strategic Partner”-organisation, matcher triggeren.

Kombineret logik (AND og OR sammen)

Kombination af AND- og OR-logik giver mulighed for mere præcis styring, hvor grupper af OR-betingelser samlet skal være opfyldt (AND’et sammen).

( Status | Is | Open
  OR
  Status | Is | Pending )
AND
Priority | Is | High
AND
( Tag | Is Present | "escalation_needed"
  OR
  Custom field: Urgency | Is | "Critical" )

Triggeren matcher en sag, der er enten “Open” eller “Pending”, og har “High” prioritet, og samtidig har enten tagget “escalation_needed” eller “Critical” som urgency.

Negation (NOT-logik)

Det er også muligt at teste, at en betingelse ikke er opfyldt. Dette er nyttigt til at undgå loops eller målrette specifikke scenarier.

Ticket is Updated
AND
Tag "follow_up_sent" | Is not Present

Dette sikrer, at handlingen kun køres ved en opdatering, hvis et specifikt tag ikke allerede findes.

Typiske faldgruber og løsninger

Selv erfarne Zendesk-administratorer kan opleve uventet adfærd. Nedenfor er almindelige konflikter og tilhørende løsninger.

Faldgrube 1: Flere routing-triggers i konflikt

Problem: En sag fra en VIP-kunde lander i den generelle support-kø i stedet for den dedikerede VIP-kø. Routing fremstår upålidelig og uforudsigelig.
Årsag: En generel trigger (f.eks. “Hvis form = ‘Support’ -> Route til ‘Support’”) er placeret over den specifikke VIP-trigger og matcher derfor først.
Løsning:

  • Placer specifikke triggers først: Undtagelsesregler (VIP, enterprise, escalation) placeres øverst i trigger-listen.
  • Brug mere specifikke conditions: Udvid logikken med betingelser for organisation eller et specifikt tag i stedet for kun at tjekke en form.
  • Overvej konsolidering: Flere routing-triggers kan i nogle tilfælde samles i én trigger med avanceret OR-logik.

Faldgrube 2: Prioritet bliver overskrevet

Problem: En sag får “High” prioritet af én trigger, men ændres kort efter til “Normal” af en anden.
Årsag: Flere triggers forsøger at sætte prioritet ud fra forskellig logik uden koordinering.
Løsning:

  • Centralisér prioriteringslogik: Opret én autoritativ trigger til prioritet og placer den højt i listen.
  • Brug en hierarkisk condition-struktur: Definér en rangorden, f.eks. IF Customer Tier = VIP THEN Priority = Urgent, ELSE IF Product = Critical THEN Priority = High, ELSE IF ...
  • Deaktiver redundant logik: Identificér og deaktivér triggers, der også forsøger at sætte prioritet.

Faldgrube 3: Tag-konflikter skaber kaos

Problem: Sager ender med modstridende tags som urgent og low_priority, hvilket gør views og rapporter svære at bruge.
Årsag: Forskellige triggers tilføjer tags ud fra isoleret logik uden hensyn til hinanden.
Løsning:

  • Dokumentér tag-strategi: Opret central dokumentation for betydning af tags og hvad der tilføjer dem.
  • Undgå modstridende tags: Design logik, så det ikke er muligt at tilføje både urgent og low_priority. Brug f.eks. Tag "low_priority" | Is not Present i triggeren, der tilføjer urgent.
  • Overvej Custom Fields: Ved kompleks kategorisering (kundetype, produkt, problemområde) er custom fields ofte mere robuste og skalerbare end mange tags.

Bedste praksis for robuste workflows

Følgende best practices understøtter et vedligeholdeligt Zendesk-setup.

1. Design en hierarkisk trigger-struktur

Triggers kan betragtes som en tragt: de mest specifikke og kritiske regler øverst, de mest generelle nederst.

  1. Exception Handling: VIP-routing, eskaleringer, blokering af spam.
  2. Specific Routing: Routing baseret på specifikke forms, produkter eller organisationer.
  3. General Routing: Standard routing til den primære support-gruppe.
  4. General Actions: Tilføjelse af standard-tags, opsætning af SLA’er, afsendelse af notifikationer.

2. Vær specifik først

Jo mere specifik en trigger er, desto højere bør den placeres. En trigger, der matcher på Organization = "SuperCorp", er mere specifik end en, der matcher på Form = "Support".

✅ God orden:

  1. Organization | Is | "SuperCorp VIP" → Route til VIP Team
  2. Product | Is | "Enterprise Suite" → Route til Enterprise Team
  3. Form | Is | "Support Request" → Route til General Support
  4. Ticket is Created → Route til Default Queue

❌ Dårlig orden:

  1. Form | Is | "Support Request" → Route til General Support (matcher alt)
  2. Organization | Is | "SuperCorp VIP" → Route til VIP Team (kører ikke, da #1 allerede har matchet)

3. Dokumentér alt

Triggers uden dokumentation øger risikoen for fejl og uforudsigelig adfærd. For hver kompleks trigger bør følgende dokumenteres:

  • Formål: Hvorfor triggeren findes.
  • Betingelser: Hvilke scenarier der skal matches.
  • Handlinger: Hvad der skal ske, når triggeren kører.
  • Placering: Hvorfor triggeren er placeret på den konkrete position i rækkefølgen.

4. Test edge cases grundigt

Test bør omfatte mere end “happy path”. Opret test-sager for at validere:

  • Kombinationer: Hvad sker der, hvis en VIP-kunde bruger en form for et mindre vigtigt produkt?
  • Tomme felter: Hvordan reagerer logikken, hvis et obligatorisk felt er tomt?
  • Grænseværdier: Hvad sker der præcis ved grænsen til en SLA-udløb?

5. Overvåg og justér løbende

Forretningen ændrer sig, og Zendesk-setup bør løbende tilpasses.

  • Brug Audit Log: Gå til Admin > Activity > Audit Log for at se, hvilke triggers der har kørt på en specifik sag. Dette er et centralt værktøj til fejlfinding.
  • Analyser data: Gennemgå views og rapporter for mønstre, f.eks. om flere sager end forventet ender i en forkert gruppe.
  • Iterér: Justér, deaktivér eller slet triggers, der ikke længere har et formål.

Den farlige condition: "Ticket is Updated"

Ticket is Updated er en af de mest kraftfulde, men også mest risikofyldte, conditions. Den matcher ved enhver opdatering af en sag: ny kommentar, statusændring, tilføjet tag, tildeling af agent m.m.

Uden omhu kan denne condition skabe uendelige loops.

Eksempel på et klassisk loop:

  • Trigger A:
    • Condition: Ticket is Updated
    • Action: Ticket | Add tag | "updated"
  • Resultat: Sagen opdateres → Trigger A kører → Tagget “updated” tilføjes → dette er en opdatering → Trigger A kører igen → loop.

Løsningen er at bruge negation:

  • Trigger A (rettet):
    • Condition: Ticket is Updated AND Tag "updated" | Is not Present
    • Action: Ticket | Add tag | "updated"

Triggeren kører nu kun én gang. Ved næste opdatering er betingelsen Tag "updated" | Is not Present ikke længere sand, og triggeren ignoreres.

Samarbejdet mellem triggers og automations

Triggers og automations anvendes ofte sammen i et samlet flow.

  • En trigger kan forberede en automation: En trigger tilføjer et tag som awaiting_customer_response ved oprettelse. En time senere tjekker en automation, om sagen stadig har tagget, og sender i så fald en påmindelse.
  • En automation kan udløse en trigger: En automation, der kører hver time, opdaterer en sags status til Solved efter 7 dages inaktivitet. Statusændringen kan udløse en trigger, f.eks. en trigger der sender en “satisfaction survey”.

Hele kæden af hændelser bør indtænkes ved design af workflows.

Fejlfindingsguide: Når logikken svigter

Når en sag ikke opfører sig som forventet, kan følgende fremgangsmåde anvendes:

  1. Start med Audit Log: Find sagen i Admin > Activity > Audit Log. Her vises en kronologisk liste over hændelser, herunder hvilke triggers og automations der har kørt, hvilke betingelser der matchede, og hvilke handlinger der blev udført.
  2. Brug en Sandbox: Hvis der er adgang til en Sandbox, kan ændringer testes uden at påvirke produktionsmiljøet. Opret test-sager, der matcher de scenarier, der undersøges.
  3. Følg flowet trin for trin: Gennemgå en problematisk sag og afklar:
    • Hvad skete der ved oprettelse, og hvilken trigger matchede først?
    • Er der foretaget manuelle ændringer, som påvirker logikken?
    • Har en automation kørt senere og ændret sagen?
    • Findes der en trigger længere nede, som burde have kørt, men blev blokeret?

3-sekunders reglen: Sundhedstjek for Zendesk

En praktisk tommelfingerregel:

Hvis det ikke er muligt at forklare, hvorfor en specifik sag ender i en bestemt gruppe med en bestemt prioritet og et bestemt SLA på under 3 sekunder, er setup’et for komplekst.

Reglen kan bruges som indikator for, om logikken er blevet uoverskuelig.

Røde flag (advarsel)

  • ❌ Mere end 20-25 aktive triggers.
  • ❌ Enkeltstående triggers med 10+ conditions.
  • ❌ Flere triggers udfører modstridende handlinger.
  • ❌ Manglende central dokumentation for triggers.
  • ❌ Ingen i teamet kan med sikkerhed forklare hele flowet.

Grønne flag (sundt setup)

  • ✅ Klar, dokumenteret og logisk rækkefølge for triggers.
  • ✅ Logik, der er let at forklare for nye medarbejdere.
  • ✅ Testede workflows med kendte edge cases.
  • ✅ Hurtig identifikation af, hvorfor en sag er havnet et bestemt sted.

Strategier for forenkling og vedligeholdelse

Hvis setup’et er i “rød zone”, kan følgende tiltag anvendes.

1. Konsolidér lignende triggers

Identificér triggers, der udfører samme eller lignende handlinger, og vurder om de kan kombineres.

Før:

  • Trigger 1: Form = "Bug Report" → Priority = High
  • Trigger 2: Form = "System Down" → Priority = High
  • Trigger 3: Form = "Security Issue" → Priority = High

Efter (én trigger):

  • Conditions: (Form = "Bug Report" OR Form = "System Down" OR Form = "Security Issue")
  • Action: Priority = High

Dette gør setup’et lettere at vedligeholde og mere performant.

2. Brug custom fields i stedet for komplekse tags

Tags er fleksible, men kan blive uoverskuelige. Til strukturerede data er custom fields ofte bedre.

Før (kompleks tag-logik):

  • IF tag "vip" AND tag "enterprise" THEN...
  • IF tag "premium" AND NOT tag "trial" THEN...

Efter (simpel custom field-logik):

  • IF Custom field "Customer Tier" = "VIP Enterprise" THEN...
  • IF Custom field "Customer Tier" = "Premium" THEN...

3. Gennemfør en "trigger audit"

Afsæt tid til at gennemgå alle aktive triggers og vurder hver enkelt:

  • Er triggeren stadig nødvendig?
  • Er der triggers, der er redundante?
  • Kan logikken gøres enklere?

Vejen frem: Optimer Zendesk-setup

At mestre Business Rules er en løbende proces. Ved at anvende principperne i artiklen kan et Zendesk-setup understøtte konsistent og effektiv kundeservice.

  1. Gennemgå eksisterende triggers: Er de nødvendige, og er rækkefølgen korrekt?
  2. Dokumentér logikken: Kan flowet forklares af teamet? Hvis ikke, bør dokumentation etableres.
  3. Test edge cases: Simulér uventede scenarier for at finde svagheder, før de påvirker kunder.
  4. Simplificér bevidst: Et simpelt setup er ofte et robust setup; konsolider og ryd op løbende.

Et kontrolleret og velstruktureret sæt Business Rules bidrager til konsistent, effektiv og intelligent håndtering af sager.

Relaterede artikler

Drevet af Zendesk