> Průběžné zlepšování procesů > Správa incidentů > Zendesk Support > Datová šablona

Šablona dat pro řízení incidentů

Zendesk Support

Atributy řízení incidentů(23) Aktivity v řízení incidentů(13) Návody k extrakci dat(4)

Šablona dat pro řízení incidentů

Tato šablona přehledně shrnuje data potřebná k analýze procesu řízení incidentů. Uvádí atributy, které je vhodné shromažďovat, důležité aktivity, které je třeba sledovat, a praktický postup pro získání dat ze Zendesk Support. Pomůže vám připravit úplný a kvalitní dataset pro projekt process mining.

Doporučené atributy ke shromažďování
Důležité aktivity pro mapování procesů
Praktický návod k extrakci dat

Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Stáhnout šablonu

Atributy řízení incidentů

Toto jsou doporučená datová pole pro záznam událostí, který použijete k důkladné analýze procesu řízení incidentů.

5 Povinné 7 Doporučené 11 Volitelné

	Název	Popis
	Časové razítko události EventTimestamp	Přesné datum a čas, kdy k aktivitě došlo.
Popis Toto časové razítko zaznamenává přesný okamžik události v životním cyklu incidentu, například přidání komentáře nebo změnu stavu. Určuje chronologické pořadí všech aktivit v rámci případu. Tento atribut je základem časové analýzy process mining. Používá se k výpočtu doby mezi aktivitami, určení čekání, měření celkové délky případu a analýze výkonnosti procesu v různých obdobích. Přesná časová razítka jsou nezbytná pro vytvoření animované mapy procesu, která ukazuje průběh případů v čase, i pro sestavení dashboardů výkonnosti se sledovanými KPI, například průměrnou dobou řešení. Proč je to důležité Časová razítka určují časové pořadí aktivit. Umožňují vypočítat dobu trvání, odhalit úzká místa a analyzovat výkonnost procesu v čase. Kde data získat Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), pole created_at u každé události auditu. Příklady 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	ID incidentu TicketId	Jedinečný identifikátor incidentu, který automaticky vytvoří systém.
Popis ID incidentu je primární klíč, který jednoznačně identifikuje každý případ v Zendesk Support. V process mining slouží jako CaseId a propojuje všechny související aktivity, změny stavu a komunikaci od vytvoření incidentu až po jeho uzavření. Toto ID je zásadní pro rekonstrukci celého průběhu každého incidentu. Umožňuje spojit data o událostech a sledovat metriky jednotlivých případů, například celkovou dobu řešení, počet předání a dodržování smluv o úrovni služeb. Seskupením událostí podle tohoto ID mohou analytici zobrazit průběh procesu, odhalit obvyklé cesty a zjistit odchylky od standardního postupu. Proč je to důležité Tento nezbytný identifikátor propojuje všechny události s jedním incidentem. Díky tomu lze sledovat celý jeho životní cyklus a přesně analyzovat výkonnost procesu. Kde data získat Zendesk Tickets API (/api/v2/tickets/{id}), pole id. Příklady 19428230113521941055
	Aktivita ActivityName	Název obchodní aktivity nebo události, ke které došlo v určitém okamžiku životního cyklu incidentu.
Popis Tento atribut popisuje konkrétní krok nebo činnost v procesu řízení incidentů, například „Incident vytvořen“, „Tiket přiřazen agentovi“ nebo „Incident vyřešen“. Aktivity se odvozují ze záznamu událostí nebo auditních dat Zendesk, kde se zaznamenávají změny v systému. V process mining tvoří posloupnost těchto aktivit mapu procesu, která je základem analýzy. Analýza jejich průběhu ukáže skutečné cesty incidentů, úzká místa mezi kroky, opakované smyčky, například znovuotevření vyřešeného tiketu, i to, zda proces odpovídá stanovenému standardu. Proč je to důležité Pořadí aktivit určuje průběh procesu. Ten je základem analýzy process mining, která odhaluje neefektivitu, odchylky a příležitosti ke zlepšení. Kde data získat Odvozuje se z událostí v Zendesk Ticket Audits API. Například událost Change u pole status lze převést na „Změna stavu“. Příklady Incident vytvořenTiket přiřazen agentoviStav změněn na čekajícíIncident vyřešenIncident uzavřen
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat pro tento proces.
Popis Tento atribut zaznamenává datum a čas posledního exportu nebo aktualizace dat ze zdrojového systému. Obvykle jde o jednu hodnotu platnou pro celou datovou sadu v daném cyklu aktualizace. Tato informace je důležitá pro správu dat i pro uživatele analýzy process mining. Ukazuje, jak aktuální data jsou, a pomáhá analytikům zjistit, zda pracují s nejnovějšími dostupnými informacemi. To je důležité zejména při sledování provozní výkonnosti a včasném rozhodování na základě analýzy. Proč je to důležité Ukazuje, jak aktuální data jsou, aby uživatelé věděli, z jakého období analýza vychází a kdy byla data naposledy získána. Kde data získat Časové razítko vytvořené procesem ETL nebo datovým tokem po dokončení aktualizace dat. Příklady 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého byla data o incidentech získána.
Popis Tento atribut určuje původ procesních dat. V tomto přehledu by jeho hodnota byla statická, například „Zendesk Support“, což znamená, že všechny události a atributy pocházejí z tohoto systému. V prostředích, kde se kombinují data z více systémů, je toto pole důležité pro rozlišení zdrojů. Pomáhá zachovat integritu dat a umožňuje analýzu podle zdroje, například porovnání řízení incidentů v Zendesk s jiným nástrojem ITSM. Proč je to důležité Určuje původ dat. To je důležité pro správu dat i analýzy, které kombinují data z více zdrojových systémů. Kde data získat Statická hodnota nastavená při transformaci dat, která určuje jejich původ. Příklady Zendesk SupportZendesk
	Čas ukončení události EventEndTime	Časová značka určující, kdy byla činnost dokončena.
Popis Čas ukončení události označuje konec činnosti. V datech záznamu událostí se čas ukončení jedné činnosti často odvozuje od času zahájení následující činnosti v daném případu. U poslední činnosti případu může být čas ukončení stejný jako čas zahájení. Tento atribut je nezbytný pro výpočet doby trvání jednotlivých činností (ProcessingTime) i čekání mezi nimi. Tyto údaje tvoří základ analýzy úzkých míst. Analytici tak zjistí nejen to, jak dlouho krok trvá, ale také jak dlouho byl případ nečinný před jeho zahájením. Proč je to důležité Umožňuje počítat dobu trvání činností a čekání. To je základ podrobné analýzy úzkých míst a zpoždění v procesu. Kde data získat Vypočítá se jako čas zahájení následující události v rámci stejného případu. Čas ukončení poslední události může být stejný jako její čas zahájení nebo čas uzavření případu. Příklady 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	Kanál nahlášení Channel	Kanál, kterým byl incident původně nahlášen, například „E-mail“, „Web“ nebo „API“.
Popis Tento atribut zachycuje způsob, jakým koncový uživatel nebo systém vytvořil tiket incidentu. Znalost kanálu je důležitá při analýze zdrojů incidentů a přizpůsobování procesu podpory. Analýza incidentů podle kanálu může odhalit různé vzorce. Například incidenty nahlášené telefonicky se mohou řešit rychleji než incidenty oznámené e-mailem. Tyto informace podporují dashboard „Incident Throughput Volume“ a pomáhají při plánování zdrojů i optimalizaci kanálů. Proč je to důležité Umožňuje analyzovat objem incidentů a průběh procesu podle zdroje. Podporuje cílené zlepšování jednotlivých kanálů i plánování zdrojů. Kde data získat Zendesk Tickets API, pole via.channel. Příklady webe-mailapitelefon
	Priorita TicketPriority	Priorita přiřazená incidentu, například „Nízká“, „Normální“, „Vysoká“ nebo „Naléhavá“.
Popis Priorita incidentu určuje, jak rychle je třeba reagovat a problém vyřešit. Ovlivňuje také stanovení pořadí práce a přidělování zdrojů v týmu podpory. Při analýze procesů se podle priority rozdělují incidenty do skupin, aby bylo možné porovnat jejich průběh a výsledky. Analytici mohou například ověřit, zda se „Naléhavé“ incidenty skutečně řeší rychleji než incidenty s „Nízkou“ prioritou. Priorita se používá také ke sledování plnění SLA, protože cíle SLA se často liší podle úrovně priority. KPI „Míra změn priority“ vychází ze sledování změn tohoto pole. Proč je to důležité Tento atribut umožňuje rozdělit analýzu podle naléhavosti, vyhodnotit účinnost stanovení priorit a sledovat plnění SLA. Kde data získat Zendesk Tickets API, pole priority. Změny se zaznamenávají v Ticket Audits API. Příklady nízkánormálnívysokánaléhavá
	Přiřazená skupina AssignedGroup	Tým nebo skupina podpory, které je incident právě přiřazen.
Popis Tento atribut určuje, který tým za incident odpovídá. Incidenty často přecházejí mezi různými úrovněmi podpory nebo specializovanými skupinami, například z „L1 Support“ do „Network Team“. Jde o důležitý údaj pro analýzu předávání práce a hledání úzkých míst. Sledováním toku incidentů mezi skupinami mohou analytici měřit závislosti mezi týmy, počítat dobu čekání ve frontě jednotlivých týmů a upravovat pravidla směrování. Atribut přímo podporuje dashboard „Analýza předávání a opakované práce“. Proč je to důležité Sleduje, který tým za incident odpovídá. To je důležité pro analýzu předávání mezi týmy, hledání úzkých míst v jednotlivých týmech a měření čekání ve frontách. Kde data získat Zendesk Tickets API, pole group_id. Změny se zaznamenávají v Ticket Audits API. Příklady Podpora L1Síťový tým L2Infrastruktura L3Fakturace
	Přiřazený agent Assignee	Konkrétní pracovník podpory, který má incident právě na starosti.
Popis Tento atribut určuje, který agent za incident v danou chvíli odpovídá. Změna přiřazeného agenta je důležitou událostí, která znamená předání práce jiné osobě. Analýza přiřazených agentů pomáhá sledovat rozložení pracovní zátěže, výkon jednotlivců i spolupráci. Změny tohoto pole je třeba sledovat při výpočtu KPI „Průměrný počet předání na incident“ a při hledání případů, kdy si incident často předávají různí lidé. Může to ukazovat na nedostatek znalostí nebo neefektivní směrování. Proč je to důležité Určuje agenta odpovědného za incident a umožňuje analyzovat pracovní zátěž i předávání práce. Pomáhá tak odhalit neefektivní místa v procesu. Kde data získat Zendesk Tickets API, pole assignee_id. Změny se zaznamenávají v Ticket Audits API. Příklady John SmithJane DoeAutomatizace servisního oddělení
	Stav SLA SlaStatus	Aktuální stav SLA (dohody o úrovni služeb) pro incident.
Popis Tento atribut ukazuje, zda incident směřuje ke splnění stanovených cílů SLA, zda už byly překročeny, nebo zda jsou časovače SLA pozastavené. Zendesk automaticky sleduje metriky SLA podle nastavených zásad. Atribut je důležitý pro dashboard „Sledování plnění SLA“. Přímo ukazuje, jak si proces vede ve srovnání se závazky vůči zákazníkům. Analýza toho, kdy a proč dochází k porušení SLA, pomáhá odhalit slabá místa procesu a zvýšit spolehlivost služeb. Atribut přímo podporuje KPI „Míra dodržení SLA u incidentů“. Proč je to důležité Přímo měří plnění závazků v oblasti služeb a umožňuje analyzovat porušení SLA i průběžně sledovat shodu s cíli. Kde data získat Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), odvozeno z polí jako sla_policy, breached_at apod. Příklady AktivníPozastavenoPřekročenoSplněno
	Stav tiketu TicketStatus	Stav tiketu incidentu v okamžiku události, například „Otevřený“, „Čekající“ nebo „Vyřešený“.
Popis Tento atribut zachycuje stav tiketu v různých fázích jeho životního cyklu. Standardní stavy Zendesk zahrnují new, open, pending, on-hold, solved a closed. Sledování změn tohoto pole je jedním z hlavních způsobů, jak vytvářet aktivity pro process mining. Analýza stavu tiketu je zásadní pro pochopení procesu. Pomáhá zjistit, jak dlouho incidenty zůstávají v jednotlivých stavech. Stav „Pending“ například často znamená, že se čeká na odpověď zákazníka. Stav tiketu je také důležitý pro určení dokončení případu a výpočet doby řešení. Proč je to důležité Sledování změn stavů pomáhá pochopit průběh procesu, odhalit čekání a určit začátek i konec životního cyklu incidentu. Kde data získat Zendesk Tickets API, pole status. Změny se zaznamenávají v Ticket Audits API. Příklady novýotevřenýčekávyřešenýuzavřený
	Doba trvání případu CaseDuration	Celková doba od založení incidentu do jeho uzavření.
Popis Tato vypočítaná metrika vyjadřuje celkovou dobu průchodu jednoho incidentu procesem. Vypočítá se jako rozdíl mezi časovou značkou první události, například „Incident vytvořen“, a poslední události, například „Incident uzavřen“. Doba trvání případu je hlavním KPI celkové efektivity procesu. Dashboardy ji často používají k zobrazení průměrné doby průchodu, hledání dlouho otevřených případů a analýze vývoje v čase. Poskytuje celkový přehled o tom, jak rychle lze incidenty zpracovat a vyřešit. Proč je to důležité Jde o důležité KPI pro měření celkové rychlosti procesu a hledání příčin dlouhé doby řešení. Kde data získat Vypočítá se jako rozdíl mezi časovou značkou poslední a první události pro každé Incident ID. Příklady 25920060480086400
	Hodnocení spokojenosti SatisfactionRating	Hodnocení spokojenosti, které uživatel poskytl po vyřešení incidentu.
Popis Tento atribut zachycuje zpětnou vazbu zákazníka na zkušenost s podporou. Obvykle se sbírá prostřednictvím dotazníku po vyřešení tiketu. V Zendesk se běžně používají hodnocení „Dobré“ a „Špatné“. Hodnocení spokojenosti neměří přímo efektivitu procesu, ale ukazuje jeho výsledek. V process mining je lze porovnat s variantami procesu a zjistit, které cesty řešení vedou k vyšší spokojenosti zákazníků. Dostávají například incidenty s větším počtem předání horší hodnocení? Proč je to důležité Poskytuje ukazatel výsledku, který lze porovnat s charakteristikami procesu a zjistit, jak jeho průběh ovlivňuje spokojenost uživatelů. Kde data získat Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), pole satisfaction_rating.score. Příklady dobréšpatnénabídnutonenabídnuto
	Je automatizovaná IsAutomated	Logická hodnota určující, zda činnost provedl automatizovaný systém, nebo člověk.
Popis Tento odvozený atribut rozlišuje události provedené uživateli od těch, které provedly systémové automatizace, spouštěče nebo integrace přes API. Obvykle se určuje podle toho, zda je autor události známý systémový uživatel. Míra automatizace je důležitá pro současnou analýzu procesů. Pomáhá vyhodnotit účinnost pravidel automatizace, najít ruční úkony vhodné k automatizaci a měřit vliv automatizace na efektivitu a dobu řešení. Pomocí tohoto atributu lze porovnat průběh automatizovaných a ručních činností. Proč je to důležité Rozlišuje činnosti lidí a systémů. To je důležité pro analýzu vlivu automatizace na efektivitu procesu i pro hledání dalších možností automatizace. Kde data získat Odvozuje se podle toho, zda autor události (author_id v Ticket Audits API) odpovídá známému systémovému uživateli nebo uživateli automatizace. Příklady truefalse
	Kategorie hlavní příčiny RootCauseCategory	Obecná kategorie hlavní příčiny incidentu.
Popis Tento atribut slouží k zařazení základního důvodu vzniku incidentu. Obvykle se zaznamenává ke konci životního cyklu incidentu, například při následném vyhodnocení nebo v rámci řízení problémů, a ukládá se do vlastního pole. Tyto údaje jsou důležité pro dashboard „Přesnost určení hlavní příčiny“ a KPI „Pokrytí analýzou hlavní příčiny“. Analýza incidentů podle příčiny pomáhá odhalit opakující se problémy a zaměřit se na trvalá řešení, která sníží počet budoucích incidentů. Tím se pozornost přesouvá od řešení následků k předcházení problémům. Proč je to důležité Podporuje preventivní řízení problémů. Zařazení příčin incidentů pomáhá hledat opakující se vzorce a předcházet dalším případům. Kde data získat Obvykle jde o vlastní pole tiketu. Nastavení najdete v konfiguraci Ticket Fields v Zendesk Admin Center. Příklady Chyba softwaruPorucha hardwaruChyba uživateleVýpadek sítě
	Odesílatel Submitter	Koncový uživatel nebo systém, který incident původně nahlásil.
Popis Tento atribut určuje osobu nebo subjekt, který vytvořil tiket. Liší se od žadatele, protože agent může tiket založit jménem někoho jiného. Odesílatel pomáhá zjistit, kdo problémy hlásí. V kombinaci s údaji o organizaci může odhalit, zda určití zákazníci nebo skupiny uživatelů zaznamenávají velký počet incidentů. Na základě těchto zjištění lze plánovat preventivní podporu nebo školení. Proč je to důležité Určuje zdroj hlášení incidentu. Analýza může odhalit souvislosti s konkrétními uživateli, odděleními nebo automatizovanými systémy. Kde data získat Zendesk Tickets API, pole submitter_id. Příklady alice.jones@example.combob.williams@example.comSledování systému
	Organizace zákazníka Organization	Organizace nebo společnost, ke které patří žadatel o řešení incidentu.
Popis Tento atribut propojuje incident s organizací zákazníka. Je důležitý v podpoře B2B, kde se úroveň služeb a postupy podpory mohou u jednotlivých zákazníků lišit. Analýza incidentů podle organizace umožňuje týmům podpory sledovat stav zákazníků, hledat opakující se problémy u konkrétních klientů a kontrolovat plnění smluvních závazků. Jde o důležitý údaj pro filtrování dashboardů a reportů podle zákazníka. Proč je to důležité Umožňuje analyzovat údaje podle zákazníků, sledovat úroveň služeb, hledat trendy u významných klientů a účinněji řídit vztahy se zákazníky. Kde data získat Zendesk Tickets API, pole organization_id. Příklady Global Tech Inc.Innovate SolutionsData Corp
	Počet předání HandoffCount	Celkový počet přeřazení incidentu jinému agentovi nebo skupině.
Popis Tato vypočítaná metrika udává, kolikrát se změnila odpovědnost za incident. Každá změna pole Assignee nebo AssignedGroup zvýší počet předání v daném případu. Předávání práce často způsobuje neefektivitu a zpoždění při řešení incidentů. Vysoký počet předání může ukazovat na nejasná pravidla směrování, nedostatek znalostí v týmech podpory nebo příliš složitý proces. Metrika slouží jako základ KPI „Průměrný počet předání na incident“ a je důležitá pro dashboard „Analýza předávání a opakované práce“. Proč je to důležité Vyjadřuje zdržení způsobené předáváním práce a pomáhá najít neefektivní směrování i nedostatek znalostí, které prodlužují řešení. Kde data získat Vypočítá se podle počtu změn pole AssignedGroup nebo Assignee u incidentu. Příklady 0135
	Štítky Tags	Seznam štítků přiřazených incidentu pro jeho zařazení a doplnění kontextu.
Popis Štítky jsou pružné popisky, které lze přidat k tiketům pro doplnění kontextu, zařazení nebo směrování. Agenti je mohou přidávat ručně, případně se přidají automaticky pomocí spouštěčů a automatizací. Štítky jsou cenným zdrojem dat pro analýzu process mining. Lze je použít k podrobnějšímu rozdělení dat, například filtrováním incidentů souvisejících s uvedením konkrétního produktu („launch_q4“) nebo známým výpadkem („outage_20231027“). Díky tomu lze zkoumat proces i nad rámec standardních polí tiketů. Proč je to důležité Umožňuje pružně zařazovat a filtrovat incidenty a provádět podrobnou analýzu podle kontextu i tam, kde samotná standardní pole nestačí. Kde data získat Zendesk Tickets API, pole tags. Příklady vip_usernetwork_issueoutage_20231027billing_related
	Typ tiketu TicketType	Zařazení tiketu, například „Incident“, „Problém“, „Dotaz“ nebo „Úkol“.
Popis Toto pole zařazuje tiket podle povahy požadavku. Proces řízení incidentů se zaměřuje na tikety typu „Incident“, které představují neplánovaný výpadek nebo zhoršení kvality IT služby. Při analýze slouží tento atribut především jako filtr, který zajistí, že zobrazení procesu bude obsahovat pouze incidenty. Lze ho využít také při širší analýze ITSM, například k porovnání postupů při řešení incidentů, problémů a servisních požadavků. Proč je to důležité Umožňuje filtrovat data pouze na incidenty, aby se analýza zaměřovala na životní cyklus jejich řešení. Kde data získat Zendesk Tickets API, pole type. Příklady incidentproblémdotazúkol
	Vyřešeno při prvním kontaktu IsFirstContactResolution	Logická hodnota, která je pravdivá, pokud incident vyřešil první přiřazený agent nebo skupina bez předání.
Popis Vyřešení při prvním kontaktu (FCR) je důležitou metrikou efektivity podpory a spokojenosti zákazníků. Tento vypočítaný atribut označuje incidenty vyřešené bez přeřazení jinému agentovi nebo týmu. Logika obvykle ověřuje, zda tiket dosáhl stavu „Vyřešeno“, přestože zůstal přiřazen původnímu agentovi a skupině. V process mining lze přímo vypočítat míru FCR a porovnat průběh incidentů vyřešených při prvním kontaktu s těmi, které vyžadovaly eskalaci. Analýza pomáhá najít možnosti, jak posílit pravomoci pracovníků první linie podpory. Proč je to důležité Přímo měří efektivitu prvního kontaktu s podporou a pomáhá najít možnosti, jak vyřešit incident dříve v procesu. Kde data získat Vypočítaná logická hodnota. Je pravdivá, pokud je stav tiketu „vyřešený“ nebo „uzavřený“ a během životního cyklu incidentu byl přiřazen pouze jeden jedinečný agent nebo skupina. Příklady truefalse
	Závažnost Severity	Míra dopadu incidentu na provoz organizace.
Popis Závažnost vyjadřuje dopad incidentu na organizaci. Spolu s prioritou často určuje celkovou naléhavost. V Zendesk se obvykle nastavuje jako vlastní pole. Analýza závažnosti pomáhá posoudit, jak kritické incidenty tým řeší. Slouží k rozdělení dat v dashboardech, jako jsou „Sledování plnění SLA“ a „Metriky účinnosti stanovení priorit“. Porovnání průběhu procesů u různých úrovní závažnosti může ukázat, zda se závažné incidenty řeší dostatečně rychle a s odpovídajícími zdroji. Proč je to důležité Ukazuje dopad incidentu na provoz a umožňuje zaměřit analýzu na nejzávažnější problémy a ověřit, zda se řeší účinně. Kde data získat Obvykle jde o vlastní pole. Nastavení najdete v konfiguraci Ticket Fields v Zendesk Admin Center. Příklady 1 - Kritická2 - Vysoká3 - Střední4 - Nízká

Povinné Doporučené Volitelné

Aktivity v řízení incidentů

Zachyťte tyto důležité kroky a milníky procesu v záznamu událostí, abyste mohli proces přesně objevit a analyzovat.

6 Doporučené 7 Volitelné

	Aktivita	Popis
	Incident uzavřen	Označuje konec životního cyklu incidentu, kdy se tiket trvale uzavře. V Zendesk k tomu často dochází automaticky po uplynutí stanovené doby od vyřešení. Uzavření se zaznamená jako poslední změna stavu.
Proč je to důležité Jde o konečnou aktivitu procesu. Celková doba procesu se počítá od události „Incident vytvořen“ do této události a poskytuje přehled o celém průběhu. Kde data získat Zaznamenává se z auditního protokolu tiketu podle události „Change“, při které se nová hodnota pole 'status' změní na 'closed'. Zachycení Určuje se podle události „Change“, při které se pole 'status' změní na 'closed'. Typ události explicit
	Incident vyřešen	K tomuto důležitému milníku dochází, když agent zavede řešení a označí tiket jako 'solved'. Jde o výslovnou akci zaznamenanou jako změna stavu v auditním protokolu tiketu.
Proč je to důležité Jde o hlavní aktivitu řešení a důležitý bod pro měření doby do vyřešení. Doba mezi touto událostí a událostí „Incident uzavřen“ představuje období, kdy uživatel potvrzuje řešení nebo kdy se tiket automaticky uzavře. Kde data získat Zaznamenává se z auditního protokolu tiketu podle události „Change“, při které se nová hodnota pole 'status' změní na 'solved'. Zachycení Určuje se podle události „Change“, při které se pole 'status' změní na 'solved'. Typ události explicit
	Incident vytvořen	Označuje začátek životního cyklu incidentu, kdy se v Zendesk vytvoří nový tiket. Tato událost je výslovně zaznamenána v auditním protokolu vytvoření tiketu a představuje počáteční bod každého případu.
Proč je to důležité Jde o hlavní počáteční aktivitu. Doba od této události k dalším událostem je důležitá pro měření celkové délky životního cyklu tiketu a doby první reakce. Kde data získat Jde o výslovně zaznamenanou událost v auditních protokolech tiketů Zendesk. Při vytvoření každého nového tiketu se zaznamená událost „Create“ s příslušným časovým razítkem. Zachycení Přímo z události vytvoření tiketu v auditním protokolu. Typ události explicit
	Stav změněn na otevřený	Označuje, že agent začal na incidentu aktivně pracovat. Tato aktivita se obvykle odvozuje ze změny pole 'status' tiketu z hodnoty 'new' na 'open', která značí začátek šetření a diagnostiky.
Proč je to důležité Tato událost označuje přechod od čekání ve frontě k aktivní práci. Doba, po kterou je tiket ve stavu 'new' před změnou na 'open', je důležitým ukazatelem doby první reakce. Kde data získat Odvozuje se z auditního protokolu tiketu. Hledá se událost „Change“, při které se nová hodnota pole 'status' změní na 'open' a předchozí hodnota byla 'new'. Zachycení Odvozuje se ze změny pole stavu z 'new' na 'open'. Typ události inferred
	Tiket přiřazen agentovi	K této aktivitě dochází, když je tiket přidělen konkrétnímu agentovi k řešení. Jde o výslovně zaznamenanou událost v historii auditu tiketu, která znamená, že za něj převzal odpovědnost konkrétní pracovník.
Proč je to důležité Tento milník je důležitý pro měření doby do prvního přiřazení a pro analýzu předávání, opakovaného zpracování a míry vyřešení při prvním kontaktu. Kde data získat Zaznamenává se z auditního protokolu tiketu při vyplnění nebo změně pole 'assignee_id'. První přiřazení je důležitým milníkem pro výpočet KPI. Zachycení Určuje se podle události „Change“ pro pole 'assignee_id' v auditním protokolu tiketu. Typ události explicit
	Tiket znovu přiřazen	K této události dochází, když se po počátečním přiřazení převede odpovědnost za tiket z jednoho agenta nebo skupiny na jiného. Změna se výslovně zaznamená v historii auditu tiketu.
Proč je to důležité Opětovná přiřazení jsou důležitá pro analýzu předávání a opakovaného zpracování. Časté změny mohou ukazovat na nesprávné počáteční směrování, složité problémy nebo úzká místa v procesu. Kde data získat Zaznamenává se z auditního protokolu tiketu. Hledá se událost „Change“ u pole 'assignee_id' nebo 'group_id' poté, co bylo pole poprvé vyplněno. Zachycení Určuje se podle následné události „Change“ u pole 'assignee_id' nebo 'group_id'. Typ události explicit
	Nastavena priorita	Je určena úroveň priority incidentu, například nízká, běžná, vysoká nebo urgentní. Zaznamenává se jako výslovná změna a určuje naléhavost i požadovanou dobu reakce na tiket.
Proč je to důležité Sledování toho, kdy a jak se nastavuje priorita, je důležité pro dashboard „Metriky efektivity určování priorit“. Pomáhá zajistit, aby se kritické problémy řešily včas. Kde data získat Zaznamenává se z události „Change“ u pole 'priority' v auditním protokolu tiketu. Lze sledovat i další změny a vypočítat KPI míry změn priority. Zachycení Určuje se podle události „Change“ pro pole 'priority' v auditním protokolu tiketu. Typ události explicit
	Odeslána veřejná odpověď	Označuje zprávu, kterou agent podpory odeslal koncovému uživateli. Jde o výslovnou událost v Zendesk, zaznamenanou při přidání veřejného komentáře k tiketu.
Proč je to důležité Sledování veřejných odpovědí pomáhá pochopit četnost komunikace. Jejich časová osa může být důležitá při analýze prodlev, než uživatel potvrdí řešení. Kde data získat Zaznamenává se z dat komentářů k tiketu. Komentář je veřejný, pokud má atribut 'public' hodnotu true. Zachycení Událost se zaznamená při přidání nového komentáře s hodnotou 'public: true' k tiketu. Typ události explicit
	Ohodnocena spokojenost uživatele	Označuje okamžik, kdy koncový uživatel ohodnotí podporu, kterou obdržel. Jde o výslovnou událost zaznamenanou v Zendesk po vyřešení tiketu.
Proč je to důležité Analýza hodnocení spokojenosti poskytuje důležitou zpětnou vazbu o práci agentů a efektivitě procesu. Propojuje metriky procesu s výsledky pro zákazníky. Kde data získat Zaznamenává se z dat hodnocení spokojenosti přiřazených k tiketu. Obvykle obsahují hodnocení („good“ nebo „bad“) a případný komentář. Zachycení Událost se zaznamená při odeslání hodnocení spokojenosti k tiketu. Typ události explicit
	Překročen cíl SLA	Označuje okamžik, kdy tiket nesplnil podmínky definované smlouvou o úrovni služeb, například dobu první odpovědi nebo dobu řešení. Událost se vypočítá podle definic zásad SLA a časových razítek aktualizací tiketu.
Proč je to důležité Tato událost přímo podporuje sledování dodržování SLA. Zjištění, kdy a proč k porušení dochází, je základem pro zlepšení spolehlivosti služeb a důvěry zákazníků. Kde data získat Jde o vypočítanou událost. Lze ji odvodit analýzou dat 'sla_policy_metrics' přiřazených k tiketu a použitím časového razítka 'breached_at' pro každý cíl SLA. Zachycení Odvozuje se z časového razítka 'breached_at' v datech metrik SLA daného tiketu. Typ události calculated
	Přidána interní poznámka	Tato aktivita označuje interní spolupráci. Agent přidá k tiketu soukromou poznámku pro ostatní členy týmu. Výslovně se zaznamená, když je komentář označen jako neveřejný.
Proč je to důležité Analýza interních poznámek může odhalit složité problémy vyžadující spolupráci. Jejich nadměrný počet ale může ukazovat na nedostatek znalostí nebo neefektivní proces. Kde data získat Zaznamenává se z dat komentářů k tiketu. Komentář je interní poznámkou, pokud má atribut 'public' hodnotu false. Zachycení Událost se zaznamená při přidání nového komentáře s hodnotou 'public: false' k tiketu. Typ události explicit
	Stav změněn na čekající	Označuje pozastavení procesu, kdy se čeká na odpověď od žadatele. Událost se odvozuje ze změny pole 'status' tiketu na 'pending'.
Proč je to důležité Tato aktivita je důležitá pro výpočet doby čekání na potvrzení od uživatele. Dlouhé čekání v tomto stavu může výrazně prodloužit celkovou dobu řešení a upozornit na prodlevy v komunikaci. Kde data získat Odvozuje se z auditního protokolu tiketu. Hledá se událost „Change“, při které se nová hodnota pole 'status' změní na 'pending'. Zachycení Odvozuje se ze změny pole stavu na 'pending'. Typ události inferred
	Tiket přiřazen skupině	Označuje počáteční směrování nebo třídění incidentu a jeho přiřazení konkrétní skupině podpory. Obvykle jde o první krok při určení odpovědnosti. Zaznamenává se jako výslovná změna v historii auditu tiketu.
Proč je to důležité Sledování přiřazení skupinám pomáhá vyhodnotit efektivitu počátečního třídění a odhalit prodlevy před předáním tiketu správnému týmu. Kde data získat Zaznamenává se z auditního protokolu tiketu při nastavení nebo změně pole 'group_id'. První taková změna po vytvoření tiketu představuje počáteční přiřazení. Zachycení Určuje se podle události „Change“ pro pole 'group_id' v auditním protokolu tiketu. Typ události explicit

Doporučené Volitelné

Návody k extrakci dat

Jak získat data ze Zendesk Support

Kroky

Otevřete Zendesk Explore: Přihlaste se do své instance Zendesk Support pomocí uživatelského účtu, který má oprávnění vytvářet a spravovat reporty v Zendesk Explore.
Vytvořte nový report: Přejděte do modulu Explore. V levém navigačním panelu klikněte na ikonu „Reports“ a potom na tlačítko „New report“.
Vyberte dataset: V okně „Choose a dataset“ vyberte dataset Support: Ticket updates [default]. Obsahuje auditní záznamy všech změn tiketů, které jsou nezbytné pro vytvoření záznamu událostí.
Přidejte počáteční atributy (sloupce): V editoru reportu přejděte do části „Rows“. Klikněte na „Add“ a vyberte následující atributy. Vytvoří sloupce záznamu událostí: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
Vytvořte vypočítané atributy: Jde o nejdůležitější krok. Otevřete nabídku „Calculations“ (ikona kádinky) a vyberte „Standard calculated attribute“. Vytvořte tři atributy uvedené v části „Query“ níže: ActivityName, SourceSystem a LastDataUpdate. Zkopírujte přesně dodané vzorce.
Upravte sloupce reportu: Přidejte nově vytvořené vypočítané atributy (ActivityName, SourceSystem, LastDataUpdate) do části „Rows“. Potom můžete odebrat původní pole použitá k vytvoření ActivityName (Changes - Field name, Changes - Previous value, Changes - New value, Comment public) a zpřehlednit tak výstup.
Přidejte filtry reportu: Přejděte do části „Filters“ a klikněte na „Add“. Přidejte filtr pro Update - Date a vyberte vhodné období, například poslední 3 měsíce. Přidejte také filtr pro vypočítaný atribut ActivityName a vylučte prázdné hodnoty. Odstraníte tak aktualizace tiketů, které neodpovídají požadované aktivitě.
Spusťte report a zkontrolujte ho: Zendesk Explore bude report automaticky aktualizovat při přidávání atributů a filtrů. Zkontrolujte tabulku a ověřte, že řádky a sloupce odpovídají očekávání. Každý řádek by měl představovat jednu událost.
Exportujte data do CSV: Po dokončení reportu klikněte v pravém horním rohu na tlačítko „Export“ a vyberte „CSV“. Zendesk vytvoří a stáhne soubor CSV.
Připravte data k nahrání: Otevřete exportovaný soubor CSV. Přejmenujte záhlaví sloupců podle požadovaných názvů atributů v nástroji process mining, například změňte „Ticket ID“ na TicketId a „Update - Timestamp“ na EventTimestamp. Ověřte, že časová razítka mají formát odpovídající normě ISO 8601. Soubor je nyní připraven k nahrání.

Konfigurace

Dataset Zendesk: Report musí vycházet z datasetu Support: Ticket updates [default]. Jde o jediný standardní dataset s podrobnými auditními záznamy potřebnými k rekonstrukci procesu událost po události.
Filtr časového období: Omezte objem dat pomocí filtru data. Jako hlavní filtr použijte atribut Update - Date. Pro počáteční analýzu se obvykle doporučuje období 3 až 6 měsíců.
Filtr aktivit: Po vytvoření vypočítaného atributu ActivityName nastavte filtr, který vyloučí řádky s prázdnou hodnotou. Ze záznamu událostí tak odstraníte nerelevantní změny tiketů, například systémové aktualizace a změny štítků.
Vypočítané atributy: Extrakce se ve velké míře opírá o standardní vypočítaný atribut, který převádí nezpracované změny polí tiketu na srozumitelné názvy aktivit. Přesnost vzorce je zásadní.
Předpoklady: Uživatel spouštějící report potřebuje v Zendesk Explore alespoň roli „Viewer“. K vytvoření a uložení reportu jsou nutná oprávnění „Editor“ nebo „Admin“.

Ukázkový dotaz config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

Kroky

Předpoklady: Ověřte, že máte v systému nainstalovaný Python 3.6 nebo novější a knihovny requests a pandas. Nainstalovat je můžete příkazem pip: pip install requests pandas.
Vygenerujte API token Zendesk: Přihlaste se do Zendesk Support jako správce. Přejděte do Admin Center > Apps and integrations > APIs > Zendesk APIs. V části „API Tokens“ přidejte nový aktivní API token a bezpečně uložte jeho hodnotu.
Nastavte Python skript: Vytvořte nový soubor Python, například extract_zendesk_logs.py, a zkopírujte do něj dodaný skript. Upravte zástupné proměnné na začátku skriptu: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL a ZENDESK_API_TOKEN nahraďte svými přihlašovacími údaji. Nastavte START_TIMESTAMP na začátek požadovaného období extrakce, a to jako časové razítko Unix epoch.
Seznamte se s koncovými body API: Skript používá hlavně dva koncové body Zendesk API. Koncový bod incremental/tickets/cursor.json slouží k efektivnímu načtení všech tiketů aktualizovaných od času START_TIMESTAMP. U každého tiketu pak skript zavolá koncový bod tickets/{ticket_id}/audits.json a získá podrobnou historii všech změn a událostí.
Spusťte skript: Spusťte skript v terminálu příkazem python extract_zendesk_logs.py. Skript začne načítat data z Zendesk API.
Sledujte průběh skriptu: Skript vypisuje do konzole počet zpracovaných tiketů, takže můžete sledovat průběh. V závislosti na časovém období a počtu tiketů může zpracování trvat delší dobu.
Načítání dat a stránkování: Skript automaticky zpracovává stránkování API. Začne počáteční URL pro export tiketů a pokračuje podle hodnoty after_url z každé odpovědi API, dokud nenačte všechny tikety za dané období.
Transformace událostí: U každého tiketu skript projde historii auditních záznamů. Zpracuje jednotlivé události a převede interní typy událostí Zendesk, například Create, Change a Comment, na požadované obchodní aktivity, například Incident Created, Status Changed to Open a Public Reply Sent.
Zpracování dat SLA: Skript obsahuje samostatnou funkci get_sla_breach_events, která načítá metriky SLA pro každý vyřešený tiket. Je to nutné, protože porušení SLA nejsou standardními událostmi v auditním záznamu. Funkce provede další volání API a načte podrobnosti o použití zásad SLA.
Vytvořte záznam událostí: Po zpracování všech tiketů skript sestaví extrahované události do pandas DataFrame a uloží výsledný záznam událostí do souboru CSV zendesk_incident_event_log.csv ve složce, ze které byl skript spuštěn.
Připravte data k nahrání: Zkontrolujte správnost vytvořeného souboru CSV. Nyní má požadovaný formát a můžete ho nahrát přímo do ProcessMind k analýze.

Konfigurace

Přihlašovací údaje Zendesk API: Zadejte subdoménu Zendesk, e-mailovou adresu spojenou s účtem správce nebo agenta a platný API token. Přihlašovací údaje bezpečně uložte. Ve skriptech používaných v produkčním prostředí je neukládejte přímo do kódu spravovaného verzovacím systémem.
Počáteční časové razítko (START_TIMESTAMP): Tato celočíselná hodnota určuje začátek extrakce dat. Musí jít o časové razítko Unix epoch. Doporučujeme začít 3 až 6 měsíců zpětně, abyste získali dostatek dat a zároveň zbytečně nezatížili systém. Správné časové razítko pro konkrétní datum můžete zjistit pomocí online převodníku.
Omezení počtu požadavků API: Skript provádí mnoho volání API. Zendesk uplatňuje limity, které se liší podle tarifu. Skript funguje při středním objemu dat. U velmi rozsáhlých instancí může být nutné do smyček přidat volání time.sleep(), aby nedošlo k překročení limitu a chybě 429.
Požadované knihovny Pythonu: Skript používá knihovnu requests pro volání API a pandas pro zpracování dat a export do CSV. Ověřte, že jsou nainstalované ve vašem prostředí Python.
Oprávnění uživatele: Uživatelský účet spojený s API tokenem musí mít dostatečná oprávnění ke čtení dat tiketů, včetně auditních záznamů a metrik tiketů.

Ukázkový dotaz python

import requests
import pandas as pd
import time
import os
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
START_TIMESTAMP = 1672531200 

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
AUTH = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

if __name__ == class="hl-string">"__main__":
    main()

Kroky

Vytvořte klienta Zendesk API s oprávněním číst tikety, audity tiketů, uživatele, skupiny, hodnocení spokojenosti a přírůstkové exporty. Použijte token API nebo přihlašovací údaje OAuth nastavené pro vaši instanci Zendesk Support. Subdoménu, přihlašovací údaje a značku posledního zpracování uložte jako zabezpečené konfigurační hodnoty.
Pomocí Zendesk Incremental Ticket Export API načtěte tikety aktualizované po poslední úspěšné značce. Níže uvedený skript používá dokumentovaný vzor koncového bodu https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json a pokračuje v načítání stránek pomocí kurzoru, dokud API nepotvrdí, že jsou zpracovány všechny výsledky.
U každého vráceného tiketu načtěte historii auditů z koncového bodu auditů tiketů. Auditní záznamy jsou nutné, protože ProcessMind pracuje se záznamem událostí tak, jak je, a neodvozuje aktivity z konečného stavu tiketu. Zachovejte časové razítko auditu, aktéra, identifikátor tiketu a události auditu.
Převeďte události auditu na samostatné řádky událostí. Zaznamenejte vytvoření tiketu, přiřazení skupiny, přiřazení agenta, změny priority, změny stavu na otevřený, veřejné odpovědi, interní poznámky, změny přiřazení, změny stavu na čekající, vyřešení a uzavření. Pokud je k dispozici hodnocení spokojenosti, zaznamenejte ho jako samostatný řádek. Porušení SLA vypočítejte pouze tehdy, jsou-li k dispozici požadovaný cíl SLA a časová razítka událostí. Vstupní údaje pro výpočet zdokumentujte.
Uchovávejte časové razítko nebo kurzor poslední úspěšně zpracované aktualizace. Značku neposouvejte, dokud nebudou úspěšně zapsány všechny stránky, audity tiketů a případné záznamy o spokojenosti. Při prvním spuštění použijte omezený počáteční čas, například [Start date in ISO 8601 format], obvykle za poslední tři až šest měsíců.
Vyplňte povinné sloupce TicketId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate. Pokud to zdrojová data umožňují, vyplňte také doporučené sloupce TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus a EventEndTime. Prázdnou hodnotu použijte pouze tehdy, pokud Zendesk daný atribut pro událost neposkytuje.
Odstraňte duplicity podle polí TicketId, ActivityName a EventTimestamp a podle stabilního identifikátoru zdrojové události, pokud je k dispozici. Zachovejte všechny oprávněné opakované výskyty stejné aktivity, například několik veřejných odpovědí, interních poznámek, přiřazení nebo změn stavu.
Výsledné řádky uložte do CSV nebo jiného formátu záznamu událostí podporovaného ProcessMind. Časová razítka zapište ve formátu ISO 8601 s výslovně uvedeným posunem vůči UTC, TicketId udržujte ve stejném datovém typu, hodnoty ActivityName musí přesně odpovídat zdokumentovaným názvům aktivit a LastDataUpdate musí být pro všechny řádky stejné dávky extrakce totožné.
Nahrajte záznam událostí do ProcessMind a nastavte ID incidentu jako identifikátor případu, Aktivitu jako sloupec aktivity a Čas události jako sloupec času události. Ověřte, že každá požadovaná aktivita je zaznamenána samostatným řádkem a není odvozena až při vizualizaci.

Konfigurace

Metoda API: Zendesk Incremental Ticket Export API se stránkováním pomocí kurzoru. Pro extrakci jednotlivých událostí použijte koncový bod auditních záznamů tiketů. Pokud jsou hodnocení spokojenosti zapnutá a dostupná, použijte také koncový bod pro hodnocení.
Požadovaná konfigurace: subdoména Zendesk, ověření API, počáteční datum, časová značka posledního úspěšného načtení, časový limit požadavku, zásady opakování a cílové umístění výstupu. Nahraďte [Your Zendesk subdomain], [Your API email] a [Your API token] zabezpečenými hodnotami pro nasazení.
Časové období: Při prvním načtení použijte tři až šest měsíců, pokud nepotřebujete delší historii. Při pravidelném načítání požadujte záznamy po poslední úspěšné časové značce a přidejte krátké překrývající se období, abyste zachytili pozdě doručené aktualizace. Poté odstraňte duplicity.
Filtry: Filtrujte podle společnosti, značky, skupiny, organizace, formuláře tiketu, kanálu nebo vlastních polí pouze tehdy, pokud to výslovně vyžaduje rozsah procesu. Zendesk Support nepoužívá filtry Company Code ani Document Type ve stylu SAP, pokud tyto pojmy nejsou zastoupeny nakonfigurovanými poli Zendesk.
Význam událostí: Auditní události považujte za autoritativní zdroj výslovných změn. Nevytvářejte událost změny stavu jen proto, že má aktuální stav tiketu nějakou hodnotu. Událost stavu musí vycházet z auditní události nebo jiného zdokumentovaného zdroje.
Konfigurace SLA: K určení porušení cíle SLA potřebujete přístup k příslušným zásadám SLA, délce cílové doby, kalendáři pracovní doby a časovým razítkům potřebným k vyhodnocení cíle. Pokud Zendesk poskytuje událost nebo metriku porušení, použijte tento zdroj. Jinak porušení vypočítejte pouze na základě zdokumentovaných údajů o zásadách a uchovejte podklady výpočtu.
Konfigurace spokojenosti: Aktivitu User Satisfaction Rated lze zaznamenat pouze tehdy, jsou-li zapnutá hodnocení spokojenosti a záznam hodnocení je dostupný přes API. Vyřešenému tiketu bez hodnocení nevytvářejte umělou událost hodnocení.
Výkon: Používejte stránkování pomocí kurzoru, omezený souběh požadavků na auditní záznamy tiketů, opakované využití připojení, exponenciální prodlevy při překročení limitů a ukládání kontrolních bodů po úspěšných dávkách. Při každém spuštění znovu nenačítejte všechny auditní záznamy tiketů.
Úplnost: Přírůstkové exporty mohou obsahovat tikety aktualizované po požadovaném čase, ale načítání auditních záznamů a pozdějších aktualizací je třeba řešit samostatně. Používejte překrývající se období a stabilní klíče pro odstranění duplicit.
Předpoklady: Přístup k API, oprávnění číst tikety a auditní záznamy, přístup k uživatelům a skupinám pro převod identifikátorů na názvy, přístup k údajům o spokojenosti, pokud jsou vyžadovány, a přístup k údajům SLA, pokud je potřeba počítat porušení. Dostupnost konkrétních typů auditních událostí se může lišit podle konfigurace a předplatného Zendesk.

Ukázkový dotaz python

import csv
import json
import os
import time
from datetime import datetime, timezone, timedelta
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"SourceSystem", class="hl-string">"LastDataUpdate",
    class="hl-string">"TicketStatus", class="hl-string">"Assignee", class="hl-string">"AssignedGroup", class="hl-string">"TicketPriority", class="hl-string">"Channel",
    class="hl-string">"SlaStatus", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        response = SESSION.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

Kroky

Vyberte komerční nástroj ETL nebo pro integraci dat, který má ověřený konektor Zendesk Support, podporuje historii auditních záznamů tiketů a extrakci komentářů a dokáže zapisovat do cílového datového skladu nebo souborového systému. Ověřte, že konektor podporuje přírůstkovou extrakci, stránkování, zpracování limitů požadavků a zachování zdrojových časových razítek.
Ve vybraném nástroji vytvořte připojení Zendesk. V konfiguračním rozhraní zadejte subdoménu Zendesk, způsob ověřování, přihlašovací údaje nebo token a případná další nastavení připojení. Udělte přístup k tiketům, auditním záznamům tiketů, komentářům, uživatelům, skupinám, hodnocením spokojenosti a údajům SLA, pokud jsou tyto objekty dostupné ve vašem tarifu Zendesk a konektoru.
Nastavte období extrakce. Při prvním načtení použijte klouzavé období 3 až 6 měsíců. Poté nastavte přírůstkové načítání podle časového razítka aktualizace nebo auditu, které konektor podporuje. Časovou značku poslední úspěšné extrakce ukládejte mimo záznam událostí, aby další spuštění události neduplikovala ani nevynechala.
Extrahujte data na úrovni tiketu potřebná pro kontext případu, včetně identifikátoru tiketu, aktuálního stavu nebo stavu při události, přiřazeného uživatele, skupiny, priority, kanálu, stavu SLA a příslušných časových razítek aktualizací. Extrahujte také auditní záznamy tiketů, protože změny přiřazení, priority, stavu a dalších polí musí být zachyceny jako samostatné řádky událostí.
Extrahujte komentáře k tiketům a pomocí indikátoru veřejnosti nebo viditelnosti konektoru rozlište veřejné komentáře od interních poznámek. Načtěte časová razítka komentářů, identifikátory tiketů a autorů a případný dostupný čas ukončení nebo dokončení. Pro veřejné komentáře vytvořte řádky Public Reply Sent a pro soukromé komentáře řádky Internal Note Added.
Extrahujte záznamy hodnocení spokojenosti a porušení SLA, pokud je konektor zpřístupňuje. Pokud konektor neposkytuje události porušení SLA přímo, nastavte v nástroji ETL jejich výpočet z dostupných cílů a zásad SLA, pracovní doby a časových razítek událostí tiketů. Řádek o porušení vytvořte pouze tehdy, když zdrojová data nebo nakonfigurovaný výpočet potvrzují, že cíl nebyl splněn.
Uspořádejte extrahované zdrojové záznamy do normalizovaného záznamu událostí. Vytvořte jeden řádek pro každý výslovný výskyt aktivity. Vytvoření tiketu namapujte na Incident Created, změnu přiřazené skupiny na Ticket Assigned to Group nebo Ticket Reassigned, změnu přiřazeného agenta na Ticket Assigned to Agent nebo Ticket Reassigned, změnu priority na Priority Set, přechody stavů na odpovídající aktivitu stavu, komentáře na Public Reply Sent nebo Internal Note Added, vyřešení na Incident Resolved, záznamy hodnocení na User Satisfaction Rated a uzavření na Incident Closed.
Pravidla klasifikace událostí uplatňujte v jednoznačném pořadí. Pokud jsou k dispozici, použijte předchozí a nové hodnoty z historie auditu. První přiřazení skupiny klasifikujte jako Ticket Assigned to Group, první přiřazení agenta jako Ticket Assigned to Agent a pozdější změny vlastníka jako Ticket Reassigned. Vytvořte řádek pro každou odpovídající změnu, nejen pro poslední stav tiketu.
Vyplňte povinné sloupce TicketId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate. Pokud jsou k dispozici, doplňte doporučené sloupce TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus a EventEndTime podle kontextu události nebo nejbližšího platného zdrojového záznamu. Zdrojová časová razítka uchovávejte v jednotném časovém pásmu, nejlépe UTC, a zachovejte přesnost, kterou konektor podporuje.
Ověřte transformovaný výstup. Zkontrolujte, že každý TicketId obsahuje řádek Incident Created, časová razítka událostí spadají do období extrakce, pokud je to relevantní, že je zastoupeno všech 13 požadovaných názvů aktivit, pokud pro ně existují zdrojová data, a že duplicity řešíte podle identifikátoru zdrojového auditu nebo zdokumentovaného složeného klíče.
Zapište záznam událostí do tabulky cílového datového skladu nebo souboru v tabulkovém formátu kompatibilním s ProcessMind, například CSV nebo podporovaném formátu konektoru datového skladu. Použijte jeden řádek záhlaví, stabilní názvy sloupců, kódování UTF-8, časová razítka ISO 8601 a ve výsledných sloupcích událostí nepoužívejte vnořený JSON. Výsledný záznam událostí nahrajte do ProcessMind nebo se k němu připojte. Nespoléhejte na odvozování aktivit, protože ProcessMind načítá extrahované řádky tak, jak jsou.

Konfigurace

Konektor a licence: Použijte komerční nástroj ETL nebo pro integraci dat s konektorem Zendesk Support, který zpřístupňuje tikety, auditní záznamy tiketů, komentáře, uživatele, skupiny, hodnocení spokojenosti a údaje SLA podle možností tarifu Zendesk a verze konektoru.
Ověřování a oprávnění: Nastavte subdoménu Zendesk a schválený způsob ověřování. Udělte pouze oprávnění potřebná k extrakci tiketů, auditních záznamů, komentářů, uživatelů, skupin, hodnocení spokojenosti a údajů SLA. Ověřte, že integrační účet může číst historické záznamy.
Časové období: Pro ověření a počáteční načtení začněte obdobím 3 až 6 měsíců. Rozšiřte ho až po ověření počtu řádků, stránkování a chování při překročení limitů požadavků. Pro plánovaná spuštění používejte časovou značku posledního úspěšného načtení.
Požadované filtry: Používejte pouze filtry specifické pro společnost, které jsou potvrzené v konfiguraci zdroje, například vybranou subdoménu Zendesk, značku, organizaci, skupinu nebo rozsah tiketů. Filtry Company Code ani Document Type nepoužívejte, pokud tato pole nejsou součástí nakonfigurovaného datového modelu Zendesk.
Historie auditních záznamů: Zapněte extrakci auditních událostí tiketů a pokud možno uchovávejte zdrojový identifikátor auditu, abyste při přírůstkovém načítání předešli duplicitám.
Komentáře: Extrahujte veřejné i soukromé komentáře. Pomocí indikátoru viditelnosti ze zdroje je klasifikujte jako Public Reply Sent nebo Internal Note Added. Viditelnost neodvozujte z textu komentáře.
Klasifikace přiřazení: Porovnejte předchozí a nové hodnoty skupiny nebo přiřazeného uživatele. První odpovídající přiřazení klasifikujte samostatně a následné změny vlastníka označte jako Ticket Reassigned.
Klasifikace stavu: Vytvářejte řádky pouze pro výslovné přechody stavů. Hodnoty new, open, pending, solved a closed namapujte podle nakonfigurovaného modelu stavů Zendesk. Pokud používáte vlastní stavy, před načtením zdokumentujte jejich mapování.
Zpracování SLA: Upřednostněte zdrojové události porušení SLA. Pokud nejsou k dispozici, nastavte zdokumentovaný výpočet z dostupného cíle a zásad SLA, pracovní doby a časových razítek událostí. Základ výpočtu zaznamenejte v metadatech ETL, nevymýšlejte zdrojová pole.
Zpracování časových razítek: Převeďte EventTimestamp a EventEndTime na UTC nebo jiné zdokumentované časové pásmo. Zachovejte zdrojové časové razítko a nenahrazujte čas události časem extrakce.
LastDataUpdate: LastDataUpdate nastavte na čas úspěšné aktualizace ETL. Pro všechny řádky v daném načtení použijte stejnou hodnotu.
Výkon: Používejte stránkování, přírůstkovou extrakci, dělení podle času aktualizace tiketu nebo auditu, řízený souběh, opakování požadavků a prodlevy při překročení limitů. Při každém plánovaném spuštění znovu neextrahujte celou historii tiketů.
Cílové schéma: Nastavte plochou tabulku událostí nebo soubor s povinnými sloupci TicketId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate a s doporučenými atributy, pokud jsou k dispozici.
Chování ProcessMind: Nespoléhejte na to, že ProcessMind odvodí změny stavů, přiřazení, odpovědi, poznámky, porušení SLA nebo milníky životního cyklu. Každá aktivita musí být samostatným řádkem události už před nahráním.

Ukázkový dotaz config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

Chcete začít?

Použijte tuto šablonu k přípravě dat a získejte přehled o výkonnosti řízení incidentů. Začněte zlepšovat svůj proces ještě dnes.

Zpět na průvodce zlepšováním

Stáhnout šablonu

Zlepšete řízení incidentů a řešte je rychleji

Zkraťte MTTR o 35 %, omezte opakované incidenty a zvyšte spokojenost.

Začněte zkušební verzi zdarma

Bez platební karty. Zlepšovat můžete začít během několika minut.

Šablona dat pro řízení incidentů

Šablona dat pro řízení incidentů

Atributy řízení incidentů

Aktivity v řízení incidentů

Návody k extrakci dat

Export reportu Zendesk Explore z uživatelského rozhraní do souboru CSV

Kroky

Konfigurace

Ukázkový dotaz config

Python skript využívající Zendesk Support REST API

Kroky

Konfigurace

Ukázkový dotaz python

Zendesk Incremental Export API pro hromadnou synchronizaci dat

Kroky

Konfigurace

Ukázkový dotaz python

Nástroj ETL třetí strany s konektorem Zendesk API

Kroky

Konfigurace

Ukázkový dotaz config

Chcete začít?

Zlepšete řízení incidentů a řešte je rychleji