Deskhero
Norsk
Prøv gratis

← Back to articles

Slik automatiserer du SLA-påminnelser før de fører til brudd

Slik automatiserer du SLA-påminnelser før de fører til brudd

Automatiserte SLA-påminnelser bør gjøre en sak synlig mens det fortsatt er tid til å handle, og deretter gjøre en forsinket sak umulig å overse. Det riktige oppsettet avhenger av helpdesken. Noen plattformer tilbyr innebygde varsler for saker som snart forfaller og brudd på SLA, mens en tilpasset arbeidsflyt kan trenge planlagte kontroller og tydelige eskaleringstrinn.

Begynn med klokken, ikke varslingen:

  • Definer separate mål for første svar og løsning.
  • Bestem om målene skal bruke kalendertid eller arbeidstid.
  • Velg hvilke saksstatuser som setter løsningsklokken på pause.

ProffTips: Test alle SLA-tilstander med eksempelsaker før du stoler på varsler i produksjon. Ta med saker som snart forfaller, saker med brudd, saker som er satt på pause, omfordelte saker og saker som allerede er fullført.

Viktigste punkter

På­litelige påminnelser begynner med nøyaktige tidsfrister. Tidspunkt for varsler, mottakere og eskaleringsprosedyrer kommer etter at selve policyen er riktig.

Punkt Detaljer
Definer begge klokkene Følg første svar og løsning separat fordi de fullføres av ulike hendelser.
Ta hensyn til arbeidstid Bruk en arbeidsplan når netter og helger ikke skal telle med i målet.
Konfigurer pausestatus Sett løsningsmålet på pause mens saken venter på kunden eller en annen ekstern part.
Velg mottakere med hensikt Sørg for at varsler om saker som snart forfaller og SLA-brudd når noen som kan handle på saken.
Test før utrulling Bekreft tidsfrister, pausefunksjon og levering av varsler med kontrollerte saker.
Bruk innebygde SLA-funksjoner først En helpdesk med innebygde policyer, arbeidsplaner, varsler, filtre og rapportering eliminerer behovet for en separat kontrollarbeidsflyt.

Autoritativ dokumentasjon og veiledninger du bør se på videre

Se Jiras dokumentasjon om automatiserte oppfølginger for et plattformspesifikt eksempel. Den beskriver både planlagte regler og en tilnærming basert på SLA-terskler, inkludert en anbefaling om å teste mot et lite spørringsomfang før det utvides.

Innholdsfortegnelse

Bygging av automatisering for SLA-påminnelser, trinn for trinn

Skriv ned nøyaktig hva hver SLA måler før du konfigurerer et varsel. Et mål for første svar og et løsningsmål er to forskjellige klokker. Bestem hvilken saks­hendelse som starter hver klokke, hvilken hendelse som fullfører den, og om tidsfristen følger kalendertid eller en arbeidsplan.

Konfigurer deretter påminnelsesforløpet.

  1. Definer policyen. Knytt grupper og prioriteter til mål for første svar og løsning. Ta med en standardpolicy for saker som ikke samsvarer med en mer spesifikk regel.
  2. Angi arbeidskalenderen. Legg til åpningstidene og tidssonen som gjelder for målet. Hvis forpliktelsen gjelder kontinuerlig, bruker du kalendertid.
  3. Konfigurer pausefunksjonen. Velg statuser som stopper løsningsklokken mens teamet venter på informasjon. Bekreft om klokken for første svar kan settes på pause, siden mange systemer behandler den annerledes.
  4. Aktiver varsler. Bestem hvem som skal motta tilstander for saker som snart forfaller og saker med brudd, og hvilke støttede kanaler helpdesken skal bruke.
  5. Legg til en operativ respons. Dokumenter hva mottakeren skal gjøre, for eksempel svare, endre prioritet, tilordne saken på nytt eller involvere en ansvarlig leder. Varslingen og det korrigerende tiltaket trenger ikke være den samme tekniske regelen.

Hvis helpdesken mangler innebygde SLA-terskler, kan en planlagt arbeidsflyt kontrollere åpne saker og sammenligne tidsfristene deres med gjeldende klokkeslett. Et eksempel med kontroll hvert 15. minutt er dokumentert av LOW/CODE, men riktig intervall avhenger av det korteste målet, API-begrensninger, arbeidstid og hvor mye forsinkelse teamet kan tåle. Lagre en varslingsstatus slik at senere kjøringer ikke sender det samme varselet på nytt.

Velge terskler som ikke fører til varslingstretthet

Et nyttig varsel gir mottakeren nok tid til å svare. En prosentbasert terskel kan fungere i et tilpasset system, men et fast varslingsvindu er ofte enklere å forstå på tvers av policyer med ulik varighet.

  • Godt innenfor fristen: Hold saken synlig i vanlige køvisninger uten å sende et varsel.
  • Forfaller snart: Varsle den ansvarlige brukeren eller gruppen mens målet fortsatt kan nås.
  • Brudd: Merk saken som forsinket og følg teamets dokumenterte eskaleringsprosess.

Ikke kopier en universell terskel på 80 prosent uten å kontrollere de underliggende målene. Ved et mål på én time gir den 12 minutter, mens den ved et mål på tre dager gir mer enn en halv dag. Mål hvor mye tid teamet faktisk trenger for å handle.

Gjentatte påminnelser skaper raskt støy. Innebygde helpdesk-varsler bør varsle ved en overgang mellom tilstander, ikke ved hver oppdatering av skjermbildet. En tilpasset kontrollarbeidsflyt bør registrere at den sendte varslet om at saken snart forfaller eller har brutt SLA, og bare tilbakestille denne statusen når policyen faktisk starter på nytt.

Velge terskler som ikke fører til varslingstretthet: oversiktsdiagram

Hva SLA-varsler bør si, og hvor de bør sendes

Et varsel bør identifisere saken, vise tidsfristen og tydeliggjøre forventet respons. Unngå å legge til kundedata som mottakeren ikke trenger.

  • Saks-ID og lenke slik at mottakeren kan åpne riktig samtale.
  • Måltype, for eksempel første svar eller løsning.
  • Tidsfrist eller varighet over fristen i en entydig tidssone.
  • Gjeldende status, prioritet, gruppe og saksbehandler når disse feltene påvirker eierskapet.
  • Ett neste steg, for eksempel å svare, tilordne saken på nytt eller be en leder om å gjennomgå den.

Bruk kanaler supportteamet allerede følger med på. Varsler i appen og på e-post er ofte tilstrekkelig når de pålitelig når saksbehandleren eller den ansvarlige gruppen. Hvis det kreves et separat personsøkings- eller meldingssystem, må du bekrefte at helpdesken støtter integrasjonen før du bygger prosessen rundt den.

ProffTips: Vis en presis tidsfrist eller nedtelling. Et konkret klokkeslett er enklere å prioritere enn en vag advarsel.

Hva SLA-varsler bør si, og hvor de bør sendes: oversiktsdiagram

Slik holder du SLA-klokkene nøyaktige med pausestatus

En påminnelse er bare så pålitelig som klokken den bygger på. Løsningsmål settes vanligvis på pause mens en sak venter på kunden, men de nøyaktige statusene bør samsvare med teamets faktiske arbeidsflyt.

  • Velg tydelige pausestatuser og dokumenter hvorfor hver av dem stopper klokken.
  • Start klokken igjen når saken går ut av en pausestatus.
  • Test saker som går inn og ut av en pausestatus mer enn én gang.
  • Bekreft om mål for første svar og løsning følger de samme pausereglene.

Arbeidsplaner løser et annet problem. De utelukker stengte timer fra selve målet, mens pausestatuser utelukker tid basert på saksstatus. Konfigurer og test begge deler. En helg skal ikke forbruke et mål basert på arbeidstid, og en sak på en ukedag som venter på kunden, skal fortsatt være satt på pause selv om teamet er tilgjengelig.

Teste og finjustere før du stoler på automatiseringen

Bruk kontrollerte saker til å teste hele livssyklusen. Historiske data kan bidra til å identifisere realistiske mål, men en test med aktiv status er bedre for å verifisere levering av varsler og endringer i tidsfrister.

  1. Dekk alle policyer. Opprett en testsak for hver kombinasjon av gruppe og prioritet som kan velge en annen SLA-policy.
  2. Bruk korte, midlertidige mål. Bekreft tilstandene for saker som snart forfaller og saker med brudd uten å vente i timevis eller dagevis, og gjenopprett deretter de faktiske verdiene.
  3. Test pausestatuser. Sett løsningsklokken på pause og start den igjen, og bekreft at tidsfristen endres som forventet.
  4. Kontroller mottakerne. Test både en tilordnet og en ikke-tilordnet sak, slik at de riktige personene mottar hvert varsel.
  5. Undersøk registreringen. Bekreft at saken viser hvilken policy som ble brukt, og når hver klokke ble oppfylt eller overskredet.

Etter lansering bør du gjennomgå falske varsler og mislykkede overleveringer. Hvis varslene er nøyaktige, men fortsatt ignoreres, kan problemet være eierskap eller bemanning snarere enn tidspunktet for tersklene.

Slik håndterer Deskhero SLA-påminnelser

Deskhero har dedikerte SLA-policyer. Disse er separate fra de generelle automatiseringsreglene, som ikke er planlagte eller tidsbaserte.

  • Ei​​ere og administratorer kan prioritere SLA-policyer som samsvarer med saksgrupper og prioriteter. Den første samsvarende policyen angir målene for første svar og løsning.
  • Hver policy kan bruke en navngitt ukentlig arbeidsplan med egen tidssone, eller telle kalendertid.
  • Løsningsklokken settes på pause i statuser som er valgt i arbeidsområdet. Klokken for første svar settes ikke på pause.
  • Deskhero merker en sak som utsatt i løpet av de siste 60 minuttene før den neste tidsfristen og merker den som brutt etter at tidsfristen er passert.
  • En bakgrunnskontroll kjører hvert femte minutt og sender varsler i appen samt en e-postoppsummering til saksbehandleren, eller til gruppemedlemmer når saken ikke er tilordnet. Brukere kan styre SLA-varslingskanaler per gruppe.

Sakslisten inneholder en SLA-kolonne og SLA-filtre, dashbordet fremhever utsatte saker og saker med brudd, og sakens tidslinje registrerer policy- og klokkehendinger. Statistikk gir oversikter over SLA-oppnåelse etter at arbeidsflyten er aktiv.

Hva du bør følge med på når varslene er aktive

Det første spørsmålet er om påminnelsene forhindrer brudd. Sammenlign saker som står i fare, med antallet som senere ikke når målet, og undersøk deretter sakene som varslingene ikke klarte å få tilbake på rett spor.

Følg oppnåelse av første svar og oppnåelse av løsning separat. Se også på antallet saker som for øyeblikket forfaller innenfor varslingsvinduet, antallet som allerede har brutt SLA, og hvilke policyer eller kombinasjoner av gruppe og prioritet som fører til flest overskridelser.

Sett prosentene inn i en operativ sammenheng. En høy samlet prosent kan skjule én kø som stadig bryter SLA. En plutselig nedgang kan skyldes en endret arbeidsplan, en ny prioritet eller et hull i eierskapet, snarere enn tregere arbeid.

Håndtere overlappende SLA-er uten varslingskollisjoner

En sak kan ha både et mål for første svar og et løsningsmål. Behandle dem som separate klokker fordi et svar bare fullfører den første. Løsningsmålet fortsetter til saken når hendelsen som oppfyller det.

Saksgrensesnittet bør vise hvilken utestående tidsfrist som kommer først, samtidig som detaljene for begge målene beholdes. Filtre og rapportering bør også skille mellom første svar og løsning, slik at ett godt resultat ikke skjuler problemer med det andre.

Når kunder har ulike forpliktelser, bruker du separate policyer som samsvarer med stabile saksfelt, for eksempel gruppe og prioritet. Plasser spesifikke policyer før standardpolicyen, og test deretter en sak mot alle meningsfulle kombinasjoner. Unngå å opprette skjulte kontraktsnivåer som brukere ikke kan se eller kontrollere i saken.

Være klar for revisjon når SLA-er kjører automatisk

Oppbevar en registrering av hvilken policy som ble brukt, de beregnede tidsfristene og når hver klokke ble oppfylt eller overskredet. Hvis en endring i gruppe, prioritet eller arbeidsplan fører til at en tidsfrist beregnes på nytt, bør også denne endringen kunne spores.

Dokumenter policyendringer utenfor innboksen for varsler. Registrer hvem som godkjente endringen, når den trådte i kraft, og om den gjelder eksisterende saker. Dette gjør det enklere å svare på senere spørsmål fra kunder og forhindrer stille endringer i betydningen av en SLA-rapport.

Ved kontraktsgjennomganger bør du bekrefte plattformens funksjonalitet i stedet for å anta at alle synlige hendelser er en revisjonslogg. Deskheroes tidslinje for saker registrerer bruk av SLA-policyer og klokkeresultater, mens Statistikkområdet rapporterer oppnåelse. Organisasjoner med formelle krav til oppbevaring bør kontrollere at disse registreringene oppfyller deres egne forpliktelser.

Skrive SLA-meldinger for brukere, ledere og kunder

Interne varsler og kundeoppdateringer har ulike formål. Hold hver melding fokusert på hva leseren kan gjøre videre.

Brukervendte varsler bør starte med lenken til saken, måltypen, tidsfristen og den umiddelbare handlingen. Unngå et avsnitt med bakgrunn om policyen når brukeren trenger å behandle saken.

Gjennomganger for ledere bør vise mønstre på tvers av en gruppe, prioritet eller policy. Én overskredet sak krever handling, mens gjentatte overskridelser krever en beslutning om bemanning eller prosess.

Kundekommunikasjon bør være nøyaktig og konkret. Hvis teamet forventer en forsinkelse, kan en oppdatering gjennomgått av et menneske angi et realistisk tidspunkt for neste kontakt. Ikke vis interne varslingsetiketter eller lov en løsningstid teamet ikke kan overholde.

Koble SLA-automatisering til verktøyene du allerede bruker

Begynn med innebygde SLA-funksjoner når de dekker de nødvendige policyene, kalenderne, pausestatusene, varslene, filtrene og rapporteringen. Innebygde tidsfrister holder seg vanligvis mer pålitelig synkronisert med endringer i saker enn et parallelt regneark.

Der den innebygde støtten er begrenset, har team brukt fellesskapsutvidelser og løsninger dokumentert i forumet. Kontroller vedlikeholdsstatus og versjonskompatibilitet før du gjør deg avhengig av denne tilnærmingen.

En separat arbeidsflyt kan være hensiktsmessig når flere systemer må sende informasjon til én eskaleringskanal. Definer først hvilken kilde som er fasiten. Doble SLA-beregninger i en helpdesk og et integrasjonslag kan avvike, særlig rundt tidssoner, arbeidstid, pausestatus og omfordeling.

Redaksjonell vurdering: Varslet er ikke poenget – handlingen er

Et varsel om at en sak snart forfaller, er bare nyttig når eierskapet er tydelig. Mottakeren trenger tillatelse, kontekst og tid til å føre saken videre.

Nøyaktige klokker kommer først. En feil arbeidsplan eller pausekonfigurasjon produserer sikre, men misvisende varsler. Rett opp beregningen av tidsfristen før du justerer meldingsformuleringen eller legger til kanaler.

Bygg i denne rekkefølgen: policymål, arbeidsplaner, pausefunksjon, varslingsmottakere, operativ respons og rapportering. Denne rekkefølgen knytter påminnelsen til en tidsfrist alle forstår.

Få SLA-påminnelsene i gang uten et migreringsprosjekt

Deskhero kobler seg til Gmail eller Microsoft 365 med toveis synkronisering, slik at team kan beholde den eksisterende supportadressen samtidig som de får delt sakshåndtering og SLA-policyer.

Deskhero

Konfigurer mål for første svar og løsning etter gruppe og prioritet, legg til en ukentlig arbeidsplan ved behov, og velg hvilke statuser som setter løsningen på pause. Deskhero viser deretter den neste tidsfristen, fremhever saker som forfaller innen én time, varsler de ansvarlige brukerne og registrerer SLA-resultater.

Den 30 dager lange gratis prøveperioden krever ikke kredittkort. Koble til én postkasse, konfigurer et lite sett med policyer, og test hele SLA-livssyklusen før du utvider oppsettet til flere grupper.

Kilder

Vanlige spørsmål

Hva er forskjellen mellom en SLA, en SLO og en SLI?

En SLA er en tjenesteforpliktelse mellom parter. En SLO er et mål for en tjenestes ytelse, som ofte brukes internt for å holde seg innenfor denne forpliktelsen. En SLI er den målte verdien som brukes til å evaluere målet.

Hva regnes som et SLA-bruddsvarsel?

Et bruddsvarsel viser at en utestående tidsfrist for første svar eller løsning er passert. Et varsel om at saken snart forfaller, er annerledes fordi teamet fortsatt har tid til å nå målet.

Hva betyr en SLA på fire timer?

Det betyr at handlingen policyen angir, for eksempel første svar eller løsning, skal utføres innen fire timer slik denne policyen beregner det. Klokken kan bruke kalendertid eller en arbeidsplan.

Hvordan skiller en SLA seg fra en KPI?

En SLA angir en tjenesteforpliktelse. En KPI måler ytelse og kan brukes til å følge med på mange mål som ikke er kontraktsfestede tidsfrister.

Kan Deskhero automatisere SLA-påminnelser uten tilpasset kode?

Ja. Deskhero har innebygde SLA-policyer, et fast varslingsvindu for saker som snart forfaller, oppdagelse av brudd, varsler i appen og på e-post, saksfiltre, dashbordvisninger og SLA-rapportering. Disse funksjonene er separate fra de generelle automatiseringsreglene.