Gå til hovedindhold

Priority Calculation via Triggers

Opdateret

Automatisk beregning af prioritet via triggers er en central del af et effektivt Zendesk-setup. Ved at implementere et system, der automatisk tildeler prioritet baseret på foruddefinerede, objektive kriterier, sikres en ensartet, retfærdig og effektiv håndtering af indkommende henvendelser. Dette reducerer manuelle fejl, forkorter behandlingstiden og sikrer, at de mest kritiske sager behandles først.

Hvorfor er konsistent prioritering afgørende?

Manuel prioritering er tidskrævende og er ofte subjektiv og fejlbehæftet. Forskellige agenter kan vurdere den samme ticket forskelligt baseret på erfaring eller aktuel arbejdsbyrde. Dette kan føre til:

  • Inkonsistent kundeoplevelse: En VIP-kunde kan opleve længere ventetid end forventet, mens en mindre kritisk sag behandles først.
  • Ineffektiv ressourceallokering: Erfarne agenter bruger tid på sager af lav betydning, mens kritiske problemer afventer.
  • Manglende overblik: Uden en standardiseret skala bliver rapportering om problemtyper og fokusområder mindre meningsfuld.

Automatisk prioritering omdanner processen fra en subjektiv vurdering til en objektiv model. Det skaber et solidt fundament for service-level agreements (SLA'er), rapportering og agenternes daglige arbejde.

Forståelse af priority-niveauer

I Zendesk anvendes typisk en standardiseret skala for prioritet. Det er afgørende, at organisationen har en fælles forståelse af, hvad hvert niveau dækker.

  • Urgent: Højeste alvorlighedsgrad. Dækker kritiske problemer med markant negativ indvirkning på forretningen eller kundens drift, f.eks. totalt systemnedbrud, sikkerhedsbrist eller fejl, der forhindrer alle brugere i at tilgå en kernefunktion. Kræver øjeblikkelig opmærksomhed og eskalering.
  • High: Vigtige problemer med betydelig, men ikke katastrofal, indvirkning. Kan være fejl, der rammer en stor del af brugerbasen, eller et problem, der hindrer en enkelt bruger i at udføre en afgørende opgave. Skal håndteres hurtigt og prioriteres over standardopgaver.
  • Medium: Standardniveau for almindelige supportforespørgsler. Omfatter spørgsmål, how-to, mindre fejl med løsning eller workaround samt generelle henvendelser uden tidskritisk karakter.
  • Low: Ikke-kritiske opgaver eller forbedringsforslag. Kan være generelle forespørgsler, kosmetiske fejl eller opgaver, der kan afvente uden negativ påvirkning af kunden eller forretningen.

Metoder til automatisk priority-beregning

Flere metoder kan kombineres for at etablere et mere præcist prioriteringssystem. Nedenfor er de mest almindelige tilgange.

1. Form-baseret prioritering

En enkel metode er at basere prioritet på den form, kunden vælger ved oprettelse af ticketen. Dette er velegnet til klart adskilte kategorier.

Eksempel: Der findes en form "Critical System Outage" til rapportering af nedbrud.

Betingelse:
  Ticket er oprettet
  OG
  Form er "Critical System Outage"

Handling:
  Sæt Priority til "Urgent"
  Tilføj intern note: "Ticket prioriteret automatisk som Urgent pga. Critical System Outage-form."

2. Nøgleords-baseret prioritering

Denne metode scanner emnefeltet (subject) og beskrivelsen (description) for nøgleord, der kan indikere et kritisk problem.

Eksempel: Ord som "nedbrud", "kritisk", "haster" eller "emergency" skal identificeres.

Betingelse:
  Ticket er oprettet
  OG
  Emnefelt indeholder mindst et af følgende: "nedbrud", "kritisk", "haster", "emergency", "down"
  ELLER
  Beskrivelse indeholder mindst et af følgende: "nedbrud", "kritisk", "haster", "emergency", "down"

Handling:
  Sæt Priority til "Urgent"
  Tilføj tag: "keyword_detected"

Vigtigt: Der skal tages højde for falske positiver. Ordet "ned" kan eksempelvis optræde i andre sammenhænge. Overvej mere specifikke fraser eller regulære udtryk (regex) for at øge præcisionen.

3. Kundeklasse-baseret prioritering

Prioritet kan tildeles ud fra kundens værdi. Dette kræver et custom field på bruger- eller organisationsniveau.

Eksempel: Et custom dropdown-felt "Customer Tier" på brugere med værdierne "VIP", "Enterprise" og "Standard".

Betingelse:
  Ticket er oprettet
  OG
  Requester > Custom field "Customer Tier" er "VIP"

Handling:
  Sæt Priority til "High"

Der kan oprettes flere triggers, f.eks. en der sætter prioritet til "Medium" for "Enterprise", mens "Standard" forbliver på "Low" eller "Medium" som standard.

4. Felt-baseret prioritering: Impact og Urgency

En mere avanceret metode er at adskille impact (problemets omfang) fra urgency (tidskritikalitet). Dette er en klassisk ITIL-tilgang.

Opsætning:

  1. Opret to custom dropdown-felter til tickets: Impact (Low, Medium, High) og Urgency (Low, Medium, High).
  2. Felterne kan udfyldes af kunden via formularen eller af en agent efter en kort vurdering.
  3. Opret triggers, der kombinerer værdierne for at beregne endelig prioritet.

Eksempel:

Betingelse:
  Ticket er oprettet
  OG
  Custom field "Impact" er "High"
  OG
  Custom field "Urgency" er "High"

Handling:
  Sæt Priority til "Urgent"

5. Kombineret logik: den stærkeste tilgang

Den største effekt opnås ved at kombinere flere metoder. Regler kan eksempelvis opgradere en ticket, hvis den både kommer fra en VIP-kunde og indeholder et kritisk nøgleord.

Eksempel: En standardkunde, der skriver "nedbrud", får måske "High", mens en VIP-kunde med samme ord får "Urgent".

Betingelse:
  Ticket er oprettet
  OG
  (Requester > Custom field "Customer Tier" er "VIP" ELLER Requester > Organization > Tags indeholder "vip-account")
  OG
  (Emnefelt indeholder "nedbrud" ELLER Beskrivelse indeholder "nedbrud")

Handling:
  Sæt Priority til "Urgent"
  Tilføj tag: "vip_critical"

Prioritetsmatricen: et beslutningsværktøj

Ved brug af Impact og Urgency er en matrix et nyttigt værktøj til at definere reglerne klart og visuelt. Matricen kan danne grundlag for priority-triggers.

Impact Urgency Endelig Priority Begrundelse
High High Urgent Kritisk problem, der kræver øjeblikkelig handling.
High Medium High Stor påvirkning, men der er en vis tid at handle på.
High Low Medium Stor påvirkning, men lav tidskritikalitet.
Medium High High Mindre problem, men det haster at få det løst.
Medium Medium Medium Standard support sag.
Medium Low Low Mindre problem, der kan vente.
Low High Medium Minimal påvirkning, men kunden har brug for en hurtig løsning.
Low Medium Low Mindre problem, standard behandling.
Low Low Low Kan afventes uden negative konsekvenser.

Eskalering af priority over tid

En tickets prioritet er ikke nødvendigvis statisk. Triggers kan opsættes til automatisk at eskalere en ticket, hvis den ikke håndteres inden for en given tidsramme.

Tidsbaseret eskalering

Betingelse:
  Ticket er oprettet i mere end 24 timer
  OG
  Status er "Open", "Pending" eller "Hold"
  OG
  Priority er "Medium"

Handling:
  Sæt Priority til "High"
  Tilføj intern note: "Priority eskaleret fra Medium til High efter 24 timers inaktivitet."

SLA-drevet eskalering

SLA-målinger kan anvendes til at eskalere, før en deadline overskrides.

Betingelse:
  Ticket er oprettet
  OG
  Tid tilbage til "First reply SLA" er mindre end 30 minutter
  OG
  Priority er ikke "Urgent"

Handling:
  Sæt Priority til "Urgent"
  Tilføj tag: "sla_breach_warning"

Best practices for implementering

For at understøtte en succesfuld implementering bør følgende principper anvendes:

1. Definér objektive og målbare kriterier

Subjektive vurderinger bør undgås. Anvend data, der kan verificeres.

  • Godt: Customer Tier er "VIP", Form er "Critical Incident".
  • Dårligt: Subject "lyder stresset".

2. Dokumentér prioriteringslogikken

Et internt dokument bør beskrive:

  • Definitionen af hvert priority-niveau.
  • Alle regler og triggers, der anvendes.
  • Prioriteringsrækkefølgen for triggers (en trigger kan overskrive en anden).
  • Retningslinjer for, hvornår og hvordan en agent manuelt kan ændre prioritet.

3. Start simpelt og byg videre

Start med de mest oplagte regler (f.eks. form-baseret prioritering for nedbrud). Når systemet kører stabilt, kan mere kompleks logik tilføjes, f.eks. Impact/Urgency-matricen.

4. Gennemgå og justér regelmæssigt

En prioritetsmodel bør løbende evalueres. Planlæg kvartalsvise eller halvårlige reviews for at vurdere:

  • Om fordelingen af priorities er hensigtsmæssig (f.eks. om der oprettes for mange "Urgent" tickets).
  • Om reglerne fortsat er relevante for forretningen.
  • Om nye kundetyper eller produkter kræver nye regler.

5. Tillad manuel tilsidesættelse (med ansvar)

Agenter bør kunne tilsidesætte en automatisk tildelt prioritet, hvis konteksten kræver det. Ved ændring bør der tilføjes en intern note med begrundelse, da dette kan bruges som input til fremtidige justeringer af reglerne.

Fejlfinding og almindelige udfordringer

Selv med en gennemarbejdet opsætning kan der opstå udfordringer.

Problem: Triggeren kører, men prioriteten ændres ikke.

  • Løsning:
    1. Tjek trigger-rækkefølgen: En anden trigger, der kører efterfølgende, kan overskrive prioriteten. Triggers kører i rækkefølge fra top til bund.
    2. Verificér betingelserne: Bekræft, at betingelserne er opfyldt. Test med en reel ticket og kontrollér felter, tags, form m.m.
    3. Tjek handlingen: Bekræft, at handlingen "Set priority to..." er konfigureret korrekt.

Problem: Der oprettes for mange "Urgent" tickets.

  • Løsning:
    1. Gør betingelserne mere restriktive: Tilføj en AND-betingelse, f.eks. at ticketen både skal indeholde "nedbrud" og komme fra en VIP-kunde for at blive "Urgent".
    2. Refinér nøgleordslisten: Identificér ord, der skaber falske positiver, og erstat dem eventuelt med mere specifikke fraser.
    3. Introducer en negativ betingelse: Subject contains ... OG Subject does not contain "spørgsmål om nedbrud".

Problem: Prioriteten er inkonsistent mellem forskellige ticket-typer.

  • Løsning: Sikr, at der findes dækkende triggers for alle former. Hvis en form ikke indgår i nogen priority-triggers, beholder ticketen standardprioriteten, hvilket kan skabe inkonsistens.

Implementeringsplan: næste skridt

Udrulning af et automatisk prioriteringssystem kræver en struktureret tilgang. Følgende trin kan anvendes:

  1. Fase 1: Analyse og design

    • Afhold workshop med nøglepersoner fra support, product og management.
    • Definér priority-niveauer (Urgent, High osv.) og deres betydning.
    • Beslut hvilke kriterier (form, nøgleord, kundeklasse, felter) der skal anvendes.
    • Udarbejd prioritetsmatrixen og dokumentér den samlede logik.

  2. Fase 2: Teknisk opsætning

    • Opret nødvendige custom fields (f.eks. Customer Tier, Impact, Urgency).
    • Byg triggers én ad gangen. Start med de enkleste og tilføj gradvist mere kompleks logik.
    • Navngiv triggers tydeligt, så de er lette at administrere (f.eks. "Priority: Urgent for VIP + Critical Keyword").

  3. Fase 3: Test og validering

    • Opret test-tickets for alle scenarier og verificér, at korrekt prioritet tildeles hver gang.
    • Lad udvalgte agenter anvende systemet i en pilotperiode og indsamle feedback.

  4. Fase 4: Udrulning og træning

    • Rul systemet ud til alle agenter.
    • Afhold et træningsmøde, hvor logikken gennemgås, dokumentationen præsenteres, og rammerne for manuel tilsidesættelse forklares.

  5. Fase 5: Monitorering og optimering

    • Opret Views i Zendesk, der grupperer tickets efter prioritet, så agenter og ledere hurtigt kan danne overblik.
    • Byg rapporter, der følger fordelingen af priorities over tid og sammenligner med SLA-overholdelse.
    • Planlæg første review-møde med henblik på justering og optimering baseret på reelle data.

Relaterede artikler

Drevet af Zendesk