Deskhero
Dansk
Prøv gratis

← Back to articles

Sådan automatiserer du SLA-påmindelser, før de bliver til overskridelser

Sådan automatiserer du SLA-påmindelser, før de bliver til overskridelser

Automatiserede SLA-påmindelser bør gøre en sag synlig, mens der stadig er tid til at handle, og derefter gøre en overskredet sag umulig at overse. Den rette opsætning afhænger af helpdesken. Nogle platforme har indbyggede advarsler om nærmerende deadlines og overskridelser, mens et brugerdefineret workflow kan kræve planlagte kontroller og tydelige eskaleringstrin.

Start med uret, ikke med notifikationen:

  • Definér separate mål for første svar og løsning.
  • Beslut, om målene skal bruge kalendertid eller åbningstid.
  • Vælg, hvilke sagsstatusser der sætter løsningstiden på pause.

Pro tip: Test alle SLA-tilstande med eksempelsager, før du stoler på live-advarsler. Medtag sager, der nærmer sig deadline, overskredne sager, satte sager på pause, omfordelte sager og allerede afsluttede sager.

Vigtigste pointer

Pålidelige påmindelser begynder med nøjagtige deadlines. Tidspunktet for advarsler, modtagerne og eskaleringsprocedurerne kommer først, når selve politikken er korrekt.

Punkt Detaljer
Definér begge ure Følg første svar og løsning separat, fordi de afsluttes ved forskellige hændelser.
Respektér arbejdstiden Brug en arbejdsplan, når nætter og weekender ikke skal tælle med i målet.
Konfigurér pausestatusser Sæt løsningsmålet på pause, mens sagen afventer kunden eller en anden ekstern part.
Vælg modtagere bevidst Sørg for, at advarsler om nærmende deadlines og overskridelser når frem til nogen, der kan handle på sagen.
Test før udrulning Verificér deadlines, pauseadfærd og levering af notifikationer med kontrollerede sager.
Brug indbyggede SLA-funktioner først En helpdesk med indbyggede politikker, arbejdsplaner, advarsler, filtre og rapportering eliminerer behovet for et separat polling-workflow.

Autoritative dokumenter og vejledninger, du bør se på som det næste

Se Jiras dokumentation om automatiserede opfølgninger for et platformspecifikt eksempel. Den beskriver både planlagte regler og en tilgang baseret på SLA-tærskler, herunder en anbefaling om at teste med et lille forespørgselsomfang, før det udvides.

Indholdsfortegnelse

Sådan opbygger du automatisering af SLA-påmindelser trin for trin

Skriv præcis ned, hvad hver SLA måler, før du konfigurerer en advarsel. Et mål for første svar og et løsningsmål er to forskellige ure. Beslut, hvilken hændelse i sagen der starter hvert ur, hvilken hændelse der afslutter det, og om deadline følger kalendertid eller en arbejdsplan.

Konfigurér derefter påmindelsesforløbet.

  1. Definér politikken. Knyt grupper og prioriteter til mål for første svar og løsning. Medtag en standardpolitik for sager, der ikke matcher en mere specifik regel.
  2. Indstil arbejdsplanen. Tilføj de åbningstider og den tidszone, der gælder for målet. Hvis forpligtelsen gælder kontinuerligt, skal du bruge kalendertid.
  3. Konfigurér pauseadfærden. Vælg statusser, der stopper løsningstiden, mens teamet afventer oplysninger. Bekræft, om tiden til første svar kan sættes på pause, da mange systemer behandler den anderledes.
  4. Aktivér notifikationer. Beslut, hvem der modtager statusserne for nærmende deadlines og overskridelser, samt hvilke understøttede kanaler helpdesken skal bruge.
  5. Tilføj en operationel reaktion. Dokumentér, hvad modtageren skal gøre, f.eks. svare, ændre prioriteten, omfordele sagen eller involvere en leder. Notifikationen og den korrigerende handling behøver ikke være den samme tekniske regel.

Hvis helpdesken ikke har indbyggede SLA-tærskler, kan et planlagt workflow gennemgå åbne sager og sammenligne deres deadlines med det aktuelle tidspunkt. Et eksempel med polling hvert 15. minut er dokumenteret af LOW/CODE, men det rette interval afhænger af det korteste mål, API-begrænsninger, åbningstider og hvor meget forsinkelse teamet kan acceptere. Gem en advarselsstatus, så senere kørsler ikke sender den samme notifikation igen.

Sådan vælger du tærskler, der ikke udløser alarmtræthed

En nyttig advarsel efterlader modtageren med tilstrækkelig tid til at reagere. En procentbaseret tærskel kan fungere i et brugerdefineret system, men et fast advarselsvindue er ofte lettere at forstå på tværs af politikker med forskellige varigheder.

  • Godt inden for deadline: Hold sagen synlig i de normale køvisninger uden at sende en advarsel.
  • Deadline nærmer sig: Underret den ansvarlige bruger eller gruppe, mens målet stadig kan nås.
  • Overskredet: Markér sagen som forsinket, og følg teamets dokumenterede eskaleringsproces.

Kopiér ikke en universel tærskel på 80 procent uden at kontrollere de underliggende mål. Ved et mål på én time efterlader den 12 minutter, mens den ved et mål på tre dage efterlader mere end en halv dag. Mål, hvor meget handlingstid teamet faktisk har brug for.

Gentagne påmindelser skaber hurtigt støj. Indbyggede helpdesk-advarsler bør underrette ved en tilstandsovergang i stedet for ved hver opdatering af skærmen. Et brugerdefineret polling-workflow bør registrere, at det har sendt meddelelsen om nærmende deadline eller overskridelse, og kun nulstille denne status, når politikken reelt starter forfra.

Sådan vælger du tærskler, der ikke udløser alarmtræthed: oversigtsdiagram

Hvad SLA-advarsler bør sige, og hvor de bør sendes hen

En advarsel bør identificere sagen, vise deadlinen og gøre den forventede reaktion tydelig. Undgå at tilføje kundedata, som modtageren ikke har brug for.

  • Sags-ID og link, så modtageren kan åbne den rigtige samtale.
  • Måltype, f.eks. første svar eller løsning.
  • Deadline eller varighed af overskridelsen i en entydig tidszone.
  • Aktuel status, prioritet, gruppe og ansvarlig, når disse felter har betydning for ejerskabet.
  • Ét næste trin, f.eks. at svare, omfordele sagen eller bede en leder om at gennemgå den.

Brug kanaler, som supportteamet allerede overvåger. Notifikationer i appen og via e-mail er ofte tilstrækkelige, når de pålideligt når den ansvarlige eller den ansvarlige gruppe. Hvis der kræves et separat paging- eller beskedsystem, skal du bekræfte, at helpdesken understøtter integrationen, før du designer processen omkring den.

Pro tip: Vis en præcis deadline eller nedtælling. Et konkret tidspunkt er lettere at prioritere end en vag advarsel.

Hvad SLA-advarsler bør sige, og hvor de bør sendes hen: oversigtsdiagram

Sådan holder du SLA-timere nøjagtige med pausestatusser

En påmindelse er kun så pålidelig som sit ur. Løsningsmål sættes normalt på pause, mens en sag afventer kunden, men de præcise statusser bør afspejle teamets faktiske workflow.

  • Vælg tydelige pausestatusser, og dokumentér, hvorfor hver af dem stopper uret.
  • Genoptag uret, når sagen forlader en pausestatus.
  • Test sager, der går ind og ud af en pausestatus mere end én gang.
  • Bekræft, om målene for første svar og løsning følger de samme pauseregler.

Arbejdsplaner løser et andet problem. De udelukker lukkede timer fra selve målet, mens pausestatusser udelukker tid baseret på sagens status. Konfigurér og test begge dele. En weekend bør ikke tælle med i et mål baseret på åbningstid, og en sag på en hverdag, der afventer kunden, bør forblive på pause, selv mens teamet har åbent.

Test og finjustering, før du stoler på automatiseringen

Brug kontrollerede sager til at teste hele livscyklussen. Historiske data kan hjælpe med at identificere realistiske mål, men en test af live-tilstanden er bedre til at verificere levering af notifikationer og ændringer i deadlines.

  1. Dæk alle politikker. Opret en testsag for hver kombination af gruppe og prioritet, der kan vælge en anden SLA-politik.
  2. Brug korte midlertidige mål. Bekræft statusserne for nærmende deadline og overskridelse uden at vente i timer eller dage, og gendan derefter de faktiske værdier.
  3. Afprøv pausestatusser. Sæt løsningstiden på pause og genoptag den, og kontrollér, at deadlinen ændres som forventet.
  4. Kontrollér modtagere. Test en tildelt og en ikke-tildelt sag, så de rigtige personer modtager hver notifikation.
  5. Gennemgå registreringen. Bekræft, at sagen viser, hvilken politik der blev anvendt, og hvornår hvert ur blev nået eller overskredet.

Efter lanceringen skal du gennemgå falske advarsler og manglende overleveringer. Hvis advarslerne er nøjagtige, men stadig ignoreres, kan problemet være ejerskab eller bemanding snarere end tærskeltidspunktet.

Sådan håndterer Deskhero SLA-påmindelser

Deskhero har dedikerede SLA-politikker. De er adskilt fra de generelle automatiseringsregler, som ikke er planlagte eller tidsbaserede.

  • Ejere og administratorer kan prioritere SLA-politikker, der matcher sagsgrupper og prioriteter. Den første matchende politik fastsætter målene for første svar og løsning.
  • Hver politik kan bruge en navngiven ugentlig arbejdsplan med sin egen tidszone eller tælle kalendertid.
  • Løsningstiden sættes på pause i statusser, der er valgt i arbejdsområdet. Tiden til første svar sættes ikke på pause.
  • Deskhero markerer en sag som i risikozonen i de sidste 60 minutter før den næste deadline og markerer den som overskredet, når deadlinen er passeret.
  • En baggrundskontrol kører hvert femte minut og sender notifikationer i appen samt en e-mailoversigt til den ansvarlige eller til gruppemedlemmer, når sagen ikke er tildelt. Brugere kan styre SLA-notifikationskanaler pr. gruppe.

Saglisten indeholder en SLA-kolonne og SLA-filtre, dashboardet fremhæver sager i risikozonen og overskredne sager, og sagens tidslinje registrerer politik- og urhændelser. Statistikker indeholder visninger af SLA-opfyldelse, når workflowet er aktivt.

Hvad du bør følge, når dine advarsler er aktive

Det første spørgsmål er, om påmindelserne forhindrer overskridelser. Sammenlign sager i risikozonen med antallet, der senere overskrider målet, og undersøg derefter de sager, som advarslerne ikke fik tilbage på sporet.

Følg opfyldelsen af målene for første svar og løsning separat. Gennemgå også antallet af sager, der aktuelt har deadline inden for advarselsvinduet, antallet, der allerede er overskredet, og hvilke politikker eller kombinationer af gruppe og prioritet der giver flest overskridelser.

Sæt procentsatserne i en operationel kontekst. En stærk samlet procent kan skjule én kø, der gentagne gange overskrider målene. Et pludseligt fald kan skyldes en ændret arbejdsplan, en ny prioritet eller et hul i ejerskabet snarere end langsommere arbejde.

Sådan håndterer du overlappende SLA'er uden advarselskollisioner

En sag kan have både et mål for første svar og et løsningsmål. Behandl dem som separate ure, fordi et svar kun afslutter det første. Løsningsmålet fortsætter, indtil sagen når den hændelse, der opfylder det.

Sagsgrænsefladen bør vise, hvilken af de aktuelle deadlines der kommer først, samtidig med at den bevarer oplysninger om begge mål. Filtre og rapportering bør også skelne mellem første svar og løsning, så én sund måling ikke skjuler problemer i den anden.

Når kunder har forskellige forpligtelser, skal du bruge separate politikker, der matcher stabile sagsfelter som gruppe og prioritet. Placér specifikke politikker før standardpolitikken, og test derefter en sag mod alle relevante kombinationer. Undgå at opfinde skjulte kontraktniveauer, som brugerne ikke kan se eller verificere i sagen.

Sådan er du klar til audit, når SLA'er kører automatisk

Bevar en registrering af, hvilken politik der blev anvendt, de beregnede deadlines, og hvornår hvert ur blev nået eller overskredet. Hvis en ændring af gruppe, prioritet eller arbejdsplan medfører, at en deadline beregnes på ny, bør denne ændring også kunne spores.

Dokumentér ændringer af politikker uden for notifikationsindbakken. Registrér, hvem der godkendte ændringen, hvornår den trådte i kraft, og om den gælder for eksisterende sager. Det gør det lettere at besvare senere kundespørgsmål og forhindrer tavse ændringer af betydningen af en SLA-rapport.

Ved kontraktgennemgange skal du bekræfte platformens adfærd i stedet for at antage, at enhver synlig hændelse er en auditlog. Deskheroes tidslinje for sager registrerer anvendelsen af SLA-politikken og urenes resultater, mens området Statistikker rapporterer opfyldelse. Organisationer med formelle krav til opbevaring bør kontrollere, at disse registreringer opfylder deres egne forpligtelser.

Sådan skriver du SLA-beskeder til brugere, ledere og kunder

Interne advarsler og kundeopdateringer tjener forskellige formål. Hold hver af dem fokuseret på, hvad læseren kan gøre som det næste.

Brugerrettede advarsler bør begynde med linket til sagen, måltypen, deadlinen og den umiddelbare handling. Undgå et afsnit med baggrund om politikken, når brugeren har brug for at arbejde på sagen.

Lederrettede gennemgange bør vise mønstre på tværs af en gruppe, prioritet eller politik. En enkelt overskredet sag kræver handling, mens gentagne overskridelser kræver en beslutning om bemanding eller proces.

Kommunikation til kunder bør være nøjagtig og specifik. Hvis teamet forventer en forsinkelse, kan en opdatering, der er gennemgået af et menneske, angive et realistisk tidspunkt for næste kontakt. Afslør ikke interne advarselslabels, og lov ikke en løsningstid, som teamet ikke kan overholde.

Sådan forbinder du SLA-automatisering med de værktøjer, du allerede bruger

Begynd med de indbyggede SLA-funktioner, når de dækker de nødvendige politikker, kalendere, pausestatusser, advarsler, filtre og rapportering. Indbyggede deadlines forbliver normalt mere pålideligt synkroniseret med ændringer i sager end et parallelt regneark.

Hvor den indbyggede understøttelse er begrænset, har teams brugt community-plugins og forumdokumenterede løsninger. Gennemgå vedligeholdelsesstatus og versionskompatibilitet, før du baserer dig på denne tilgang.

Et separat workflow kan være passende, når flere systemer skal levere data til én eskaleringskanal. Definér først, hvad der er den autoritative datakilde. Dobbeltberegninger af SLA'er i en helpdesk og et integrationslag kan afvige, især omkring tidszoner, åbningstider, pausestatusser og omfordeling.

Redaktionens vurdering: Advarslen er ikke pointen, det er handlingen

En advarsel om en nærmende deadline er kun nyttig, når ejerskabet er tydeligt. Modtageren har brug for tilladelse, kontekst og tid til at føre sagen fremad.

Nøjagtige timere kommer først. En forkert arbejdsplan eller pausekonfiguration skaber selvsikre, men vildledende advarsler. Ret deadlineberegningen, før du justerer formuleringen af beskeden eller tilføjer kanaler.

Opbyg det i denne rækkefølge: mål for politikker, arbejdsplaner, pauseadfærd, notifikationsmodtagere, operationel reaktion og rapportering. Denne rækkefølge holder påmindelsen knyttet til en deadline, som alle forstår.

Få dine SLA-påmindelser i gang uden et migreringsprojekt

Deskhero forbinder til Gmail eller Microsoft 365 med tovejssynkronisering, så teams kan beholde deres eksisterende supportadresse, samtidig med at de får delt sagsbehandling og SLA-politikker.

Deskhero

Konfigurér mål for første svar og løsning efter gruppe og prioritet, tilføj en ugentlig arbejdsplan efter behov, og vælg, hvilke statusser der sætter løsningen på pause. Deskhero viser derefter den næste deadline, fremhæver sager med deadline inden for én time, underretter de ansvarlige brugere og registrerer SLA-resultater.

Den gratis prøveperiode på 30 dage kræver ikke et kreditkort. Tilslut én postkasse, konfigurér et lille sæt politikker, og test hele SLA-livscyklussen, før du udvider opsætningen til flere grupper.

Kilder

FAQ

Hvad er forskellen mellem en SLA, en SLO og en SLI?

En SLA er en serviceforpligtelse mellem parter. En SLO er et mål for en services ydeevne, som ofte bruges internt til at holde sig inden for denne forpligtelse. En SLI er den målte værdi, der bruges til at evaluere målet.

Hvad tæller som en advarsel om en SLA-overskridelse?

En advarsel om en overskridelse angiver, at en udestående deadline for første svar eller løsning er passeret. En advarsel om en nærmende deadline er anderledes, fordi teamet stadig har tid til at nå målet.

Hvad betyder en SLA på 4 timer?

Det betyder, at den handling, der er angivet i politikken, f.eks. første svar eller løsning, skal udføres inden for fire timer som beregnet af denne politik. Uret kan bruge kalendertid eller en arbejdsplan.

Hvordan adskiller en SLA sig fra en KPI?

En SLA angiver en serviceforpligtelse. En KPI måler ydeevne og kan bruges til at følge mange mål, der ikke er kontraktlige deadlines.

Kan Deskhero automatisere SLA-påmindelser uden brugerdefineret kode?

Ja. Deskhero har indbyggede SLA-politikker, et fast advarselsvindue for nærmende deadlines, registrering af overskridelser, notifikationer i appen og via e-mail, sagsfiltre, dashboardvisninger og SLA-rapportering. Disse funktioner er adskilt fra de generelle automatiseringsregler.