Admin Pro Tip: Business Hours og Schedules - Realiteten vs. Teorien

I teorien er opsætning af Business Hours og Schedules i Zendesk ligetil. Der defineres, hvornår organisationen arbejder, og Zendesk beregner, hvornår en ticket skal besvares for at overholde sin SLA. I praksis er dette et af de mest misforståede og fejlbehæftede områder i Zendesk-administration. Et forkert opsat schedule kan i bedste fald give forvirrende SLA-tider og i værste fald påvirke serviceaftaler og kundetillid.
Der ses ofte schedules, der ikke er blevet opdateret i årevis, teams der udfordres af tidszoner, samt situationer hvor en helligdag indtræffer uden opdatering af systemet. Artiklen samler erfaringer, praktiske løsninger og pro-tips til at få schedules til at afspejle den faktiske drift frem for en teoretisk idealtilstand.

Fundamentet: Hvorfor Schedules er meget mere end en kalender

Før gennemgang af faldgruberne er det afgørende at forstå, hvad et schedule gør i Zendesk. Et schedule er ikke blot en note om åbningstider. Et schedule fungerer som motoren bag SLA-beregninger og angiver, hvornår “uret tikker” på en ticket, og hvornår det er sat på pause.

Når en ticket oprettes uden for definerede Business Hours, starter SLA-beregningen først, når næste Business Hour begynder. Det samme gælder for pauser mellem dage. En SLA på 8 timer med åbent 9-17 betyder ikke 8 kalendertimer, men 8 business hours. Det er en afgørende forskel.

Denne motor er koblet til tre centrale steder i Zendesk:

1. SLA Policies: Her defineres servicemål (f.eks. Første svarstid, Næste svarstid, Opklaringstid). Hver policy tilknyttes et schedule.
2. Views: Her kan tickets filtreres baseret på, om SLA er overholdt eller i risiko for at blive overtrådt, baseret på deres schedule.
3. Automations og Triggers: Her kan logik bygges, der reagerer på, om en ticket er i risiko, eller hvis SLA er blevet overtrådt.

Fejl i schedule-opsætningen forplanter sig derfor gennem hele support-setup’et og kan skabe en kædereaktion af unøjagtige data, forkerte alarmer og i sidste ende en dårlig kundeoplevelse.

Almindelige fejl i schedule-opsætning – faldgruberne mange møder

Der findes en række klassiske fejl, som ofte opstår i schedule-opsætning. Ved at kende dem kan de mest almindelige og omkostningsfulde fejl undgås.

Fejl #1: “Set and forget”-syndromet

Dette er en af de mest udbredte fejl. Der bruges tid på at opsætte schedules, hvorefter de ikke vedligeholdes. Drift ændrer sig: åbningstider justeres, helligdage ændres, og teams udvides eller reduceres.

• Hvordan det ser ud: Et primært schedule er oprettet i 2019 og er ikke blevet opdateret siden. Et helligdags-schedule indeholder stadig “Store Bededag”, selvom den er afskaffet.
• Hvorfor det er et problem: SLA-beregninger bliver gradvist mere unøjagtige. En ticket oprettet onsdag aften kan få en forkert forsinkelse, hvis åbningstiderne er ændret. Det underminerer tilliden til data.
• Løsningen: Gør schedule-review til en fast del af en kvartalsvis eller halvårlig Zendesk-audit. Opret en tilbagevendende opgave i et projektstyringsværktøj (Asana, Trello, Jira) med en gentagende deadline: “Review og opdater Zendesk Schedules”.

Fejl #2: Forveksling af “Business Hours” og “Agent Schedule”

Zendesk har to koncepter, der ofte forveksles: Schedules (under Admin > Business Hours) og Agent Schedules (under Admin > People > Schedules). De har forskellige formål.

• Business Hours Schedule: Definerer, hvornår organisationen er åben for at levere support. Dette er motoren, der driver SLA’er.

• Agent Schedule: Bruges primært til at se, hvem der er på vagt, og til at tildele tickets baseret på, om en agent er “online” eller “offline” i en given periode. Dette har ingen direkte indflydelse på SLA-beregninger.

• Hvordan det ser ud: Der forsøges styring via Agent Schedules, og der opstår forvirring over, at SLA’er fortsat kører, selvom ingen agenter er “online”.

• Hvorfor det er et problem: Tid bruges på at konfigurere det forkerte værktøj. SLA-motoren (Business Hours Schedule) kører uafhængigt af vagtplaner.

• Løsningen: Hold koncepterne adskilt. Brug Business Hours Schedules til at definere serviceløfter over for kunder. Brug Agent Schedules til operationel planlægning og vagtplanlægning. De kan understøtte hinanden, men er ikke det samme.

Fejl #3: Ignorering af tidszone-kompleksitet

Selv for et enkelt team i én tidszone er tidszoneindstillingen kritisk. Zendesk beregner alt baseret på den tidszone, som schedule er sat til.

• Hvordan det ser ud: Et team i København (GMT+1/GMT+2) har et primært schedule sat til “Pacific Time (PT)”.
• Hvorfor det er et problem: Åbent 9-17 forstås som 9-17 PT, hvilket svarer til 18-02 dansk tid. Tickets oprettet om morgenen i Danmark kan blive behandlet som oprettet “uden for åbningstid”, og SLA starter først mange timer senere.
• Løsningen: Vælg korrekt tidszone ved oprettelse af schedule, og dobbelttjek indstillingen. En praktisk tommelfingerregel er at navngive schedules med tidszone, f.eks. “Support DK - CET (GMT+1)”.

Fejl #4: Overlap, gaps og “forældreløse” tickets

Dette er en subtil, men risikabel fejl, især ved flere skift eller dækning på tværs af tidszoner.

• Hvordan det ser ud: Morgenskift 8-16 og aftenskift 16-24 er sat som 8-16 og 16:01-24, eller 8-15 og 16-24.
• Hvorfor det er et problem: Et hul (f.eks. mellem 15:59 og 16:01 eller mellem 15 og 16) betyder, at Zendesk anser organisationen for lukket i perioden. En ticket oprettet i dette tidsrum får forsinket SLA-start, selvom der reelt er bemanding. Det giver unøjagtige rapporter og kan få en ticket til at fremstå som overtrådt.
• Løsningen: Sørg for, at intervaller flugter præcist. For døgnåbent schedule: f.eks. 00:00 - 23:59. For skift: f.eks. 08:00 - 16:00 og 16:00 - 00:00. Ingen huller og ingen overlap.

Håndtering af ferie og sygdom – SLA’ernes fjende nummer ét

Uforudset fravær eller en glemt helligdag kan hurtigt påvirke SLA-overblik. Nedenstående tilgang hjælper med at bevare kontrol uden panik.

Den forkerte måde: Manuel ændring af primære schedules

En typisk reaktion er at ændre åbningstider direkte i det primære schedule for en helligdag, f.eks. “Juleaften er der kun åbent til 12”.

• Hvorfor det er en katastrofe: Metoden er fejlbehæftet. Det er let at glemme at ændre tilbage. Det skaber historik i det primære schedule og gør det sværere at se “normalen”. Ved flere schedules skal alle ændres. Løsningen er hverken skalerbar eller sikker.

Den rette måde: Brug af Holiday Schedules

Zendesk understøtter Holiday Schedules. Et holiday schedule er et separat schedule med specifikke datoer og tidspunkter, hvor der er lukket eller reduceret åbningstid.

Fremgangsmåde:

1. Opret et Holiday Schedule: Gå til Admin > Business Hours > Holiday Schedules. Opret et nyt schedule, f.eks. “Helligdage DK 2024”.
2. Definer helligdagene: Tilføj alle danske helligdage for året. Ved fuld lukning tilføjes datoen med et interval, der dækker hele dagen (f.eks. 00:00 - 23:59).
3. Håndtering af “halve dage”: For juleaften eller nytårsaftensdag med reduceret åbningstid kan to perioder anvendes:
   • En periode for normal åbningstid (f.eks. 09:00 - 12:00).
   • En periode for resten af dagen som “lukket” (f.eks. 12:01 - 23:59).
     Dette angiver, at SLA’er kun kører i tidsrummet 9-12 den dag.
4. Tilknyt Holiday Schedule til SLA Policies: Gå ind i hver SLA Policy og vælg relevant holiday schedule under “Holidays”. Zendesk tager herefter automatisk højde for helligdage i SLA-beregninger for tickets omfattet af den pågældende policy.

Proaktiv planlægning: Helligdagskalenderen

En anbefalet praksis er en dedikeret opgave til helligdage, som gennemføres kvartalsvist:

• Q1: Review og tilføj helligdage for Q2.
• Q2: Review og tilføj helligdage for Q3.
• Q3: Review og tilføj helligdage for Q4 (inkl. jul og nytår).
• Q4: Review og tilføj helligdage for Q1 i det næste år.

Dette reducerer risikoen for overraskelser og sikrer opdaterede schedules i god tid.

Håndtering af sygdom: Den menneskelige faktor

Zendesk kan ikke forudsige sygdom, og schedules bør ikke bruges til at “lukke” supporten ved fravær. Fokus bør være på håndtering af konsekvenser.

• Tilgang: Views anvendes til at overvåge arbejdsbyrde. Ved sygdom kan en leder hurtigt vurdere pres via et view som “Ubesvarede Tickets - I Dag”.
• Fallback-mekanismer: For kritiske tickets kan en escalation-path anvendes. Hvis en ticket nærmer sig SLA-grænsen, og den tildelte agent er syg, kan en trigger automatisk sende en notifikation til en gruppe eller en leder, så omfordeling kan ske.
• Vigtigt: Sygdom ændrer ikke Business Hours. Organisationen er fortsat “åben” som defineret. Ændring af schedule pga. sygdom skaber unøjagtige SLA-data; fokus bør være omfordeling af arbejdet.

Multi-timezone teams – arkitekturen bag et globalt supportteam

Global support på tværs af flere kontorer kræver en robust arkitektur.

Kerneprincippet: Ét schedule pr. tidszone/region

En hyppig fejl er at forsøge at oprette ét “globalt” schedule, der dækker alle tidszoner. Det bliver hurtigt uoverskueligt.

• Metode: Opret et primært schedule pr. region/lokation:
  • Support København - CET
  • Support London - GMT
  • Support San Francisco - PST

Hvert schedule definerer lokale åbningstider for det pågældende team.

Follower Schedules – den elegante løsning

For at sikre dækning hele døgnet, når et team lukker og et andet åbner, anvendes Follower Schedules.

Et follower schedule følger et andet schedule og er designet til netop dette.

Sådan etableres et “Follow the Sun”-setup:

1. Opret de primære schedules: Opret Support København, Support London, Support San Francisco med respektive tidszoner og åbningstider.
2. Opret et “globalt” follower schedule: Opret et nyt schedule, f.eks. Global Support - 24/5. Sæt tidszonen til UTC (ofte en god praksis for globale schedules).
3. Konfigurer follower-intervaller: I stedet for faste tider vælges “Follows a different schedule” for hvert interval:
   • Interval 1 (Mandag-fredag): Følg Support San Francisco - PST fra starttid til sluttid.
   • Interval 2 (Mandag-fredag): Følg Support London - GMT fra starttid til sluttid.
   • Interval 3 (Mandag-fredag): Følg Support København - CET fra starttid til sluttid.

Resultatet er ét samlet schedule (Global Support - 24/5), der følger dækningen på tværs af teams.

Praktisk eksempel: København–San Francisco–London setup

• Primære schedules:
  • SF - PST: 09:00 - 17:00 PST
  • London - GMT: 09:00 - 17:00 GMT
  • CPH - CET: 09:00 - 17:00 CET
• Follower schedule Global - 24/5:
  • Mandag-fredag: Følg SF - PST fra 09:00 til 17:00 PST.
  • Mandag-fredag: Følg London - GMT fra 09:00 til 17:00 GMT.
  • Mandag-fredag: Følg CPH - CET fra 09:00 til 17:00 CET.

Resultat: En ticket med SLA på 2 timer har “timeren” kørende, uanset hvilket team der er på vagt. Hvis ticketen oprettes kl. 16:30 PST, har SF-teamet 30 minutter til at svare. Hvis det ikke nås, “fryser” timeren, når SF lukker, og starter igen, når London åbner, hvor London-teamet har de resterende 1,5 time.

Vigtigt: Globale SLA Policies skal tilknyttes Global - 24/5 follower schedule og ikke de regionale schedules.

Kommunikation og handover-protokoller

Teknologi løser ikke alene et multi-timezone setup; kommunikation er afgørende.

• Handover-notes: En intern makro eller et custom felt kan bruges til korte overdragelsesnoter, f.eks.: “Ticket sat til ‘Pending’ af SF-teamet. Afventer svar fra kunden. CPH-teamet følger op i morgen tidlig.”
• Fælles Slack/Teams-kanal: En dedikeret kanal til “Global Support Handover” kan bruges til at dele links til tickets, der kræver særlig opmærksomhed ved næste skift.
• Fælles møder: Et ugentligt 15-minutters møde mellem team leads fra hver tidszone kan bruges til at drøfte trends, problemer og kommende ændringer.

Edge cases – når virkeligheden udfordrer teorien

Uforudsete hændelser som nedbrud, produktlanceringer eller pludselige ændringer i åbningstider kræver en plan.

Edge case #1: Den “ekstraordinære dag” (nedbrud, lanceringer)

Ved større hændelser kan der være behov for hurtigere eskalering og dækning uden for normal åbningstid.

• Løsning: Midlertidigt “incident” schedule
  1. Opret et midlertidigt schedule, f.eks. Incident Schedule - [Dato] - 24/7.
  2. Sæt schedule til at være åbent 24/7 for den relevante dag eller periode.
  3. Opret en midlertidig SLA Policy, f.eks. Incident Response - 30 min, og tilknyt den nye Incident Schedule.
  4. Opret en trigger, der automatisk tilføjer en specifik tag (f.eks. incident_2024_10_26) og anvender den nye Incident Response SLA Policy på relevante tickets i perioden.
• Fordel: Ændringen er kontrolleret og midlertidig. Når hændelsen er afsluttet, deaktiveres triggeren, og det midlertidige schedule og policy kan fjernes. Det normale setup forbliver uændret.

Edge case #2: “On-call firefighter”-schedule

Der kan være behov for, at én person er på vagt uden for normal tid, men kun for de mest kritiske henvendelser.

• Løsning: Kombination af tag, trigger og view
  1. Opret en specifik tag, f.eks. urgent_on_call.
  2. Opret en trigger, der reagerer på tagget og kan sende SMS eller push-notifikation via en integration (f.eks. PagerDuty, Slack) til den relevante on-call person.
  3. Opret et view, On-Call Queue, der viser alle ubesvarede tickets med urgent_on_call-tagget.
• Vigtigt: Business Hours Schedule bør ikke ændres til dette formål. SLA for disse tickets kan fortsat være baseret på normal åbningstid, mens notifikationen sikrer hurtigere opmærksomhed. Dette er en advarsel, ikke en ændring af service-løftet.

Edge case #3: Delvise dage (firmafest, kursus)

Hvis hele teamet skal tidligt hjem, kan åbningstiden være reduceret en enkelt dag.

• Løsning: Brug Holiday Schedules
  Dette kan håndteres i det eksisterende holiday schedule ved at tilføje en ny dag:
  • Dato: [Dato for firmafest]
  • Tid 1: 09:00 - 14:00 (åbent)
  • Tid 2: 14:01 - 23:59 (lukket)

Dette er sporbart og let at rulle tilbage.

Sådan testes schedules – antagelser er ikke nok

Schedules bør testes regelmæssigt for at sikre korrekt funktion.

Sandbox-miljøet

Hvis der er adgang til Zendesk Sandbox, kan ændringer testes uden påvirkning af produktionsdata.

1. Klon setup: Sørg for, at Sandbox er en nylig klon med opdaterede schedules og SLA Policies.
2. Opret test-scenarier: Gennemgå situationer som beskrevet i artiklen.

Manuel test: “Time machine”-tickets

Dette er en effektiv testmetode, som kan udføres i Sandbox og i produktion (med forsigtighed).

1. Opret en test-ticket: Opret en ny ticket.
2. Manipuler tiden: Før ticketen indsendes, ændres oprettelsestidspunktet. Klik på kalender-ikonet ved siden af “Due date” (eller i avancerede options) og sæt Created at til en fremtidig dato og tid.
3. Test scenarier:
   • Helligdagstest: Sæt Created at til kl. 10:00 på en helligdag. Indsend ticketen og kontrollér SLA-måleren. Den bør være grøn, da holiday schedule er aktivt. Kontrollér også “Due date”, som bør ligge på næste åbne business day.
   • Multi-timezone test: Sæt Created at til kl. 17:30 San Francisco-tid på en fredag. Kontrollér, hvornår SLA udløber. Det bør være mandag morgen London-tid, hvis follower schedule er korrekt opsat.
   • “Gap”-test: Sæt Created at til et tidspunkt med et muligt hul mellem skift. Kontrollér om SLA reagerer som forventet.

Brug af triggers og automations til verificering

Enkle triggers kan understøtte test.

• Eksempel-trigger:
  • Condition: Ticket > Is > Created | Ticket > Created at > Is > -X hours (f.eks. -2 hours)
  • Action: Add tag schedule_test_2h_ago

Herefter kan en ticket oprettes med oprettelsestid 2 timer i fortiden for at se, om tagget tilføjes. Det kan hjælpe med at verificere tidszoner og beregninger.

Checklisten: Hvad skal verificeres?

Test bør gennemføres systematisk:

• Normal hverdag: Bliver en ticket oprettet kl. 10:00 mandag behandlet korrekt?
• Uden for åbningstid: Bliver en ticket oprettet kl. 20:00 onsdag sat på pause til kl. 9:00 torsdag?
• Weekend: Bliver en ticket oprettet lørdag sat på pause til mandag morgen?
• Helligdag: Bliver en ticket oprettet på en helligdag behandlet som en weekend?
• Halv helligdag: Bliver en ticket oprettet juleaften kl. 11:00 behandlet korrekt, og en ticket kl. 13:00 sat på pause?
• Multi-timezone: Bliver en ticket, der krydser mellem tre tidszoner, behandlet korrekt af det “vindende” schedule?
• Tidszone-check: Opret en ticket i en anden tidszone end den lokale (via VPN eller med hjælp fra en kollega). Ser SLA-beregningen korrekt ud?

Røde flag: Schedules der ikke matcher driften

Følgende signaler indikerer, at setup’et kan være på vej ud af kurs:

• Holiday Schedule er ikke opdateret i over et år. Det indikerer ofte manglende opdatering af helligdage eller ændringer i eksisterende.
• Agenter oplever gentagne gange, at SLA’er er “forkerte”. Manglende tillid til data er et tydeligt tegn på fejl i opsætningen.
• Kun ét schedule anvendes, selvom der er teams i flere tidszoner. Det skaber ofte forvirring og forkerte beregninger.
• Primære schedules ændres manuelt ved helligdage eller særlige begivenheder. Det er usikkert og uholdbart på længere sigt.
• Ansvar for schedules er uklart. Uden tydeligt ejerskab bliver vedligeholdelse ofte nedprioriteret.
• SLA-rapporter viser mærkelige udsving omkring weekender og helligdage. Det kan indikere, at schedules ikke håndterer pauser korrekt.
• “Det har altid været sådan.” I schedule-sammenhæng er dette ofte et tegn på manglende review.

Grønne flag: Realistiske schedules der anvendes i praksis

Følgende kendetegner en sund og pålidelig schedule-arkitektur:

• Der findes en dokumenteret og tilbagevendende proces for review og opdatering (mindst kvartalsvist).
• Schedules er navngivet klart og tydeligt, inkl. tidszone (f.eks. Support_NAM_PST, Support_EU_CET).
• Holiday Schedules bruges som standardmetode til lukkedage.
• Follower Schedules anvendes til at samle global dækning for multi-timezone teams.
• Der findes en testplan, som anvendes ved større ændringer i schedules eller SLA’er.
• Supportteamet kan identificere, hvilket schedule en ticket bruger, og forstår grundlæggende SLA-beregning.
• Schedules afspejler faktisk dækning frem for ønsket dækning. Hvis dækningen reelt er lavere på bestemte dage, bør schedules afspejle dette (f.eks. via længere SLA-tider på fredage).

At mestre Business Hours og Schedules kræver løbende opmærksomhed, sund fornuft og vilje til at afspejle den faktiske drift i systemet. Når opsætningen fungerer, skaber det et fundament af pålidelighed og præcision, som styrker hele Zendesk-setup’et. Det er ikke den mest synlige del af arbejdet som Zendesk-admin, men det er blandt de mest afgørende.