> Průběžné zlepšování procesů > Řízení servisních požadavků > Zendesk Support > Datová šablona

Šablona dat pro správu požadavků na služby

Zendesk Support

Atributy správy požadavků na služby(21) Aktivity při správě požadavků na služby(13) Návody na získání dat(3)

Šablona dat pro správu požadavků na služby

Tato šablona vám ukáže, jak získat data potřebná k analýze procesu správy požadavků na služby v Zendesk Support. Obsahuje přehled důležitých atributů, které je třeba shromáždit, hlavních aktivit, které je vhodné sledovat, i praktický návod, jak data získat přímo ze systému. Pomocí těchto informací připravíte kvalitní záznam událostí pro process mining.

Doporučené atributy pro podrobnou analýzu
Důležité aktivity požadavků na služby, které je vhodné sledovat
Návod na získání 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.

Stáhnout šablonu

Atributy správy požadavků na služby

Toto jsou doporučená datová pole, která zahrňte do záznamu událostí pro podrobnou analýzu správy požadavků na služby v Zendesk Support.

5 Povinné 7 Doporučené 9 Volitelné

	Název	Popis
	Aktivita ActivityName	Název obchodní aktivity nebo události, ke které došlo při vyřizování servisního požadavku.
Popis Aktivita představuje konkrétní krok nebo událost v průběhu vyřizování servisního požadavku, například „Vytvoření servisního požadavku“, „Přiřazení požadavku agentovi“ nebo „Vyřešení servisního požadavku“. Aktivity se odvozují ze změn zaznamenaných v auditním záznamu tiketu Zendesk. Ten sleduje změny polí, jako jsou stav, přiřazená osoba a priorita, i přidání komentářů. Analýza aktivit je základem process mining. Umožňuje zobrazit mapu procesu, odhalit úzká místa mezi kroky a analyzovat opakované průchody. Z pořadí a četnosti aktivit lze určit neefektivní místa a příležitosti ke zlepšení procesů. Proč je to důležité Tento atribut určuje jednotlivé kroky procesu a umožňuje zobrazit mapy procesů a analyzovat jejich průběh, varianty i shodu. Kde data získat Tento údaj se odvozuje z událostí zaznamenaných v Zendesk Ticket Audits API. Například změnu pole „status“ z „new“ na „open“ lze převést na aktivitu „Třídění požadavku“. Příklady Vytvoření servisního požadavkuPřeřazení požadavku jinému agentoviVyřešení servisního požadavku
	Čas zahájení EventTimestamp	Přesné datum a čas, kdy k aktivitě došlo.
Popis Časové razítko události neboli čas zahájení zaznamenává přesný okamžik, kdy aktivita proběhla. Zachycuje například přiřazení agenta, odeslání veřejné odpovědi nebo změnu stavu tiketu na „Resolved“. Časové údaje pocházejí z auditního záznamu každého tiketu Zendesk. Tento atribut je nezbytný pro časovou analýzu. Slouží k chronologickému seřazení událostí, výpočtu doby mezi aktivitami, měření čekání a analýze celkové doby průchodu případu. Pomáhá také odhalovat úzká místa a vyhodnocovat plnění časových cílů, například SLA. Proč je to důležité Toto časové razítko řadí události chronologicky a je nezbytné pro analýzu dob trvání, výkonnosti i úzkých míst. Kde data získat Zendesk Ticket Audits API, pole „created_at“ u každé události auditu. Příklady 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	ID servisního požadavku ServiceRequestId	Jedinečný identifikátor každého tiketu servisního požadavku v Zendesk.
Popis ID servisního požadavku, v Zendesk často označované jako ID tiketu, slouží jako primární klíč každého případu. Propojuje všechny související aktivity, komentáře a změny stavu od vytvoření požadavku až po jeho uzavření. Díky tomu lze sledovat celý průběh jednotlivého požadavku. Tento atribut je pro analýzu process mining zásadní. Určuje případ a umožňuje rekonstruovat průběh procesu, identifikovat varianty a počítat metriky na úrovni případu, například dobu průchodu. Každá událost v datové sadě musí být přiřazena k ID servisního požadavku, aby bylo možné určit její souvislost s celým procesem. Proč je to důležité Tento identifikátor případu propojuje všechny události v průběhu vyřizování servisního požadavku a umožňuje analyzovat celý proces od začátku do konce. Kde data získat Zendesk Tickets API, pole „id“. Příklady 102451024610247
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat ze zdrojového systému.
Popis Tento atribut zaznamenává datum a čas posledního získání dat ze Zendesk Support. Informuje o aktuálnosti analyzovaných dat, takže uživatelé vědí, jak aktuální je zobrazení procesu. Při průběžném sledování a práci s dashboardy je tato informace důležitá. Analytici i další uživatelé díky ní poznají, zda pracují s téměř aktuálními daty, nebo se snímkem z minulého období. To má vliv na platnost jejich závěrů. Proč je to důležité Informuje o aktuálnosti dat, takže uživatelé vědí, jak aktuální je analýza. Kde data získat Jde o pole metadat, které se vytvoří a doplní do datové sady při získávání dat. Příklady 2023-10-27T08:00:00Z
	Zdrojový systém SourceSystem	Označuje systém, ze kterého byla data získána.
Popis Tento atribut určuje původ dat servisního požadavku. V tomto zobrazení procesu bude jeho hodnota vždy „Zendesk Support“, tedy systém, ve kterém se evidují všechny aktivity správy služeb. V prostředí s více propojenými systémy je toto pole důležité pro sledování původu dat a řešení problémů. Zajišťuje, že analýza zahrnuje správný systém, a pomáhá rozlišit data sloučená z různých zdrojů. Proč je to důležité Určuje zdrojový systém dat, umožňuje sledovat jejich původ a předchází nejasnostem při spojování dat z více systémů. Kde data získat Jde o statickou hodnotu („Zendesk Support“), která se přidává při získávání a transformaci dat. Příklady Zendesk Support
	Jméno agenta AgentName	Jméno agenta přiřazeného k servisnímu požadavku v době události.
Popis Tento atribut určuje agenta podpory odpovědného za vyřízení servisního požadavku. Během životního cyklu tiketu se přiřazený agent může několikrát změnit. Pole zaznamenává, kdo za požadavek odpovídal v jednotlivých krocích. Jméno agenta je důležité pro analýzu výkonnosti. Umožňuje filtrovat a členit data podle rozložení pracovní zátěže, doby řešení u jednotlivých agentů a četnosti přeřazení. Pomáhá tak sestavit dashboard výkonnosti agentů a týmů a porozumět tomu, jak jednotliví agenti přispívají k efektivitě procesu. Proč je to důležité Tento atribut je důležitý při analýze výkonnosti agentů, rozložení pracovní zátěže a vlivu přeřazení na dobu řešení. Kde data získat Zendesk Users API, propojením hodnoty „assignee_id“ z odpovědi Tickets API. Příklady Jana NovákováJan NovákEva Jonesová
	Kanál požadavku RequestChannel	Kanál, přes který byl servisní požadavek odeslán, například e-mail, webový formulář nebo telefon.
Popis Tento atribut označuje zdroj, ze kterého servisní požadavek přišel. Zendesk zaznamenává, jak byl tiket vytvořen, například e-mailem, přes webový portál, integraci API, chat nebo jiný kanál. Díky tomu lze určit, jakým způsobem zákazník podporu kontaktoval. Kanál požadavku je užitečná dimenze pro analýzu. V dashboardu „Efektivita kanálů požadavků“ umožňuje porovnávat dobu řešení, hodnocení spokojenosti a míru opakované práce v jednotlivých kanálech. Firmy tak mohou zlepšovat své kanály podpory a nasměrovat uživatele k těm nejefektivnějším. Proč je to důležité Pomáhá analyzovat efektivitu a výsledky různých kanálů zákaznické podpory a cíleně je zlepšovat. Kde data získat Zendesk Tickets API, objekt „via“ a jeho vlastnost „channel“. Příklady webe-mailapichat
	Priorita požadavku RequestPriority	Úroveň priority přiřazená servisnímu požadavku, například nízká, běžná, vysoká nebo naléhavá.
Popis Priorita požadavku označuje jeho naléhavost. Často určuje cílovou dobu řešení a zásady SLA, které se na tiket vztahují. Prioritu může při vytvoření nastavit systém nebo uživatel a agent ji může během vyřizování změnit. Tento atribut je důležitý pro členění dat a analýzu příčin. Pomáhá zjistit, zda se požadavky s vysokou prioritou řeší rychleji než požadavky s nízkou prioritou. Je také jednou z hlavních dimenzí dashboardů „Trendy eskalací servisních požadavků“ a „Dodržování SLA“. Proč je to důležité Umožňuje členit požadavky podle naléhavosti, což je důležité při analýze dodržování SLA a zajištění včasného řešení naléhavých problémů. Kde data získat Zendesk Tickets API, pole „priority“. Příklady NízkáBěžnáVysokáNaléhavá
	Přiřazený tým AssignedTeam	Tým nebo skupina podpory přiřazená k servisnímu požadavku.
Popis Tento atribut označuje tým nebo skupinu v rámci podpory, která odpovídá za servisní požadavek. V Zendesk se tyto skupiny označují jako „Groups“. Tikety se často nejprve přiřadí skupině a teprve potom konkrétnímu agentovi. Analýza podle přiřazeného týmu pomáhá vyhodnotit výkonnost a pracovní zátěž jednotlivých týmů. Ukáže, které týmy vyřizují jaké typy požadavků, jaká je jejich průměrná doba řešení a jak dodržují SLA. Jde o jednu z hlavních dimenzí dashboardu výkonnosti agentů a týmů. Proč je to důležité Umožňuje analyzovat výkonnost týmů, rozložení pracovní zátěže a efektivitu směrování mezi skupinami podpory. Kde data získat Zendesk Groups API, propojením hodnoty „group_id“ z odpovědi Tickets API. Příklady Podpora první úrovněTechnická podporaFakturace
	Stav požadavku RequestStatus	Stav servisního požadavku v době události, například nový, otevřený nebo čekající.
Popis Stav požadavku označuje stav tiketu v konkrétním okamžiku. Zendesk nabízí několik standardních stavů, například New, Open, Pending, On-hold, Solved a Closed, které vyjadřují průběh vyřizování požadavku. Změny tohoto pole jsou hlavním podnětem pro vytváření aktivit v záznamu událostí. Analýza doby strávené v jednotlivých stavech je základem analýzy úzkých míst. Pomáhá odhalit, kde se tikety zdržují, například pokud příliš dlouho čekají ve stavu „Pending“ nebo „On-hold“. Porozumění přechodům mezi stavy pomáhá také odhalit opakované průchody. Proč je to důležité Sledování stavu je základem pro pochopení průběhu požadavku a zjištění, kolik času stráví čekáním a aktivním zpracováním. Kde data získat Zendesk Tickets API, pole „status“. Příklady NovýOtevřenýČekajícíVyřešenýUzavřený
	Štítky tiketu TicketTags	Seznam štítků přiřazených servisnímu požadavku pro jeho kategorizaci a směrování.
Popis Štítky jsou pružné popisky, které mohou agenti přidávat k tiketům ručně nebo se mohou přidávat automaticky podle obchodních pravidel. Doplňují kontext nebo kategorie, které nepokrývají standardní pole, jako jsou typ nebo priorita. Štítky mají při analýze process mining široké využití. Lze podle nich filtrovat konkrétní situace, sledovat vlastní workflow nebo hledat příčiny problémů. Štítek „VIP“ lze například použít k analýze požadavků důležitých zákazníků a štítek „product_bug“ ke sledování průběhu hlášení závad. Proč je to důležité Umožňuje pružně členit data a podrobně analyzovat konkrétní dílčí procesy nebo vlastnosti tiketů, které nejsou zachyceny v jiných polích. Kde data získat Zendesk Tickets API, pole „tags“. Jde o pole řetězců. Příklady dotaz_na_prodejproblém_s_fakturacípožadavek_na_funkcivip_zákazník
	Typ služby ServiceType	Kategorie nebo typ servisního požadavku, například incident, dotaz, problém nebo úkol.
Popis Typ služby označuje povahu servisního požadavku. Zendesk používá pole „type“ k rozlišení různých druhů požadavků na podporu. Toto prvotní zařazení pomáhá směrovat tiket správnému týmu a použít odpovídající postup. Tento atribut je důležitý pro filtrování a porovnávání. Analytici díky němu mohou zkoumat průběh procesu u různých typů požadavků, které se často řeší odlišnými způsoby a podléhají různým SLA. V dashboardu výkonnosti agentů a týmů jde o jednu z hlavních dimenzí, která ukazuje, kdo nejlépe vyřizuje konkrétní typy požadavků. Proč je to důležité Rozděluje požadavky do kategorií a umožňuje samostatně analyzovat různé procesy, například incidenty a dotazy, které mají odlišný průběh. Kde data získat Zendesk Tickets API, pole „type“. Příklady dotazincidentproblémúkol
	Bylo porušeno SLA IsSlaBreached	Příznak, který udává, zda požadavek na službu překročil některý z cílů SLA.
Popis Tento atribut je logický nebo kategoriální příznak, který vyjadřuje výsledek SLA u ticketu. Může nabývat hodnot jako „Splněno“, „Porušeno“ nebo „Aktivní“. Výsledek se určuje porovnáním skutečné doby odpovědi nebo vyřešení s cíli stanovenými v použité SLA policy. Tento atribut je důležitý pro dashboard „Analýza plnění a porušení SLA“. Umožňuje snadno spočítat a zobrazit tickety, které splnily nebo nesplnily SLA. Další analýza se pak může zaměřit na vlastnosti procesu u ticketů s porušeným SLA a hledat příčiny, například dlouhé čekání nebo časté přeřazování. Proč je to důležité Přímo měří plnění závazků týkajících se úrovně služeb. Jde o důležitý ukazatel kvality služeb a spokojenosti zákazníků. Kde data získat Vychází z Zendesk Ticket Metrics API, které poskytuje informace o stavu SLA u každého ticketu. Příklady SplněnoPorušenoAktivní
	Čas ukončení EndTime	Přesné datum a čas dokončení aktivity.
Popis Čas ukončení označuje dokončení aktivity. U mnoha událostí v Zendesk je doba trvání okamžitá, takže čas ukončení odpovídá času zahájení. U aktivit založených na stavu, například „Pozastavení požadavku“, jde o okamžik, kdy se tiket přestane pozastavovat. Tento atribut je nezbytný pro výpočet doby trvání jednotlivých aktivit, který pomáhá odhalovat úzká místa. Porovnáním času zahájení a ukončení lze přímo změřit dobu zpracování a určit, které kroky zabírají nejvíce času. Proč je to důležité Umožňuje vypočítat dobu trvání jednotlivých aktivit, což je důležité pro odhalování úzkých míst procesu a měření efektivity jednotlivých kroků. Kde data získat U jednotlivých událostí bývá tento údaj často stejný jako StartTime. U doby trvání stavů jde o časové razítko následující události, která stav změní. Příklady 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Hodnocení spokojenosti SatisfactionRating	Hodnocení spokojenosti, které žadatel zadal po vyřešení tiketu.
Popis Tento atribut zachycuje zpětnou vazbu zákazníka k podpoře. Obvykle se získává v dotazníku poté, co je tiket označen jako vyřešený. Mezi běžná hodnocení patří „Dobré“ a „Špatné“, někdy doplněná komentářem. Hodnocení spokojenosti je důležitým ukazatelem výsledku. Porovnání průběhu procesu s hodnocením může odhalit, jaké postupy vedou ke spokojenosti nebo nespokojenosti zákazníků. Analýza může například ukázat, že časté přeřazování nebo dlouhá doba řešení úzce souvisí s negativním hodnocením. Proč je to důležité Propojuje průběh procesu s výsledky u zákazníků a pomáhá určit, které postupy ovlivňují jejich spokojenost. Kde data získat Zendesk Tickets API, pole „satisfaction_rating.score“ nebo „satisfaction_rating.reason“. Příklady DobréŠpatnéNabídnuto
	Jde o opakované zpracování IsRework	Příznak má hodnotu true, pokud byl požadavek na službu po vyřešení znovu otevřen.
Popis Tento logický příznak označuje případy, které vyžadovaly opakované zpracování. Za opakované zpracování se požadavek na službu obvykle považuje tehdy, když se jeho stav změní z „Vyřešeno“ zpět na otevřený. Znamená to, že původní řešení nestačilo a zákazník se musel znovu ozvat se stejným problémem. Tento atribut je nezbytný pro výpočet KPI „Míra opakovaného zpracování požadavků na službu“ a pro dashboard „Analýza opakovaného zpracování a znovuotevření“. Označením těchto případů mohou analytici oddělit neefektivní průběhy procesu, zjistit příčiny znovuotevření a hledat způsoby, jak zvýšit míru vyřešení při prvním kontaktu. Proč je to důležité Odhaluje případy, kdy řešení nebylo konečné. Upozorňuje na problémy s kvalitou a efektivitou, které přímo ovlivňují spokojenost zákazníků. Kde data získat Vypočítá se analýzou posloupnosti stavů ticketu v Zendesk Ticket Audits API. Přechod ze stavu 'solved' do stavu 'open' označuje opakované zpracování. Příklady truefalse
	Jméno žadatele RequestorName	Jméno koncového uživatele nebo zákazníka, který servisní požadavek odeslal.
Popis Tento atribut označuje osobu, která servisní požadavek zadala. Propojení požadavku s konkrétním zákazníkem umožňuje sledovat proces z pohledu uživatele. Při analýze procesů lze podle žadatele zkoumat vzorce u konkrétních zákazníků nebo jejich skupin. Lze například zjistit, zda se některým zákazníkům požadavky řeší déle nebo se častěji vracejí. To může ukazovat na problém s produktem nebo službou, kterou používají. Proč je to důležité Propojuje proces se zákazníkem a umožňuje analyzovat jeho konkrétní problémy, opakované požadavky a míru spokojenosti. Kde data získat Zendesk Users API, propojením hodnoty „requester_id“ z odpovědi Tickets API. Příklady Alice JohnsonováBob WilliamsCharlie Brown
	Název zásad SLA SlaPolicyName	Název zásad dohody o úrovni služeb (SLA) použitých na požadavek.
Popis Tento atribut určuje konkrétní SLA policy, která stanovuje cílovou dobu první odpovědi a vyřešení požadavku. Policy se obvykle vybírá podle faktorů, jako je priorita a typ požadavku nebo úroveň předplatného zákazníka. Informace o použité SLA policy je nezbytná pro dashboard „Analýza plnění a porušení SLA“. Poskytuje kontext potřebný k vyhodnocení výkonu, protože každá policy může mít jiné cíle. Díky tomu můžete přesně a spravedlivě posoudit, zda ticket splnil stanovené cíle úrovně služeb. Proč je to důležité Poskytuje kontext pro analýzu SLA. Určuje, podle kterých cílů se požadavek vyhodnocoval, a umožňuje přesně vykazovat plnění SLA. Kde data získat Zendesk Ticket Metrics API. Údaje o SLA se často vztahují k metrikám ticketu. Příklady Urgentní, odpověď do 1 hodinyStandardní, vyřešení do 24 hodinSLA pro prémiové zákazníky
	Organizace žadatele RequestorOrganization	Organizace nebo společnost, ke které žadatel patří.
Popis Tento atribut propojuje servisní požadavek s konkrétní zákaznickou organizací. Je důležitý zejména při podpoře B2B, kde se dohody o úrovni služeb a smlouvy o podpoře často sjednávají na úrovni organizace. Analýza podle organizace poskytuje přehled o výkonnosti podpory na úrovni společnosti. Pomáhá odhalit organizace, které vytvářejí velké množství tiketů, opakovaně řeší stejné problémy nebo mají nízké hodnocení spokojenosti. Tyto informace jsou užitečné pro správu zákaznických vztahů i sledování celkového stavu zákazníků. Proč je to důležité Umožňuje analyzovat podporu B2B podle společností, což je důležité pro správu zákaznických vztahů a SLA na úrovni organizace. Kde data získat Zendesk Organizations API, propojením hodnoty „organization_id“ z odpovědi Tickets API. Příklady Acme CorporationGlobal Tech Inc.Innovate Solutions
	Počet přeřazení mezi agenty AgentReassignmentCount	Celkový počet případů, kdy byl požadavek přeřazen od jednoho agenta k jinému.
Popis Tento atribut počítá, kolikrát se změnilo pole 'assignee_id' u ticketu. Vysoký počet přeřazení jednoho ticketu může ukazovat na různé problémy v procesu, například nesprávné počáteční přiřazení, nedostatečné znalosti agenta nebo příliš složitý požadavek, který jeden agent nedokáže vyřešit. Jde o důležitou metriku pro měření efektivity procesu a přímo podporuje KPI „Míra přeřazení mezi agenty“. Analýza případů s častým přeřazováním může odhalit možnosti, jak upravit pravidla přiřazování, školení agentů nebo zdroje znalostní báze, aby se tickety rychleji dostaly ke správné osobě. Proč je to důležité Pomáhá měřit předávání práce mezi zaměstnanci a odhalovat třecí místa v procesu. Časté přeřazování obvykle způsobuje zpoždění a neefektivitu. Kde data získat Vypočítá se jako počet změn 'assignee_id' v Zendesk Ticket Audits API u každého ticketu. Příklady 013
	Vyřešeno při prvním kontaktu IsFirstContactResolution	Příznak udává, zda požadavek vyřešil první přiřazený agent bez přeřazení a odpovědi od žadatele.
Popis Vyřešení při prvním kontaktu (FCR) je důležitá metrika, která ukazuje, zda byl problém zákazníka vyřešen během jediné interakce. Tento vypočítaný atribut je logický příznak s hodnotou true, pokud ticket vyřešil první přiřazený agent, bez přeřazení a s jedinou odpovědí agenta. Atribut přímo podporuje KPI „Míra vyřešení při prvním kontaktu“. Analýza případů s FCR může ukázat, jak nastavit procesy pro spolehlivé řešení požadavků. Naopak případy bez FCR mohou odhalit příležitosti ke zlepšení školení agentů, článků ve znalostní bázi nebo počátečního třídění požadavků. Proč je to důležité Měří schopnost vyřešit problém efektivně při jediném kontaktu. To výrazně přispívá ke spokojenosti zákazníků i efektivitě provozu. Kde data získat Jde o složitý vypočítaný atribut. Je třeba analyzovat záznam událostí ticketu a ověřit přeřazení mezi agenty i počet veřejných odpovědí agentů. Příklady truefalse

Povinné Doporučené Volitelné

Aktivity při správě požadavků na služby

Toto jsou důležité kroky a milníky procesu, které zaznamenejte do záznamu událostí, abyste mohli přesně zjistit průběh požadavků na služby.

7 Doporučené 6 Volitelné

	Aktivita	Popis
	Nesplnění cíle SLA	Tato aktivita označuje okamžik, kdy servisní požadavek nesplní stanovený cíl SLA, například dobu první odpovědi nebo dobu vyřešení. Zendesk zaznamenává nesplnění cíle jako explicitní událost.
Proč je to důležité Tato událost je důležitá pro sledování shody a slouží jako jeden z hlavních vstupů pro KPI míry dodržení SLA. Ukazuje, kdy nebyly splněny závazky vůči zákazníkům. Kde data získat Zachycuje se jako událost „SLABreach“ v událostech tiketu Zendesk nebo v auditním záznamu. Událost uvádí, která metrika SLA nebyla splněna. Zachycení Identifikuje se podle explicitní události „SLABreach“ v datech tiketu. Typ události explicit
	Odeslání veřejné odpovědi	Tato aktivita označuje každou zprávu, kterou agent odešle žadateli. V datech tiketu Zendesk se zaznamenává jako explicitní událost „Comment“ s atributem „public“ nastaveným na true.
Proč je to důležité Tyto události jsou důležité při analýze četnosti komunikace, měření doby odezvy agentů a zjišťování počtu interakcí potřebných k vyřešení požadavku. Kde data získat Jde o explicitní událost „Comment“ v datech tiketu. Podrobnosti události obsahují atribut „public: true“, který ji odlišuje od interních poznámek. Zachycení Zachycuje se z událostí „Comment“ v tiketu, u kterých je příznak „public“ nastaven na true. Typ události explicit
	Opětovné otevření servisního požadavku	K této události dojde, když žadatel odpoví na požadavek ve stavu „solved“ a jeho stav se automaticky změní zpět na „open“. Znamená to, že navržené řešení nestačilo.
Proč je to důležité Tato aktivita je hlavním ukazatelem opakované práce. Analýza její četnosti pomáhá posoudit kvalitu řešení a odhalit příčiny nespokojenosti zákazníků. Kde data získat Odvozuje se z události „Change“ v poli „status“ v auditním záznamu tiketu, pokud byla předchozí hodnota „solved“ a nová hodnota je „open“. Zachycení Odvozuje se ze změny stavu z „solved“ na „open“. Typ události inferred
	Přiřazení požadavku agentovi	K této činnosti dojde, když je servisní požadavek poprvé přiřazen konkrétnímu agentovi. Odvozuje se z události „Change“ v auditním záznamu ticketu, při níž pole „assignee_id“ získá hodnotu místo null nebo ID skupiny.
Proč je to důležité Tím začíná aktivní práce agenta. Tato událost je důležitá pro měření doby do první reakce, prodlevy před prvním přidělením a rozložení práce mezi agenty. Kde data získat Odvozuje se z první události „Change“ v poli „assignee_id“ v auditním záznamu ticketu, při které se nastaví ID konkrétního uživatele. Zachycení Odvozuje se z první události změny, která nastaví pole „assignee_id“ na konkrétního agenta. Typ události inferred
	Uzavření servisního požadavku	Označuje konečné a trvalé uzavření servisního požadavku. Po uplynutí stanovené doby ve stavu „solved“ se tiket automaticky změní na „closed“ a už ho nelze znovu otevřít.
Proč je to důležité Tato aktivita označuje definitivní konec procesu vyřízení servisního požadavku. Slouží jako koncový bod pro výpočet celkové doby případu. Kde data získat Odvozuje se z události „Change“ v poli „status“ v auditním záznamu tiketu, pokud je nová hodnota „closed“. Zachycení Odvozuje se z události „Change“ v auditním záznamu, při které se stav změní na „closed“. Typ události inferred
	Vyřešení servisního požadavku	Tato aktivita označuje okamžik, kdy agent poskytne řešení a změní stav tiketu na „solved“. Z pohledu agenta je požadavek vyřízený, žadatel ho však může znovu otevřít.
Proč je to důležité Jde o důležitý milník, který označuje konec aktivní práce agenta. Doba do dosažení tohoto stavu je jedním z hlavních ukazatelů efektivity řešení. Kde data získat Odvozuje se z události „Change“ v poli „status“ v auditním záznamu tiketu, pokud je nová hodnota „solved“. Zachycení Odvozuje se z události „Change“ v auditním záznamu, při které se stav změní na „solved“. Typ události inferred
	Vytvoření servisního požadavku	Označuje začátek životního cyklu servisního požadavku, kdy žadatel odešle nový ticket některým z dostupných kanálů. V auditním záznamu ticketu Zendesk se tato událost zaznamená jako „Create“ a určuje přesný začátek procesu.
Proč je to důležité Tato činnost je počáteční událostí každého servisního požadavku. Je proto nezbytná pro výpočet celkové doby vyřízení a analýzu počtu přijatých požadavků. Kde data získat V auditním záznamu ticketu Zendesk se tato událost zaznamenává jako typ „Create“. Její časové razítko udává, kdy byl ticket servisního požadavku vytvořen. Zachycení Získává se přímo z události „Create“ v auditním záznamu ticketu. Typ události explicit
	Eskalace požadavku	Označuje formální předání servisního požadavku na vyšší úroveň podpory, jinému týmu nebo vedení. Obvykle se odvozuje ze změny skupiny přiřazené k tiketu nebo ze změny vlastního pole určeného ke sledování eskalací.
Proč je to důležité Sledování eskalací pomáhá odhalit složité požadavky, potřebu školení agentů první úrovně podpory a systémové problémy, které vyžadují zásah na vyšší úrovni. Kde data získat Nejde o standardní událost. Je nutné ji odvodit z události „Change“ v poli „group_id“, pokud se změní na skupinu pro eskalace, nebo ze změny vlastního pole tiketu určeného ke sledování eskalací. Zachycení Odvozuje se ze změny pole „group_id“ nebo vlastního pole „escalation“. Typ události inferred
	Pozastavení požadavku	K této aktivitě dojde, když se stav servisního požadavku změní na „on-hold“. Obvykle to znamená, že agent čeká na informace od žadatele nebo třetí strany. Událost se odvozuje ze změny stavu.
Proč je to důležité Díky tomu lze oddělit a měřit čekání, které tým podpory nemůže přímo ovlivnit, a přesněji určit dobu práce agenta na požadavku. Kde data získat Odvozuje se z události „Change“ v poli „status“ v auditním záznamu tiketu, pokud je nová hodnota „on-hold“. Zachycení Odvozuje se z události „Change“ v auditním záznamu, při které se stav změní na „on-hold“. Typ události inferred
	Přeřazení požadavku jinému agentovi	Označuje předání odpovědnosti za servisní požadavek od jednoho agenta jinému. Událost se odvozuje z každé další události „Change“ v poli „assignee_id“ po prvním přiřazení.
Proč je to důležité Sledování přeřazení je důležité pro výpočet KPI míry přeřazení mezi agenty. Pomáhá odhalit neefektivní procesy, chybné směrování nebo nedostatky ve znalostech. Kde data získat Odvozuje se z událostí „Change“ v poli „assignee_id“ v auditním záznamu tiketu. První událost přiřazení tiketu se nezapočítává. Zachycení Odvozuje se z druhé a každé následující události „Change“ v poli „assignee_id“. Typ události inferred
	Přidání interní poznámky	Agent přidal k servisnímu požadavku interní poznámku nebo komentář, který vidí pouze ostatní agenti. Zaznamenává se jako událost „Comment“ s atributem „public“ nastaveným na false.
Proč je to důležité Sledování interních poznámek ukazuje, jak spolupracují agenti a týmy. Tato spolupráce může proces zpomalovat, ale také přispívat k rychlejšímu řešení problémů. Kde data získat Jde o explicitní událost „Comment“ v datech tiketu. Podrobnosti události obsahují atribut „public: false“, který označuje interní poznámku. Zachycení Zachycuje se z událostí „Comment“ v tiketu, u kterých je příznak „public“ nastaven na false. Typ události explicit
	Přiřazení cíle SLA	Označuje okamžik, kdy se na ticket servisního požadavku použije pravidlo SLA. Událost se zaznamená, když vlastnosti ticketu odpovídají podmínkám aktivního pravidla SLA.
Proč je to důležité Sledování okamžiku přiřazení SLA je důležité pro kontrolu dodržování pravidel, analýzu možných porušení a pochopení očekávané doby vyřízení různých typů požadavků. Kde data získat Získává se z události „SLAPolicyApplied“ v událostech ticketu nebo v auditním záznamu Zendesk. Událost určuje, které pravidlo bylo použito. Zachycení Určuje se podle výslovné události „SLAPolicyApplied“ v datech ticketu. Typ události explicit
	Změna priority	Označuje změnu priority servisního požadavku, například na „Low“, „Normal“, „High“ nebo „Urgent“. V auditním záznamu ticketu se zaznamená jako událost „Change“ v poli „priority“.
Proč je to důležité Analýza změn priority pomáhá odhalit požadavky, jejichž naléhavost se postupně zvyšuje, a posoudit, zda se priority řídí účinně. Kde data získat Zaznamenává se jako událost „Change“ v poli „priority“ v auditním záznamu tiketu Zendesk. Událost obsahuje předchozí i novou hodnotu. Zachycení Odvozuje se z událostí „Change“ v poli „priority“ v auditním záznamu. Typ události inferred

Doporučené Volitelné

Návody na získání dat

Jak získat data ze Zendesk Support

Kroky

Otevřete Zendesk Explore a vytvořte hlavní sestavu: V horní liště vpravo otevřete nabídku produktů Zendesk a vyberte Explore. V Explore klikněte vlevo na ikonu Queries a potom na New query. Jako zdroj vyberte datovou sadu Support: Ticket updates.
Nastavte metriky a atributy událostí ticketu: V nástroji pro tvorbu dotazů přidejte metriku, například COUNT(Tickets), abyste zobrazili data. Potom v části Rows přidejte tyto atributy: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type a Ticket tags.
Vytvořte vypočítaný atribut ActivityName: Abyste nezpracované aktualizace převedli na srozumitelné aktivity, vytvořte standardní vypočítaný atribut. Otevřete nabídku Calculations (ikona kalkulačky), vyberte Standard calculated attribute a pojmenujte atribut ActivityName. Vložte logiku uvedenou v části Query do pole vzorce. Vzorec přiřadí různým událostem aktualizace ticketu odpovídající názvy aktivit.
Upravte a filtrujte hlavní sestavu: Přidejte nový atribut ActivityName do části Rows. Nastavte pro něj filtr, který vyloučí hodnoty (null) a nežádoucí hodnoty generované systémem, aby byla data čistá. Přidejte také filtr pro Ticket created - Date a omezte dotaz na přiměřené období, například posledních 6 měsíců.
Vytvořte druhou sestavu pro události SLA: Vytvořte další dotaz a tentokrát vyberte datovou sadu Support: SLAs. Je to nutné, protože datová sada Ticket updates události SLA neobsahuje.
Nastavte sestavu SLA: V dotazu SLA přidejte do části Metrics metriku COUNT(SLA tickets). V části Rows přidejte Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status a Updater name. Aktivitu odvodíme ze SLA status při transformaci dat.
Exportujte obě datové sady: Spusťte oba dotazy v Explore. Po vygenerování tabulek klikněte na Export a vyberte formát CSV. Získáte dva samostatné soubory CSV.
Sloučte a transformujte data: Sloučte oba soubory CSV pomocí tabulkového procesoru, například Microsoft Excel, nebo skriptovacího jazyka, například Pythonu. Cílem je vytvořit jeden záznam událostí. V souboru SLA vytvořte sloupec ActivityName. Pokud má SLA status hodnotu Active, nastavte aktivitu na SLA Target Applied. Pokud má hodnotu Breached, nastavte ji na SLA Target Breached. Jako EventTimestamp použijte SLA updated - Timestamp.
Sjednoťte názvy sloupců: V konečném sloučeném souboru přejmenujte sloupce tak, aby odpovídaly požadovanému formátu pro process mining. Například přejmenujte Ticket ID na ServiceRequestId, Update - Timestamp na EventTimestamp a Updater name na AgentName.
Přidejte statické sloupce a dokončete soubor: Do konečného souboru CSV přidejte dva sloupce. Do SourceSystem zadejte hodnotu 'Zendesk'. Do LastDataUpdate zadejte časové razítko exportu. Soubor je nyní připravený k nahrání.

Konfigurace

Plán Zendesk: K vytváření vlastních dotazů a atributů potřebujete plán Zendesk Support, který zahrnuje Zendesk Explore Professional nebo Enterprise.
Oprávnění: Musíte být agentem s oprávněním vytvářet a upravovat dotazy v Explore. Obvykle jde o správce nebo agenta s vlastní rolí.
Výběr datové sady: Tato metoda vyžaduje dvě samostatné sestavy založené na různých datových sadách: Support: Ticket updates pro běžné události a Support: SLAs pro události SLA.
Filtr období: Je důležité nastavit filtr období, například pro Ticket created - Date, aby objem dat zůstal přiměřený. Pro počáteční analýzu doporučujeme období 3 až 6 měsíců.
Vypočítané atributy: Názvy aktivit se odvozují pomocí složitého vlastního vypočítaného atributu v Explore. Vzorec vytvořte správně, aby ve výstupu nedocházelo k chybám.
Objem dat: Uživatelské rozhraní Zendesk Explore a funkce exportu mohou být u velmi rozsáhlých dat pomalé nebo mohou přestat reagovat. Pokud exportujete data za více než rok nebo miliony ticketů, rozdělte export na menší období.

Ukázkový dotaz config

This method uses the Zendesk Explore UI, where queries are built visually. The following describes the configuration for the two required reports.

**Report 1: Ticket Events Configuration**
* **Dataset**: `Support: Ticket updates`
* **Metrics**: `COUNT(Tickets)`
* **Rows**:
  * `Ticket ID`
  * `ActivityName` (This is the custom calculated attribute defined below)
  * `Update - Timestamp`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
  * `Ticket status`
  * `Submission channel`
  * `Ticket type`
  * `Ticket tags`
* **Standard Calculated Attribute (`ActivityName`) Formula**:
```
IF [Update - Field name] = "assignee_id" AND ([Update - Previous value] = "" OR [Update - Previous value] = NULL) THEN
    "Request Assigned to Agent"
ELIF [Update - Field name] = "assignee_id" AND [Update - Previous value] != "" AND [Update - Previous value] != NULL THEN
    "Agent Reassigned"
ELIF [Update - Field name] = "group_id" THEN
    "Request Escalated"
ELIF [Update - Field name] = "priority" AND [Update - New value] != [Update - Previous value] THEN
    "Priority Changed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "hold" THEN
    "Request Placed On-Hold"
ELIF [Update - Field name] = "status" AND [Update - New value] = "solved" THEN
    "Service Request Resolved"
ELIF [Update - Field name] = "status" AND [Update - New value] = "closed" THEN
    "Service Request Closed"
ELIF [Update - Field name] = "status" AND [Update - New value] = "open" AND [Update - Previous value] = "solved" THEN
    "Service Request Reopened"
ELIF [Update - Field name] = "requester_id" AND [Update - Previous value] = NULL THEN
    "Service Request Created"
ELSE
    NULL
ENDIF
```
* **Note on Comment Activities**: Capturing `Public Reply Sent` and `Internal Note Added` from the `Ticket updates` dataset is not reliably possible as the public vs. internal distinction is often missing. For these events, creating a third report on the `Support: Comments` dataset and merging it is the recommended, though more complex, approach.

**Report 2: SLA Events Configuration**
* **Dataset**: `Support: SLAs`
* **Metrics**: `COUNT(SLA tickets)`
* **Rows**:
  * `Ticket ID`
  * `SLA updated - Timestamp`
  * `SLA status`
  * `Updater name`
  * `Assignee name`
  * `Group name`
  * `Ticket priority`
* **Note**: The `ActivityName` for this report (`SLA Target Applied`, `SLA Target Breached`) must be generated after export based on the value in the `SLA status` column.

Kroky

Předpoklady: Ověřte, že máte v systému nainstalovaný Python 3.6 nebo novější. K vytvoření API tokenu budete také potřebovat správcovský přístup k instanci Zendesk Support.
Nainstalujte knihovny Pythonu: Otevřete terminál nebo příkazový řádek a pomocí pip nainstalujte potřebné knihovny Pythonu. Knihovna requests slouží k volání API a pandas ke zpracování dat a exportu do souboru CSV.
```
pip install requests pandas
```
Vytvořte API token Zendesk: Přihlaste se do Zendesk jako správce. Přejděte do Admin Center > Apps and integrations > APIs > Zendesk API. V části Token Access tuto možnost zapněte, pokud ještě není aktivní, a klikněte na „Add API token“. Zadejte popis, například „ProcessMind Extraction“, a zkopírujte vytvořený token. Později už se znovu nezobrazí.
Nastavte skript v Pythonu: Otevřete dodaný skript v textovém editoru. Vyplňte konfigurační proměnné v horní části souboru: ZENDESK_SUBDOMAIN (název domény Zendesk vaší společnosti), ZENDESK_EMAIL (e-mailová adresa správce, ke kterému je token přiřazen) a ZENDESK_API_TOKEN. Nastavte také START_TIME_STR, který určuje začátek období extrakce dat, obvykle 3 až 6 měsíců zpětně.
Seznamte se s logikou skriptu: Skript nejprve pomocí efektivního Incremental Tickets API načte seznam ticketů aktualizovaných ve zvoleném období. Potom u každého ticketu načte úplnou historii auditů, komentáře a metriky SLA. Události seřadí chronologicky a vytvoří podrobnou historii.
Převeďte události Zendesk na aktivity: Skript obsahuje logiku, která převádí nezpracované události Zendesk na požadované obchodní aktivity. Například událost 'Change' v poli 'status' se převede na aktivity jako 'Service Request Resolved' nebo 'Request Placed On-Hold'. U událostí komentářů skript určí, zda jde o 'Public Reply Sent', nebo 'Internal Note Added'.
Spusťte skript pro extrakci: V terminálu spusťte příkaz python your_script_name.py. Skript bude při načítání dat z Zendesk API vypisovat průběh. Doba zpracování závisí na objemu dat a limitech API.
Zkontrolujte výstupní soubor: Po dokončení skript vytvoří ve stejné složce soubor CSV s názvem zendesk_event_log.csv. Soubor obsahuje extrahovaný záznam událostí se všemi zadanými aktivitami a atributy.
Připravte soubor k nahrání: Otevřete soubor CSV a ověřte, že má správný formát. Názvy sloupců musí odpovídat požadovaným atributům, například ServiceRequestId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate. Soubor je nyní připravený k nahrání do ProcessMind.

Konfigurace

Přístup k Zendesk API: Skript vyžaduje platný API token přiřazený správci nebo agentovi s dostatečnými oprávněními. E-mailová adresa uživatele nastavená ve skriptu musí být stejná jako adresa uživatele, který vytvořil API token.
Parametry skriptu: Před spuštěním nastavte ve skriptu tyto důležité proměnné: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN a START_TIME_STR. Hodnotu START_TIME_STR zadejte ve formátu 'YYYY-MM-DD'.
Období: Pro začátek doporučujeme extrahovat data za poslední 3 až 6 měsíců (START_TIME_STR). Získáte reprezentativní data pro analýzu, aniž by extrakce trvala příliš dlouho nebo často narážela na limity API. Při delším období se doba extrakce výrazně prodlouží.
Incremental Exports API: Skript používá endpoint Incremental Exports (/api/v2/incremental/tickets/cursor.json), který efektivně načítá pouze tickety aktualizované od posledního spuštění nebo od zadaného počátečního času. Je to výrazně rychlejší než procházet všechny tickety.
Omezení počtu požadavků: Zendesk uplatňuje limity pro API. Skript při dosažení limitu pozastaví zpracování, ale extrakce z velmi rozsáhlých instancí může trvat dlouho. Doporučujeme spustit skript mimo špičku.
Logika eskalace: Aktivita 'Request Escalated' se odvozuje ze změny pole group_id. Pokud vaše organizace používá jiný způsob, například vlastní pole ticketu, upravte logiku skriptu tak, aby eskalace správně rozpoznal.

Ukázkový dotaz python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, admin email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[Your Subdomain]'
ZENDESK_EMAIL = class="hl-string">'[Your Zendesk Admin Email]'
ZENDESK_API_TOKEN = class="hl-string">'[Your Zendesk API Token]'

class=class="hl-string">"hl-comment"># Set the start date for the data extraction (YYYY-MM-DD)
START_TIME_STR = class="hl-string">'2023-01-01'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

class=class="hl-string">"hl-comment"># Set up constants and session
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.now(timezone.utc).isoformat()

session = requests.Session()
session.auth = AUTH

class=class="hl-string">"hl-comment"># Caches for user and group names to reduce API calls
user_cache = {}
group_cache = {}

def get_user_name(user_id):
    if not user_id:
        return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'User ID {user_id}'

def get_group_name(group_id):
    if not group_id:
        return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return fclass="hl-string">'Group ID {group_id}'

def handle_rate_limit(response):
    if response.status_code == 429:
        retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
        print(fclass="hl-string">'Rate limit reached. Waiting for {retry_after} seconds...')
        time.sleep(retry_after)
        return True
    response.raise_for_status()
    return False

def fetch_paginated_data(url):
    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            yield data
            url = data.get(class="hl-string">'next_page')
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'Error fetching data from {url}: {e}')
            break

def process_ticket(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    print(fclass="hl-string">'Processing Ticket ID: {ticket_id}')

    class=class="hl-string">"hl-comment"># --- 1. Fetch Ticket Audits ---
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    all_events = [] class=class="hl-string">"hl-comment"># A temporary list to hold all events for sorting

    for audit_page in fetch_paginated_data(audits_url):
        for audit in audit_page.get(class="hl-string">'audits', []):
            author_id = audit.get(class="hl-string">'author_id')
            timestamp = audit[class="hl-string">'created_at']

            class=class="hl-string">"hl-comment"># Store ticket state at the time of the audit
            ticket_state = {}
            for event in audit.get(class="hl-string">'events', []):
                if event.get(class="hl-string">'field_name') in [class="hl-string">'assignee_id', class="hl-string">'group_id', class="hl-string">'priority', class="hl-string">'status', class="hl-string">'channel', class="hl-string">'type', class="hl-string">'tags']:
                    ticket_state[event[class="hl-string">'field_name']] = event.get(class="hl-string">'value')

            for event in audit.get(class="hl-string">'events', []):
                event[class="hl-string">'timestamp'] = timestamp
                event[class="hl-string">'author_id'] = author_id
                event[class="hl-string">'ticket_state'] = ticket_state
                all_events.append(event)

    class=class="hl-string">"hl-comment"># --- 2. Fetch Comments (which are not fully detailed in audits) ---
    comments_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/comments.json'
    for comment_page in fetch_paginated_data(comments_url):
        for comment in comment_page.get(class="hl-string">'comments', []):
            comment[class="hl-string">'type'] = class="hl-string">'Comment'
            comment[class="hl-string">'timestamp'] = comment[class="hl-string">'created_at']
            class=class="hl-string">"hl-comment"># Add ticket_state placeholder, though it's less relevant for comments
            comment[class="hl-string">'ticket_state'] = {}
            all_events.append(comment)

    class=class="hl-string">"hl-comment"># --- 3. Fetch SLA Metrics ---
    metrics_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json'
    try:
        response = session.get(metrics_url)
        if not handle_rate_limit(response):
            metrics_data = response.json().get(class="hl-string">'ticket_metric', {})
            if metrics_data.get(class="hl-string">'sla_policy'):
                for sla in metrics_data[class="hl-string">'sla_policy'][class="hl-string">'policy_metrics']:
                    all_events.append({
                        class="hl-string">'type': class="hl-string">'SlaApply',
                        class="hl-string">'timestamp': metrics_data[class="hl-string">'created_at'],
                        class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                        class="hl-string">'ticket_state': {}
                    })
                    if sla.get(class="hl-string">'breach_at') and datetime.fromisoformat(sla[class="hl-string">'breach_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')) < datetime.now(timezone.utc):
                        all_events.append({
                            class="hl-string">'type': class="hl-string">'SlaBreach',
                            class="hl-string">'timestamp': sla[class="hl-string">'breach_at'],
                            class="hl-string">'policy_name': sla[class="hl-string">'policy'][class="hl-string">'title'],
                            class="hl-string">'metric': sla[class="hl-string">'metric'],
                            class="hl-string">'ticket_state': {}
                        })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Could not fetch SLA metrics for ticket {ticket_id}: {e}')


    class=class="hl-string">"hl-comment"># --- 4. Sort all collected events by timestamp ---
    all_events.sort(key=lambda x: x[class="hl-string">'timestamp'])

    class=class="hl-string">"hl-comment"># --- 5. Process sorted events to create event log rows ---
    last_assignee = None

    for event in all_events:
        activity_name = None
        timestamp = event[class="hl-string">'timestamp']

        event_type = event.get(class="hl-string">'type')
        field_name = event.get(class="hl-string">'field_name')

        if event_type == class="hl-string">'Create':
            activity_name = class="hl-string">'Service Request Created'
            last_assignee = event.get(class="hl-string">'value') if field_name == class="hl-string">'assignee_id' else None

        elif event_type == class="hl-string">'Change':
            prev_value = event.get(class="hl-string">'previous_value')
            new_value = event.get(class="hl-string">'value')

            if field_name == class="hl-string">'status':
                if new_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Resolved'
                elif new_value == class="hl-string">'closed': activity_name = class="hl-string">'Service Request Closed'
                elif new_value == class="hl-string">'hold': activity_name = class="hl-string">'Request Placed On-Hold'
                elif new_value == class="hl-string">'open' and prev_value == class="hl-string">'solved': activity_name = class="hl-string">'Service Request Reopened'
            elif field_name == class="hl-string">'priority': activity_name = class="hl-string">'Priority Changed'
            elif field_name == class="hl-string">'assignee_id':
                if prev_value is None and new_value is not None:
                    activity_name = class="hl-string">'Request Assigned to Agent'
                elif prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Agent Reassigned'
                last_assignee = new_value
            elif field_name == class="hl-string">'group_id':
                if prev_value is not None and new_value is not None:
                    activity_name = class="hl-string">'Request Escalated'

        elif event_type == class="hl-string">'Comment':
            if event.get(class="hl-string">'public', False):
                activity_name = class="hl-string">'Public Reply Sent'
            else:
                activity_name = class="hl-string">'Internal Note Added'

        elif event_type == class="hl-string">'SlaApply':
            activity_name = class="hl-string">'SLA Target Applied'
        elif event_type == class="hl-string">'SlaBreach':
            activity_name = class="hl-string">'SLA Target Breached'

        if activity_name:
            class=class="hl-string">"hl-comment"># Get attribute values from the ticket object itself as a baseline
            agent_id = ticket.get(class="hl-string">'assignee_id')
            group_id = ticket.get(class="hl-string">'group_id')
            priority = ticket.get(class="hl-string">'priority')
            status = ticket.get(class="hl-string">'status')
            
            class=class="hl-string">"hl-comment"># Override with values at the time of the event if available
            state = event.get(class="hl-string">'ticket_state', {})
            agent_id = state.get(class="hl-string">'assignee_id', agent_id)
            group_id = state.get(class="hl-string">'group_id', group_id)
            priority = state.get(class="hl-string">'priority', priority)
            status = state.get(class="hl-string">'status', status)
            
            event_log.append({
                class="hl-string">'ServiceRequestId': ticket_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTimestamp': timestamp,
                class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                class="hl-string">'AgentName': get_user_name(agent_id),
                class="hl-string">'AssignedTeam': get_group_name(group_id),
                class="hl-string">'RequestPriority': priority,
                class="hl-string">'RequestStatus': status,
                class="hl-string">'RequestChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'type'),
                class="hl-string">'TicketTags': class="hl-string">', '.join(ticket.get(class="hl-string">'tags', [])),
            })


def main():
    print(class="hl-string">'Starting Zendesk data extraction...')
    event_log = []
    start_unix_time = int(datetime.strptime(START_TIME_STR, class="hl-string">'%Y-%m-%d').timestamp())
    
    class=class="hl-string">"hl-comment"># Use the incremental export endpoint for efficiency
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={start_unix_time}'

    while url:
        try:
            response = session.get(url)
            if handle_rate_limit(response):
                continue
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])
            print(fclass="hl-string">'Fetched {len(tickets)} tickets...')
            for ticket in tickets:
                process_ticket(ticket, event_log)
            
            if not data.get(class="hl-string">'after_cursor'):
                break
            url = data[class="hl-string">'next_page']

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'A critical error occurred: {e}')
            break

    print(fclass="hl-string">'Extraction complete. Total events found: {len(event_log)}')
    
    if not event_log:
        print(class="hl-string">'No events were extracted. Please check your configuration and date range.')
        return

    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Reorder columns to match requirements
    columns = [
        class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'AgentName', class="hl-string">'AssignedTeam', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus',
        class="hl-string">'RequestChannel', class="hl-string">'ServiceType', class="hl-string">'TicketTags'
    ]
    df = df[columns]
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTimestamp']).reset_index(drop=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'zendesk_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">'Event log saved to {output_filename}')

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

Kroky

V Zendesk Admin Center požádejte o nativní export celého účtu ve formátu JSON nebo jej spusťte pomocí funkce exportu dostupné ve vašem předplatném a účtu Zendesk. Přesná cesta v nabídce a požadavky na oprávnění se liší podle nastavení účtu. Použijte možnost exportu v Admin Center a postupujte podle schvalovacího procesu vaší organizace.
Vyberte období, které pokrývá požadovanou analýzu, nejlépe tři až šest měsíců. Pokud nativní export neumožňuje nastavit filtr období, stáhněte export celého účtu a filtrujte data při transformaci.
Stáhněte a uchovejte všechny soubory JSON vytvořené exportem. Zachovejte původní soubory, časové razítko exportu, identifikátor účtu a případný soubor manifestu nebo metadat. Při zpracování nepřepisujte zdrojové soubory.
Zpracujte záznamy ticketů, záznamy auditů ticketů, události auditů, komentáře, uživatele, organizace, skupiny, záznamy související se SLA a vlastní pole obsažená v exportu. Názvy souborů a struktura JSON se mohou lišit podle verze exportu Zendesk. Před spuštěním proto v zástupných hodnotách skriptu nastavte cesty ke zdrojovým souborům a mapování vlastností JSON.
Převeďte každou událost auditu ticketu do jednotné struktury, která obsahuje ServiceRequestId, časové razítko auditu, typ události, název pole, předchozí hodnotu, novou hodnotu, identifikátor aktéra, příznak veřejného komentáře, stav ticketu, přiřazeného agenta, skupinu, prioritu, kanál, typ služby, štítky, zdrojový systém a LastDataUpdate.
Vytvořte jeden řádek záznamu událostí pro každou odpovídající aktivitu. Extrakce musí výslovně vytvořit řádky pro aktivity Service Request Created, SLA Target Applied, Request Assigned to Agent, Priority Changed, Agent Reassigned, Public Reply Sent, Internal Note Added, Request Placed On-Hold, Request Escalated, SLA Target Breached, Service Request Reopened, Service Request Resolved a Service Request Closed. ProcessMind načte tyto řádky beze změny a další události neodvozuje.
Pokud jsou k dispozici odpovídající exportované záznamy uživatelů, skupin a organizací, přiřaďte k identifikátorům agentů, skupin, organizací a žadatelů jejich údaje. Hodnoty AgentName a AssignedTeam určete podle přiřazení platného v době události. Pokud se zobrazovaný název nepodaří zjistit, ponechte identifikátor nebo prázdnou hodnotu.
Použijte jednoznačně definovaná pravidla pro události. Pro Service Request Created použijte událost vytvoření ticketu v auditu. Pro SLA Target Applied a SLA Target Breached použijte výslovné události SLA auditu. První odpovídající změnu přiřazeného agenta použijte pro Request Assigned to Agent a další změny pro Agent Reassigned. Pro události odpovědí a poznámek použijte příznaky veřejných a soukromých komentářů. Pro události pozastavení, znovuotevření, vyřešení a uzavření použijte změny stavu. Pro Request Escalated použijte změny skupiny nebo nastaveného eskalačního pole.
Seřaďte výsledné řádky podle ServiceRequestId a EventTimestamp. Při shodě použijte jako další kritérium stabilní pořadí zdrojových událostí. Neodstraňujte události jen proto, že mají stejné časové razítko. Ve stejnou dobu může dojít k několika komentářům nebo událostem auditu.
Ověřte, že jsou přítomny všechny povinné sloupce a že každá aktivita má alespoň jeden odpovídající řádek, pokud zdrojová data obsahují příslušnou událost. Výsledek exportujte jako soubor UTF-8 CSV nebo v jiném formátu záznamu událostí podporovaném ProcessMind. Každá událost musí mít vlastní řádek a požadované názvy sloupců ServiceRequestId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate.

Konfigurace

Rozsah exportu: Použijte nativní export celého účtu Zendesk Support ve formátu JSON a uchovejte všechny vytvořené soubory JSON. Export by měl obsahovat data ticketů a jejich auditů nebo událostí. Pokud jsou data SLA, komentářů, uživatelů, organizací, skupin nebo vlastních polí dodána samostatně, zahrňte tyto soubory do vstupních dat pro transformaci.
Období: Při počáteční extrakci a ověřování zvolte nejlépe tři až šest měsíců. Pokud nativní export zahrnuje celý účet a nelze jej omezit na konkrétní období, filtrujte po zpracování podle EventTimestamp a současně uchovejte úplný archiv zdrojových dat.
Pravidla pro aktivity: Nastavte výslovné mapování všech 13 aktivit. Nespoléhejte na to, že ProcessMind odvodí události přiřazení, eskalace, SLA, změny stavu nebo komentářů z jiných řádků.
Nastavení SLA: Namapujte skutečné názvy událostí nebo vlastnosti v exportu, které účet používá pro uplatnění cíle SLA a jeho porušení. Pokud export neobsahuje výslovné události SLA, nevytvářejte je uměle. Nastavte odpovídající cesty ke zdrojovým datům v zástupných hodnotách a zdokumentujte všechny nedostupné aktivity.
Nastavení eskalace: Určete pole skupiny nebo vlastní pole konkrétního účtu, které označuje eskalaci. Před spuštěním nastavte ESCALATION_FIELD_ID nebo odpovídající konfiguraci na skutečný identifikátor pole v exportu.
Cesty ke zdrojovým datům: Ve skriptu nastavte cesty k souborům JSON a mapování vlastností JSON. Názvy souborů exportu Zendesk a jejich vnořená struktura se mohou lišit podle verze exportu a nastavení účtu.
Požadovaný výstup: U každého řádku události musí být vyplněny hodnoty ServiceRequestId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate. Doporučené sloupce jsou AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType a TicketTags.
Filtry: Filtr období analýzy, rozsah účtu nebo značky a případné filtry specifické pro společnost použijte až po ověření odpovídající vlastnosti v exportu. Nepoužívejte filtry založené na nepodporovaných nebo neověřených názvech polí.
Výkon: Pokud možno zpracovávejte JSON postupně a nenačítejte celý export účtu do paměti. Indexujte identifikátory ticketů a auditů a před vytvořením konečného záznamu událostí zapisujte normalizovaná mezidata. Rozsáhlé exporty může být nutné rozdělit podle období nebo identifikátoru ticketu.
Předpoklady: Správcovský přístup k vyžádání nebo stažení nativního exportu účtu, oprávnění k auditům ticketů a referenčním údajům uživatelů nebo skupin, předplatné Zendesk s podporou exportu, místní úložiště pro celý export a prostředí, které dokáže zpracovat JSON a zapisovat soubory UTF-8 CSV.
Ochrana dat: S údaji o žadatelích, agentech, organizacích, komentářích a ticketech zacházejte jako s potenciálně citlivými. Zdrojové i transformované soubory ukládejte v souladu s pravidly organizace pro uchovávání dat, řízení přístupu a ochranu soukromí.

Ukázkový dotaz config

import csv
import json
import os
from datetime import datetime, timezone
from pathlib import Path

SOURCE_DIRECTORY = "[Path to extracted Zendesk JSON directory]"
OUTPUT_FILE = "[Path to ProcessMind event log CSV]"
START_DATE = "[YYYY-MM-DD or blank]"
END_DATE = "[YYYY-MM-DD or blank]"
SOURCE_SYSTEM = "Zendesk Support"
LAST_DATA_UPDATE = "[ISO-8601 timestamp of source refresh]"
ESCALATION_FIELD_ID = "[Zendesk custom field identifier used for escalation, or blank]"


def load_json_files(directory):
    documents = []
    for path in Path(directory).rglob("*.json"):
        with path.open("r", encoding="utf-8") as handle:
            documents.append((path.name, json.load(handle)))
    return documents


def as_list(value):
    if isinstance(value, list):
        return value
    if isinstance(value, dict):
        for key in ("tickets", "ticket", "audits", "events", "comments", "users", "groups", "organizations", "data", "results"):
            if isinstance(value.get(key), list):
                return value[key]
    return []


def parse_timestamp(value):
    if not value:
        return None
    text = str(value).replace("Z", "+00:00")
    try:
        parsed = datetime.fromisoformat(text)
        if parsed.tzinfo is None:
            parsed = parsed.replace(tzinfo=timezone.utc)
        return parsed.astimezone(timezone.utc)
    except ValueError:
        return None


def in_range(timestamp):
    if timestamp is None:
        return False
    if START_DATE and timestamp.date().isoformat() < START_DATE:
        return False
    if END_DATE and timestamp.date().isoformat() > END_DATE:
        return False
    return True


def value(record, *keys):
    for key in keys:
        if isinstance(record, dict) and record.get(key) is not None:
            return record.get(key)
    return None


def identifier(record):
    return value(record, "id", "user_id", "group_id", "organization_id", "ticket_id")


def normalize_id(value_to_normalize):
    if value_to_normalize is None or value_to_normalize == "":
        return None
    return str(value_to_normalize)


def audit_events(audit):
    events = value(audit, "events", "audit_events")
    return events if isinstance(events, list) else []


def event_type(event):
    return str(value(event, "type", "event_type", "action") or "").lower()


def event_field(event):
    return str(value(event, "field_name", "field", "property") or "").lower()


def event_value(event, key):
    return value(event, key, key.replace("_", ""))


def status_value(ticket, event, new=True):
    if new:
        return value(event, "value", "new_value", "to") or value(ticket, "status")
    return value(event, "previous_value", "old_value", "from")


def comment_public(event):
    public_value = value(event, "public", "is_public")
    return public_value is True or str(public_value).lower() == "true"


def add_row(rows, ticket, activity, timestamp, agent_name=None, assigned_team=None, priority=None, status=None, channel=None, service_type=None, tags=None, sequence=0):
    parsed = parse_timestamp(timestamp)
    if not in_range(parsed):
        return
    rows.append({
        "ServiceRequestId": str(value(ticket, "id", "ticket_id")),
        "ActivityName": activity,
        "EventTimestamp": parsed.isoformat(),
        "SourceSystem": SOURCE_SYSTEM,
        "LastDataUpdate": LAST_DATA_UPDATE,
        "AgentName": agent_name or "",
        "AssignedTeam": assigned_team or "",
        "RequestPriority": priority or "",
        "RequestStatus": status or "",
        "RequestChannel": channel or "",
        "ServiceType": service_type or "",
        "TicketTags": ",".join(tags) if isinstance(tags, list) else (tags or ""),
        "SourceSequence": sequence
    })


def main():
    documents = load_json_files(SOURCE_DIRECTORY)
    tickets = {}
    audits_by_ticket = {}
    users = {}
    groups = {}
    organizations = {}
    standalone_comments = []
    standalone_sla_events = []

    for filename, document in documents:
        records = as_list(document)
        lower_name = filename.lower()
        for record in records:
            if not isinstance(record, dict):
                continue
            record_id = normalize_id(identifier(record))
            if any(token in lower_name for token in ("user", "agent")) and record_id:
                users[record_id] = record
            elif "group" in lower_name and record_id:
                groups[record_id] = record
            elif "organization" in lower_name and record_id:
                organizations[record_id] = record
            elif "audit" in lower_name and value(record, "ticket_id") is not None:
                audits_by_ticket.setdefault(normalize_id(value(record, "ticket_id")), []).append(record)
            elif "comment" in lower_name:
                standalone_comments.append(record)
            elif "sla" in lower_name:
                standalone_sla_events.append(record)
            elif value(record, "ticket_id") is not None and value(record, "type", "event_type") is not None:
                standalone_sla_events.append(record)
            elif value(record, "id") is not None and any(key in record for key in ("status", "priority", "assignee_id", "group_id", "tags")):
                tickets[record_id] = record

    rows = []
    for ticket_id, ticket in tickets.items():
        if not ticket_id:
            continue
        ticket_audits = audits_by_ticket.get(ticket_id, [])
        ticket_audits.sort(key=lambda item: (parse_timestamp(value(item, "created_at", "timestamp", "time")) or datetime.min.replace(tzinfo=timezone.utc), str(value(item, "id") or "")))
        current_assignee = normalize_id(value(ticket, "assignee_id"))
        current_group = normalize_id(value(ticket, "group_id"))
        assignment_seen = False
        sequence = 0
        base_priority = value(ticket, "priority")
        base_status = value(ticket, "status")
        base_channel = value(ticket, "via", "channel")
        base_service_type = value(ticket, "type", "service_type")
        base_tags = value(ticket, "tags") or []

        for audit in ticket_audits:
            audit_time = value(audit, "created_at", "timestamp", "time")
            actor_id = normalize_id(value(audit, "author_id", "actor_id", "user_id"))
            actor = users.get(actor_id, {})
            agent_name = value(actor, "name", "display_name", "email") or ""
            audit_group = groups.get(current_group, {})
            assigned_team = value(audit_group, "name", "display_name") or ""
            for event in audit_events(audit):
                sequence += 1
                kind = event_type(event)
                field = event_field(event)
                timestamp = value(event, "created_at", "timestamp", "time") or audit_time
                new_value = event_value(event, "value") or event_value(event, "new_value") or event_value(event, "to")
                old_value = event_value(event, "previous_value") or event_value(event, "old_value") or event_value(event, "from")
                event_agent = agent_name
                event_team = assigned_team
                if field in ("assignee_id", "assignee"):
                    new_assignee = normalize_id(new_value)
                    old_assignee = normalize_id(old_value)
                    if new_assignee and not assignment_seen and new_assignee != current_group:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Request Assigned to Agent", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                        assignment_seen = True
                    elif new_assignee and assignment_seen and new_assignee != old_assignee:
                        assigned_agent = users.get(new_assignee, {})
                        add_row(rows, ticket, "Agent Reassigned", timestamp, value(assigned_agent, "name", "display_name", "email") or event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_assignee = new_assignee or current_assignee
                elif field in ("priority",):
                    add_row(rows, ticket, "Priority Changed", timestamp, event_agent, event_team, new_value, base_status, base_channel, base_service_type, base_tags, sequence)
                    base_priority = new_value or base_priority
                elif field in ("group_id", "group"):
                    new_group = normalize_id(new_value)
                    new_group_record = groups.get(new_group, {})
                    new_team = value(new_group_record, "name", "display_name") or event_team
                    if new_group and new_group != current_group:
                        add_row(rows, ticket, "Request Escalated", timestamp, event_agent, new_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    current_group = new_group or current_group
                elif field in ("status", "status_category"):
                    status_text = str(new_value or "").lower()
                    old_status_text = str(old_value or "").lower()
                    if status_text == "on-hold":
                        add_row(rows, ticket, "Request Placed On-Hold", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "solved":
                        add_row(rows, ticket, "Service Request Resolved", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if status_text == "closed":
                        add_row(rows, ticket, "Service Request Closed", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    if old_status_text == "solved" and status_text in ("open", "pending", "on-hold"):
                        add_row(rows, ticket, "Service Request Reopened", timestamp, event_agent, event_team, base_priority, status_text, base_channel, base_service_type, base_tags, sequence)
                    base_status = new_value or base_status
                elif kind in ("comment", "comment_created", "comment_added") or field in ("comment", "comment_body"):
                    if comment_public(event):
                        add_row(rows, ticket, "Public Reply Sent", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    else:
                        add_row(rows, ticket, "Internal Note Added", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif "sla" in kind or "sla" in field:
                    sla_text = str(value(event, "target_status", "status", "action", "event_type", "type") or "").lower()
                    if any(token in sla_text for token in ("breach", "breached", "missed", "failed")):
                        add_row(rows, ticket, "SLA Target Breached", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                    elif any(token in sla_text for token in ("applied", "active", "started", "target")):
                        add_row(rows, ticket, "SLA Target Applied", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
                elif ESCALATION_FIELD_ID and field == ESCALATION_FIELD_ID.lower():
                    add_row(rows, ticket, "Request Escalated", timestamp, event_agent, event_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

            if str(value(audit, "action", "type", "event_type") or "").lower() == "create":
                add_row(rows, ticket, "Service Request Created", audit_time, agent_name, assigned_team, base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

        for record in standalone_sla_events:
            if normalize_id(value(record, "ticket_id")) != ticket_id:
                continue
            timestamp = value(record, "created_at", "timestamp", "time")
            text = str(value(record, "event_type", "type", "status", "action") or "").lower()
            if "breach" in text or "missed" in text or "failed" in text:
                add_row(rows, ticket, "SLA Target Breached", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)
            elif "sla" in text or "applied" in text or "active" in text:
                add_row(rows, ticket, "SLA Target Applied", timestamp, "", "", base_priority, base_status, base_channel, base_service_type, base_tags, sequence)

    rows.sort(key=lambda row: (row["ServiceRequestId"], row["EventTimestamp"], int(row["SourceSequence"])))
    output_columns = ["ServiceRequestId", "ActivityName", "EventTimestamp", "SourceSystem", "LastDataUpdate", "AgentName", "AssignedTeam", "RequestPriority", "RequestStatus", "RequestChannel", "ServiceType", "TicketTags"]
    with open(OUTPUT_FILE, "w", encoding="utf-8", newline="") as handle:
        writer = csv.DictWriter(handle, fieldnames=output_columns)
        writer.writeheader()
        for row in rows:
            writer.writerow({column: row.get(column, "") for column in output_columns})


if __name__ == "__main__":
    main()

Chcete začít?

Začněte zlepšovat proces vyřizování požadavků na služby. Pomocí této šablony dat odhalte úzká místa a zvyšte efektivitu v Zendesk Support.

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

Stáhnout šablonu

Zlepšete správu požadavků na služby. Omezte zpoždění.

Omezte pomalé vyřizování požadavků a nespokojenost uživatelů. Dosáhněte 70% automatizace.

Začněte používat zkušební verzi

Platební kartu nepotřebujete. Nastavení je rychlé.

Šablona dat pro správu požadavků na služby

Šablona dat pro správu požadavků na služby

Atributy správy požadavků na služby

Aktivity při správě požadavků na služby

Návody na získání dat

Zendesk Explore: uživatelské rozhraní pro sestavy a export dat

Kroky

Konfigurace

Ukázkový dotaz config

Extrakce dat ze Zendesk REST API pomocí skriptu v Pythonu

Kroky

Konfigurace

Ukázkový dotaz python

Nativní export celého účtu Zendesk Support ve formátu JSON

Kroky

Konfigurace

Ukázkový dotaz config

Chcete začít?

Zlepšete správu požadavků na služby. Omezte zpoždění.