Triggers - Real-time automation

Triggers er kraftfulde, hændelsesdrevne automatiseringer, der udføres i realtid, når specifikke betingelser er opfyldt. De fungerer som et centralt element i et Zendesk-setup og udgør fundamentet for effektiv ticket-håndtering, intelligent routing og en strømlinet kundeoplevelse. Ved at anvende triggers kan repetitive opgaver automatiseres, ensartet behandling af henvendelser sikres, og tid frigøres til, at supportteamet kan fokusere på komplekse problemstillinger og kundeinteraktion.

Hvad er Triggers?

En trigger er en "hvis-så"-regel, der overvåger tickets i realtid. Når en bestemt hændelse indtræffer, og de definerede betingelser er opfyldt, udfører triggeren automatisk en række foruddefinerede handlinger. Triggers er designet til at reagere øjeblikkeligt på ændringer og sikre, at den rette handling sker på det rette tidspunkt.

Triggers kan reagere på en lang række hændelser, herunder:

• Ticket oprettelse: En ny ticket modtages via e-mail, webformular, API osv.
• Statusændringer: En tickets status ændres (f.eks. fra "Åben" til "Løst").
• Field opdateringer: Et felt i ticketen opdateres, f.eks. prioritet, gruppe eller et brugerdefineret felt.
• Tag tilføjelser eller fjernelser: Et tag tilføjes eller fjernes fra en ticket.
• Requester ændringer: Personen, der har oprettet ticketen, ændres.
• Kommentarer eller opdateringer: En intern note eller en offentlig kommentar tilføjes.

Triggers vs. Automations: Den afgørende forskel

I Zendesk findes to primære automatiseringsværktøjer: Triggers og Automations. Forståelse af forskellen er afgørende for at opbygge et effektivt workflow. Den primære forskel er, hvornår de kører.

Egenskab	Triggers	Automations
Udløser	Hændelser (Events)	Tid (Time)
Eksekvering	Realtid (øjeblikkeligt)	Planlagt (f.eks. hver time)
Formål	Øjeblikkelig reaktion på ændringer	Opfølgende handlinger baseret på tidsforløb

Kort sagt:

• Triggers reagerer på, hvad der sker nu. De fungerer som førstelinje-automatisering.
• Automations reagerer på, hvad der ikke er sket inden for en tidsramme. De fungerer som opfølgningsmekanisme.

Anatomien af en Trigger: Betingelser, handlinger og rækkefølge

En trigger består af tre centrale komponenter, der tilsammen definerer logik og funktion.

1. Betingelser (Conditions): "Hvornår skal der handles?"

Betingelserne er kriterierne, der skal være opfyldt, for at triggeren aktiveres. "AND" og "OR"-logik kan anvendes til at opbygge alt fra simple til meget komplekse regler.

Eksempler på betingelser:

• Ticket is Created
• Status is Changed to "Solved"
• Custom Field "Priority" is "High"
• Tag "escalation" is Present
• Group is "Billing Team"

Jo mere specifikke betingelserne er, desto mere præcis og forudsigelig bliver triggerens adfærd.

2. Handlinger (Actions): "Hvad skal der ske?"

Når alle betingelser er opfyldt, udfører triggeren en eller flere handlinger. Handlingerne er de ønskede resultater – f.eks. tildeling af en ticket, afsendelse af en notifikation eller opdatering af et felt.

Eksempler på handlinger:

• Set Group to "Enterprise Support"
• Set Priority to "Urgent"
• Add Tag "escalation"
• Notify user "Support Manager"
• Set Custom Field "Escalated" to "Yes"

En enkelt trigger kan udføre flere handlinger samtidigt.

3. Rækkefølge (Order): "Hvem vinder?"

Zendesk evaluerer triggers i en fast rækkefølge fra top til bund i listen over aktive triggers. Dette er et centralt koncept. Når en tickets betingelser matcher en trigger, udføres dens handlinger, og evalueringen stopper. Det betyder, at "første match vinder". Hvis en ticket kan matche flere triggers, er det den øverste i listen, der afvikles.

Gennemprøvede trigger-mønstre til workflow

Nedenfor er nogle almindelige og effektive mønstre til at strukturere supportprocesser.

1. Indledende routing

Sikrer, at nye tickets straks sendes til det rette team baseret på oplysninger i henvendelsen.

Condition:
  Ticket is Created
  AND
  Form is "Enterprise Support"

Action:
  Set Group to "Enterprise Support"
  Set Priority to "High"
  Add Tag "enterprise"

2. Eskalering

Håndterer tickets, der kræver særlig opmærksomhed, f.eks. når de ikke er blevet besvaret inden for en given tidsramme.

Condition:
  Status is "Open"
  AND
  Ticket is Updated
  AND
  First reply time is More than 4 hours

Action:
  Set Priority to "Urgent"
  Add Tag "escalation"
  Notify user "Support Manager"

3. Statushåndtering

Automatiserer statusændringer for at holde workflowet i gang og sikre, at alle trin følges.

Condition:
  Status is Changed to "Solved"
  AND
  Requester is Present

Action:
  Add Tag "awaiting-feedback"
  Set Custom Field "Solved Date" to Current time

4. Routing baseret på tags

Anvender tags, der tilføjes manuelt eller af andre systemer, til at styre routing og prioritering.

Condition:
  Tag "billing" is Added
  AND
  Status is "New"

Action:
  Set Group to "Billing Team"
  Set Priority to "Medium"

5. Logik baseret på brugerdefinerede felter

Udfører handlinger baseret på data indsamlet via webformularer eller andre integrationspunkter.

Condition:
  Custom Field "Order Type" is "Return"
  AND
  Ticket is Created

Action:
  Set Group to "Returns Team"
  Set Custom Field "Return Deadline" to "7 days from now"

6. Automatisk bekræftelse og svar

Sender en øjeblikkelig bekræftelse til kunden, så det er tydeligt, at henvendelsen er modtaget.

Condition:
  Ticket is Created
  AND
  Channel is "Email"
  AND
  Comment is Public

Action:
  Email user "Requester" with template "Initial Confirmation"

Best practices: Robuste og effektive triggers

For at undgå fejl og sikre et stabilt system kan følgende best practices anvendes ved opbygning og vedligeholdelse af triggers.

1. Vær specifik i betingelser

Jo mere specifikke betingelserne er, desto mindre er risikoen for, at triggeren udløses utilsigtet.

✅ God praksis:

Ticket is Created
AND
Form is "Support"
AND
Custom Field "Product" is "Enterprise"

❌ Dårlig praksis:

Ticket is Created

2. Forstå rækkefølgen

Da "første match vinder", er trigger-rækkefølgen afgørende. De mest specifikke og kritiske triggers (f.eks. VIP-routing) placeres øverst i listen før mere generelle triggers.

3. Test grundigt og systematisk

En trigger, der ikke er testet tilstrækkeligt, kan skabe uforudsete konsekvenser. Test kan omfatte:

• Nye tickets: Simulering af en kundes første henvendelse.
• Opdaterede tickets: Test af reaktion på ændringer.
• Forskellige feltkombinationer: Verifikation af logik på tværs af scenarier.
• Edge cases: Håndtering af tomme felter eller manglende brugerdata.

4. Brug tags strategisk

Tags er et fleksibelt værktøj og kan anvendes til:

• Sporing: Markering af tickets som "escalated", "vip" eller "needs-follow-up".
• Routing: Anvendelse af tags som "billing", "technical" eller "sales" til at styre flow.
• Rapportering: Gruppering af tickets i dashboards til trendanalyse (f.eks. "first-contact-resolution").

5. Undgå konflikter

Det er vigtigt at sikre, at triggers ikke modarbejder hinanden. Det kan indebære:

• Grundig gennemgang af trigger-rækkefølgen.
• Undgåelse af modstridende handlinger på tværs af triggers.
• Dokumentation af logikken bag komplekse triggers, så den er forståelig for hele teamet.

6. Dokumentér logikken

Formål og baggrund for en trigger bør fremgå tydeligt. Interne noter eller separat dokumentation kan sikre, at viden bevares, og at fremtidige justeringer træffes på et oplyst grundlag.

Trigger-rækkefølge: Prioritering i praksis

Vigtigheden af rækkefølge kan illustreres med følgende eksempel, hvor to triggers findes:

Trigger A (placeret øverst):

Condition: Ticket is Created AND Tag "vip" is present
Action: Set Priority to "High"

Trigger B (placeret under Trigger A):

Condition: Ticket is Created
Action: Set Priority to "Normal"

Hvis en VIP-kunde opretter en ticket, matcher Trigger A først og sætter prioriteten til "High". Evalueringen stopper derefter, og Trigger B afvikles ikke. Hvis rækkefølgen byttes, vil alle tickets få prioriteten "Normal" (inklusive VIP-tickets), fordi Trigger B matcher først. Dette viser, hvor kritisk placeringen er.

Avanceret betingelseslogik: AND vs. OR

Logik kan kombineres for at opbygge præcise regler.

AND: Alle betingelser i gruppen skal være opfyldt.

Status is "Open"
AND
Priority is "High"
AND
Group is "Support"

Resultat: Triggeren kører kun for åbne, højprioritets tickets i Support-gruppen.

OR: Mindst én af betingelserne i gruppen skal være opfyldt.

Tag "vip" is Present
OR
Custom Field "Customer Tier" is "Premium"

Resultat: Triggeren kører for tickets, der enten har "vip"-tagget ELLER hvor kunden er "Premium".

Logik kan også kombineres: (Ticket is Created AND Form is "Technical") OR Tag "urgent" is Present.

Overblik over almindelige handlinger

Handlinger er værktøjer til at forme ticketens livscyklus.

Routing og tildeling

• Set Group: Sender ticketen til en specifik afdeling.
• Assign to User: Tildeler ticketen til en specifik agent.
• Assign to Group: Tildeler ticketen til en vilkårlig agent i en gruppe.

Status og prioritet

• Set Status: Ændrer status (f.eks. til "Pending", "Solved", "Closed").
• Set Priority: Sætter prioriteten (f.eks. "Low", "Normal", "High", "Urgent").
• Set Type: Kategoriserer ticketen (f.eks. "Question", "Incident", "Problem").

Data og tags

• Set Custom Field: Opdaterer et brugerdefineret felt med en specifik værdi.
• Add Tag: Tilføjer et eller flere tags til ticketen.
• Remove Tag: Fjerner et specifikt tag.

Notifikationer og kommunikation

• Notify User: Sender en notifikation i Zendesk til en specifik bruger eller gruppe.
• Email User: Sender en e-mail til en hvilken som helst e-mailadresse, ofte anvendt til notifikationer uden for Zendesk.
• CC's and Followers: Administrerer, hvem der følger ticketen.

Forms og SLA'er

• Set Form: Skifter den formular, der er knyttet til ticketen.
• Set SLA Policy: Anvender en specifik Service Level Agreement-politik på ticketen.

Fejlfinding: Når triggers ikke opfører sig som forventet

Selv veldesignede triggers kan give uventede resultater. Nedenfor er en guide til fejlfinding.

Problem: Triggeren kører slet ikke.

• Løsning:
  1. Tjek betingelserne: Er alle betingelser opfyldt? En enkelt afvigelse kan forhindre afvikling.
  2. Tjek trigger-rækkefølgen: Bliver triggeren overstyret af en trigger højere i listen? Brug linket "Why was this ticket updated?" på ticketen for at se, hvilken trigger der sidst har kørt.
  3. Tjek, om den er aktiv: Er triggeren slået til?

Problem: Tickets bliver routet til det forkerte team.

• Løsning:
  1. Verificér rækkefølgen: Ligger der en mere generel trigger ovenover, som "overtager" ticketen?
  2. Test betingelserne: Opret en test-ticket, der matcher de forventede betingelser, og observer resultatet.
  3. Tjek for modstridende handlinger: Kører en anden trigger efterfølgende og ændrer gruppen igen?

Problem: En trigger kører for ofte eller på forkerte tickets.

• Løsning:
  1. Gør betingelserne mere specifikke: Tilføj flere "AND"-betingelser for at indsnævre omfanget.
  2. Overvej hændelsen: Skal triggeren køre ved Ticket is Created eller Ticket is Updated? Updated kan i nogle tilfælde være for bred.

Systematisk testning: Sikring af kvalitet i automatiseringer

En fast testproces kan anvendes for at sikre, at nye triggers ikke introducerer fejl i eksisterende workflow.

1. Opret dedikerede test-tickets: Brug en test-konto eller opret tickets med specifikke data til at udløse triggeren.
2. Verificér alle handlinger: Gennemgå ticketen efter triggeren er kørt. Er gruppen korrekt? Er tags tilføjet? Er notifikationer sendt?
3. Test edge cases: Hvad sker der, hvis et obligatorisk felt er tomt? Hvad hvis en agent manuelt ændrer noget kort efter oprettelse?
4. Udfør regressionstest: Sikr, at den nye trigger ikke påvirker eksisterende triggers. Test almindelige scenarier for at bekræfte, at de fortsat fungerer som forventet.
5. Monitor i live: Efter lancering kan triggeren overvåges via audit loggen for at identificere uforudsete problemer i et reelt miljø.

Konklusion: Fra reaktiv til proaktiv support

Triggers er mere end simple regler; de er byggesten i en intelligent, effektiv og skalerbar supportorganisation. Ved at designe, teste og optimere triggers kan supporten bevæge sig fra reaktiv til proaktiv. Det understøtter konsistens, reducerer manuelle fejl og giver agenter bedre forudsætninger for at levere høj kundeservice. Løbende forbedring af trigger-logik er en central del af arbejdet med at levere hurtigere og mere relevant hjælp til kunder.