> Průběžné zlepšování procesů > Zákaznický servis > Zendesk Support > Datová šablona

Šablona dat pro zákaznickou podporu

Zendesk Support

Atributy zákaznické podpory(18) Aktivity zákaznické podpory(14) Průvodci extrakcí dat(4)

Šablona dat pro zákaznickou podporu

Tato šablona vám pomůže shromáždit potřebná data pro analýzu procesu zákaznické podpory. Uvádí důležité atributy, které je třeba sbírat, klíčové aktivity, které je vhodné sledovat, a praktické pokyny k extrakci dat. Podle tohoto průvodce sestavíte záznam událostí, který vám pomůže odhalit možnosti zlepšení provozu podpory.

Doporučené atributy ke sběru
Důležité aktivity ke sledování v procesu zákaznické podpory
Pokyny k extrakci dat z 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 zákaznické podpory

Toto jsou doporučená datová pole pro záznam událostí určený k podrobné analýze zákaznické podpory.

5 Povinné 6 Doporučené 7 Volitelné

	Název	Popis
	Čas zahájení StartTime	Časové razítko označující, kdy aktivita nebo událost začala.
Popis Čas zahájení neboli časové razítko události zaznamenává přesné datum a čas konkrétní aktivity. Zachycuje například přidání komentáře zákazníka, přiřazení agenta nebo změnu stavu ticketu na „Resolved“. Toto časové razítko je pro process mining zásadní, protože určuje chronologické pořadí událostí. Používá se k výpočtu doby mezi aktivitami, měření průběžné doby, vyhodnocení plnění SLA a pochopení časového průběhu procesu zákaznické podpory. Proč je to důležité Toto časové razítko je nezbytné pro seřazení událostí, výpočet dob trvání a analýzu časového průběhu vyřizování požadavku zákaznické podpory. Kde data získat Zendesk Ticket Audits API, pole `created_at` u každé události v auditním záznamu. Příklady 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Požadavek zákaznické podpory ServiceRequest	Jedinečný identifikátor každého požadavku zákaznické podpory, označovaného také jako ticket nebo případ.
Popis Požadavek zákaznické podpory je hlavní identifikátor případu, který propojuje všechny aktivity související s jedním dotazem nebo problémem zákazníka, od vytvoření až po konečné vyřešení. Každá interakce, aktualizace i interní úkon se váže k tomuto jedinečnému ID. V process mining analýze umožňuje seskupení událostí podle požadavku zákaznické podpory zobrazit celou cestu zákazníka od začátku do konce. Je základem pro výpočet důležitých ukazatelů, například celkové doby vyřízení, odhalení odchylek v procesu a pochopení životního cyklu každého problému zákazníka. Proč je to důležité Jde o nezbytné ID případu, které propojuje všechny kroky procesu a umožňuje sestavit a analyzovat průběh každého jednotlivého požadavku zákaznické podpory. Kde data získat Zendesk Tickets API, pole `id`. Příklady 102451287415332
	Název aktivity ActivityName	Název konkrétní události nebo úkolu, ke kterému došlo během vyřizování požadavku zákaznické podpory.
Popis Název aktivity popisuje jeden krok nebo milník v procesu zákaznické podpory, například „Požadavek zákaznické podpory vytvořen“, „Požadavek přiřazen agentovi“ nebo „Požadavek zákaznické podpory vyřešen“. Události mají časová razítka a tvoří posloupnost úkonů u každého požadavku. Tento atribut je důležitý pro zobrazení průběhu procesu, odhalení variant procesu a analýzu četnosti a pořadí událostí. Analytici díky němu zjistí, jaké úkony se provádějí, a mohou určit obvyklé postupy, úzká místa i odchylky od standardního postupu. Proč je to důležité Tento atribut určuje jednotlivé kroky procesu. Umožňuje zobrazit mapu procesu a analyzovat jeho průběh i varianty. Kde data získat Odvozuje se z protokolů auditů ticketů Zendesk nebo ze streamů událostí, které zaznamenávají změny a úkony. Příklady Požadavek zákaznické podpory vytvořenPožadavek přiřazen agentoviOdeslána první veřejná odpověď agentaPožadavek zákaznické podpory vyřešen
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace nebo extrakce dat ze zdrojového systému.
Popis Tento atribut uvádí, kdy byla datová sada naposledy aktualizována ze Zendesk Support. Pomáhá posoudit aktuálnost analyzovaných dat. Čas poslední aktualizace analytikům a firemním uživatelům napoví, zda pracují s nejnovějšími informacemi o procesu. Pomáhá nastavit očekávání ohledně aktuálnosti dat a je důležitý pro tvorbu reportů i sledování procesu. Proč je to důležité Ukazuje, jak aktuální jsou data, aby uživatelé věděli, z jakého období analýza procesu vychází. Kde data získat Jde o pole metadat vytvořené a uložené při extrakci dat, které zaznamenává časové razítko úlohy extrakce. Příklady 2023-10-27T02:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého byla data získána.
Popis Tento atribut určuje zdrojový systém dat o požadavcích zákaznické podpory, v tomto případě Zendesk Support. Pomáhá se správou a sledováním původu dat, zejména při kombinování dat z více systémů. Při analýze zajišťuje správné přiřazení dat ke zdroji. To je důležité pro zachování integrity dat a pochopení kontextu procesu, zejména v prostředí s více systémy. Proč je to důležité Určuje původ dat. Je důležitý pro správu dat a rozlišení procesních dat v propojených systémech. Kde data získat Jde o neměnnou hodnotu přidanou při extrakci dat, která označuje jejich původ. Příklady Zendesk Support
	Bylo překročeno SLA IsSlaBreached	Logická hodnota určující, zda doba vyřešení požadavku překročila cíl SLA.
Popis Tento vypočítaný atribut má hodnotu true nebo false a ukazuje, zda se požadavek nepodařilo vyřešit v cílové době stanovené dohodou o úrovni služeb. Vypočítá se porovnáním skutečné doby vyřešení s cílem SLA. Tento příznak zjednodušuje analýzu plnění SLA. Je hlavním údajem pro dashboard „Plnění SLA“ a KPI „Míra plnění SLA“. Umožňuje rychle sečíst a zobrazit, kolik požadavků splnilo cílovou dobu a kolik ne. Proč je to důležité U každého případu jasně ukazuje, zda bylo SLA splněno. Usnadňuje tak sledování a vykazování plnění SLA. Kde data získat Vypočítá se při transformaci dat porovnáním celkové doby vyřešení s hodnotou SlaTargetResolutionTime. Příklady truefalse
	Cílová doba vyřešení podle SLA SlaTargetResolutionTime	Cílová doba, během které má být požadavek na podporu vyřešen podle pravidel SLA.
Popis Tento atribut určuje cílovou dobu vyřešení požadavku podle dohody o úrovni služeb (SLA). Cíl se často mění podle faktorů, jako je priorita a typ požadavku nebo zákazníkův plán služeb. Jde o základní atribut dashboardu „Plnění SLA“. Skutečná doba vyřešení se porovnává s tímto cílem. Analýza výsledků pomáhá vyhodnotit kvalitu poskytovaných služeb a ověřit, zda plníte smluvní závazky vůči zákazníkům. Proč je to důležité Vyjadřuje závazek vůči zákazníkovi a slouží jako měřítko pro hodnocení včasného vyřešení i plnění SLA. Kde data získat Odvozuje se od pravidel SLA použitých pro daný požadavek. Tyto informace jsou dostupné přes Zendesk Ticket Metrics API. Příklady 144002880086400
	Komunikační kanál CommunicationChannel	Kanál, přes který byl požadavek na podporu odeslán nebo probíhala komunikace.
Popis Tento atribut určuje použitý způsob komunikace, například e-mail, webový formulář, chat nebo telefon. Ukazuje, jak zákazníci komunikují s podporou. Znalost využívaných kanálů je důležitá pro plánování zdrojů a zlepšování zákaznické zkušenosti. Dashboard „Přehled využití komunikačních kanálů“ analyzuje, které kanály jsou nejpoužívanější a zda některé z nich souvisejí s delší dobou řešení nebo odlišným průběhem procesu. Pomáhá rozhodnout, do kterých zlepšení podpory nebo automatizace investovat. Proč je to důležité Ukazuje, jak spolu zákazníci a pracovníci podpory komunikují. Umožňuje analyzovat efektivitu jednotlivých kanálů a jejich vliv na proces i zákaznickou zkušenost. Kde data získat Zendesk Tickets API, pole `via.channel`. Příklady webe-mailAPIchat
	Priorita Priority	Úroveň priority požadavku zákaznické podpory, například „Nízká“, „Normální“, „Vysoká“ nebo „Naléhavá“.
Popis Priorita vyjadřuje naléhavost požadavku zákaznické podpory a často ovlivňuje jeho pořadí ve frontě i cílovou dobu vyřízení. Agentům pomáhá zaměřit se nejprve na nejzávažnější problémy. Tento atribut je důležitý pro analýzu výkonu a SLA. Dashboard „Analýza doby vyřízení požadavků zákaznické podpory“ rozděluje data podle priority. Ukáže, zda se požadavky s vysokou prioritou vyřizují rychleji než požadavky s nižší prioritou a zda jsou zdroje přidělovány podle potřeb organizace. Proč je to důležité Udává naléhavost požadavku. Tento údaj je důležitý pro analýzu plnění SLA a rychlé řešení kritických problémů. Kde data získat Zendesk Tickets API, pole `priority`. Příklady NízkáNormálníVysokáNaléhavá
	Přiřazený agent AssignedAgent	Jméno nebo ID agenta zákaznické podpory, který vyřizuje požadavek.
Popis Tento atribut určuje konkrétního agenta odpovědného za aktivitu nebo požadavek v daném okamžiku. Pokud je požadavek předán jinému agentovi, může se jeho hodnota v průběhu vyřizování změnit. Analýza podle přiřazeného agenta pomáhá porozumět pracovní zátěži, výkonu a efektivitě agentů. Podporuje dashboard „Pracovní zátěž a efektivita agentů“, který umožňuje porovnávat dobu vyřizování a počet případů jednotlivých agentů. Díky tomu můžete určit, kde se hodí další školení, a lépe rozdělit pracovní zátěž. Proč je to důležité Zaznamenává, který agent provedl daný úkon. Umožňuje analyzovat individuální výkon, rozložení pracovní zátěže a přidělování zdrojů. Kde data získat Zendesk Tickets API, pole `assignee_id`. Podrobnosti o uživatelích lze získat z Users API. Příklady Jan NovákJana NovákováSupportBot
	Typ požadavku zákaznické podpory ServiceRequestType	Klasifikace požadavku zákaznické podpory, například „Dotaz“, „Incident“, „Problém“ nebo „Úkol“.
Popis Tento atribut zařazuje požadavek zákaznické podpory podle jeho povahy. Typ se obvykle nastavuje při vytvoření nebo třídění požadavku a pomáhá určit vhodný workflow a prioritu. Rozdělení analýzy podle typu požadavku zákaznické podpory je zásadní. Umožňuje porovnat dobu vyřízení, četnost eskalací a průběh procesu u různých typů problémů. Tuto analýzu nabízejí například dashboardy „Analýza doby vyřízení požadavků zákaznické podpory“ a „Četnost a příčiny interních eskalací“. Pomáhá zjistit, zda se některé typy požadavků vyřizují obtížněji nebo méně efektivně. Proč je to důležité Zařazuje požadavky do kategorií, aby bylo možné porovnávat výkon a analyzovat různé typy problémů. To je důležité pro cílené zlepšování procesů. Kde data získat Zendesk Tickets API, pole `type`. Příklady DotazIncidentProblémÚkol
	Byl znovu otevřen IsReopened	Logická hodnota určující, zda byl požadavek na podporu po označení jako vyřešený znovu otevřen.
Popis Tento příznak má hodnotu true, pokud se požadavek po označení jako vyřešený nebo uzavřený vrátí do otevřeného stavu. Znamená to, že původní řešení nestačilo. Příznak pomáhá sledovat opakovanou práci a případy, které se nepodařilo vyřešit při prvním kontaktu. Podporuje dashboard „Trendy znovuotevřených požadavků na podporu“ a KPI „Míra znovuotevření požadavků na podporu“. Snadno tak spočítáte a analyzujete případy vyžadující další pozornost, které často poukazují na hlubší problémy. Proč je to důležité Odhaluje opakovanou práci a neúspěšná řešení. Pomáhá měřit kvalitu a účinnost poskytnutých řešení. Kde data získat Vypočítá se při transformaci dat kontrolou, zda se stav požadavku změnil z „resolved“ nebo „closed“ zpět na „open“. Příklady truefalse
	Čas ukončení EndTime	Časové razítko označující, kdy byla aktivita nebo událost dokončena.
Popis Čas ukončení označuje, kdy byla aktivita dokončena. V mnoha strukturách záznamů událostí může jako čas ukončení aktuální aktivity sloužit čas zahájení následující aktivity. U aktivit založených na stavu, například „Agent prověřuje problém“, označuje okamžik, kdy daný stav skončil. Tento atribut je nezbytný pro přesný výpočet doby trvání aktivit, který je základem analýzy výkonu. Pomáhá určit časově nejnáročnější kroky a slouží jako podklad pro podrobnou analýzu úzkých míst a efektivity využití zdrojů. Proč je to důležité Umožňuje vypočítat dobu trvání aktivit, což je důležité pro odhalení úzkých míst a měření výkonu. Kde data získat Často se odvozuje z času zahájení následující události v posloupnosti pro daný požadavek zákaznické podpory. Příklady 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Hodnocení spokojenosti SatisfactionRating	Hodnocení spokojenosti, které zákazník poskytne po vyřešení požadavku na podporu.
Popis Tento atribut zachycuje zpětnou vazbu zákazníka k poskytnuté podpoře. Obvykle se sbírá v dotazníku po vyřešení požadavku. Hodnocení může mít podobu například „Dobré“, „Špatné“ nebo číselného skóre. Jde o přímé měřítko spokojenosti zákazníků a důležitý ukazatel výsledků. Používá se k výpočtu KPI „Skóre spokojenosti zákazníků“. Analýza hodnocení spolu s údaji o procesu, například dobou vyřešení nebo počtem kontaktů s pracovníky podpory, může ukázat, jaký průběh procesu vede k lepším výsledkům pro zákazníky. Proč je to důležité Přímo měří zpětnou vazbu zákazníků k poskytnuté podpoře a propojuje výkon procesu s výsledky pro zákazníky. Kde data získat Zendesk Tickets API, pole `satisfaction_rating.score`. Příklady dobréšpatnénabídnuto
	Kategorie produktu nebo služby ProductServiceCategory	Konkrétní produkt, služba nebo funkce, které se zákaznický požadavek týká.
Popis Tento atribut poskytuje podrobnější souvislosti tím, že požadavek zařazuje podle oblasti produktu nebo služby. Pracovník podpory jej často nastavuje ručně, případně se určí automaticky podle obsahu požadavku. Toto členění je důležité pro dashboardy „Přesnost kategorizace požadavků“ a „Rozbor délky vyšetřování“. Umožňuje podrobně analyzovat, které produkty vedou k největšímu počtu požadavků na podporu, které se řeší nejsložitěji a zda původní kategorie odpovídá konečnému řešení. Výsledky pomáhají zlepšit směrování požadavků i školení pracovníků podpory. Proč je to důležité Propojuje požadavky s konkrétními oblastmi podnikání, produkty nebo službami. Umožňuje zaměřit analýzu na problémové oblasti a jejich vliv na proces. Kde data získat Obvykle jde o vlastní pole požadavku v Zendesk. Přesný název pole závisí na konkrétní konfiguraci Zendesk. Příklady Mobilní aplikaceSpráva předplatnéhoIntegrace APIHardware
	Kód vyřešení ResolutionCode	Kód nebo kategorie označující důvod konečného vyřešení či uzavření požadavku.
Popis Kód vyřešení poskytuje strukturované informace o výsledku požadavku na podporu. Příklady: „Vyřešeno pracovníkem podpory“, „Duplicitní požadavek“, „Není třeba nic dělat“ nebo „Známý problém“. Oproti prostému stavu „Uzavřeno“ nabízí více souvislostí. Tento atribut je užitečný zejména při analýze hlavních příčin. V dashboardu „Trendy znovuotevřených požadavků na podporu“ může analýza četnosti opětovného otevření podle kódu vyřešení ukázat, zda jsou některé typy řešení méně účinné a zákazníci se kvůli nim musí znovu obracet na podporu. Proč je to důležité Ukazuje výsledek požadavku na podporu. Pomáhá analyzovat hlavní příčiny a zjistit, proč se požadavky znovu otevírají. Kde data získat Obvykle jde o vlastní pole požadavku v Zendesk. Přesný název pole závisí na konkrétní konfiguraci Zendesk. Příklady Vyřešeno při prvním kontaktuPředáno na podporu 2. úrovněČeká se na zákazníkaChyba produktu
	Počet žádostí o informace InformationRequestCount	Celkový počet případů, kdy byly od zákazníka vyžádány informace k jednomu požadavku na podporu.
Popis Tato vypočítaná metrika počítá, kolikrát se u každého požadavku na podporu vyskytla aktivita „Vyžádání informací od zákazníka“. Vysoký počet může znamenat, že pracovníci podpory nezískávají všechny potřebné informace hned na začátku. Atribut se používá v dashboardu „Analýza opakovaných žádostí o informace“. Sledování počtu pomáhá odhalit neefektivní místa v procesu a potřeby školení pracovníků podpory. Omezení opakovaných žádostí o informace může výrazně zkrátit dobu vyřešení a zlepšit zákaznickou zkušenost. Proč je to důležité Vyjadřuje četnost komunikace se zákazníkem tam a zpět. Odhaluje neefektivitu, která prodlužuje dobu vyřešení a zhoršuje zákaznickou zkušenost. Kde data získat Vypočítá se tak, že se u každého požadavku na podporu spočítají události, u kterých má ActivityName hodnotu „Information Requested From Customer“. Příklady 013
	Skupina pracovníků podpory AgentGroup	Skupina nebo tým podpory, kterému je požadavek přidělen.
Popis Tento atribut označuje tým pracovníků odpovědných za vyřízení požadavku. Požadavky se často směrují konkrétním skupinám podle potřebných dovedností, oblasti produktu nebo jazyka. Analýza podle skupiny pracovníků podpory pomáhá porozumět výkonu týmů, rozložení pracovní zátěže a předávání požadavků mezi týmy. Nabízí širší pohled než analýza jednotlivých pracovníků a může odhalit systémové problémy v konkrétních odděleních nebo funkcích. Proč je to důležité Ukazuje, který tým odpovídá za požadavek. Umožňuje analyzovat výkon skupin, předávání práce mezi týmy a rozdělení zdrojů mezi úrovněmi podpory či specializacemi. Kde data získat Zendesk Tickets API, pole `group_id`. Podrobnosti o skupinách lze získat přes Groups API. Příklady Podpora 1. úrovněTechnická podporaFakturace

Povinné Doporučené Volitelné

Aktivity zákaznické podpory

Toto jsou důležité kroky procesu a milníky, které je třeba zaznamenat pro přesné zmapování procesu zákaznické podpory.

6 Doporučené 8 Volitelné

	Aktivita	Popis
	Od zákazníka vyžádány další informace	K této aktivitě dochází, když agent potřebuje od zákazníka další informace a změní stav ticketu na „pending“. Tato změna stavu výslovně označuje, že proces čeká na externí stranu.
Proč je to důležité Tato aktivita ukazuje závislost na zákazníkovi a pozastavuje interní měření SLA. Časté nebo opakované vyžádání informací u jednoho ticketu může znamenat, že při prvním kontaktu nebyly zjištěny všechny potřebné informace, a prodlužovat dobu vyřízení. Kde data získat Jde o výslovnou událost změny stavu zaznamenanou v Zendesk Ticket Audits API. Zachytí se při změně pole „status“ na „pending“. Zachycení V Ticket Audits vyhledejte události „Change“, při kterých se stav ticketu změní na „pending“. Typ události explicit
	Požadavek přiřazen agentovi	Tato událost označuje přiřazení požadavku konkrétnímu agentovi k vyřízení. K přiřazení může dojít automaticky podle pravidel směrování nebo ručně, například vedoucím týmu či agentem.
Proč je to důležité Přiřazení je důležitým milníkem pro určení odpovědnosti a řízení pracovní zátěže. Analýza doby do přiřazení a opakovaného přiřazování odhalí úzká místa v třídění a rozdělování požadavků. Kde data získat Jde o výslovnou událost „Change“ v Zendesk Ticket Audits API, která se zaznamená při vyplnění nebo změně pole „assignee_id“. Zachycení Sledujte změny pole „assignee_id“ v protokolu Ticket Audits. Typ události explicit
	Požadavek zákaznické podpory uzavřen	Jde o poslední aktivitu, která označuje trvalé uzavření požadavku. Obvykle k němu dojde automaticky po uplynutí stanovené doby od označení ticketu jako „solved“, pokud zákazník mezitím neodpoví.
Proč je to důležité Jako konečná událost uzavírá životní cyklus ticketu. Doba mezi stavy „solved“ a „closed“ představuje období, během kterého lze ticket znovu otevřít. Událost „closed“ potvrzuje, že zákazník řešení přijal. Kde data získat Jde o výslovnou změnu stavu zaznamenanou v Zendesk Ticket Audits API při nastavení pole „status“ na „closed“. Zachycení V Ticket Audits vyhledejte události „Change“, při kterých se stav ticketu změní na „closed“. Typ události explicit
	Požadavek zákaznické podpory vyřešen	Agent označí požadavek jako „solved“, když zákazníkovi poskytne řešení. Jde o dočasný stav, protože zákazník může na ticket odpovědět a znovu ho otevřít, než bude trvale uzavřen.
Proč je to důležité Tento milník je hlavním ukazatelem pro měření doby vyřízení a efektivity agentů. Označuje okamžik, kdy agent považuje práci za dokončenou. Pokud zákazník ticket znovu otevře, lze pak analyzovat nutnost opakované práce. Kde data získat Jde o výslovnou změnu stavu zaznamenanou v Zendesk Ticket Audits API při nastavení pole „status“ na „solved“. Zachycení V Ticket Audits vyhledejte události „Change“, při kterých se stav ticketu změní na „solved“. Typ události explicit
	Požadavek zákaznické podpory vytvořen	Tato aktivita označuje začátek procesu zákaznické podpory. V Zendesk se vytvoří nový ticket z některého kanálu, například z e-mailu, webového formuláře nebo chatu. Systém při vytvoření zaznamená událost s jedinečným ID ticketu a časovým razítkem.
Proč je to důležité Jako hlavní počáteční událost je důležitá pro výpočet celkové doby vyřízení případu a analýzu počtu příchozích požadavků v čase. Slouží jako základ pro měření důležitých ukazatelů, například doby do první odpovědi a celkové doby vyřízení. Kde data získat Jde o výslovně zaznamenanou událost v Zendesk Ticket Audits API. Odpovídá události „Create“ u ticketu a obsahuje časové razítko jeho vytvoření. Zachycení Zaznamenává se při vytvoření ticketu v protokolu Ticket Audits. Typ události explicit
	Požadavek zákaznické podpory znovu otevřen	K této aktivitě dochází, když zákazník odpoví na ticket ve stavu „solved“. Zendesk automaticky změní stav zpět na „open“, což znamená, že problém nebyl zcela vyřešen.
Proč je to důležité Opětovné otevření ticketu je důležitým ukazatelem neúspěšného vyřešení při prvním kontaktu a nízké kvality řešení. Analýza četnosti a příčin opětovného otevření pomáhá určit, kde zlepšit školení agentů a postupy řešení. Kde data získat Jde o výslovnou změnu stavu v Ticket Audits API, která se zaznamená při změně stavu z „solved“ zpět na „open“. Zachycení Sledujte události „Change“, při kterých se stav změní z „solved“ na „open“. Typ události explicit
	Došlo k porušení SLA	Tato aktivita označuje okamžik, kdy požadavek nesplní předem stanovenou dohodu o úrovni služeb, například dobu do první odpovědi nebo dobu vyřízení. Událost se vypočítá porovnáním časových razítek aktivit ticketu s pravidly SLA.
Proč je to důležité Porušení SLA přímo ovlivňuje spokojenost zákazníků a plnění smluvních závazků. Analýza toho, kdy a proč k němu dochází, pomáhá odhalit systémové prodlevy, nedostatek zdrojů nebo nereálné cíle výkonu. Kde data získat Údaje lze získat ze Zendesk Ticket Metrics API, které ukládá časová razítka porušení SLA („breached_at“). Případně je lze vypočítat porovnáním časových razítek událostí ticketu s definovanými pravidly SLA. Zachycení Použijte časové razítko „breached_at“ z Ticket Metrics API nebo porovnejte dobu vyřízení s časovým limitem podle pravidel SLA. Typ události calculated
	Obdrženo hodnocení spokojenosti	Tato událost nastane, když zákazník odešle odpověď na průzkum spokojenosti, například hodnocení „Good“ nebo „Bad“. Hodnocení a případný komentář se zaznamenají u ticketu.
Proč je to důležité Přímá zpětná vazba od zákazníků je velmi užitečná při měření kvality služeb a spokojenosti zákazníků. Analýza hodnocení v kontextu průběhu procesu pomáhá zjistit souvislosti mezi konkrétními aktivitami či agenty a výsledky. Kde data získat Zaznamenává se jako událost „Change“ v Zendesk Ticket Audits API, když se do pole „satisfaction_rating“ uloží hodnocení zákazníka a jeho komentář. Zachycení V protokolech Ticket Audit vyfiltrujte změny pole „satisfaction_rating“. Typ události explicit
	Odeslán průzkum spokojenosti	Označuje okamžik, kdy zákazník automaticky obdrží průzkum spokojenosti (CSAT). Obvykle se odešle krátce poté, co je ticket označen jako vyřešený.
Proč je to důležité Tato aktivita zahajuje sběr zpětné vazby od zákazníka. Informace o tom, kdy a zda se průzkumy odesílají, pomáhají správně vyhodnotit skóre spokojenosti a účinnost programu zpětné vazby. Kde data získat Událost lze odvodit z protokolu automatizace nebo podle konkrétní značky přidané k ticketu. Sekce „satisfaction_rating“ v Zendesk Ticket Audits API také zaznamenává, kdy byl průzkum nabídnut. Zachycení Vyhledejte značky jako „csat_sent“ nebo použijte časové razítko, kdy byla nabídnuta možnost ohodnotit spokojenost. Typ události inferred
	Odeslána první veřejná odpověď agenta	Tato aktivita označuje první veřejnou odpověď agenta zákazníkovi, nikoli automatické potvrzení přijetí požadavku. Jde o důležitý ukazatel toho, kdy se agent začal zákazníkovým problémem zabývat.
Proč je to důležité Tento milník je důležitý pro měření SLA „First Reply Time“, které ukazuje rychlost reakce zákaznické podpory. Odlišuje automatickou komunikaci od začátku aktivního řešení požadavku agentem. Kde data získat Najděte první veřejnou poznámku ve streamu Ticket Comments, jejímž autorem je člověk, tedy agent, nikoli automatizovaný systémový uživatel. Zachycení Projděte komentáře k ticketu, vyfiltrujte veřejné komentáře agentů a vyberte ten s nejstarším časovým razítkem. Typ události inferred
	Odesláno první potvrzení přijetí požadavku	Označuje automatickou první odpověď zákazníkovi, která potvrzuje přijetí jeho požadavku. Obvykle ji zajišťuje trigger v Zendesk, který po vytvoření ticketu ihned odešle e-mailové oznámení podle šablony.
Proč je to důležité Sledování této aktivity je důležité pro měření rychlosti první reakce a řízení očekávání zákazníků. Doba mezi vytvořením požadavku a odesláním potvrzení je důležitým ukazatelem spokojenosti zákazníků. Kde data získat Událost lze odvodit z první veřejné poznámky k ticketu, pokud ji napsal automatizovaný uživatel nebo byla přidána několik sekund po vytvoření ticketu. Zjistíte ji analýzou streamu Ticket Comments. Zachycení Najděte první veřejnou poznámku přidanou automatizací nebo triggerem bezprostředně po vytvoření ticketu. Typ události inferred
	Požadavek zařazen do kategorie a určena jeho priorita	K této aktivitě dochází, když agent nebo automatizace nastaví či změní pole ticketu, například typ, kategorii nebo prioritu. Změna se zaznamená do historie ticketu jako událost.
Proč je to důležité Správné zařazení do kategorie a určení priority jsou důležité pro efektivní směrování požadavků a přidělování zdrojů. Analýza této aktivity pomáhá posoudit přesnost úvodního třídění a jeho vliv na dobu vyřízení. Kde data získat Zaznamenává se v Zendesk Ticket Audits API jako událost „Change“. Najdete ji podle první změny polí, jako jsou „priority“, „type“ nebo vlastní pole související se zařazením do kategorie. Zachycení V protokolech Ticket Audit vyhledejte první událost „Change“ u důležitých polí pro zařazení do kategorie po vytvoření ticketu. Typ události explicit
	Zahájena interní eskalace	Označuje předání požadavku jinému internímu týmu nebo týmu podpory vyšší úrovně. Obvykle ji lze odvodit ze změny přiřazené skupiny ticketu.
Proč je to důležité Sledování eskalací pomáhá odhalit slabá místa procesu, nedostatky ve znalostech pracovníků první úrovně podpory a složité typy požadavků. Časté eskalace mohou ukazovat na potřebu lepšího školení nebo dokumentace procesů. Kde data získat Událost lze odvodit ze změny pole „group_id“ v události „Change“ v Zendesk Ticket Audits API. Změna skupiny znamená předání mezi týmy. Zachycení Sledujte změny pole „group_id“ v protokolu Ticket Audits. Typ události inferred
	Zákazník odpověděl	Tato událost se spustí, když zákazník odpoví na ticket, který je obvykle ve stavu „pending“. Zendesk automaticky změní stav ticketu z „pending“ zpět na „open“, čímž agentovi umožní pokračovat v práci.
Proč je to důležité Tato aktivita označuje konec čekání a umožňuje pokračovat v procesu. Analýza doby, za kterou zákazníci odpovídají, může ukázat, zda jsou žádosti agentů srozumitelné. Kde data získat Událost odpovídá nové veřejné poznámce od koncového uživatele, která v Ticket Audits API spustí výslovnou změnu stavu z „pending“ na „open“. Zachycení Sledujte události „Change“, při kterých se stav změní z „pending“ na „open“, nebo vyhledejte nové veřejné poznámky od koncového uživatele. Typ události explicit

Doporučené Volitelné

Průvodci extrakcí dat

Jak získat data ze Zendesk Support

Kroky

Otevřete Zendesk Explore: Přihlaste se do svého účtu Zendesk. V horní liště klikněte na ikonu pro přepínání produktů a vyberte Explore.
Vytvořte nový dotaz: V Explore klikněte v levém postranním panelu na ikonu Queries a vpravo nahoře na tlačítko „New query“.
Vyberte datovou sadu: V okně „Choose a dataset“ vyberte datovou sadu Support: Tickets. Obsahuje hlavní atributy požadavků a důležitá časová razítka událostí.
Přidejte metriky: V nástroji pro tvorbu dotazu přejděte na panel „Metrics“ a klikněte na „Add“. Vyberte COUNT(Tickets). Tím ověříte objem dat.
Přidejte atributy do řádků: Přejděte na panel „Rows“ a klikněte na „Add“. Přidejte následující atributy. Budou tvořit základní sloupce exportu v širokém formátu.
- Ticket ID (identifikátor případu, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Přidejte do řádků časová razítka aktivit: Přidejte na panel „Rows“ následující atributy s časovými razítky. Každý z nich představuje možnou aktivitu. U některých aktivit je třeba vytvořit vlastní vypočítaný atribut.
- Ticket created - Timestamp: pro Service Request Created a Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: pro Request Assigned To Agent.
- First reply time - Timestamp: pro First Agent Public Reply Sent.
- Ticket solved - Timestamp: pro Service Request Resolved a Satisfaction Survey Sent.
- Ticket reopened - Timestamp: pro Service Request Reopened.
- Satisfaction rating received - Timestamp: pro Satisfaction Rating Received.
- Ticket closed - Timestamp: pro Service Request Closed.
Vytvořte vlastní vypočítané atributy pro další aktivity: Některé aktivity vycházejí z konkrétních změn polí. Pro zachycení jejich časového razítka je třeba vytvořit vlastní atributy. Otevřete nabídku Calculations (ikona kalkulačky) a vyberte „Standard calculated attribute“. Vytvořte atribut pro každou z následujících aktivit. Přesné názvy polí a hodnot zjistíte ve svém účtu Zendesk.
- Název: Timestamp - Categorized and Prioritized. Vzorec: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Po vytvoření přidejte atribut na panel „Rows“ a změňte agregační funkci na MIN.
- Název: Timestamp - Info Requested. Vzorec: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Přidejte atribut na panel „Rows“ a nastavte agregační funkci na MIN.
- Název: Timestamp - Customer Responded. Vzorec: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Přidejte atribut na panel „Rows“ a nastavte agregační funkci na MIN.
- Název: Timestamp - Escalated. Vzorec: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Přidejte atribut na panel „Rows“ a nastavte agregační funkci na MIN.
- Název: Timestamp - SLA Breach. Vzorec: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Přidejte atribut na panel „Rows“ a nastavte agregační funkci na MIN.
Filtrujte data: Přejděte na panel „Filters“ a klikněte na „Add“. Přidejte filtr pro Ticket created - Date a vyberte vhodné období, například poslední 3 až 6 měsíců. Datová sada tak zůstane přehledná.
Spusťte report a exportujte data: Kliknutím na „Save“ spusťte dotaz. Až se zobrazí tabulka s daty, klikněte na „Export“ a vyberte požadovaný formát, například CSV nebo Excel.
Převeďte data do formátu záznamu událostí: Exportovaný soubor má široký formát. Každý řádek představuje jeden požadavek a každý sloupec časové razítko události. Pro process mining je potřeba převést data do dlouhého formátu. Použijte například Microsoft Excel s funkcí Unpivot v Power Query, Python nebo jiný nástroj pro přípravu dat.
- Pro každý řádek (požadavek) vytvořte několik nových řádků, po jednom pro každý sloupec s časovým razítkem, který není prázdný.
- Výsledná tabulka má obsahovat sloupce jako ServiceRequest, ActivityName, StartTime a další atributy. U každé aktivity daného požadavku se ostatní atributy zopakují.

Konfigurace

Datová sada: Použijte především datovou sadu Support: Tickets. V jednom dotazu zpřístupní většinu vlastností požadavků i důležitá časová razítka.
Oprávnění: K vytváření a ukládání dotazů v Zendesk Explore potřebujete alespoň roli Editor nebo Admin.
Časové období: Nastavte filtr období pro Ticket created - Date. Doporučujeme 3 až 6 měsíců dat, abyste získali užitečný přehled a zároveň zachovali dobrý výkon. Export milionů požadavků může být pomalý nebo se nemusí podařit.
Filtry dotazu: Zvažte filtrování podle vlastností požadavku, například Ticket brand, Ticket form nebo Ticket group, a zaměřte analýzu na konkrétní službu či tým.
Vypočítané atributy: Tato metoda ve velké míře využívá standardní vypočítané atributy k zachycení časových razítek událostí, které nejsou dostupné jako výchozí atributy, například změn stavu nebo eskalací. Ověřte si, že máte oprávnění tyto atributy vytvářet.

Ukázkový dotaz config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Kroky

Připravte přístup k Zendesk API: Přihlaste se do Zendesk jako správce. Otevřete Admin Center a přejděte na Apps and integrations > APIs > Zendesk API. Na kartě Settings zapněte Token Access. Kliknutím na „Add API token“ vytvořte nový token. Bezpečně si ho zkopírujte, později se už znovu nezobrazí.
Nastavte prostředí Python: Ověřte, že máte nainstalovaný Python 3.6 nebo novější. Nainstalujte knihovnu requests, která slouží k odesílání HTTP požadavků do Zendesk API. Nainstalujete ji příkazem pip install requests v příkazovém řádku.
Nastavte Python skript: Uložte dodaný skript do souboru, například extract_zendesk_log.py. Otevřete ho v textovém editoru a upravte zástupné proměnné na začátku souboru: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL a API_TOKEN. Zadejte údaje a přihlašovací údaje pro svůj účet Zendesk.
Určete období exportu: Ve skriptu najděte proměnnou START_TIMESTAMP. Určuje počáteční datum historického exportu a musí mít podobu časového razítka Unix epoch. Pro první analýzu doporučujeme hodnotu odpovídající posledním 3 až 6 měsícům.
Spusťte skript: Otevřete terminál nebo příkazový řádek, přejděte do složky, kam jste skript uložili, a spusťte příkaz python extract_zendesk_log.py.
Sledujte průběh: Skript bude v konzoli zobrazovat průběžné informace včetně počtu zpracovaných požadavků. Celková doba běhu závisí na objemu exportovaných dat a limitech API stanovených Zendesk. Skript obsahuje základní ošetření odpovědí o překročení limitu.
Získejte záznam událostí: Po úspěšném dokončení skript vytvoří ve stejné složce soubor zendesk_event_log.csv. Obsahuje strukturovaný záznam událostí připravený k analýze.
Připravte soubor k nahrání: Otevřete zendesk_event_log.csv a ověřte, že byl vytvořen správně. Zkontrolujte, zda obsahuje požadované atributy: ServiceRequest, ActivityName, StartTime, SourceSystem a LastDataUpdate. Soubor je nyní připravený k nahrání do nástroje pro process mining.

Konfigurace

Přihlašovací údaje k API: Skript vyžaduje platnou subdoménu Zendesk, e-mailovou adresu agenta nebo správce a aktivní API token. Uživatel spojený s těmito údaji musí mít oprávnění číst požadavky, audity požadavků, uživatele a metriky požadavků.
Časové období: Počáteční datum exportu určuje proměnná START_TIMESTAMP ve skriptu. Musí mít podobu časového razítka Unix epoch. Nejprve doporučujeme kratší období, například 3 měsíce. Ověříte tak výstup i výkon skriptu, než začnete exportovat delší historii.
API pro přírůstkový export: Řešení využívá Zendesk Incremental Export API. Jde o nejefektivnější doporučený způsob načítání velkého počtu požadavků. Je určený pro hromadný export dat a předchází běžným problémům se stránkováním.
Výkon a limity požadavků: Zendesk uplatňuje limity API, které se liší podle předplatného. Skript při dosažení limitu pozastaví běh podle hodnoty hlavičky Retry-After vrácené API. Export z velmi rozsáhlých účtů může trvat několik hodin.
Předpoklady: Tato metoda vyžaduje funkční prostředí Python 3.6+ a externí knihovnu requests. K vytvoření potřebného API tokenu je nutný přístup správce k příslušnému účtu Zendesk.

Ukázkový dotaz python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
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', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

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

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Kroky

Ověřte, že váš účet Zendesk Support umožňuje přístup k Incremental Exports API a že integrační účet smí číst požadavky, události požadavků, uživatele, skupiny, komentáře, hodnocení spokojenosti a data SLA, pokud jsou tyto funkce zapnuté. Podle schváleného nastavení vaší organizace ověřte subdoménu účtu a způsob ověřování.
Zvolte počáteční čas exportu, který pokrývá požadované období analýzy. Přírůstkový export požadavků používá časové razítko Unix a vrací záznamy vytvořené nebo aktualizované od tohoto okamžiku. Pro úplný historický export použijte jako počáteční čas [Configure based on your system] a uložený koncový čas použijte při dalších přírůstkových exportech. Pro běžnou analýzu doporučujeme období 3 až 6 měsíců, pokud historie provozu poskytuje dostatek dat.
Spusťte Python skript pro export. Nastavte subdoménu Zendesk, přihlašovací údaje, počáteční časové razítko a případné filtry specifické pro vaši společnost. Skript načte přírůstková data požadavků, projde stránkované výsledky a před transformací uloží nezpracované záznamy požadavků i dostupné podrobnosti o událostech.
Pokud přírůstková odpověď neobsahuje dostatek informací o změnách polí, přiřazení, komentářích nebo stavech, načtěte pro každý požadavek historii auditů či událostí. Používejte pouze zdroje Zendesk API, které jsou ve vašem účtu povolené a ke kterým máte oprávnění. Pokud jsou k dispozici, zachovejte ID zdrojového požadavku, ID auditu, ID komentáře, časové razítko události, aktéra, název pole, předchozí hodnotu a novou hodnotu.
Převeďte časová razítka na UTC a hodnoty Unix nebo ISO 8601 sjednoťte do stejného formátu data a času. Seřaďte zdrojové záznamy podle ServiceRequest, času události a identifikátoru zdrojové události. Duplicitní záznamy odstraňujte podle nejkonkrétnějšího stabilního identifikátoru, který je k dispozici, například ID auditu nebo komentáře.
Vytvořte samostatné řádky záznamu událostí pro všech 14 požadovaných aktivit. Neočekávejte, že ProcessMind odvodí aktivity ze změn stavu nebo hodnot polí. Vytvořte Service Request Created při vytvoření požadavku, Initial Acknowledgment Sent při ověřené automatické první odpovědi, Request Categorized And Prioritized při změně kategorie, typu nebo priority, Request Assigned To Agent při změně přiřazeného agenta, First Agent Public Reply Sent při první odpovídající veřejné odpovědi agenta, Information Requested From Customer při přechodu do stavu čekání spojeném s žádostí o informace, Customer Responded při odpovídající odpovědi zákazníka, Internal Escalation Triggered při změně přiřazené skupiny, SLA Breach Occurred při ověřeném časovém razítku porušení SLA nebo výslovně vypočteném porušení, Service Request Resolved při přechodu do vyřešeného stavu, Service Request Reopened při přechodu z vyřešeného do otevřeného stavu způsobeném odpovědí zákazníka, Satisfaction Survey Sent při ověřeném odeslání průzkumu, Satisfaction Rating Received při odeslání hodnocení a Service Request Closed při přechodu do uzavřeného stavu nebo ověřené události trvalého uzavření.
Vyplňte povinné sloupce ServiceRequest, ActivityName, StartTime, SourceSystem a LastDataUpdate. Pokud zdroj poskytuje spolehlivé hodnoty, vyplňte také doporučené sloupce AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime a IsSlaBreached. U nepovinných atributů, které nejsou k dispozici, použijte hodnotu null, nevymýšlejte je.
Po exportu a před uložením použijte schválené filtry specifické pro vaši společnost. V interní pracovní kopii zachovejte původní identifikátory a časová razítka zdroje, aby bylo možné rozhodnutí o událostech ověřit a export zopakovat.
Ověřte počet řádků, pokrytí aktivit, pořadí časových razítek, odstranění duplicit a vyplnění atributů. Zkontrolujte, že každý vytvořený řádek obsahuje ServiceRequest, ActivityName, StartTime, SourceSystem a LastDataUpdate.
Exportujte upravený záznam událostí jako soubor UTF-8 CSV nebo v jiném tabulkovém formátu podporovaném ProcessMind. Názvy sloupců musí přesně odpovídat požadovaným názvům atributů a každý výskyt aktivity musí být na samostatném řádku. Poté soubor nahrajte pomocí nastaveného procesu importu ProcessMind.

Konfigurace

Způsob exportu: Pro export velkého objemu požadavků použijte Zendesk Incremental Exports API. Skript má načítat data od uloženého časového razítka Unix, procházet stránkované výsledky, respektovat limity požadavků a uložit vrácené koncové časové razítko pro další běh.
Ověřování: Nastavte schválený způsob ověřování Zendesk, subdoménu účtu, přihlašovací údaje a oprávnění API podle bezpečnostních zásad vaší organizace. Neukládejte přihlašovací údaje přímo do správy zdrojového kódu.
Časové období: Pro běžnou analýzu procesů použijte období 3 až 6 měsíců. Při prvním exportu zvolte počáteční čas před začátkem požadovaného období, protože aktivity požadavků vytvořených dříve mohou spadat do období analýzy. Při přírůstkovém exportu použijte časový bod posledního úspěšného exportu a přidejte krátký překryv, který zachytí pozdě doručené změny. Poté odstraňte duplicity podle zdrojových identifikátorů.
Filtry: Používejte pouze filtry podporované zdroji Zendesk dostupnými ve vašem účtu, například schválené filtry podle organizace, skupiny, značky, typu požadavku, stavu nebo vlastního pole. Filtry specifické pro vaši společnost nastavte podle svého systému. Nepředpokládejte, že Zendesk obsahuje pole Company Code nebo Document Type.
Povinné výstupní sloupce: ServiceRequest, ActivityName, StartTime, SourceSystem a LastDataUpdate.
Doporučené výstupní sloupce: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime a IsSlaBreached.
Podrobnosti o událostech: Samotné přírůstkové záznamy požadavků nemusí obsahovat všechny historické změny. Podle potřeby načtěte oprávněné audity požadavků, komentáře, záznamy o spokojenosti a události SLA. Každou požadovanou aktivitu vytvořte jako samostatný řádek.
Nastavení SLA: Pokud jsou k dispozici, použijte skutečné zásady SLA a časová razítka porušení vrácená účtem. Pokud stav porušení počítáte, zdokumentujte použitou zásadu, pracovní dobu, přestávky a časové pásmo. Pokud platí pravidla pracovní doby, nepočítejte porušení pouze podle uplynulého času.
Výkon: Zpracovávejte stránky průběžně, záznamy načítejte po dávkách nebo jako proud, ukládejte podrobnosti požadavků do mezipaměti, používejte omezený počet souběžných požadavků, respektujte odpovědi Zendesk o překročení limitu a po úspěšném zpracování stránek ukládejte průběh. Vyhněte se opakovanému načítání celé historie.
Uchovávání dat: Pro porovnání výsledků a opakování exportu uchovávejte nezpracované odpovědi API, časové body exportu, metadata požadavků a protokoly transformací.
Předpoklady: Přístup k Zendesk API, oprávnění číst příslušné zdroje požadavků a událostí, zapnuté audity požadavků a komentáře, pokud jsou potřeba, přístup k údajům o spokojenosti, pokud potřebujete aktivity CSAT, a přístup k údajům SLA, pokud potřebujete aktivity porušení SLA. Dostupnost funkcí závisí na tarifu Zendesk a nastavení účtu.

Ukázkový dotaz python

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

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        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, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_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, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    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=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Kroky

Vyberte komerční platformu ETL nebo ELT s podporovaným konektorem Zendesk Support. Ověřte, že konektor dokáže replikovat požadavky, události či audity požadavků, komentáře, uživatele, skupiny, hodnocení spokojenosti, data SLA a výsledky triggerů nebo automatizací dostupné ve vašem účtu Zendesk.
Vytvořte integraci Zendesk API pomocí způsobu ověřování schváleného vaší organizací a podporovaného vybraným konektorem. Udělte pouze oprávnění ke čtení potřebná pro data požadavků, auditů, komentářů, uživatelů, skupin, spokojenosti a SLA. Připojovací řetězec a přihlašovací údaje uložte do zabezpečeného úložiště nástroje.
Nastavte konektor tak, aby požadované objekty Zendesk replikoval do cílového datového skladu. Používejte zdrojové objekty vytvořené konektorem a nepředpokládejte pevné názvy tabulek nebo sloupců. Skutečné mapování objektů a polí zaznamenejte do projektové dokumentace jako [Your table name] a [Your column name], pokud konektor používá názvy specifické pro daný účet.
Nastavte přírůstkový export pomocí podporovaného časového razítka aktualizace zdrojového systému, kurzoru nebo mechanismu sledování změn. Zahrňte historická data za vybrané období analýzy, obvykle tři až šest měsíců, a zachovejte identifikátor zdrojové události nebo auditu, aby bylo možné odstranit duplicity při opakovaných aktualizacích.
Vytvořte normalizovaný pracovní model, který propojí záznamy požadavků s historií požadavků, audity či událostmi, komentáři, uživateli, skupinami, hodnoceními spokojenosti, záznamy SLA a případnými záznamy triggerů či automatizací specifickými pro konektor. Kdykoli jsou k dispozici, zachovejte původní časové razítko, identifikátor zdrojového záznamu, identifikátor požadavku, identifikátor aktéra, typ události, název pole, předchozí hodnotu a novou hodnotu.
Vytvořte transformaci událostí, která pro každou výslovně zaznamenanou aktivitu vytvoří samostatný řádek. Vytvoření požadavku namapujte na Service Request Created, odpovídající automatickou první odpověď na Initial Acknowledgment Sent, změny typu, kategorie nebo priority na Request Categorized And Prioritized, změny přiřazeného agenta na Request Assigned To Agent, první odpovídající veřejnou odpověď agenta na First Agent Public Reply Sent, přechod do stavu čekání spojený s žádostí o informace na Information Requested From Customer, odpověď zákazníka na Customer Responded, změnu skupiny na Internal Escalation Triggered, zaznamenané porušení SLA nebo událost porušení na SLA Breach Occurred, přechod do vyřešeného stavu na Service Request Resolved, přechod z vyřešeného do otevřeného stavu způsobený odpovědí zákazníka na Service Request Reopened, zaznamenané odeslání průzkumu na Satisfaction Survey Sent, odeslané hodnocení na Satisfaction Rating Received a trvalý přechod do uzavřeného stavu na Service Request Closed.
Nevytvářejte odvozené řádky pouze na základě aktuálního stavu požadavku nebo uplynulého času. Pokud zdroj výslovně nezaznamenává odeslání průzkumu, porušení SLA, automatické potvrzení nebo trvalé uzavření, danou aktivitu vynechte nebo použijte samostatný zdroj dat, který ji výslovně zaznamenává, a tento postup zdokumentujte. ProcessMind načítá záznam událostí tak, jak je, a chybějící události nedopočítává.
Pokud je k dispozici identifikátor zdrojové události nebo auditu, použijte ho k odstranění duplicit. Pokud stabilní identifikátor chybí, použijte zdokumentovaný složený klíč obsahující ServiceRequest, ActivityName, StartTime, aktéra a identifikátor zdrojového záznamu. Zachovejte všechny oprávněné opakované výskyty aktivit, jako jsou Customer Responded, Information Requested From Customer, Internal Escalation Triggered a Service Request Reopened.
Vyplňte povinné výstupní sloupce ServiceRequest, ActivityName, StartTime, SourceSystem a LastDataUpdate. Pokud je zdroj poskytuje, přidejte AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime a IsSlaBreached. Používejte jednotný formát časových razítek UTC a zachovejte pravidlo převodu časového pásma zdroje.
Exportujte výsledný záznam událostí jako soubor CSV kompatibilní s ProcessMind nebo ho načtěte do nastaveného umístění pro import do ProcessMind. Každý výskyt aktivity musí být na samostatném řádku, ServiceRequest musí označovat případ, ActivityName musí obsahovat přesné názvy aktivit, StartTime musí být platné časové razítko a každý řádek musí obsahovat požadované atributy, pokud jsou technicky dostupné.

Konfigurace

Rozsah konektoru a zdrojů: Nastavte vybraný komerční nástroj ETL nebo ELT pro Zendesk Support a vyberte zdrojové objekty, které zpřístupňují požadavky, audity či události požadavků, komentáře, uživatele, skupiny, hodnocení spokojenosti, informace SLA a výsledky automatizací či triggerů. Názvy objektů se liší podle konektoru a účtu. Používejte skutečný katalog konektoru, nikoli předpokládané názvy tabulek.
Ověřování a oprávnění: Použijte způsob ověřování Zendesk schválený vaší organizací. Udělte přístup ke čtení všech vybraných zdrojových objektů včetně historických událostí požadavků a údajů o spokojenosti zákazníků. Ověřte, že je zapnutý přístup k API, potřebné funkce tarifu Zendesk i licence konektoru.
Časové období: Začněte s historií za tři až šest měsíců. Období prodlužte až po ověření kvót API, kapacity datového skladu, objemu událostí a dostupnosti historických auditů, záznamů SLA a hodnocení spokojenosti.
Přírůstkové načítání: Upřednostněte nativní kurzor konektoru, sledování změn nebo časové razítko aktualizace zdroje. Naplánujte první historické načtení a poté pravidelné přírůstkové načítání. Zahrňte i předchozí období, abyste zachytili pozdě doručené komentáře, hodnocení, výsledky SLA a aktualizace požadavků.
Filtry aktivit: Filtrujte zdrojové záznamy podle zvoleného období analýzy a příslušné instance Zendesk Support. Nefiltrujte pouze podle aktuálního stavu požadavku, protože historické aktivity mohou patřit k požadavkům, jejichž stav se mezitím změnil.
Filtry společnosti nebo účtu: Pokud konektor zpřístupňuje více instancí Zendesk, značek, organizací nebo obchodních jednotek, použijte schválený filtr společnosti či účtu podle skutečného pole konektoru. Nepředpokládejte, že existuje pole Company Code.
Mapování událostí: Udržujte výslovnou mapovací tabulku, která propojuje typ zdrojové události, název pole, změnu stavu, typ aktéra a indikátor automatizace se 14 požadovanými hodnotami ActivityName. Každý vytvořený řádek musí mít oporu ve zdrojových datech.
Rozpoznání potvrzení: Initial Acknowledgment Sent namapujte pouze tehdy, když zdroj označuje automatickou první odpověď nebo odpovídající oznámení vytvořené triggerem. Bez potvrzení ve zdrojových datech nepovažujte odpověď agenta za automatické potvrzení.
Zpracování SLA: Používejte výslovné záznamy o porušení SLA nebo výsledky SLA zpřístupněné konektorem. Cílovou dobu uložte do SlaTargetResolutionTime a výsledek porušení do IsSlaBreached. Porušení nepočítejte pouze podle uplynulého času, pokud nemáte k dispozici kalendář SLA, zásady, pracovní dobu a cílovou hodnotu a výpočet není zdokumentovaný.
Výkon: Omezte první načtení podle data, vybírejte pouze potřebné sloupce, používejte přírůstkovou replikaci a tam, kde je to podporováno, nastavte v datovém skladu dělení nebo clustering podle ServiceRequest a StartTime. Normalizovaný model událostí vytvořte až po načtení nezpracovaných dat. Vyhněte se opakovanému procházení celé historie požadavků.
Kvalita dat: Zachovejte zdrojové identifikátory a časová razítka, sjednoťte časová razítka na UTC, standardizujte logické hodnoty a ponechte hodnotu null, pokud zdroj atribut neposkytuje. Chybějící údaje o agentovi, kategorii, prioritě, SLA nebo kanálu nenahrazujte vymyšlenými hodnotami.
Čas aktualizace: Nastavte LastDataUpdate na čas dokončení exportu nebo transformace. V celém záznamu událostí používejte jednotné časové pásmo a formát.

Ukázkový dotaz config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

Chcete začít?

Začněte zlepšovat zákaznický servis ještě dnes. Připravte data pomocí této šablony a získejte přehled o provozu Zendesk Support i o možnostech, jak zvýšit jeho efektivitu.

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

Stáhnout šablonu

Odstraňte úzká místa v zákaznickém servisu a zvyšte CSAT

Omezte opakované kontakty. Dosáhněte 80% FCR a zvyšte spokojenost zákazníků.

Začněte se zkušební verzí

Platební kartu nepotřebujete

Šablona dat pro zákaznickou podporu

Šablona dat pro zákaznickou podporu

Atributy zákaznické podpory

Aktivity zákaznické podpory

Průvodci extrakcí dat

Uživatelské rozhraní Zendesk Explore pro tvorbu reportů a export dat

Kroky

Konfigurace

Ukázkový dotaz config

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

Kroky

Konfigurace

Ukázkový dotaz python

Zendesk Incremental Exports API pro hromadný export dat

Kroky

Konfigurace

Ukázkový dotaz python

Konektor Zendesk pro externí ETL nástroj

Kroky

Konfigurace

Ukázkový dotaz config

Chcete začít?

Odstraňte úzká místa v zákaznickém servisu a zvyšte CSAT