Gå til hovedindhold

SLA Policies - Forskellige mål baseret på kontekst

Opdateret

I en verden, hvor kundeforventninger konstant stiger, er Service Level Agreement (SLA) Policies ikke kun en teknisk funktion i Zendesk. De fungerer som et centralt fundament for kundeservice og som et tydeligt løfte til kunderne. SLA Policies definerer, hvad der kan forventes, og giver supportteams klare, målbare mål for leveringen af service. Med differentierede SLA Policies sikres det, at henvendelser ikke behandles ens, men at respons og indsats tilpasses konteksten og værdien af den enkelte ticket.

Hvad er en SLA Policy?

En SLA Policy er et sæt foruddefinerede regler, der fastsætter tidsmål for, hvor hurtigt en kundes henvendelse skal håndteres. Reglerne fungerer som en automatisk kontrakt mellem organisationen og kunden og sikrer konsistens og gennemsigtighed på tværs af supportkanaler. Hver policy er typisk bygget op omkring tre centrale metrikker:

  • First Reply Time (FRT): Den maksimale tid fra en ticket oprettes, til kunden modtager det første svar fra en agent. Metrikken er vigtig for at anerkende henvendelsen og afstemme forventninger til den videre proces.
  • Next Reply Time (NRT): Den maksimale tid fra kunden svarer, til der svares igen. Metrikken reducerer unødvendige pauser i dialogen og understøtter en stabil kundeoplevelse.
  • Resolution Time: Den maksimale tid fra ticketens oprettelse, til problemet er løst, og ticketen kan lukkes. Metrikken afspejler den samlede effektivitet og evnen til at levere en endelig løsning.

Ved at kombinere metrikkerne i forskellige policies kan der etableres et nuanceret og dynamisk system, der afspejler forretningsprioriteter.

Strategisk værdi: Hvorfor differentierede SLA'er er afgørende

En ensartet (“one-size-fits-all”) SLA kan føre til overbelastede teams eller utilfredse kunder. Den største effekt opnås ved at differentiere mål baseret på forretningskritiske faktorer, så ressourcer kan prioriteres der, hvor de skaber mest værdi.

Baseret på brand

Ved support af flere brands kan SLA'er bidrage til at understøtte hvert brands serviceniveau og løfte.

  • Premium brand: Kunder forventer en mere eksklusiv service. En policy kan eksempelvis være First Reply Time: 1 time og Resolution Time: 4 timer.
  • Standard brand: Forventningerne er fortsat høje, men mere moderate. En policy kan eksempelvis være First Reply Time: 4 timer og Resolution Time: 24 timer.

Baseret på prioritet

Ikke alle problemer har samme forretningsmæssige påvirkning. Prioritetsniveauer kan sikre, at kritiske issues håndteres først.

  • Urgent: Systemnedbrud, der påvirker alle kunder. First Reply Time: 15 minutter, Resolution Time: 2 timer.
  • High: Problem, der blokerer en enkelt kundes kernefunktioner. First Reply Time: 30 minutter, Resolution Time: 4 timer.
  • Medium: Generel forespørgsel eller mindre problem. First Reply Time: 4 timer, Resolution Time: 24 timer.
  • Low: Forbedringsidé eller mindre kosmetisk fejl. First Reply Time: 24 timer, Resolution Time: 72 timer.

Baseret på kundetype

Kunder med højere værdi kan tildeles hurtigere og mere dedikerede mål.

  • VIP/Enterprise-kunder: Kunder med høj lifetime value (CLV) kan tildeles en dedikeret SLA, f.eks. First Reply Time: 30 minutter.
  • Standard-kunder: Standard SLA, der balancerer service og effektivitet.
  • Free Tier/prøveperiode: Kunder, der endnu ikke betaler for servicen, kan tildeles en længere SLA for at prioritere betalende kunder.

Baseret på kanal

Forventninger afhænger i høj grad af den valgte kontaktkanal.

  • Telefon: Kunden venter aktivt i kø. SLA handler her om svartid i køen, ikke ticket-svar.
  • Chat: Realtidskanal med forventning om svar inden for få minutter. First Reply Time: 60 sekunder.
  • E-mail: Asynkron kanal, hvor forventningen typisk er svar inden for få timer eller samme forretningsdag. First Reply Time: 4 timer.

Dybdegående kig på SLA-metrikker

For effektiv brug af SLA'er er det vigtigt at forstå nuancerne i hver metrik.

First Reply Time (FRT)

FRT er første mulighed for at skabe en god oplevelse. En hurtig FRT reducerer usikkerhed og opbygger tillid. Selv uden en endelig løsning viser en hurtig anerkendelse, at sagen er modtaget og under behandling.

  • Eksempel: For henvendelser via chatbot, der eskaleres til en agent, kan der sigtes mod en FRT på under 90 sekunder for at bevare en oplevet realtidsfornemmelse.

Next Reply Time (NRT)

Når kunden svarer med yderligere information, starter målingen igen. En lang NRT kan give indtryk af, at sagen er glemt. Metrikken er særligt vigtig i længere sager med mange dialogtrin.

  • Eksempel: Hvis en kunde sender efterspurgte logfiler, kan en NRT på 2 timer anvendes til at bekræfte modtagelse og give en statusopdatering.

Resolution Time

Resolution Time er den overordnede måling af effektivitet. Metrikken handler ikke kun om hurtige svar, men om at løse problemet. Lav resolutionstid hænger ofte sammen med høj kundetilfredshed (CSAT). Hastighed bør afbalanceres med kvalitet, da en hurtig, men forkert løsning er dårligere end en langsommere, korrekt løsning.

Konfiguration af SLA-Policies: En trin-for-trin guide

Oprettelse af en SLA Policy i Zendesk er en proces med fleksible muligheder.

  1. Naviger til Admin Center: Gå til Admin Center → Objects and rules → Tickets → SLA policies.
  2. Opret en ny policy: Klik på Add SLA policy.
  3. Navngiv policyen: Angiv et beskrivende navn, der tydeligt viser formålet, f.eks. “Enterprise - Urgent SLA” eller “Standard - Email SLA”. Dette understøtter administration og fejlfinding.
  4. Definér målene: Indstil tidsmål for FRT, NRT og Resolution Time. Der kan vælges mellem timer, minutter eller forretningsdage.
  5. Vælg en tidsplan (Schedule): Knyt policyen til en tidsplan (f.eks. “Danmark - Business Hours” eller “24/7 Support”). Tidsplanen afgør, hvornår uret tæller.
  6. Anvend policyen via betingelser (Conditions): Definér, hvilke tickets der omfattes. Betingelser kan baseres på Brand, Priority, Group, Ticket form, Custom fields m.fl.
    • Eksempel på betingelse: Ticket > Priority > Is > Urgent OG Ticket > Group > Is > Technical Support.
  7. Gem og aktivér: Gem policyen og sørg for, at den er aktiv. Det er også muligt at oprette den som inaktiv, indtil implementering ønskes.

Tidsplaner og arbejdstid: Hvornår tæller uret?

En SLA på “8 timer” kan betyde forskellige ting afhængigt af, hvornår uret tæller.

  • Business Hours: SLA-tælleren kører kun i defineret åbningstid (f.eks. mandag–fredag 9–17). En ticket oprettet fredag kl. 16 vil have 7 timer tilbage mandag morgen. Dette er standard for mange B2B-supportteams.
  • 24/7: SLA-tælleren kører konstant, døgnet rundt, alle ugens dage. Dette er relevant for kritiske systemer eller globale brands på tværs af tidszoner.
  • Custom Schedule: Egne tidsplaner kan defineres, f.eks. udvidet service 8–22 eller en tidsplan, der kun gælder i weekender.

Feriekalendere og lokale helligdage

For at sikre fairness og nøjagtighed kan feriekalendere integreres i tidsplaner. Helligdage som jul, påske eller grundlovsdag fratrækkes automatisk i SLA-beregningen. Dette forhindrer, at teams måles på dage uden forventet bemanding, og understøtter en konsistent serviceoplevelse for kunder globalt.

Anvendelse af SLA'er i praksis

En SLA Policy er kun effektiv, hvis den anvendes på de rette tickets på det rette tidspunkt. Automatisering sker typisk via tre metoder:

1. Triggers

Triggers er “hvis-så”-regler, der kører, når en ticket oprettes eller opdateres.

  • Eksempel:
    • Betingelse (IF): Ticket is Created OG Custom field "Customer Tier" > Is > "VIP"
    • Handling (THEN): Set SLA policy to "VIP Support SLA"

2. Ticket forms

Hver ticket form kan have en standard SLA Policy. Dette er relevant, når formularen indikerer typen af henvendelse. En “Betalingsproblem”-form kan f.eks. have en hurtigere SLA end en “Generel forespørgsel”-form.

3. Manuel tildeling

I særlige tilfælde kan en agent eller teamleder manuelt ændre SLA på en ticket. Dette bruges typisk til eskalering eller håndtering af undtagelser, som automatiserede regler ikke fanger.

Håndtering af SLA-brud: Fra proaktiv advarsel til eskalering

SLA'er kan blive brudt, selv med klare mål. En tydelig plan for proaktiv håndtering og reaktion er afgørende.

Proaktive advarsler

Systemet kan konfigureres til at give forvarsel, før en deadline nås.

  • F.eks. 30 minutter før FRT-brud: Ticketen får automatisk et tag som SLA Warning og vises i en specifik “View” for teamlederen. Agenten kan samtidig modtage en notifikation. Dette skaber et handlingsvindue, før kunden oplever forsinkelse.

Håndtering af faktiske brud

Når en SLA er brudt, bør håndteringen være hurtig og struktureret.

  • Automatiske handlinger: En trigger kan tilføje tagget SLA Breached, hæve prioriteten til High og eskalere ticketen til en anden gruppe (f.eks. fra L1 til L2 support eller til en teamleder).
  • Intern kommunikation: Teamlederen modtager en notifikation og kan tage ejerskab for at sikre afklaring.
  • Ekstern kommunikation (væsentligt): Kunden bør informeres proaktivt. En besked som: “Vi beklager forsinkelsen i vores svar. Sagen er mere kompleks end forventet, og der arbejdes aktivt på en løsning. Der gives en opdatering inden for [nyt, realistisk tidsrum].” kan understøtte kundeoplevelsen.

Best practices for effektive SLA-strategier

For at få mest muligt ud af SLA'er kan følgende principper anvendes:

  1. Start med data, ikke ønsketænkning: Analyser historiske data for at sætte realistiske mål. Hvad er nuværende gennemsnitlig FRT og Resolution Time? Mål bør være ambitiøse, men opnåelige.
  2. Differentier meningsfuldt: Forskelle i SLA-mål bør være begrundede og mærkbare for både kunde og team. En VIP-kunde bør opleve markant bedre service.
  3. Kommunikér klart og tydeligt: Sikr, at både kunder og agenter forstår betydningen af SLA'er. Standard-svartider kan kommunikeres på hjemmeside eller i auto-respons-mails.
  4. Monitorér og rapportér løbende: Brug Zendesks rapportering til at overvåge SLA-performance. Hvor mange tickets overholder målene, og hvor opstår flaskehalse?
  5. Juster og optimér: En SLA-strategi er ikke statisk. Policies kan gennemgås kvartalsvist og justeres baseret på performance-data, agentfeedback og ændringer i forretningsstrategi.
  6. Dokumentér og kommunikér internt: Sikr, at supportteamet kender de forskellige SLA'er og forstår rationalet bag dem. Dette understøtter ejerskab og motivation for at nå målene.

Fejlfinding og almindelige udfordringer

Selv et velkonfigureret setup kan give udfordringer. Nedenfor er typiske problemer og tilhørende løsninger:

  • Problem: SLA-tælleren kører, selvom ticketen er sat til “Pending”.
    • Løsning: Kontrollér SLA Policy-indstillingerne. Der findes en mulighed for at sætte uret på pause, når status ændres til “Pending” eller “On-hold”. Sørg for, at den er aktiveret.
  • Problem: Forkert SLA Policy anvendes på en ticket.
    • Løsning: Gennemgå triggers. En trigger højere på listen kan overskrive en trigger længere nede. Brug “Audit Log” i Zendesk til at se, hvilken handling der ændrede SLA, og hvilke betingelser der var opfyldt.
  • Problem: Der opleves konstante SLA-brud trods høj aktivitet.
    • Løsning: Dette kan indikere urealistiske mål eller underbemanding. Analyser belastning og overvej justering af SLA-mål eller interne workflows for effektivisering.
  • Problem: SLA'er tæller ikke i weekenden, selvom de bør.
    • Løsning: Dobbelttjek den tidsplan (Schedule), der er knyttet til SLA Policy. Kontrollér, at den er konfigureret til 24/7 eller inkluderer weekenddage.

Vej frem: Implementering og optimering

SLA Policies kræver løbende arbejde og justering. Med en struktureret tilgang kan kundeservice udvikles fra reaktiv til proaktiv, datadrevet og kundecentreret.

  1. Analyser og definér: Start med en grundig analyse af nuværende performance og kundebehov. Definér klare, differentierede mål.
  2. Implementér gradvist: Udrul nye SLA Policies i faser. Start med én ticket-type (f.eks. baseret på prioritet) for at teste og finjustere før udvidelse.
  3. Eskalér og automatisér: Etablér triggers og views til automatisk allokering, advarsler og eskalering.
  4. Mål, lær og justér: Gør rapportering til en fast praksis, og brug indsigter til løbende forbedring af både SLA-mål og understøttende processer.
Drevet af Zendesk