On-hold workflow

Dette workflow er en central del af supportprocessen i Zendesk. Formålet er at sikre, at ingen sager risikerer at blive overset, når de midlertidigt sættes på hold. Ved at kombinere øjeblikkelige reaktioner fra triggers med tidsstyrede handlinger fra automations etableres et intelligent og selvkørende system. Systemet sikrer, at en sag enten genåbnes, når der forventes en opdatering, eller automatisk returneres til køen som en sikkerhedsforanstaltning, hvis en forfaldsdato er blevet overset.

Formålet med et On-Hold Workflow

At sætte en sag på status On-hold er en nødvendig del af supportarbejdet. Der kan afventes svar fra en kunde, en tredjepartsleverandør eller en intern afklaring. Uden et struktureret workflow er der risiko for, at sager forsvinder i mængden. On-hold workflowet er designet til at reducere denne risiko og skabe forudsigelighed. Workflowet sikrer, at:

• Kunder ikke oplever unødig ventetid: Sager følges proaktivt op.
• Ingen sager falder mellem stolene: Et 7-dages sikkerhedsnet fanger sager uden forfaldsdato.
• Agenter sparer tid: Manuelle opfølgninger minimeres, og fokus kan holdes på aktive sager.
• Høj servicekvalitet opretholdes: Systematisk håndtering af ventetid styrker kundetilliden.

Workflowets arkitektur: Triggers og Automations

On-hold workflowet er bygget op omkring en synergi mellem fire kernekomponenter, der tilsammen sikrer overblik:

• 2 Triggers: Reaktive komponenter, der handler øjeblikkeligt, når en agent foretager en specifik ændring i en sag.
• 2 Automations: Proaktive komponenter, der kører med jævne mellemrum og udfører tidsbaserede handlinger baseret på specifikke betingelser.

Samlet skaber komponenterne et dynamisk system, der tilpasser sig agentens handlinger og sikrer, at sagen altid har en planlagt vej tilbage til den aktive kø.

Komponenter i detaljer

Nedenfor gennemgås hver komponent og dens rolle i workflowet.

De reaktive komponenter: Triggers

Triggers aktiveres i det øjeblik, en betingelse er opfyldt, og udfører straks en række handlinger.

Trigger 1: Sikkerhedsnettet – identifikation af sager uden forfaldsdato

Denne trigger fungerer som det primære sikkerhedsnet. Den aktiveres, når en agent sætter en sag på status On-hold uden at angive en forfaldsdato.

• Betingelse: Status ændres til On-hold OG Forfaldsdato er Ikke sat.
• Handling: Tilføj tagget due_date_is_not_set.

Formål: Tagget markerer systematisk sagen som en sag uden konkret genopfølgningsdato. Tagget fungerer som signal til 7-dages automationen, som kan genkende og handle på det. Dette reducerer risikoen for, at en sag overses, fordi en forfaldsdato ikke er angivet.

Trigger 2: Den dynamiske justering – fjernelse af sikkerhedsnettet

Denne trigger sikrer, at systemet forbliver tilpasningsdygtigt. Den aktiveres, hvis en agent efterfølgende tilføjer en forfaldsdato til en sag, der allerede er på hold.

• Betingelse: Status er On-hold OG Forfaldsdato bliver sat.
• Handling: Fjern tagget due_date_is_not_set.

Formål: Når en forfaldsdato er angivet, er 7-dages fallback-mekanismen ikke længere nødvendig for den pågældende sag. Ved at fjerne tagget undgås det, at 7-dages automationen genåbner sagen på et forkert tidspunkt. Den specifikke forfaldsdato får dermed førsteprioritet.

De proaktive komponenter: Automations

Automations kører med jævne mellemrum (typisk hver time) og scanner sager for at identificere, om betingelserne er opfyldt.

Automation 1: Præcis genåbning – opfølgning på specifikke forfaldsdatoer

Denne automation håndterer sager, hvor der er en konkret forventning til opfølgningstidspunkt. Den er designet til at genåbne sagen kl. 08:00 på den angivne forfaldsdato, så sagen er klar i køen ved arbejdsdagens start.

• Betingelser:
  • Status er On-hold
  • Forfaldsdato er mindre end 8 timer siden (> -8 hours)
• Handlinger:
  • Status til Open
  • (Valgfrit men anbefalet): Tilføj en intern note som "Genåbnet automatisk pga. forfaldsdato."

Vigtig teknisk forklaring: Zendesk behandler en forfaldsdato uden et specifikt klokkeslæt som kl. 12:00 på den pågældende dag. Betingelsen > -8 timer betyder, at automationen kører, når der er inden for de sidste 8 timer før forfaldsdatoens kl. 12:00. Dette sikrer, at automationen aktiveres én gang om morgenen (ca. kl. 04:00 og frem) på selve forfaldsdatoen, så sagen er klar i køen, når arbejdsdagen starter kl. 08:00.
Bemærk: Denne automation skal konfigureres til at køre mindst en gang i timen for at fungere optimalt.

Automation 2: Den ultimative failsafe – genåbning efter 7 dage

Dette er den sidste forsvarslinje for sager, der er sat på hold uden en tydelig tidsramme. Den sikrer, at ingen sag kan ligge i dvale i mere end en uge.

• Betingelser:
  • Status er On-hold
  • Indeholder mindst et af følgende tags: due_date_is_not_set
  • Sag er opdateret mindre end 168 timer siden (> 168)
• Handlinger:
  • Status til Open
  • (Valgfrit men anbefalet): Tilføj en intern note som "Genåbnet automatisk efter 7 dage på hold."

Formål: Hvis en sag har været på hold i 7 dage (168 timer) uden at der er sat en forfaldsdato, antages det, at sagen kan være overset, eller at ventetiden er blevet unødvendigt lang. Automationen bringer sagen tilbage til den aktive kø, så en agent kan vurdere status, kontakte kunden eller eskalere sagen.

Anvendelse i praksis: Scenarier og anbefalinger

Korrekt anvendelse af workflowet kræver forståelse for, hvornår de forskellige mekanismer skal anvendes.

Hvornår skal en specifik forfaldsdato bruges?

En forfaldsdato bør anvendes, når der findes et estimat for, hvornår en opdatering kan forventes. Dette skaber præcision og forudsigelighed.

• Scenario 1: Venter på information fra kunden
  En kunde har rapporteret en fejl, men der mangler logfiler for at kunne diagnosticere problemet. Agenten sætter sagen på hold med en intern note: "Venter på logfiler fra kunden. Forventer modtaget i morgen formiddag." og sætter forfaldsdatoen til i morgen kl. 09:00.
• Scenario 2: Venter på en 3. parts leverandør
  En sag er eskaleret til en teknisk partner. Partneren har bekræftet, at sagen undersøges, og har lovet svar inden for 3 hverdage. Agenten sætter sagen på hold med en intern note: "Eskaleret til [Partner]. Venter på feedback." og sætter forfaldsdatoen til 3 hverdage frem.
• Scenario 3: Planlagt opgave eller release
  Der afventes en systemopdatering, som implementeres næste tirsdag nat for at løse en kendt fejl. Agenten sætter sagen på hold med en intern note: "Venter på release af version X.X, som løser problemet." og sætter forfaldsdatoen til onsdag morgen.

Hvornår bør en forfaldsdato undlades?

7-dages reglen anvendes som fallback, når tidshorisonten er usikker, og et estimat vil være misvisende.

• Scenario 1: Uafklaret og sjældent problem
  En kunde rapporterer en fejl, som ikke kan genskabes, og det er den første rapport af sin art. Der afventes, om flere kunder bliver ramt, før sagen kan eskaleres til udvikling. En forfaldsdato vurderes her som meningsløs, og 7-dages automationen håndterer sagen.
• Scenario 2: Venter på intern afklaring om fremtidig feature
  En kunde spørger til en feature, der ikke er på roadmappen. Produktteamet er spurgt, men der foreligger endnu ikke et svar. Sagen sættes på hold uden forfaldsdato, og automationen sikrer opfølgning efter en uge.

Best practices for effektiv sagshåndtering

• Skriv altid en klar intern note: Når en sag sættes på hold, bør der tilføjes en kort og præcis intern note om, hvorfor sagen er på hold, og hvad der afventes. Dette er vigtigt både for den ansvarlige agent og for andre agenter, der senere kan overtage sagen.
• Foretræk specifikke datoer: Selvom 7-dages reglen fungerer som sikkerhedsnet, er en konkret forfaldsdato typisk bedre, da det giver mere forudsigelighed og en bedre kundeoplevelse.
• Opdater forfaldsdatoen proaktivt: Hvis ventetiden bliver længere end forventet, bør forfaldsdatoen opdateres, så sagen ikke genåbnes for tidligt. Det er bedre at justere datoen én gang end at genåbne og sætte sagen på hold igen.
• Gennemgå jævnligt On-Hold-køen: Selvom workflowet er automatiseret, kan en ugentlig gennemgang af On-Hold-køen af en teamleder eller senior agent identificere unødvendigt lange ventetider eller sager, hvor en mere passende forfaldsdato kunne være sat.

Fejlfinding og ofte stillede spørgsmål (FAQ)

Spørgsmål: Hvorfor blev sagen ikke genåbnet kl. 08:00 på forfaldsdatoen?
Svar: Kontroller først, om automationen kører som forventet (typisk mindst en gang i timen). Verificer derefter, at sagens status stadig var On-hold, og at forfaldsdatoen var korrekt angivet. Automationen aktiveres, når betingelsen > -8 timer opfyldes, hvilket sker i løbet af morgenen på forfaldsdatoen. Hvis automationen kører kl. 04:00, vil sagen blive genåbnet og være klar i køen kl. 08:00.

Spørgsmål: Hvad sker der, hvis der sættes en forfaldsdato på en sag, der allerede har været på hold i 5 dage?
Svar: Workflowet er designet til at håndtere dette. Når forfaldsdatoen sættes, fjerner Trigger 2 tagget due_date_is_not_set. Dette annullerer 7-dages automationen for den pågældende sag. Sagen genåbnes i stedet på den nye, specifikke forfaldsdato.

Spørgsmål: Sagen blev genåbnet, selvom den netop blev sat på hold. Hvorfor?
Svar: Dette kan ske, hvis sagen sættes på hold med en forfaldsdato, der allerede er overskredet, eller som ligger meget tæt på det aktuelle tidspunkt (inden for 8 timer før kl. 12:00). I så fald opfylder automationsbetingelsen > -8 timer straks kriterierne, og sagen genåbnes. Forfaldsdatoen bør altid sættes til et tidspunkt i fremtiden.

Spørgsmål: Hvad sker der, hvis en kunde svarer på en sag, der er på hold?
Svar: Når en kunde svarer, ændres sagens status automatisk til Open via Zendesks standardfunktion, og sagen vises i den aktive kø. On-hold workflowet bliver i den situation overflødigt, da kundens kommentar er den primære årsag til genåbning. Dette sikrer, at kundehenvendelser håndteres hurtigt.

Ved at implementere og følge dette workflow understøttes en høj og konsistent servicekvalitet, risikoen for glemte sager reduceres, og en effektiv og struktureret supportfunktion opretholdes. Workflowet fungerer som et system, der understøtter løbende opfølgning og prioritering af sager.