Šablona dat pro správu problémů

Zendesk Support
Šablona dat pro správu problémů

Šablona dat pro správu problémů

Tato šablona nabízí rámec pro mapování životního cyklu správy problémů v Zendesk Support. Obsahuje potřebné atributy, milníky procesu a pravidla extrakce dat, které pomáhají odhalit úzká místa při analýze hlavních příčin. Podle této struktury můžete sestavit kvalitní záznam událostí a získat podrobnější přehled o procesu.
  • Doporučené atributy pro podrobnou analýzu
  • Důležité aktivity procesu a změny stavu
  • Pokyny k extrakci dat ze Zendesk Support
Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Atributy řízení problémů

Tato doporučená datová pole poskytují potřebný kontext pro analýzu kategorií tiketů, úrovní priority a odpovědnosti v průběhu celého životního cyklu řešení problému.
5 Povinné 8 Doporučené 6 Volitelné
Název Popis
Aktivita
ActivityName
Název události nebo akce provedené se záznamem o problému.
Popis

Tento atribut zachycuje konkrétní krok nebo akci v životním cyklu záznamu o problému. Může jít například o změnu stavu z 'Open' na 'Pending', změnu přiřazení nebo konkrétní krok workflow, jako je 'Workaround Published'.

Při analýze tvoří tyto aktivity uzly mapy procesu. Jejich posloupnost umožňuje analytikům zobrazit průběh práce, odhalit úzká místa a měřit dobu mezi jednotlivými kroky procesu.

Proč je to důležité

Popisuje, co se v procesu děje, a umožňuje zobrazit tok procesu a analyzovat jeho varianty.

Kde data získat

Odvozuje se z auditních záznamů Zendesk Ticket nebo z metrik Zendesk Ticket

Příklady
Záznam o problému vytvořenZahájeno šetřeníZveřejněno náhradní řešení
Čas zahájení
EventTimestamp
Konkrétní datum a čas, kdy k aktivitě došlo.
Popis

Tento atribut zaznamenává přesný okamžik, kdy aktivita proběhla v systému Zendesk. Poskytuje časový údaj potřebný ke správnému seřazení událostí a výpočtu doby mezi jednotlivými kroky.

Při analýze je zásadní pro výpočet doby průchodu, odhalování zdržení, kontrolu dodržování SLA a zobrazení procesu v čase. Bez přesných časových razítek nelze zjistit, jak rychle probíhá řešení problémů.

Proč je to důležité

Umožňuje řadit aktivity a počítat všechny časové KPI.

Kde data získat

Auditní záznamy Zendesk Ticket, pole 'created_at'

Příklady
2023-10-12T08:30:00Z2023-10-12T09:15:22Z
Poslední aktualizace dat
LastDataUpdate
Časové razítko poslední změny záznamu o problému.
Popis

Tento atribut uvádí, kdy byla data záznamu o problému naposledy aktualizována ve zdrojovém systému. Liší se od časového razítka události, protože se vztahuje k celému záznamu, nikoli k jednotlivé aktivitě.

Při analýze pomáhá určit aktuálnost dat. Umožňuje zjistit, zda je datová sada aktuální, nebo zda dochází ke zpoždění synchronizace mezi zdrojovým systémem a prostředím process mining.

Proč je to důležité

Sleduje aktuálnost dat a pomáhá s postupným načítáním dat.

Kde data získat

Objekt Zendesk Ticket, pole 'updated_at'

Příklady
2023-11-01T14:20:00Z
Záznam o problému
ProblemRecordId
Jedinečný číselný identifikátor přiřazený požadavku na problém v Zendesk.
Popis

Tento atribut představuje jedinečný klíč záznamu o problému v systému Zendesk Support. Slouží jako hlavní ID případu pro process mining a umožňuje seskupit všechny navazující události, aktualizace a interakce do jedné instance procesu.

Při analýze se toto ID používá k jednoznačnému rozlišení jednotlivých šetření problémů od vytvoření až po uzavření. Umožňuje propojit související incidenty a sledovat životní cyklus problému napříč různými úrovněmi podpory.

Proč je to důležité

Jde o základní povinný klíč, který je nutný k seskupení událostí do případů při jakékoli analýze process mining.

Kde data získat

Objekt Zendesk Ticket, pole 'id', kde type je 'problem'

Příklady
1045293849921
Zdrojový systém
SourceSystem
Název systému, ze kterého data pocházejí.
Popis

Tento atribut určuje softwarovou platformu, ze které byla procesní data získána. V tomto případě bude vždy obsahovat hodnotu 'Zendesk Support'.

Při analýze, zejména při kombinování dat z více systémů, například Zendesk a Jira, umožňuje toto pole filtrovat nebo seskupovat data podle zdroje. V přehledech procesů napříč systémy zajišťuje dohledatelnost původu dat.

Proč je to důležité

Zajišťuje dohledatelnost původu dat a podporuje nastavení process mining napříč více systémy.

Kde data získat

Nastaví se pevně při extrakci

Příklady
Zendesk Support
Jméno řešitele
AssigneeName
Konkrétní agent přiřazený k řešení problému.
Popis

Tento atribut obsahuje jméno uživatele, který právě odpovídá za záznam o problému. Umožňuje přesně zjistit, kdo provedl jednotlivé akce.

Při analýze pomáhá porozumět pracovní zátěži a výkonu jednotlivců. Analýza na úrovni skupin je běžná, ale údaje o konkrétních řešitelích mohou odhalit potřebu školení nebo ukázat, kdo zvládá složité hlavní příčiny obzvlášť dobře.

Proč je to důležité

Umožňuje analyzovat zdroje na úrovni jednotlivců.

Kde data získat

Objekt Zendesk Ticket, pole 'assignee_id' (převedené na jméno)

Příklady
Jan NovákJana SvobodováSystém
Kategorie hlavní příčiny
RootCauseCategory
Zjištěná příčina problému, například chyba v kódu nebo konfiguraci.
Popis

Tento atribut zaznamenává konečnou diagnózu příčiny problému. Obvykle se vyplňuje při aktivitě „Zjištění hlavní příčiny“.

Při analýze slouží k vytvoření přehledu „Přesnost kategorizace problémů“ a ke sledování trendů systémových selhání. Vedení díky němu může posoudit, zda se zaměřit na kvalitu kódu, stabilitu infrastruktury nebo správu dodavatelů.

Proč je to důležité

Umožňuje analyzovat vzorce selhání a zaměřit dlouhodobé zlepšování.

Kde data získat

Vlastní pole ticketu v Zendesk

Příklady
Chyba v softwaruChyba konfiguraceChyba uživatele
Kategorie problému
ProblemCategory
Klasifikace problému, například software, hardware nebo síť.
Popis

Tento atribut zařazuje problém podle dotčené služby nebo technologické platformy. V Zendesk formulářích jde obvykle o vlastní pole s výběrem z nabídky.

Při analýze slouží pro dashboard „Přesnost kategorizace problémů“. Porovnání původní kategorie s konečnou příčinou pomáhá zjistit, zda prvotní třídění správně směruje problémy příslušným týmům.

Proč je to důležité

Umožňuje rozdělit problémy podle technologie nebo obchodní služby.

Kde data získat

Vlastní pole ticketu v Zendesk

Příklady
DatabázeUživatelské rozhraní a prostředíSíťová infrastruktura
Počet souvisejících incidentů
RelatedIncidentCount
Počet požadavků na incident propojených s tímto záznamem o problému.
Popis

Tento atribut počítá jednotlivé požadavky na incident propojené s daným záznamem o problému. V Zendesk se propojení provádí pomocí pole 'problem_id' v požadavcích na incident, které odkazuje na tento záznam.

Při analýze jde o hlavní metriku pro korelaci incidentů a jejich dopadu. Pomáhá upřednostnit problémy, které se týkají největšího počtu uživatelů, a rozhodnout, které opravy nejvíce sníží počet požadavků na podporu.

Proč je to důležité

Ukazuje rozsah problému a jeho dopad na uživatele.

Kde data získat

Zendesk Tickets API, počet požadavků, kde type='incident' a problem_id=ThisID

Příklady
015342
Priorita
Priority
Úroveň naléhavosti přiřazená záznamu o problému.
Popis

Tento atribut vyjadřuje relativní závažnost problému, obvykle jako Nízká, Normální, Vysoká nebo Naléhavá. Určuje očekávané úrovně služeb (SLA) a rozdělení zdrojů.

Při analýze se používá k rozdělení procesu do skupin a porovnání výsledků podle úrovně naléhavosti. Pomáhá například ověřit, zda se problémy s prioritou 'Naléhavá' skutečně řeší rychleji než problémy s prioritou 'Nízká', jak požaduje dashboard rychlosti analýzy hlavních příčin.

Proč je to důležité

Je nezbytná pro rozdělení případů při analýze dodržování SLA a určování priorit při přidělování zdrojů.

Kde data získat

Objekt Zendesk Ticket, pole 'priority'

Příklady
NaléhaváVysokáNormálníNízká
Skupina podpory
SupportGroup
Tým nebo oddělení, kterému je záznam o problému aktuálně přiřazen.
Popis

Tento atribut určuje konkrétní skupinu agentů odpovědných za řešení problému v daném okamžiku. Mění se při předání požadavku z jednoho týmu druhému.

Je důležitý pro dashboard analýzy předávání mezi skupinami podpory. Umožňuje měřit výsledky jednotlivých týmů, odhalovat úzká místa při předávání a analyzovat rozložení pracovní zátěže.

Proč je to důležité

Umožňuje analyzovat práci napříč organizací a odhalovat úzká místa mezi odděleními.

Kde data získat

Objekt Zendesk Ticket, pole 'group_id' (převedené na název)

Příklady
Podpora 2. úrovněDatabázový týmProvoz sítě
Stav problému
ProblemStatus
Aktuální stav záznamu o problému v jeho životním cyklu.
Popis

Tento atribut uvádí aktuální stav problému, například New, Open, Pending, Solved nebo Closed. Odráží průběh šetření.

Při analýze se používá k filtrování otevřených a uzavřených případů. Je důležitý pro dashboard sledování neaktivních záznamů o problémech, který pomáhá odhalit aktivní případy, jež nepostupují očekávaným životním cyklem stavů.

Proč je to důležité

Umožňuje filtrovat případy podle stavu dokončení.

Kde data získat

Objekt Zendesk Ticket, pole 'status'

Příklady
novýotevřenýčekajícívyřešenýuzavřený
Termín SLA
SlaDueDate
Cílové datum a čas, do kdy má být problém vyřešen.
Popis

Tento atribut představuje termín řešení podle nastavení dohody o úrovni služeb. Obvykle se vypočítává podle priority a času vytvoření požadavku.

Při analýze se porovnává se skutečnou dobou řešení a používá se k výpočtu míry dodržování SLA u problémů. Dashboard výkonnosti a rizik SLA díky němu upozorňuje na případy, u kterých se blíží termín nebo už byl překročen.

Proč je to důležité

Je nezbytný pro měření dodržování dohod a plnění smluvních závazků.

Kde data získat

Endpoint Zendesk Ticket Metrics nebo SLA Policies

Příklady
2023-12-01T17:00:00Z
Bez nedávné aktivity
IsStale
Označuje, zda u problému neproběhla žádná aktivita déle než 14 dní.
Popis

Tento vypočítaný atribut označuje záznamy, které nebyly v poslední době aktualizovány. Porovnává aktuální datum (nebo datum analýzy) s časem poslední aktivity.

Při analýze slouží pro dashboard „Sledování neaktivních záznamů problémů“. Manažeři díky němu rychle najdou opomenuté případy, které zbytečně zůstávají v nevyřízených položkách a mohou vyžadovat administrativní uzavření nebo nové přiřazení.

Proč je to důležité

Pomáhá odhalit plýtvání v procesu a opomenuté pracovní položky.

Kde data získat

Vypočítáno v nástroji process mining: (Now - LastDataUpdate) > 14 days

Příklady
truefalse
Dočasné řešení aktivní
WorkaroundActive
Příznak označující, zda bylo poskytnuto nebo zveřejněno dočasné řešení.
Popis

Tento booleovský atribut označuje, zda bylo pro problém zdokumentováno dočasné řešení. Obvykle se odvozuje z aktivity „Zveřejnění dočasného řešení“ nebo z konkrétního zaškrtávacího pole ve formuláři.

Při analýze slouží pro dashboard „Dodržování zveřejňování dočasných řešení“. Měří, jak často tým podpory poskytne uživatelům okamžitou úlevu, zatímco pokračuje dlouhodobé šetření.

Proč je to důležité

Pomáhá měřit, jak se během šetření zmírňuje dopad na uživatele.

Kde data získat

Odvozeno z aktivity „Zveřejnění dočasného řešení“ nebo z vlastního pole

Příklady
truefalse
ID článku znalostní báze
KnowledgeArticleId
ID článku znalostní báze vytvořeného v souvislosti s problémem nebo k němu připojeného.
Popis

Tento atribut uchovává odkaz na článek v Zendesk Guide nebo na externí položku znalostní báze. Ukazuje, že poznatky získané při řešení problému byly zaznamenány.

Při analýze se podle vyplnění tohoto pole počítá „Míra propojení se znalostní bází“. Ověřuje, zda organizace zaznamenává řešení pro budoucí použití a uzavírá tak cyklus učení.

Proč je to důležité

Měří účinnost procesů správy znalostí.

Kde data získat

Vlastní pole ticketu v Zendesk nebo propojený obsah

Příklady
360045889KB-2991
ID požadavku na změnu
ChangeRequestId
Identifikátor požadavku na změnu propojeného s implementací opravy.
Popis

Tento atribut propojuje záznam problému se záznamem správy změn, případně v jiném systému nebo pod jiným typem ticketu. Znamená, že byl zahájen formální proces změny.

Při analýze podporuje dashboard „Míra zahájení požadavků na změnu“. Pomáhá sledovat přechod od diagnózy k implementaci a ověřit, zda zjištěné hlavní příčiny vedou k formálním změnovým opatřením.

Proč je to důležité

Propojuje proces řešení problémů s procesem správy změn.

Kde data získat

Vlastní pole ticketu v Zendesk nebo propojené tickety

Příklady
CR-1002CHG00394
Předmět problému
ProblemSubject
Stručný popis nebo název záznamu o problému.
Popis

Tento atribut obsahuje textový souhrn zadaný při vytvoření problému. Obvykle popisuje příznak nebo řešený problém.

Při analýze poskytuje analytikovi kontext při prohlížení konkrétních případů. Lze na něj použít také metody textové analýzy a seskupit podobné problémy nebo odhalit opakující se témata, která nejsou zachycena ve strukturovaných polích kategorií.

Proč je to důležité

Poskytuje srozumitelný kontext ke konkrétním případům.

Kde data získat

Objekt Zendesk Ticket, pole 'subject'

Příklady
V oblasti EU nelze zpracovat platbyVýkyvy latence na přihlašovacím serveruExport dat selhává uživatelům s oprávněním správce
Proběhla kontrola po implementaci
HasPostImplementationReview
Označuje, zda proběhla kontrola po implementaci.
Popis

Tento atribut označuje, zda proces řešení problému zahrnoval fázi kontroly. Odvozuje se z toho, zda se v historii případu nachází aktivita „Provedení kontroly po implementaci“.

Při analýze podporuje dashboard „Pokrytí kontrolami po implementaci“. Jde o ukazatel shody, který ověřuje, zda se organizace poučila z významných problémů.

Proč je to důležité

Ověřuje shodu s procesy průběžného zlepšování.

Kde data získat

Odvozeno z aktivity „Provedení kontroly po implementaci“

Příklady
truefalse
Povinné Doporučené Volitelné

Aktivity při řízení problémů

Zaznamenávejte tyto důležité kroky procesu a změny stavů. Zobrazíte tak celý průběh od prvotního rozpoznání problému až po zavedení trvalé opravy.
8 Doporučené 4 Volitelné
Aktivita Popis
Nasazena trvalá oprava
Označuje nasazení technického řešení do prostředí. Obvykle se sleduje pomocí vlastní změny stavu nebo konkrétního štítku před úplným vyřešením požadavku.
Proč je to důležité

Nezbytné pro měření doby od diagnostiky po nasazení v dashboardu efektivity implementace oprav.

Kde data získat

Odvozuje se z konkrétního štítku, například 'fix_deployed', nebo z vlastního pole stavu, pokud je k dispozici.

Zachycení

Sledujte štítky nebo vlastní rozbalovací nabídky stavu

Typ události inferred
Ověřeno vyřešení
Formální označení problému jako vyřešeného. V Zendesk k tomu dojde, když se standardní stav systému změní na 'Solved', což znamená, že oprava byla ověřena a případ je dokončen.
Proč je to důležité

Hlavní koncový bod pro výpočty výkonnosti a rizik SLA a míry dodržování SLA u problémů.

Kde data získat

Odvozuje se ze změny stavu požadavku na 'Solved'.

Zachycení

Zaznamená se při změně stavu na Solved

Typ události explicit
Přiřazeno skupině podpory
Předání záznamu o problému konkrétnímu technickému týmu nebo oddělení. Sleduje se při aktualizaci pole Group ID v požadavku.
Proč je to důležité

Nezbytné pro měření čekání mezi odděleními v dashboardu analýzy předávání mezi skupinami podpory.

Kde data získat

Sledujte změny pole 'group_id' v auditním záznamu požadavku.

Zachycení

Zaznamená se při provedení transakce Group Assignment Change

Typ události explicit
Zahájeno šetření
Označuje přechod z neaktivního stavu 'New' do aktivního řešení. Agent tím potvrzuje, že problém převzal a zahájil diagnostiku.
Proč je to důležité

Používá se k výpočtu ukazatelů neaktivních záznamů o problémech a jako začátek KPI průměrné délky analýzy hlavní příčiny.

Kde data získat

Odvozuje se ze změny stavu požadavku z 'New' na 'Open' nebo 'Pending'.

Zachycení

Porovnejte hodnotu pole stavu před změnou a po ní

Typ události inferred
Záznam o problému uzavřen
Závěrečná událost životního cyklu, při které se požadavek uzamkne a nelze v něm provádět další změny. V Zendesk k tomu obvykle dojde automaticky 4 dny po přechodu do stavu Solved.
Proč je to důležité

Označuje definitivní konec životního cyklu záznamu a používá se pro uchovávání dat a historické přehledy.

Kde data získat

Odvozuje se ze změny stavu požadavku na 'Closed'.

Zachycení

Zaznamená se při změně stavu na Closed

Typ události explicit
Záznam o problému vytvořen
Vytvoření požadavku na problém v Zendesk Support. Událost zaznamenává čas, kdy byl problém poprvé zapsán do systému, a obvykle tím zahajuje instanci procesu.
Proč je to důležité

Určuje začátek celého cyklu řešení a slouží jako výchozí bod pro měření všech navazujících dob průchodu.

Kde data získat

Odvozuje se z časového razítka 'created_at' v objektu požadavku nebo z první položky v auditním záznamu požadavku.

Zachycení

Zaznamená se při provedení transakce Ticket Created

Typ události explicit
Zjištěna hlavní příčina
Okamžik, kdy je určena základní příčina problému. Obvykle se zaznamená vyplněním vlastního textového pole 'Root Cause' nebo výběrem hodnoty z rozbalovací nabídky agentem.
Proč je to důležité

Důležitý milník pro dashboard rychlosti analýzy hlavních příčin a měření efektivity diagnostiky.

Kde data získat

Sledujte změny vlastních polí označených 'Root Cause', 'RCA' nebo 'Problem Source', která získají hodnotu.

Zachycení

Porovnejte, zda byla vlastní pole vyplněna

Typ události inferred
Zveřejněno náhradní řešení
Zdokumentování a sdílení dočasného řešení problému. V Zendesk se tato událost často zaznamenává pomocí konkrétního štítku nebo vlastního zaškrtávacího pole, které označuje dostupnost náhradního řešení.
Proč je to důležité

Podporuje dashboard dodržování pravidel pro zveřejňování náhradních řešení a pomáhá zajistit, aby uživatelé měli dočasné řešení k dispozici i během dlouhého šetření.

Kde data získat

Sledujte přidání štítku 'workaround_published' nebo změnu vlastního logického pole s názvem 'Workaround'.

Zachycení

Porovnejte hodnoty vlastního pole nebo štítku

Typ události inferred
Připraven návrh řešení
Vytvoření článku znalostní báze na základě šetření problému. Událost se odvozuje od použití aplikace Zendesk Knowledge Capture nebo propojení nového článku.
Proč je to důležité

Podporuje KPI míry integrace znalostní báze a pomáhá zachovat znalosti v organizaci.

Kde data získat

Sledujte události související s integrací 'Knowledge Capture' nebo štítky jako 'kcs_draft'.

Zachycení

Odvoďte událost z konkrétních systémových štítků nebo událostí propojení

Typ události inferred
Provedena kontrola po nasazení
Potvrzení, že po opravě proběhla zpětná kontrola. Obvykle se zaznamenává zaškrtnutím pole nebo vyplněním data koordinátorem procesu.
Proč je to důležité

Požadavek pro KPI četnosti kontrol po nasazení, který pomáhá zajistit dodržování standardů kvality.

Kde data získat

Sledujte aktualizace vlastního zaškrtávacího pole 'PIR Completed' nebo datového pole 'PIR Date'.

Zachycení

Sledujte dokončení ve vlastním poli

Typ události inferred
Zahájen požadavek na změnu
Označuje zahájení formálního procesu řízení změn s cílem problém vyřešit. Událost se obvykle odvozuje od vyplnění vlastního pole 'Change Request ID' nebo propojení s požadavkem typu 'Change'.
Proč je to důležité

Sleduje míru zahájených požadavků na změnu a propojuje workflow správy problémů a řízení změn.

Kde data získat

Sledujte aktualizace vlastního pole, například 'change_reference', nebo vytvoření odkazu typu 'problem_change'.

Zachycení

Sledujte zadání externího ID do vlastního pole

Typ události inferred
Znovu otevřeno šetření problému
Nastane, když se záznam o problému, který byl dříve označen jako vyřešený, vrátí do stavu Open nebo jiného aktivního stavu. Znamená to, že oprava selhala nebo řešení nebylo přijato.
Proč je to důležité

Podporuje KPI míry znovuotevření problémů a pomáhá odhalit nedostatky v procesu řešení.

Kde data získat

Odvozuje se z přechodu stavu ze 'Solved' zpět na 'Open', 'New' nebo 'Pending'.

Zachycení

Porovnejte hodnotu pole stavu před změnou a po ní

Typ události inferred
Doporučené Volitelné

Návody k extrakci dat

Jak získat data ze Zendesk Support

Chcete začít?

Použijte tuto šablonu ve svém prostředí Zendesk a získejte lepší přehled o stabilitě IT. Náš tým vám pomůže upravit extrakci dat a začít s process mining.

Zlepšete řízení problémů a urychlete opravy v IT

Zkraťte dobu řešení o 30 % a odstraňte úzká místa v IT.

Spustit zkušební verzi

Platební kartu nepotřebujete. Nastavení zabere jen několik minut.