Deskhero
Čeština
Vyzkoušet zdarma

← Back to articles

Jak automatizovat připomínky SLA, než dojde k jejich porušení

Jak automatizovat připomínky SLA, než dojde k jejich porušení

Automatické připomínky SLA by měly upozornit na tiket v době, kdy je stále ještě možné jednat, a poté jednoznačně označit tiket po překročení lhůty. Správné nastavení závisí na helpdesku. Některé platformy poskytují nativní upozornění na blížící se termín a překročení lhůty, zatímco vlastní workflow může vyžadovat naplánované kontroly a explicitní kroky eskalace.

Začněte u hodin, ne u oznámení:

  • Definujte samostatné cíle pro první odpověď a vyřešení.
  • Rozhodněte, zda cíle využívají kalendářní čas, nebo pracovní hodiny.
  • Určete, které stavy tiketu pozastavují odpočet do vyřešení.

Tip pro profesionály: Každý stav SLA otestujte pomocí testovacích tiketů, než se začnete spoléhat na ostrá upozornění. Zahrňte případy s blížícím se termínem, po překročení lhůty, pozastavené, znovu přiřazené i již dokončené.

Hlavní poznatky

Spolehlivé připomínky začínají přesně stanovenými termíny. Načasování upozornění, příjemci a postupy eskalace přicházejí až poté, co je správně nastavena samotná politika.

Oblast Podrobnosti
Definujte obě odpočítávání Sledujte první odpověď a vyřešení odděleně, protože končí při různých událostech.
Respektujte pracovní dobu Použijte pracovní kalendář, pokud se do cíle nemají započítávat noci a víkendy.
Nastavte stavy pozastavení Pozastavte cíl vyřešení, pokud tiket čeká na zákazníka nebo jinou externí stranu.
Promyšleně zvolte příjemce Zajistěte, aby upozornění na blížící se termín i překročení lhůty dostal někdo, kdo může s tiketem jednat.
Testujte před nasazením Pomocí řízených tiketů ověřte termíny, chování při pozastavení i doručování oznámení.
Nejprve využijte nativní funkce SLA Helpdesk s vestavěnými politikami, pracovními kalendáři, upozorněními, filtry a reporty eliminuje potřebu samostatného workflow s pravidelným dotazováním.

Autoritativní dokumentaci a návody, které se vyplatí prostudovat

Konkrétní příklad pro určitou platformu najdete v dokumentaci Jira k automatizovaným následným akcím. Popisuje naplánovaná pravidla i přístup založený na prahových hodnotách SLA včetně doporučení nejprve testovat malý rozsah dotazu a teprve poté jej rozšířit.

Obsah

Vytvoření automatizace připomínek SLA krok za krokem

Před nastavením upozornění si přesně sepište, co každé SLA měří. Cíl první odpovědi a cíl vyřešení představují odlišná odpočítávání. Určete, která událost tiketu každé odpočítávání spustí, která událost je dokončí a zda se termín řídí kalendářním časem, nebo pracovním kalendářem.

Poté nastavte cestu připomínky.

  1. Definujte politiku. Přiřaďte skupinám a prioritám cíle první odpovědi a vyřešení. Zahrňte také univerzální politiku pro tikety, které neodpovídají konkrétnějšímu pravidlu.
  2. Nastavte pracovní kalendář. Přidejte provozní hodiny a časové pásmo platné pro daný cíl. Pokud závazek běží nepřetržitě, použijte kalendářní čas.
  3. Nakonfigurujte chování při pozastavení. Vyberte stavy, které zastaví odpočet do vyřešení, když tým čeká na informace. Ověřte, zda lze pozastavit odpočet do první odpovědi, protože mnoho systémů s ním zachází odlišně.
  4. Povolte oznámení. Rozhodněte, kdo bude dostávat upozornění na blížící se termín a překročení lhůty a které podporované kanály helpdesk použije.
  5. Přidejte provozní reakci. Zdokumentujte, co má příjemce udělat, například odpovědět, změnit prioritu, znovu přiřadit tiket nebo zapojit vedoucího. Oznámení a nápravná akce nemusí být stejným technickým pravidlem.

Pokud helpdesk nemá nativní prahové hodnoty SLA, může naplánované workflow kontrolovat otevřené tikety a porovnávat jejich termíny s aktuálním časem. Příklad kontroly v patnáctiminutových intervalech dokumentuje LOW/CODE, ale vhodný interval závisí na nejkratším cíli, limitech API, pracovní době a míře zpoždění, kterou tým dokáže tolerovat. Ukládejte stav upozornění, aby další spuštění neposílala stejné oznámení znovu.

Volba prahových hodnot, které nevyvolají únavu z upozornění

Užitečné varování ponechává příjemci dostatek času na reakci. Procentuální práh může ve vlastním systému fungovat, ale pevně stanovené varovné okno je často srozumitelnější napříč politikami s různou délkou.

  • Bezpečně v termínu: Udržujte tiket viditelný v běžných zobrazeních fronty, ale neposílejte varování.
  • Blíží se termín: Upozorněte odpovědného uživatele nebo skupinu, dokud lze cíl ještě splnit.
  • Po překročení lhůty: Označte tiket jako po termínu a postupujte podle zdokumentovaného eskalačního procesu týmu.

Nepřebírejte univerzální hranici 80 procent, aniž byste ověřili příslušné cíle. U hodinového cíle ponechává 12 minut, zatímco u třídenního cíle více než půl dne. Změřte, kolik času tým skutečně potřebuje k provedení akce.

Opakované připomínky rychle vytvářejí šum. Nativní upozornění helpdesku by měla informovat při změně stavu, nikoli při každém obnovení obrazovky. Vlastní workflow s pravidelným dotazováním by mělo zaznamenat, že odeslalo upozornění na blížící se termín nebo překročení lhůty, a tento stav resetovat pouze tehdy, když se politika skutečně znovu spustí.

Volba prahových hodnot, které nevyvolají únavu z upozornění: přehledový diagram

Co by měla upozornění SLA obsahovat a kam by měla směřovat

Upozornění by mělo identifikovat tiket, zobrazit termín a jasně uvést očekávanou reakci. Nepřidávejte údaje o zákazníkovi, které příjemce nepotřebuje.

  • ID tiketu a odkaz, aby příjemce mohl otevřít správnou konverzaci.
  • Typ cíle, například první odpověď nebo vyřešení.
  • Termín nebo délka překročení lhůty v jednoznačně uvedeném časovém pásmu.
  • Aktuální stav, priorita, skupina a přiřazená osoba, pokud tato pole ovlivňují vlastnictví tiketu.
  • Jeden další krok, například odpovědět, znovu přiřadit tiket nebo požádat vedoucího o kontrolu.

Používejte kanály, které tým podpory již sleduje. Oznámení v aplikaci a e-mailová upozornění často postačují, pokud se spolehlivě dostanou k přiřazené osobě nebo odpovědné skupině. Pokud je vyžadován samostatný pagingový nebo komunikační systém, před návrhem procesu ověřte, zda helpdesk danou integraci podporuje.

Tip pro profesionály: Zobrazujte přesný termín nebo odpočítávání. Konkrétní čas se určuje podle priorit snáze než vágní varování.

Co by měla upozornění SLA obsahovat a kam by měla směřovat: přehledový diagram

Jak udržet časovače SLA přesné pomocí stavů pozastavení

Připomínka je důvěryhodná jen do té míry, do jaké je důvěryhodné její odpočítávání. Cíle vyřešení se běžně pozastavují, když tiket čeká na zákazníka, ale konkrétní stavy by měly odpovídat skutečnému workflow týmu.

  • Vyberte jasně definované stavy pozastavení a zdokumentujte, proč každý z nich zastavuje odpočet.
  • Obnovte odpočet, když tiket opustí stav pozastavení.
  • Otestujte tikety, které do stavu pozastavení vstoupí a znovu z něj vystoupí více než jednou.
  • Ověřte, zda se cíle první odpovědi a vyřešení řídí stejnými pravidly pozastavení.

Pracovní kalendáře řeší jiný problém. Vylučují uzavřené hodiny ze samotného cíle, zatímco stavy pozastavení vylučují čas na základě stavu tiketu. Nakonfigurujte a otestujte obojí. Víkend by se neměl započítávat do cíle podle pracovní doby a tiket z pracovního dne čekající na zákazníka by měl zůstat pozastavený, i když je tým právě v provozu.

Testování a ladění předtím, než začnete automatizaci důvěřovat

K otestování celého životního cyklu použijte řízené tikety. Historická data mohou pomoci určit realistické cíle, ale pro ověření doručování oznámení a změn termínů je lepší test ve skutečném stavu.

  1. Pokryjte každou politiku. Vytvořte testovací tiket pro každou kombinaci skupiny a priority, která může vybrat jinou politiku SLA.
  2. Použijte krátké dočasné cíle. Ověřte stavy blížícího se termínu a překročení lhůty bez čekání hodin nebo dnů a poté vraťte skutečné hodnoty.
  3. Procvičte stavy pozastavení. Pozastavte a obnovte odpočet do vyřešení a ověřte, že se termín mění podle očekávání.
  4. Zkontrolujte příjemce. Otestujte přiřazený i nepřiřazený tiket, aby správní lidé dostali jednotlivá oznámení.
  5. Prohlédněte záznam. Ověřte, že tiket uvádí použitou politiku a okamžik splnění nebo nesplnění každého cíle.

Po spuštění kontrolujte falešná varování a neuskutečněná předání. Pokud jsou upozornění přesná, ale přesto se ignorují, může být problém spíše ve vlastnictví tiketu nebo personálním obsazení než v načasování prahových hodnot.

Jak Deskhero vyřizuje připomínky SLA

Deskhero má vyhrazené politiky SLA. Ty jsou oddělené od obecných automatizačních pravidel, která nejsou naplánovaná ani založená na čase.

  • Vlastníci a administrátoři mohou seřadit politiky SLA odpovídající skupinám a prioritám tiketů. První odpovídající politika nastaví cíle první odpovědi a vyřešení.
  • Každá politika může využívat pojmenovaný týdenní pracovní kalendář s vlastním časovým pásmem, nebo počítat kalendářní čas.
  • Odpočet do vyřešení se pozastavuje ve stavech vybraných v pracovním prostoru. Odpočet do první odpovědi se nepozastavuje.
  • Deskhero označí tiket jako ohrožený během posledních 60 minut před jeho nejbližším termínem a po uplynutí termínu jej označí jako po lhůtě.
  • Kontrola na pozadí probíhá každých pět minut a odesílá oznámení v aplikaci spolu s e-mailovým souhrnem přiřazené osobě, případně členům skupiny, pokud tiket není přiřazen. Uživatelé mohou ovládat kanály upozornění SLA podle skupiny.

Seznam tiketů obsahuje sloupec SLA a filtry SLA, řídicí panel zvýrazňuje ohrožené tikety a tikety po lhůtě a časová osa tiketu zaznamenává události politik a odpočítávání. Statistiky poskytují po spuštění workflow přehledy plnění SLA.

Co sledovat po spuštění upozornění

První otázkou je, zda připomínky zabraňují překročení lhůt. Porovnejte tikety označené jako ohrožené s počtem tiketů, u nichž byl cíl později nesplněn, a poté prozkoumejte případy, u kterých varování nepomohla.

Sledujte plnění cíle první odpovědi a plnění cíle vyřešení odděleně. Kontrolujte také počet tiketů, jejichž termín nastane během varovného okna, počet tiketů již po lhůtě a politiky nebo kombinace skupiny a priority, u kterých dochází k největšímu počtu nesplnění.

Procenta doplňte provozním kontextem. Vysoké celkové procento může skrývat jednu frontu, u níž opakovaně dochází k překročení lhůty. Náhlý pokles může být způsoben změnou pracovního kalendáře, nově přidanou prioritou nebo mezerou ve vlastnictví tiketu, nikoli pomalejší prací.

Správa překrývajících se SLA bez kolizí upozornění

Tiket může mít cíl první odpovědi i cíl vyřešení. Zacházejte s nimi jako s oddělenými odpočítáváními, protože odpověď dokončí pouze první z nich. Cíl vyřešení pokračuje až do události, která jej splní.

Rozhraní tiketu by mělo zobrazovat, který z nevyřízených termínů nastane jako další, a zároveň zachovat podrobnosti o obou cílech. Filtry a reporty by také měly rozlišovat první odpověď od vyřešení, aby jeden dobrý ukazatel nezakrýval problémy v druhém.

Pokud mají zákazníci různé závazky, používejte samostatné politiky odpovídající stabilním polím tiketu, jako jsou skupina a priorita. Konkrétní politiky seřaďte před univerzální politiku a poté otestujte tiket proti každé smysluplné kombinaci. Nevytvářejte skryté smluvní úrovně, které uživatelé na tiketu nemohou vidět ani ověřit.

Jak zůstat připraveni na audit, když SLA běží automaticky

Uchovávejte záznam o použité politice, vypočtených termínech a okamžiku splnění nebo nesplnění každého cíle. Pokud změna skupiny, priority nebo kalendáře způsobí přepočet termínu, měla by být dohledatelná i tato změna.

Změny politik dokumentujte mimo schránku s oznámeními. Zaznamenejte, kdo změnu schválil, kdy nabyla účinnosti a zda se vztahuje na existující tikety. Pozdější odpovědi na dotazy zákazníků tak budou snazší a zabráníte tichým změnám významu reportu SLA.

Při smluvních kontrolách ověřte chování platformy a nepředpokládejte, že každá viditelná událost představuje auditní záznam. Časová osa tiketu v Deskhero zaznamenává použití politiky SLA a výsledky odpočítávání, zatímco oblast Statistiky reportuje plnění. Organizace s formálními požadavky na uchovávání záznamů by měly ověřit, zda tyto záznamy splňují jejich vlastní povinnosti.

Jak psát zprávy SLA pro uživatele, manažery a zákazníky

Interní upozornění a aktualizace pro zákazníky slouží různým účelům. Každé z nich zaměřte na to, co může jeho příjemce udělat jako další krok.

Upozornění pro uživatele by měla začínat odkazem na tiket, typem cíle, termínem a okamžitou akcí. Pokud uživatel potřebuje na tiketu pracovat, vyhněte se odstavci s podrobným vysvětlením politiky.

Kontroly pro manažery by měly zobrazovat vzorce napříč skupinou, prioritou nebo politikou. Jeden nesplněný tiket vyžaduje zásah, zatímco opakované nesplnění vyžaduje rozhodnutí o personálním obsazení nebo procesu.

Komunikace se zákazníky by měla být přesná a konkrétní. Pokud tým očekává zpoždění, aktualizace zkontrolovaná člověkem může stanovit realistický čas dalšího kontaktu. Neodhalujte interní označení upozornění ani neslibujte čas vyřešení, který tým nemůže dodržet.

Propojení automatizace SLA s nástroji, které již používáte

Začněte s nativními funkcemi SLA, pokud pokrývají požadované politiky, kalendáře, stavy pozastavení, upozornění, filtry a reporty. Nativní termíny obvykle zůstávají synchronizované se změnami tiketů spolehlivěji než paralelní tabulka.

Tam, kde je nativní podpora omezená, týmy využívaly komunitní pluginy a řešení popsaná na fórech. Před závislostí na tomto přístupu zkontrolujte stav údržby a kompatibilitu verzí.

Samostatné workflow může být vhodné, pokud musí několik systémů zásobovat jeden eskalační kanál. Nejprve definujte zdroj pravdy. Duplicitní výpočty SLA v helpdesku a integrační vrstvě se mohou rozcházet, zejména u časových pásem, pracovní doby, stavů pozastavení a opětovného přiřazení.

Redakční pohled: Upozornění není to hlavní, důležitá je akce

Upozornění na blížící se termín je užitečné pouze tehdy, když je jasné, kdo tiket vlastní. Příjemce potřebuje oprávnění, kontext a čas k posunutí tiketu vpřed.

Přesnost časovače je na prvním místě. Nesprávný pracovní kalendář nebo nastavení pozastavení vytváří sebejistá, ale zavádějící upozornění. Než upravíte znění zpráv nebo přidáte další kanály, opravte výpočet termínu.

Postupujte v tomto pořadí: cíle politik, pracovní kalendáře, chování při pozastavení, příjemci upozornění, provozní reakce a reporty. Díky tomuto pořadí zůstane připomínka navázaná na termín, kterému všichni rozumějí.

Spusťte připomínky SLA bez migračního projektu

Deskhero se obousměrně synchronizuje s Gmailem nebo Microsoft 365, takže týmy mohou zachovat svou stávající adresu podpory a zároveň přidat sdílené zpracování tiketů a politiky SLA.

Deskhero

Nastavte cíle první odpovědi a vyřešení podle skupiny a priority, v případě potřeby přidejte týdenní pracovní kalendář a vyberte stavy, které pozastavují vyřešení. Deskhero poté zobrazí nejbližší termín, zvýrazní tikety s termínem během jedné hodiny, upozorní odpovědné uživatele a zaznamená výsledky SLA.

30denní bezplatná zkušební verze nevyžaduje kreditní kartu. Připojte jednu schránku, nakonfigurujte malou sadu politik a před rozšířením nastavení na další skupiny otestujte celý životní cyklus SLA.

Zdroje

Časté dotazy

Jaký je rozdíl mezi SLA, SLO a SLI?

SLA je závazek týkající se úrovně služeb mezi stranami. SLO je cíl výkonnosti služby, který se často používá interně k dodržení tohoto závazku. SLI je naměřená hodnota používaná k vyhodnocení cíle.

Co se považuje za upozornění na překročení SLA?

Upozornění na překročení lhůty znamená, že uplynul termín pro první odpověď nebo vyřešení. Upozornění na blížící se termín je jiné, protože týmu stále zbývá čas cíl splnit.

Co znamená SLA na 4 hodiny?

Znamená to, že akce uvedená v politice, například první odpověď nebo vyřešení, musí být podle výpočtu dané politiky dokončena do čtyř hodin. Odpočet může využívat kalendářní čas nebo pracovní kalendář.

Jak se SLA liší od KPI?

SLA stanovuje závazek týkající se úrovně služby. KPI měří výkonnost a může se používat ke sledování mnoha cílů, které nepředstavují smluvní termíny.

Dokáže Deskhero automatizovat připomínky SLA bez vlastního kódu?

Ano. Deskhero má vestavěné politiky SLA, pevně stanovené varovné okno před termínem, detekci překročení lhůty, oznámení v aplikaci a e-mailem, filtry tiketů, zobrazení v řídicím panelu a reporty SLA. Tyto funkce jsou oddělené od obecných automatizačních pravidel.