Gå til hovedindhold

Automations - Tidsbaserede handlinger

Opdateret

I arbejdet med at levere enestående kundeservice er evnen til at være proaktiv afgørende. Zendesk Automations er et centralt værktøj til dette formål. I modsætning til Triggers, der reagerer på øjeblikkelige hændelser, er Automations tidsbaserede regler, der udfører handlinger på et planlagt tidspunkt. De understøtter SLA-håndtering, påmindelser og opfølgning, så sager ikke overses, og kunder modtager rettidig service.

Hvad adskiller Automations fra Triggers?

For at arbejde effektivt i Zendesk er det vigtigt at forstå den grundlæggende forskel mellem disse to regeltyper. De dækker forskellige, men komplementære, behov i supportopsætningen.

Automations: Den proaktive planlægger

  • Basis: Tid. Kører baseret på foruddefinerede tidsintervaller (f.eks. "efter 24 timer", "hver time").
  • Eksekvering: Kører periodisk, typisk én gang i timen, på tværs af alle sager, der opfylder betingelserne.
  • Formål: Håndtering af situationer, der kræver opmærksomhed over tid. Velegnet til SLA-overvågning, opfølgning på inaktive sager og eskalering.
  • Forsinkelse: Indbygget forsinkelse er en del af designet.

Triggers: Den reaktive respondent

  • Basis: Begivenheder (events). Kører i det øjeblik en specifik hændelse indtræffer (f.eks. "når en sag oprettes", "når en kommentar tilføjes").
  • Eksekvering: Kører i realtid, umiddelbart efter den udløsende hændelse.
  • Formål: Automatisering af øjeblikkelige handlinger. Velegnet til velkomstmails, tildeling af sager og notifikationer ved statusændringer.
  • Forsinkelse: Umiddelbar eksekvering.
Egenskab Automations Triggers
Udløser Tid (f.eks. hver time) Hændelse (f.eks. oprettelse)
Timing Planlagt, periodisk Realtid, øjeblikkelig
Typisk brug SLA-advarsler, opfølgning Tildeling, notifikationer
Natur Proaktiv Reaktiv

Anvendelsesområder og strategiske fordele

Automations anvendes ikke kun som et teknisk værktøj, men som en central del af en supportstrategi. De gør det muligt at:

  • Sikre SLA-overholdelse: Ved automatisk at advare, før en deadline overskrides.
  • Forbedre kundeoplevelsen: Ved proaktivt at følge op og sikre, at problemer er løst til kundens tilfredshed.
  • Øge operationel effektivitet: Ved automatisk at lukke inaktive sager og rydde op i systemet, hvilket frigør tid for agenter.
  • Implementere konsistente eskaleringsprotokoller: Ved at sikre, at sager, der kræver ekstra opmærksomhed, eskaleres korrekt og rettidigt.

Gennemgang af almindelige automationsmønstre

Nedenfor er mønstre, der ofte implementeres for at optimere workflow.

1. Proaktive SLA-advarsler

Dette mønster understøtter overholdelse af serviceaftaler. Ved at advare agenten før deadline skabes mulighed for proaktiv handling.

Betingelser:
  Status er "Åben"
  OG
  Tid til Første Svar er Mindre end 1 time tilbage

Handlinger:
  Sæt Prioritet til "Høj"
  Tilføj Tag "sla-advarsel"
  Notificer "Tilordnet Agent"
  Notificer "Teamleder"

2. Automatisk opfølgning på lukkede sager

For at sikre, at en løsning reelt har afhjulpet problemet, kan der følges op nogle dage efter, at sagen er markeret som "Løst". Dette signalerer engagement i sagen.

Betingelser:
  Status er "Løst"
  OG
  Sag er opdateret
  OG
  Løsningsdato er Mere end 3 dage siden
  OG
  Anmoder har ikke svaret

Handlinger:
  Tilføj Tag "opfølgning-nødvendig"
  Notificer "Tilordnet Agent"

3. Intelligent auto-lukning af inaktive sager

For at holde systemet ryddeligt og fokusere på aktive sager kan sager lukkes automatisk, når de har været inaktive i en længere periode efter at være blevet løst.

Betingelser:
  Status er "Løst"
  OG
  Sag er opdateret
  OG
  Løsningsdato er Mere end 7 dage siden
  OG
  Anmoder har ikke svaret

Handlinger:
  Sæt Status til "Lukket"
  Tilføj Tag "auto-lukket"
  Send notifikation til anmoder om sagens lukning

4. Tidsbaseret eskalering af sager

En sag, der har været åben længe uden aktivitet, kræver ofte ekstra opmærksomhed. Denne automation understøtter, at sagen ikke overses.

Betingelser:
  Status er "Åben"
  OG
  Sag er opdateret
  OG
  Sagens alder er Mere end 24 timer
  OG
  Prioritet er ikke "Høj"

Handlinger:
  Sæt Prioritet til "Høj"
  Tilføj Tag "tids-eskalering"
  Notificer "Teamleder"

5. Håndtering af nærtstående SLA-deadlines

Når en deadline for at løse en sag nærmer sig, er hurtig handling kritisk. Denne automation hæver prioritet og informerer relevante personer.

Betingelser:
  Status er "Åben"
  OG
  Tid til Løsning er Mindre end 2 timer tilbage
  OG
  Prioritet er ikke "Kritisk"

Handlinger:
  Sæt Prioritet til "Kritisk"
  Tilføj Tag "sla-kritisk"
  Notificer "Support Manager"
  Notificer "Tilordnet Agent"

6. Periodisk statusopdatering til kunder

Ved komplekse sager med lang løsningstid kan en automation sende en statusopdatering til kunden hver 7. dag for at informere om, at sagen fortsat behandles.

Betingelser:
  Status er "Afventer"
  OG
  Tag indeholder "langvarig-sag"
  OG
  Sidst opdateret er Mere end 7 dage siden

Handlinger:
  Send intern note: "Automatisk statusopdatering sendt til kunden."
  Send e-mail til anmoder: "Vi arbejder stadig på din sag..."

Dybdegående kig på tidsbaserede betingelser

Kernen i enhver automation er tidsbetingelserne. Præcis forståelse af disse er afgørende.

Ticket Age

  • Syntaks: "Sagens alder er Mere end X timer/dage"
  • Funktion: Måler den absolutte tid, siden sagen blev oprettet.
  • Anvendelse: Velegnet til at identificere ældre sager, der er blevet stillestående.

First Reply Time

  • Syntaks: "Tid til Første Svar er Mindre end X tilbage"
  • Funktion: Reagerer på den resterende tid inden for SLA-målet for første svar.
  • Anvendelse: Central for proaktive advarsler, der understøtter overholdelse af responstid-SLA’er.

Resolution Time

  • Syntaks: "Tid til Løsning er Mindre end X tilbage"
  • Funktion: Fungerer som "First Reply Time", men for den samlede løsningstid.
  • Anvendelse: Kritisk for at sikre, at sager løses inden for aftalt tid.

Update Time

  • Syntaks: "Sag er opdateret", "Sidst opdateret er Mere end X siden"
  • Funktion: Måler tiden siden seneste aktivitet på sagen (kommentar, intern note, tildeling osv.).
  • Anvendelse: Velegnet til at identificere inaktive sager, der kræver opfølgning.

Solved Date

  • Syntaks: "Løsningsdato er Mere end X dage siden"
  • Funktion: Måler tiden fra det tidspunkt, hvor sagen blev sat til statussen "Løst".
  • Anvendelse: Anvendes primært til auto-luknings- og opfølgningslogik.

Business Hours vs. Calendar Time

Det er vigtigt at være opmærksom på, at Zendesks tidsbetingelser som standard følger konfigurerede Business Hours (åbningstid). En sag oprettet fredag kl. 16 vil ikke have en alder på 24 timer før mandag kl. 16, hvis åbningstiden er 9-17. Dette skal indgå i vurderingen ved fastlæggelse af tidsvinduer.

Væsentlige handlinger i Automations

Når betingelserne er opfyldt, udfører handlingerne det konkrete arbejde.

Status- og prioritetsstyring

  • Sæt Status til "Lukket": Rydder op i inaktive sager.
  • Sæt Prioritet til "Høj": Sikrer, at vigtige sager bliver bemærket.

Kommunikation og notifikationer

  • Notificer "Tilordnet Agent": Giver agenten et direkte "nudge".
  • Notificer "Gruppe": Informerer et helt team (f.eks. Level 2 support).
  • Tilføj kommentar: Kan efterlade en intern note til næste agent, der ser sagen.

Dataorganisering med tags og brugerdefinerede felter

  • Tilføj Tag: En alsidig handling. Tags som "auto-lukket", "sla-breach" eller "opfølgning" gør det muligt at filtrere, rapportere og analysere effekten af automations.
  • Sæt Brugerdefineret Felt: Kan bruges til at registrere specifik data, f.eks. en eskaleringsårsag.

Integration med SLA-politikker: kernen i proaktiv service

Automations og SLA-politikker hænger tæt sammen. SLA-politikker definerer målene (f.eks. "første svar inden for 8 timer"), mens Automations definerer handlingsplanen for at nå disse mål.

  1. Deadline-tracking: Automations bruger betingelser som "Tid til Første Svar er Mindre end..." til at reagere på de deadlines, som SLA-politikkerne definerer.
  2. Breach-håndtering: Når en deadline overskrides (en "breach"), kan en automation automatisk eskalere sagen, ændre prioritet og notificere ledelsen.
  3. Performance-monitorering: Ved at tilføje tags som "sla-mødt" eller "sla-overskredet" via automations kan der bygges rapporter, der viser præstation over tid.

Bedste praksis for effektive Automations

For at reducere fejl og maksimere værdien af automations kan følgende principper anvendes.

1. Vælg de rette tidsvinduer

  • SLA-advarsler: Sæt dem til at køre 1-2 timer før deadline, så der er tid til at handle.
  • Opfølgning: Vent 3-7 dage efter løsning; for hurtig opfølgning kan virke påtrængende.
  • Auto-lukning: Vent mindst 7-14 dage efter løsning for at give kunden tid til at svare.

2. Undgå overbelastning af systemet

Automations kører typisk én gang i timen og evaluerer alle sager. For korte tidsintervaller (f.eks. "Mere end 30 minutter") kan skabe unødvendig belastning og øge risikoen for at ramme grænser for antallet af handlinger.

3. Vær præcis med betingelser

En automation bør være så specifik som muligt for at undgå at køre på forkerte sager. En statusbetingelse bør altid indgå.

Status er "Åben"  ← Vigtigt for at undgå lukkede sager!
OG
Sagens alder er Mere end 24 timer

4. Brug tags til sporings- og analyseformål

Tags understøtter:

  • Sporing: Identifikation af hvilke sager, der er påvirket af en automation.
  • Undgå duplikater: Forebyggelse af gentagne handlinger ved at inkludere Tag indeholder IKKE "mit-tag" som betingelse.
  • Rapportering: Analyse af effekt og performance for automations.

5. Intelligent notifikationsstrategi

  • Undgå notifikationsstøj; send kun notifikationer, når det er nødvendigt.
  • Brug grupper frem for individuelle agenter, hvor det er muligt, for at gøre regler mere robuste ved personaleændringer.
  • Overvej differentierede notifikationer baseret på kritikalitet (f.eks. kun notifikation til leder ved "sla-kritisk").

6. Dokumentér automationslogik

For at sikre fælles forståelse af, hvad hver automation gør, og hvorfor, vedligeholdes intern dokumentation. Dette understøtter fejlfinding og fremtidig vedligeholdelse.

Fejlfinding af Automations

Selv veludformede automations kan fejle. Nedenfor er en systematisk tilgang til fejlfinding.

Problem: Automation kører slet ikke

  • Løsning:
    1. Tjek, om automationen er aktiv.
    2. Verificér, at alle betingelser er opfyldt samtidig for en given sag. Ofte er det én betingelse, der ikke matcher.
    3. Brug "Ticket Conditions" i en test-sag for at se, hvilke betingelser der er opfyldt.

Problem: Automation kører for ofte eller på forkerte sager

  • Løsning:
    1. Gør betingelserne mere specifikke ved at tilføje flere OG-betingelser for at indsnævre scope.
    2. Brug tags til at forhindre gentagne kørsler. Tilføj Tag indeholder IKKE "auto-handlet" som betingelse og Tilføj Tag "auto-handlet" som handling.

Problem: Timingen er forkert

  • Løsning:
    1. Dobbelttjek tidsbetingelserne: "Mere end" vs. "Mindre end" samt "timer" vs. "dage".
    2. Verificér Business Hours-konfigurationen. Kører automationen uden for definerede åbningstider?

Problem: Handlingerne udføres ikke korrekt

  • Løsning:
    1. Tjek, om den ønskede handling er tilladt for automations (nogle handlinger er kun tilgængelige for triggers).
    2. Ved notifikation til bruger/gruppe: Kontrollér, at modtageren er aktiv og stavet korrekt.
    3. Tjek Audit Log for at se, om reglen er eksekveret, og om der fremgår fejlmeddelelser.

Systematisk test af Automations

Automations bør ikke testes i et produktionssystem uden forudgående validering.

  1. Opret test-sager: Opret sager, der specifikt opfylder betingelserne for automationen (samt sager, der næsten gør, for at teste grænseværdier).
  2. Afvent planlagt kørsel: Automations kører periodisk, så der skal afventes næste kørsel (typisk op til en time).
  3. Verificér handlinger: Efter kørsel kontrolleres test-sagen: Er status ændret, er tag tilføjet, og er notifikation sendt?
  4. Brug Audit Log: Gå til Admin > Objects and rules > Audit log for en præcis log over, hvornår automationen kørte, hvilke sager der blev evalueret, og hvilke handlinger der blev udført.

Konklusion: Fra reaktiv til proaktiv support

Zendesk Automations er mere end et tidsbaseret værktøj; det er en strategisk mulighed for at flytte support fra reaktiv til proaktiv. Ved at opbygge robuste, præcise og velovervejede automations understøttes rettidig håndtering af kundens behov. Resultatet er højere effektivitet, bedre SLA-overholdelse og en stærkere relation til kunder. Ved at implementere mønstre og bedste praksis kan der etableres et supportsystem, der arbejder kontinuerligt.

Drevet af Zendesk