> Průběžné zlepšování procesů > Správa servisních požadavků > Freshservice > Datová šablona

Šablona dat pro správu servisních požadavků

Freshservice

Atributy správy servisních požadavků(19) Aktivity při správě servisních požadavků(15) Návody k extrakci dat(3)

Šablona dat pro správu servisních požadavků

Tato šablona vám pomůže shromáždit potřebná data pro analýzu procesu správy servisních požadavků. Obsahuje základní atributy, důležité aktivity ke sledování a praktické pokyny k získání těchto údajů ze zdrojových systémů. Využijte ji k vytvoření kvalitního záznamu událostí pro podrobnou analýzu procesu.

Doporučené atributy ke sběru
Důležité aktivity ke sledování
Pokyny k extrakci dat

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

Stáhnout šablonu

Atributy správy servisních požadavků

Toto jsou doporučená datová pole, která zahrňte do záznamu událostí pro důkladnou analýzu procesu správy servisních požadavků.

5 Povinné 5 Doporučené 9 Volitelné

	Název	Popis
	Čas události EventTime	Přesné časové razítko, kdy aktivita proběhla.
Popis Čas události zaznamenává datum a čas, kdy byla u servisního požadavku zaznamenána konkrétní aktivita. Toto časové razítko je nezbytné pro správné seřazení událostí a výpočet časových intervalů mezi nimi. V process mining se podle tohoto atributu řadí aktivity v jednotlivých případech a vychází z něj veškerá časová analýza. Používá se k výpočtu průběžné doby, čekání mezi aktivitami a dodržení dohod o úrovni služeb (SLA). Přesná časová razítka pomáhají odhalovat úzká místa a porozumět výkonnosti procesu. Proč je to důležité Toto časové razítko řadí události chronologicky a tvoří základ analýzy výkonnosti, včetně měření průběžné doby a odhalování úzkých míst. Kde data získat Odpovídá časovému razítku vytvoření aktivity nebo záznamu auditu ve Freshservice. Příklady 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	ID servisního požadavku ServiceRequestId	Jedinečný identifikátor každého servisního požadavku.
Popis ID servisního požadavku je jedinečné číslo nebo kód, který Freshservice přiděluje každému nově zaznamenanému servisnímu požadavku. Slouží jako primární klíč pro sledování celého životního cyklu požadavku od vytvoření až po uzavření. V process mining je toto ID zásadní, protože slouží jako ID případu. Propojuje všechny související události, například změny stavu, přiřazení pracovníka podpory a poznámky. Analýza průběhu jednotlivých servisních požadavků umožňuje zobrazit celý proces od začátku do konce, určit obvyklé postupy a odhalit odchylky nebo úzká místa u jednotlivých případů. Proč je to důležité Jde o základní ID případu, které propojuje všechny související události a umožňuje sledovat průběh jednoho servisního požadavku od začátku do konce. Kde data získat Jde o základní pole objektu ticketu ve Freshservice. Je viditelné v uživatelském rozhraní a dostupné přes Freshservice API. Příklady SR-12943SR-13501SR-14011
	Název aktivity ActivityName	Název události nebo úkolu, který se v určitém okamžiku týkal servisního požadavku.
Popis Název aktivity popisuje konkrétní krok nebo událost v životním cyklu servisního požadavku. Aktivity se získávají ze systémových auditních záznamů, změn stavu nebo konkrétních akcí uživatelů, například „Požadavek přiřazen pracovníkovi podpory“, „Přidána poznámka“ nebo „Servisní požadavek vyřešen“. Tento atribut slouží k vytvoření mapy procesu, která znázorňuje průběh servisních požadavků. Analýza pořadí a četnosti aktivit pomáhá organizacím porozumět skutečnému průběhu procesu, odhalit úzká místa mezi kroky, měřit dobu trvání aktivit a zjistit, které varianty procesu nejsou v souladu s pravidly nebo jsou neefektivní. Proč je to důležité Tento atribut určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat workflow servisních požadavků. Kde data získat Vytváří se z aktivit nebo auditních záznamů spojených s ticketem ve Freshservice. Často je potřeba převést systémové události na názvy aktivit srozumitelné pro uživatele z byznysu. Příklady Servisní požadavek vytvořenPožadavek přiřazen agentoviServisní požadavek vyřešenServisní požadavek uzavřen
	Poslední aktualizace dat LastDataUpdate	Časové razítko udávající, kdy byla data naposledy obnovena ze zdrojového systému.
Popis Tento atribut zaznamenává datum a čas poslední extrakce nebo aktualizace dat z Freshservice. Udává, jak aktuální jsou analyzovaná data. Při analýze procesu je důležité vědět, jak čerstvá data jsou. Časové razítko vám pomůže zjistit, zda pracujete s nejnovějšími informacemi. To je důležité pro včasná provozní rozhodnutí i pro důvěru ve výsledky analýzy. Proč je to důležité Informuje o aktuálnosti dat, takže analýzy i rozhodnutí vycházejí z nejnovějších dostupných informací. Kde data získat Tato hodnota se vytvoří a přidá do datové sady při extrakci a transformaci dat (ETL). Příklady 2024-05-21T02:00:00Z2024-05-20T02:00:00Z
	Zdrojový systém SourceSystem	Určuje systém, ze kterého byla data získána.
Popis Tento atribut určuje zdrojový systém procesních dat, v tomto případě Freshservice. Hodí se zejména v prostředích, kde se data z více systémů slučují pro celkový pohled na proces. Při analýze dat z jediného systému může působit nadbytečně. Je však vhodné ho zahrnout kvůli budoucímu rozšíření a správě dat. Umožňuje určit původ dat a pomáhá spravovat datové integrační postupy. Proč je to důležité Zajišťuje informace o původu dat a jejich dohledatelnost, což je důležité při slučování dat z více systémů i pro správu dat. Kde data získat Obvykle jde o statickou hodnotu přidanou při extrakci a transformaci dat (ETL). Příklady FreshserviceFreshservice-API-v2
	Priorita Priority	Úroveň priority servisního požadavku, například nízká, střední, vysoká nebo naléhavá.
Popis Priorita vyjadřuje důležitost a naléhavost servisního požadavku. Často určuje cílovou dobu vyřešení i přidělené zdroje. Nastavit ji lze automaticky podle pravidel nebo ručně pracovníkem podpory. V process mining je priorita důležitým hlediskem analýzy. Umožňuje rozdělit požadavky do skupin a porovnat průběh procesu i výkonnost u požadavků s vysokou a nízkou prioritou. To je důležité při analýze dodržování SLA i při ověřování, zda se požadavky správně a včas třídí podle priority. Proč je to důležité Důležitý atribut pro analýzu dodržování SLA a ověření, zda se požadavky třídí a vyřizují podle jejich dopadu na provoz. Kde data získat Ve Freshservice je dostupná jako pole „priority“ objektu ticketu. Příklady NízkáStředníVysokáNaléhavá
	Přiřazený pracovník podpory AssignedAgent	Jméno pracovníka podpory, který je aktuálně přiřazen k servisnímu požadavku.
Popis Tento atribut označuje konkrétního pracovníka podpory, který je v daném okamžiku zodpovědný za vyřízení servisního požadavku. Při zpracování požadavku se může přiřazený pracovník změnit. Analýza přiřazených pracovníků pomáhá vyhodnotit jejich výkonnost a rozložení pracovní zátěže. Umožňuje vypočítat KPI, například průměrnou dobu vyřízení na jednoho pracovníka, počet aktivních požadavků nebo četnost přeřazení. Díky tomu zjistíte, kdo dosahuje nejlepších výsledků, kdo potřebuje další školení a zda je práce rozdělená rovnoměrně. Proč je to důležité Umožňuje analyzovat pracovní zátěž a výkonnost pracovníků podpory i vliv změn přiřazení na dobu vyřešení. Kde data získat Ve Freshservice je dostupný jako pole „agent“ nebo „responder“ objektu ticketu. Příklady Alice JohnsonRobert SmithNepřiřazeno
	Přiřazený tým AssignedTeam	Tým nebo skupina podpory, které je svěřeno vyřízení servisního požadavku.
Popis Tento atribut označuje funkční skupinu nebo tým, například „IT podpora 2. úrovně“ nebo „Nákup hardwaru“, který odpovídá za servisní požadavek. Požadavek může být nejprve přiřazen týmu a teprve potom konkrétnímu pracovníkovi podpory. Analýza podle přiřazeného týmu pomáhá vyhodnotit výkonnost a pracovní zátěž týmů a odhalit úzká místa v konkrétních oblastech. Umožňuje posoudit, jak efektivně jednotlivé týmy požadavky zpracovávají, a lépe rozdělit zdroje v rámci podpory. Proč je to důležité Umožňuje analyzovat výkonnost a pracovní zátěž týmů či skupin. To je důležité pro správu zdrojů a odhalování úzkých míst v jednotlivých oblastech. Kde data získat Ve Freshservice je dostupný jako pole „group“ objektu ticketu. Příklady Servisní odděleníProvoz sítěPodpora aplikací
	Stav Status	Aktuální stav servisního požadavku v jeho životním cyklu.
Popis Pole Stav označuje stav servisního požadavku v daném okamžiku, například „Otevřeno“, „Čeká se“, „Vyřešeno“ nebo „Uzavřeno“. Změny stavu jsou často hlavním zdrojem aktivit pro process mining. Analýza stavu pomáhá zasadit průběh procesu do kontextu a zjistit, jak dlouho požadavky zůstávají v jednotlivých stavech. Dlouhá doba ve stavu „Čeká se“ může například znamenat, že se čeká na informace od žadatele nebo na odpověď externího dodavatele. Tento atribut pomáhá určit začátek a konec jednotlivých fází procesu. Proč je to důležité Poskytuje důležitý kontext pro každou událost a pomáhá měřit dobu strávenou v různých stavech, například „Otevřeno“ nebo „Čeká se“, a odhalovat zpoždění. Kde data získat Ve Freshservice je dostupný jako pole „status“ objektu ticketu. Příklady OtevřenoČeká seVyřešenoUzavřeno
	Typ služby ServiceType	Konkrétní typ nebo kategorie požadované služby.
Popis Typ služby zařazuje požadavek podle potřebné služby, například „Požadavek na nový hardware“, „Přístup k softwaru“ nebo „Obnovení hesla“. Často odpovídá položce katalogu služeb, kterou uživatel vybral. Tento atribut umožňuje rozdělit servisní požadavky do skupin a porovnat procesy i výkonnost u různých typů služeb. Je nezbytný pro výpočet KPI, jako je „Průměrný počet aktivit podle typu služby“. Ten pomáhá určit, které služby jsou složitější nebo náročnější na zdroje. Výsledky analýzy mohou podpořit zjednodušení procesu a automatizaci konkrétních typů služeb. Proč je to důležité Umožňuje porovnat průběh a složitost procesů u různých kategorií požadavků a najít oblasti vhodné pro standardizaci nebo automatizaci. Kde data získat V závislosti na nastavení obvykle odpovídá polím „category“, „item“ nebo vlastnímu poli objektu ticketu ve Freshservice. Příklady Nástup nového zaměstnancePožadavek na softwarovou licenciPřístup k VPN
	Čas ukončení EndTime	Přesné časové razítko dokončení aktivity.
Popis Čas ukončení označuje časové razítko dokončení aktivity. U mnoha událostí ve Freshservice se čas zahájení a ukončení shoduje, protože jde o události v konkrétním okamžiku. U aktivit založených na stavu by čas ukončení odpovídal časovému razítku následující změny stavu. Tento atribut je nezbytný pro výpočet doby trvání aktivit a čekání mezi nimi. Odečtením StartTime od EndTime lze určit dobu zpracování konkrétního úkolu. To pomáhá zjistit, které aktivity trvají nejdéle a mohly by se optimalizovat. Proč je to důležité Umožňuje počítat dobu trvání aktivit, což je důležité pro odhalování úzkých míst a měření doby zpracování jednotlivých kroků. Kde data získat Ve výpisech Freshservice nejde o přímé pole. Je potřeba ho odvodit z časového razítka následující události v posloupnosti pro daný servisní požadavek. Příklady 2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
	Došlo k opakovanému zpracování IsRework	Logická hodnota označující, zda se požadavek musel zpracovávat opakovaně.
Popis Tento vypočítaný příznak se nastaví na true, pokud servisní požadavek zahrnuje aktivity, které ukazují na opakované zpracování. Patří mezi ně například opětovné otevření po vyřešení („Servisní požadavek znovu otevřen“), opakované změny přiřazení nebo opakované žádosti o informace od uživatele („Vyžádány informace od žadatele“). Atribut usnadňuje analýzu neefektivních procesů. Umožňuje filtrovat případy, které vyžadovaly opakované zpracování, a porovnat jejich mapy procesů a průběžnou dobu s případy bez opakování. Podporuje dashboard analýzy opakovaného zpracování servisních požadavků a pomáhá vyčíslit dopad neefektivního předávání nebo neúplných vstupních informací. Proč je to důležité Jednoduše označí a pomůže analyzovat případy s neefektivními smyčkami nebo opakovanými kroky a vyčíslit náklady spojené s nedostatečnou kvalitou. Kde data získat Vypočítá se při transformaci dat použitím obchodních pravidel na posloupnost aktivit u každého „ServiceRequestId“. Příklady truefalse
	Došlo k porušení SLA IsSlaBreached	Logická hodnota označující, zda servisní požadavek překročil cílový termín vyřešení podle SLA.
Popis Tento vypočítaný atribut je jednoduchá logická hodnota, která označuje, zda byl servisní požadavek uzavřen po termínu SLA. Získá se porovnáním časového razítka „Servisní požadavek uzavřen“ nebo „Servisní požadavek vyřešen“ s hodnotou „SlaDueDate“. Atribut usnadňuje analýzu a vizualizaci v dashboardu dodržování SLA. Umožňuje snadno filtrovat a agregovat požadavky a vypočítat celkovou míru dodržování SLA jako KPI. Rozdělení podle této hodnoty pomáhá rychle oddělit požadavky, u kterých bylo SLA překročeno, a porovnat jejich průběh s požadavky vyřešenými včas. Proč je to důležité Usnadňuje analýzu dodržování SLA tím, že označuje požadavky, které nesplnily stanovené cíle, a umožňuje je filtrovat a agregovat. Kde data získat Jde o vypočítané pole, které vzniká při transformaci dat porovnáním konečného časového razítka vyřešení s polem „SlaDueDate“. Příklady truefalse
	Kanál Channel	Způsob nebo kanál, kterým byl servisní požadavek podán.
Popis Kanál označuje, jak byl servisní požadavek vytvořen, například přes samoobslužný portál, e-mailem, telefonicky nebo v chatu. Tyto informace pomáhají porozumět preferencím uživatelů a efektivitě jednotlivých kanálů. Analýza procesu podle kanálu může přinést užitečné poznatky. Požadavky podané přes portál mohou být například úplnější a vyřešené rychleji než požadavky zaslané e-mailem, u kterých může být potřeba více výměn zpráv. Výsledky analýzy mohou pomoci podpořit využívání efektivnějších kanálů. Proč je to důležité Pomáhá zjistit, zda kanál podání ovlivňuje efektivitu procesu, dobu vyřešení nebo množství nutných oprav. Kde data získat Ve Freshservice je dostupný jako pole „source“ objektu ticketu. Příklady E-mailPortálTelefonChat
	Název zásad SLA SlaPolicyName	Název zásad dohody o úrovni služeb (SLA) použitých pro daný požadavek.
Popis Tento atribut označuje konkrétní zásady SLA, které určují cílovou dobu odezvy a vyřešení servisního požadavku. Zásady se obvykle řídí faktory, jako jsou priorita, typ služby nebo skupina žadatele. Informace o použitých zásadách SLA jsou nezbytné pro dashboard analýzy dodržování a porušení SLA. Umožňují přesně měřit výkonnost vůči stanoveným cílům a zjistit, které zásady se nejčastěji nedodržují. Na základě těchto poznatků lze přezkoumat výkonnost procesu nebo reálnost samotných cílů SLA. Proč je to důležité Určuje konkrétní cílové hodnoty služby, podle kterých se požadavek vyhodnocuje. To je nezbytné pro přesné vykazování dodržování SLA. Kde data získat Tato informace je součástí údajů SLA přiřazených k ticketu. Může být potřeba načíst ji z konkrétních polí nebo koncových bodů API pro SLA. Příklady Incidenty s vysokou prioritou, 4 hodinyStandardní požadavky, 3 dnyPodpora VIP, 1 hodina
	Oddělení žadatele RequestorDepartment	Oddělení, do kterého žadatel patří.
Popis Tento atribut označuje organizační oddělení uživatele, který podal servisní požadavek, například „Prodej“, „Finance“ nebo „Lidské zdroje“. Informace se obvykle přebírá z uživatelského profilu v systému. Analýza výkonnosti procesu podle oddělení je běžným požadavkem. Může ukázat, zda se v některých odděleních požadavky vyřizují déle nebo zda mají specifické potřeby. Tyto poznatky mohou pomoci při rozdělování zdrojů, plánování školení nebo vytváření služeb pro konkrétní oddělení. Proč je to důležité Umožňuje rozdělit proces podle organizační jednotky a odhalit problémy nebo rozdíly ve výkonnosti konkrétních oddělení. Kde data získat Informace se přebírá z profilu žadatele. Ve Freshservice může být uložena ve výchozím poli „department“ nebo ve vlastním uživatelském poli. Příklady FinanceMarketingInformační technologie
	Počet změn přiřazení ReassignmentCount	Celkový počet změn pracovníka podpory nebo týmu, kterému byl servisní požadavek přiřazen.
Popis Tento vypočítaný atribut počítá počet aktivit „Požadavek znovu přiřazen“ nebo podobných aktivit u každého servisního požadavku. Vysoký počet změn přiřazení často upozorňuje na problémy při úvodním třídění, nesprávné směrování podle dovedností nebo nerovnoměrné pracovní zatížení. Tento atribut přímo podporuje dashboard výkonnosti a pracovní zátěže pracovníků podpory a KPI „Průměrný počet změn přiřazení na požadavek“. Analýza pomáhá odhalit nedostatky procesu, kvůli kterým se tickety předávají mezi pracovníky. Tím se prodlužuje doba vyřešení a zvyšuje nespokojenost pracovníků podpory i žadatelů. Proč je to důležité Měří neefektivní směrování a komplikace v procesu. Vysoký počet změn může ukazovat na problémy při úvodním třídění nebo s pracovní zátěží, které vedou ke zpoždění. Kde data získat Vypočítá se při transformaci dat počítáním konkrétních aktivit změny přiřazení u každého „ServiceRequestId“. Příklady 013
	Termín SLA SlaDueDate	Časové razítko, do kterého má být servisní požadavek podle SLA vyřešen.
Popis Tento atribut určuje termín vyřešení servisního požadavku podle příslušných zásad SLA. Jde o vypočítané časové razítko založené na čase vytvoření požadavku, jeho prioritě a pracovní době stanovené v SLA. Tento údaj je důležitý pro průběžné sledování výkonnosti i následnou analýzu dodržování SLA. Porovnáním skutečného času vyřešení s hodnotou SlaDueDate lze určit, zda byl termín splněn, nebo překročen. Tento údaj tvoří základ pro výpočet KPI míry dodržování SLA. Proč je to důležité Jde o cílový termín vyřešení, podle kterého se určuje, zda servisní požadavek splnil, nebo překročil SLA. Kde data získat Ve Freshservice jde o vypočítané pole viditelné na ticketu jako „Due by“. Je dostupné přes API. Příklady 2023-10-28T17:00:00Z2023-11-01T09:00:00Z
	Žadatel Requestor	Uživatel, který podal servisní požadavek.
Popis Tento atribut označuje osobu, obvykle zaměstnance, která podala servisní požadavek. Udává, kdo využívá servisní podporu a jaké má potřeby. Analýza průběhu procesu se na žadatele nezaměřuje vždy, ale sledování požadavků podle žadatele nebo jeho oddělení může odhalit určité vzorce. Může například ukázat, že konkrétní oddělení často podává neúplné požadavky, a upozornit tak na potřebu cíleného školení. Tento atribut je důležitý také při analýze zákaznické zkušenosti. Proč je to důležité Poskytuje kontext o uživateli, který požadavek podal, a umožňuje analyzovat vzorce podle jednotlivých uživatelů, oddělení nebo lokalit. Kde data získat Ve Freshservice je dostupný jako pole „requester“ objektu ticketu. Příklady John DoeJane SmithServisní účet

Povinné Doporučené Volitelné

Aktivity při správě servisních požadavků

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

6 Doporučené 9 Volitelné

	Aktivita	Popis
	Nedodržen termín SLA	Vypočítaná událost, ke které dojde, když doba vyřízení servisního požadavku překročí stanovený termín dohody o úrovni služeb (SLA). Nejde o přímou systémovou událost. Odvozuje se porovnáním doby vyřízení s termínem SLA.
Proč je to důležité Tato událost přímo měří plnění dohodnutých závazků a představuje důležitý KPI pro vedení. Pomáhá určit, u kterých typů požadavků nebo priorit hrozí největší riziko nedodržení SLA. Kde data získat Vypočítá se porovnáním časové značky „Resolved“ s časovou značkou „SLA Due By“. Pokud k vyřízení dojde později, událost se zaznamená. Zachycení Porovnejte časovou značku vyřízení s časovou značkou termínu SLA. Pokud resolved_at > sla_due_by, vytvořte tuto událost. Typ události calculated
	Požadavek přiřazen agentovi	Označuje okamžik, kdy je servisní požadavek přiřazen konkrétnímu agentovi. Jde o důležitý milník, který se odvozuje ze změn pole „Assigned Agent“ nebo „Owner“ u ticketu.
Proč je to důležité Tato činnost je důležitá pro analýzu vytížení agentů a odhalení úzkých míst při přiřazování. Doba od vytvoření požadavku po jeho přiřazení je důležitým ukazatelem výkonu. Kde data získat Odvozuje se z protokolu činností ticketu nebo auditní historie polí sledováním změn pole „Agent“ nebo „Assignee“. Zachycení Zaznamenejte časovou značku, kdy se vyplní pole „Assigned Agent“ nebo se změní jeho hodnota. Typ události inferred
	Servisní požadavek uzavřen	Jde o poslední činnost, která označuje konec životního cyklu servisního požadavku. Obvykle proběhne automaticky po uplynutí stanovené doby ve stavu „Resolved“, pokud požadavek nebyl znovu otevřen.
Proč je to důležité Tato událost označuje definitivní konec instance procesu. Doba mezi stavy „Resolved“ a „Closed“ představuje lhůtu, během které může žadatel vyřízení potvrdit. Kde data získat Odvozuje se z historie změn stavu ticketu. Odpovídá časové značce, kdy se stav změní na „Closed“. Zachycení Zaznamenejte časovou značku změny stavu ticketu na „Closed“. Typ události inferred
	Servisní požadavek vyřešen	Tento důležitý milník označuje okamžik, kdy agent poskytl řešení a považuje práci za dokončenou. Odvozuje se od změny stavu ticketu na „Resolved“.
Proč je to důležité Tato činnost označuje konec aktivní fáze práce. Doba do tohoto okamžiku je důležitým měřítkem efektivity agenta i procesu a slouží jako základ pro výpočet SLA. Kde data získat Odvozuje se z historie změn stavu ticketu. Odpovídá časové značce, kdy byl stav poprvé nastaven na „Resolved“. Zachycení Zaznamenejte časovou značku první změny stavu ticketu na „Resolved“. Typ události inferred
	Servisní požadavek vytvořen	Tato činnost označuje začátek životního cyklu servisního požadavku, kdy je nový požadavek oficiálně zaznamenán ve Freshservice. Událost se zaznamená při vytvoření nového záznamu ticketu, ať už prostřednictvím katalogu služeb, e-mailu nebo jiného kanálu. Požadavek získá jedinečné ID servisního požadavku.
Proč je to důležité Jde o hlavní počáteční událost procesu. Doba od této činnosti k dalším činnostem je základem pro měření celkové doby průchodu procesem a odhalení zpoždění v jeho počáteční fázi. Kde data získat Tato událost se ve Freshservice zaznamenává přímo. Najdete ji v protokolu činností ticketu nebo v auditní historii, obvykle jako čas vytvoření ticketu. Zachycení Použijte čas vytvoření ticketu z dat o ticketech ve Freshservice. Typ události explicit
	Zapojení externího dodavatele	Tato činnost označuje předání ticketu externímu dodavateli nebo třetí straně k vyřízení. Odvozuje se od změny stavu na konkrétní hodnotu, například „Pending Vendor“ nebo „Awaiting Third Party“.
Proč je to důležité Zapojení dodavatele může výrazně prodloužit dobu vyřízení. Sledování této činnosti je důležité pro měření výkonu dodavatele a jeho vlivu na celkovou dobu vyřízení servisního požadavku. Kde data získat Odvozuje se z historie změn stavu ticketu. Vyhledejte stav nastavený speciálně pro sledování závislosti na externích dodavatelích. Zachycení Zjistěte, kdy se stav ticketu změní na hodnotu označující čekání na třetí stranu. Typ události inferred
	Požadavek přeřazen	Tato činnost zaznamenává každou změnu přiřazeného agenta nebo skupiny po prvotním přiřazení. Odvozuje se z následných změn polí „Assigned Agent“ nebo „Assigned Group“.
Proč je to důležité Časté přeřazování může ukazovat na problémy s prvotním tříděním, přiřazením podle dovedností agentů nebo vyvážením jejich vytížení. Tato činnost je důležitá pro KPI počtu přeřazení mezi agenty i analýzu opakované práce. Kde data získat Odvozuje se z historie změn polí ticketu. Událost se zaznamená pokaždé, když se po nastavení původní hodnoty změní pole „Assigned Agent“ nebo „Assigned Group“. Zachycení Zjistěte každou změnu pole „Assigned Agent“ nebo „Assigned Group“ po prvním přiřazení. Typ události inferred
	Požadavek roztříděn	Označuje prvotní posouzení a kategorizaci nově vytvořeného servisního požadavku. Tato činnost se obvykle odvozuje od prvního nastavení priority nebo přiřazení požadavku skupině. Znamená to, že požadavek byl zkontrolován a zařazen do fronty.
Proč je to důležité Sledování třídění pomáhá měřit efektivitu týmu, který zajišťuje prvotní reakci. Zpoždění v této fázi mohou výrazně prodloužit celkovou dobu vyřízení a vést k nedodržení SLA. Kde data získat Odvozuje se z protokolu činností. Určíte ji podle času první události „Nastavena priorita“ nebo „Přiřazena skupina“, která nastane po vytvoření požadavku. Zachycení Určete nejstarší časovou značku změny pole priority nebo pole přiřazené skupiny. Typ události inferred
	Přidána poznámka	Označuje každou veřejnou nebo soukromou poznámku, kterou k servisnímu požadavku přidá agent nebo žadatel. Jde o událost zaznamenanou přímo v konverzaci nebo protokolu činností ticketu.
Proč je to důležité Analýza četnosti a načasování poznámek může odhalit vzorce komunikace, efektivitu spolupráce i místa, kde dochází k nedorozuměním. Kde data získat Poznámka se zaznamenává přímo do historie konverzace ticketu ve Freshservice. Každá poznámka obsahuje časovou značku a autora. Zachycení Extrahujte každou položku z konverzace nebo protokolu komentářů ticketu. Typ události explicit
	Priorita požadavku určena	K této činnosti dochází, když je servisnímu požadavku přiřazena úroveň priority, například nízká, střední nebo vysoká. Odvozuje se od změny pole „Priority“ v historii ticketu.
Proč je to důležité Určení priority je důležité pro rozdělení zdrojů a plnění cílů SLA. Analýza této činnosti pomáhá ověřit, zda jsou požadavky správně a včas posouzeny. Kde data získat Odvozuje se z historie změn polí ticketu ve Freshservice. Vyhledejte změny pole „Priority“ a zaznamenejte časovou značku změny. Zachycení Zjistěte změnu pole „Priority“ z prázdné hodnoty nebo předchozí hodnoty a zaznamenejte časovou značku. Typ události inferred
	Provedena interní kontrola	Označuje, že navržené řešení nebo vyřízení požadavku vyžaduje před pokračováním interní kontrolu či schválení. Odvozuje se od změny stavu na hodnotu, například „Pending Approval“ nebo „Internal Review“.
Proč je to důležité Interní kontroly mohou být úzkým místem, zejména u složitých servisních požadavků nebo požadavků s velkým dopadem. Měření jejich délky pomáhá zefektivnit schvalovací workflow. Kde data získat Odvozuje se z historie změn stavu ticketu. V workflow musí být použit konkrétní stav, například „Pending Internal Approval“. Zachycení Zjistěte, kdy se stav ticketu změní na hodnotu označující interní kontrolu nebo schválení. Typ události inferred
	Servisní požadavek znovu otevřen	K této události dochází, když žadatel oznámí, že problém přetrvává i poté, co byl označen jako „Resolved“. Ticket se pak vrátí do otevřeného stavu. Událost se odvozuje ze změny stavu z „Resolved“ zpět na „Open“ nebo „In Progress“.
Proč je to důležité Opětovné otevření požadavku často ukazuje na nízkou míru vyřešení při prvním kontaktu a nespokojenost zákazníků. Sledování tohoto cyklu opakované práce je důležité pro zlepšení kvality řešení. Kde data získat Odvozuje se z historie změn stavu ticketu v protokolu činností. Jde o přímý přechod stavu z „Resolved“ na „Open“. Zachycení Zjistěte změnu stavu z vyřešeného na otevřený. Typ události inferred
	Vyžádání informací od žadatele	Označuje okamžik, kdy přiřazený agent potřebuje od žadatele další informace a práce na požadavku se pozastaví. Tato činnost se odvozuje od změny stavu ticketu na „Pending“ nebo „Awaiting Customer“.
Proč je to důležité Tato činnost upozorňuje na častý zdroj zpoždění a opakované práce. Analýza její četnosti pomáhá najít příležitosti ke zlepšení šablon požadavků a sběru údajů při jejich zadávání. Kde data získat Odvozuje se z historie změn stavu ticketu. Vyhledejte změnu na stav, jako je „Pending Customer Response“ nebo „Awaiting Information“. Zachycení Zjistěte, kdy se stav ticketu změní na hodnotu označující čekání na informace od uživatele. Typ události inferred
	Žadatel poskytl informace	K této události dochází, když žadatel poskytne potřebné informace a agent může pokračovat v práci. Obvykle se odvozuje od automatické změny stavu ticketu z „Pending“ zpět na „Open“.
Proč je to důležité Tato činnost uzavírá cyklus vyžádání informací. Doba mezi žádostí o informace a jejich poskytnutím je důležitou čekací dobou, kterou je třeba analyzovat a zkrátit. Kde data získat Odvozuje se ze změny stavu z „Pending“ zpět na „Open“ nebo „In Progress“, často po odpovědi žadatele. Zachycení Zjistěte, kdy se stav ticketu změní z čekajícího na otevřený. Typ události inferred
	Žadatel potvrdil vyřízení	Tato činnost představuje výslovné potvrzení žadatele, že je s poskytnutým řešením spokojen. Lze ji odvodit z kladné odpovědi v průzkumu nebo z konkrétního komentáře před uzavřením ticketu.
Proč je to důležité Potvrzení poskytuje přímou zpětnou vazbu o kvalitě vyřízení. Nízká míra potvrzení může znamenat, že řešení plně neodpovídají potřebám uživatelů, i když požadavky znovu neotevřou. Kde data získat Tuto událost je obtížné zaznamenat přímo a může vyžadovat vlastní konfiguraci. Lze ji odvodit z odpovědi v průzkumu spokojenosti zákazníků propojeném s ticketem nebo z přiřazení konkrétního štítku. Zachycení Vyžaduje analýzu souvisejících dat, například odpovědí v průzkumech spokojenosti nebo štítků přiřazených po vyřízení. Typ události inferred

Doporučené Volitelné

Návody k extrakci dat

Jak získat data z Freshservice

Kroky

Ověřte předpoklady: Ujistěte se, že vaše uživatelská role ve Freshservice umožňuje přístup k reportům v modulu Analytics a jejich vytváření. Obvykle je k tomu potřeba tarif Pro nebo Enterprise.
Nastavte automatizace (v případě potřeby): Aby se události správně zaznamenávaly, ověřte nebo vytvořte ve Freshservice v části Admin -> Workflow Automator dvě konkrétní automatizace. První při vypršení časovače SLA pro vyřešení přidá k tiketu soukromou poznámku nebo konkrétní štítek, například „SLA_Breached“. Druhá přidá konkrétní štítek, například „Resolution_Confirmed“, když k tiketu přijde kladné hodnocení spokojenosti zákazníka.
Vytvořte report „Události vytvoření“: Ve Freshservice otevřete kartu Analytics. Vytvořte nový report a jako zdroj dat vyberte modul „Tikety“. Tento report zachytí první událost každého servisního požadavku.
Nastavte widgety reportu „Události vytvoření“: Přidejte widget „Datová tabulka“. Do sloupců (metrik) zahrňte: ID tiketu, Vytvořeno, Přiřazeno, Skupina, Priorita, Stav a Kategorie. Nastavte filtr na požadované období vytvoření, například na posledních 6 měsíců.
Exportujte data „Událostí vytvoření“: Spusťte report a exportujte widget datové tabulky do souboru CSV. Pojmenujte ho „creation_events.csv“.
Vytvořte report „Události aktualizace“: Vytvořte druhý report a jako zdroj dat tentokrát vyberte modul „Aktivity tiketů“. Report zachytí všechny následující změny a poznámky u jednotlivých servisních požadavků.
Nastavte widgety reportu „Události aktualizace“: Přidejte widget „Datová tabulka“. Zahrňte sloupce: ID tiketu, Datum aktivity, Provedl, Typ aktivity a v části „Změny“ také Pole, Původní hodnota a Nová hodnota. Pro kontext každé události přidejte také atributy tiketu: Skupina, Přiřazeno, Priorita, Stav a Kategorie.
Nastavte filtr reportu „Události aktualizace“: U pole „Datum aktivity“ použijte stejné období jako v reportu o vytvoření. Dále omezte „Typ aktivity“ jen na relevantní události, například „Změna stavu“, „Změna priority“, „Změna skupiny“, „Změna agenta“, „Přidání soukromé poznámky“ a „Přidání veřejné poznámky“.
Exportujte data „Událostí aktualizace“: Spusťte report a exportujte widget datové tabulky do souboru CSV. Pojmenujte ho „update_events.csv“.
Spojte a upravte data: Otevřete oba soubory CSV v tabulkovém procesoru nebo použijte skript pro přípravu dat. Zkopírujte všechna data ze souboru „update_events.csv“ a vložte je pod data ze souboru „creation_events.csv“ do nového souboru „event_log.csv“.
Namapujte aktivity a atributy: Do spojeného souboru „event_log.csv“ přidejte sloupce ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status a ServiceType. Vyplňte je podle logiky popsané v části Dotaz níže. Pomocí vzorců nebo skriptu převeďte nezpracovaná data do výsledného formátu záznamu událostí.
Proveďte závěrečný export: Uložte upravený soubor „event_log.csv“. Ověřte, že datum ve sloupcích EventTime a LastDataUpdate používá standardní formát, například ISO 8601. Soubor je nyní připravený k nahrání do nástroje process mining.

Konfigurace

Tarif Freshservice: Potřebujete tarif, který zahrnuje modul Analytics, obvykle Pro nebo Enterprise.
Uživatelská oprávnění: Uživatel provádějící export musí mít oprávnění vytvářet a spouštět reporty v Analytics.
Rozsah dat: Doporučujeme exportovat nedávné období, například poslední 3 až 6 měsíců, aby datová sada zůstala přehledná. V reportu o vytvoření použijte konzistentní filtr podle pole „Vytvořeno“ a v reportu o aktualizacích podle pole „Datum aktivity“.
Filtry reportů: V reportu modulu „Tikety“ nastavte filtr „Typ“ = „Servisní požadavek“, abyste vybrali správný proces. V reportu „Aktivity tiketů“ omezte pole „Typ aktivity“ na relevantní změny (stav, priorita, přiřazení a poznámky), abyste omezili nadbytečná data v exportu.
Požadované automatizace: Extrakce aktivit „Překročení cílové doby SLA“ a „Potvrzení vyřešení žadatelem“ závisí na již nastavených pravidlech Workflow Automator, která při těchto událostech přidají k tiketu poznámku nebo štítek. Bez těchto pravidel nelze uvedené aktivity touto metodou zachytit.

Ukázkový dotaz sql

/*
This extraction method uses the Freshservice UI. The following describes the configuration
and post-processing logic required to generate the event log.
*/

-- Step 1: Configuration for Report 1 (Creation Events)
MODULE: Tickets
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Created at
  - Assigned to
  - Group
  - Priority
  - Status
  - Category
FILTERS:
  - Created at IS WITHIN [Specify Start Date] and [Specify End Date]
  - Type EQUALS 'Service Request'

-- Step 2: Configuration for Report 2 (Update Events)
MODULE: Ticket Activities
WIDGET_TYPE: Data Table
COLUMNS:
  - Ticket ID
  - Activity Date
  - Activity Type
  - Field (from Changes)
  - Old Value (from Changes)
  - New Value (from Changes)
  - Performed by
  - Group (ticket attribute)
  - Assigned to (ticket attribute)
  - Priority (ticket attribute)
  - Status (ticket attribute)
  - Category (ticket attribute)
FILTERS:
  - Activity Date IS WITHIN [Specify Start Date] and [Specify End Date]
  - Ticket Type EQUALS 'Service Request'
  - Activity Type IN ('Status changed', 'Priority changed', 'Group changed', 'Agent changed', 'Private Note added', 'Public Note added')

-- Step 3: Post-Processing Logic to create the final event log file
/* 
Apply this logic to each row of the combined data from the two exported CSV files.
The logic uses a CASE statement structure to map raw data to the final ActivityName.
*/

-- Column Mapping Logic:
`ServiceRequestId` = `Ticket ID`
`EventTime` = IF row is from creation_events.csv THEN `Created at` ELSE `Activity Date`
`SourceSystem` = 'Freshservice'
`LastDataUpdate` = CURRENT_TIMESTAMP()
`AssignedAgent` = `Assigned to`
`AssignedTeam` = `Group`
`Priority` = `Priority`
`Status` = `Status`
`ServiceType` = `Category`

-- ActivityName Mapping Logic:
CASE
  WHEN row is from creation_events.csv THEN 'Service Request Created'
  WHEN `Activity Type` = 'Group changed' AND `Old Value` IS NULL THEN 'Request Triaged'
  WHEN `Activity Type` = 'Priority changed' THEN 'Request Prioritized'
  WHEN `Activity Type` = 'Agent changed' AND `Old Value` IS NULL THEN 'Request Assigned to Agent'
  WHEN `Activity Type` IN ('Agent changed', 'Group changed') AND `Old Value` IS NOT NULL THEN 'Request Reassigned'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Customer', 'Awaiting Customer Response') THEN 'Information Requested from Requestor'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Pending Customer', 'Awaiting Customer Response') AND `New Value` = 'Open' THEN 'Information Provided by Requestor'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Vendor', 'Awaiting Third Party') THEN 'External Vendor Engaged'
  WHEN `Activity Type` = 'Status changed' AND `New Value` IN ('Pending Approval', 'Internal Review') THEN 'Internal Review Performed'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'SLA Breached' THEN 'SLA Target Breached' -- Requires custom automation
  WHEN `Activity Type` IN ('Private Note added', 'Public Note added') THEN 'Note Added'
  WHEN `Activity Type` = 'Status changed' AND `Old Value` IN ('Resolved', 'Closed') AND `New Value` IN ('Open', 'In Progress') THEN 'Service Request Reopened'
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Resolved' THEN 'Service Request Resolved'
  WHEN `Activity Type` = 'Private Note added' AND `Note Content` CONTAINS 'Resolution Confirmed' THEN 'Resolution Confirmed by Requestor' -- Requires custom automation
  WHEN `Activity Type` = 'Status changed' AND `New Value` = 'Closed' THEN 'Service Request Closed'
  ELSE NULL -- Filter out these rows
END AS ActivityName

Kroky

Předpoklady: Ujistěte se, že máte nainstalovaný Python 3.6 nebo novější a knihovny requests a pandas. Budete také potřebovat Freshservice API key s oprávněním číst data tiketů.
Získejte API key: Přihlaste se ke své instanci Freshservice jako správce. Klikněte na ikonu profilu v pravém horním rohu, otevřete 'Profile Settings' a v panelu vpravo najdete svůj API key. Bezpečně si ho zkopírujte.
Uložte skript: Uložte poskytnutý kód Pythonu do souboru extract_freshservice_srm.py na svém počítači.
Nastavte parametry skriptu: Otevřete uložený skript v textovém editoru. Najděte konfigurační část na začátku a nahraďte zástupné hodnoty FRESHSERVICE_DOMAIN, API_KEY, START_DATE a END_DATE. Pokud vaše instance používá pro vlastní stavy jiné číselné ID, upravte slovník STATUS_MAPPING.
Nainstalujte knihovny: Pokud požadované knihovny ještě nemáte, otevřete příkazový řádek nebo terminál a spusťte příkaz: pip install requests pandas.
Spusťte skript: V příkazovém řádku nebo terminálu přejděte do složky, kam jste skript uložili. Spusťte ho příkazem: python extract_freshservice_srm.py.
Sledujte průběh: Skript bude v konzoli zobrazovat průběh a informovat, kterou stránku tiketů právě zpracovává. V závislosti na zvoleném období a počtu tiketů může zpracování chvíli trvat.
Získejte záznam událostí: Po úspěšném dokončení skript vytvoří ve stejné složce soubor freshservice_event_log.csv. Obsahuje extrahovaný záznam událostí.
Připravte soubor k nahrání: Vytvořený soubor CSV obsahuje požadované sloupce (ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate) a je připravený k nahrání do ProcessMind. Obvykle není potřeba další úprava formátu.

Konfigurace

FRESHSERVICE_DOMAIN: URL vaší organizace ve Freshservice, například yourcompany.freshservice.com.
API_KEY: Osobní API key z uživatelského profilu Freshservice. Uchovávejte ho v tajnosti.
START_DATE / END_DATE: Období pro extrakci tiketů ve formátu 'YYYY-MM-DD'. Pro první analýzu doporučujeme zvolit 3 až 6 měsíců, abyste vyvážili objem dat a přínos analýzy.
STATUS_MAPPING: Důležitý slovník Pythonu ve skriptu, který při odvozování událostí mapuje vlastní názvy stavů (například 'External Vendor Engaged') na odpovídající číselná ID stavů ve vaší instanci Freshservice. Ověřte a upravte tato ID podle konfigurace svého systému.
Omezení počtu požadavků API: Ověřte limity API svého tarifu Freshservice. Skript zpracovává tikety postupně, aby tyto limity dodržel. U velmi rozsáhlých datových souborů může být nutné rozdělit extrakci do kratších časových období.
Rozsah dat: Skript načítá pouze tikety typu 'Service Request'. Tento filtr se použije při prvním načtení tiketů.

Ukázkový dotaz python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain and API key
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com" 
API_KEY = class="hl-string">"[YOUR_API_KEY]"

class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Map your custom status names to their numeric IDs in Freshservice ---
class=class="hl-string">"hl-comment"># To find these IDs, you may need to inspect API responses or admin settings
class=class="hl-string">"hl-comment"># Common defaults: Open: 2, Pending: 3, Resolved: 4, Closed: 5
STATUS_MAPPING = {
    class="hl-string">'Open': 2,
    class="hl-string">'Pending': 3, 
    class="hl-string">'Resolved': 4, 
    class="hl-string">'Closed': 5,
    class="hl-string">'Awaiting Customer': 3, class=class="hl-string">"hl-comment"># Example, often maps to Pending
    class="hl-string">'Pending Vendor': [6], class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
    class="hl-string">'Pending Approval': [7]  class=class="hl-string">"hl-comment"># Replace with your actual ID(s) for this status
}
class=class="hl-string">"hl-comment"># --- END CONFIGURATION ---

BASE_URL = fclass="hl-string">"https://{FRESHSERVICE_DOMAIN}/api/v2"
AUTH = (API_KEY, class="hl-string">"X")

class=class="hl-string">"hl-comment"># Caching for agent and group lookups to reduce API calls
agent_cache = {}
group_cache = {}

def get_api_data(url):
    class="hl-string">"""Helper function to handle API requests and rate limiting."""
    while True:
        try:
            response = requests.get(url, auth=AUTH)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
            return response.json()
        except requests.exceptions.HTTPError as e:
            if e.response.status_code == 429: class=class="hl-string">"hl-comment"># Rate limit exceeded
                print(class="hl-string">"Rate limit exceeded. Waiting for 60 seconds...")
                time.sleep(60)
                continue
            else:
                print(fclass="hl-string">"HTTP Error: {e}")
                return None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Request Error: {e}")
            return None

def get_agent_name(agent_id):
    class="hl-string">"""Fetch agent name by ID with caching."""
    if not agent_id: return None
    if agent_id in agent_cache:
        return agent_cache[agent_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/agents/{agent_id}")
    if data and class="hl-string">'agent' in data:
        name = data[class="hl-string">'agent'][class="hl-string">'first_name'] + class="hl-string">' ' + data[class="hl-string">'agent'][class="hl-string">'last_name']
        agent_cache[agent_id] = name
        return name
    return None

def get_group_name(group_id):
    class="hl-string">"""Fetch group name by ID with caching."""
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    data = get_api_data(fclass="hl-string">"{BASE_URL}/groups/{group_id}")
    if data and class="hl-string">'group' in data:
        name = data[class="hl-string">'group'][class="hl-string">'name']
        group_cache[group_id] = name
        return name
    return None

def parse_iso_datetime(dt_string):
    if not dt_string: return None
    return datetime.fromisoformat(dt_string.replace(class="hl-string">'Z', class="hl-string">'+00:00'))

def main():
    event_log = []
    last_data_update = datetime.now().isoformat()

    page = 1
    while True:
        print(fclass="hl-string">"Fetching tickets, page {page}...")
        query = fclass="hl-string">'"created_at:>\\'{START_DATE}\\class="hl-string">' AND created_at:<\\'{END_DATE}\\class="hl-string">' AND ticket_type:\\\'Service Request\\\class="hl-string">'"'
        url = fclass="hl-string">"{BASE_URL}/tickets?query={query}&page={page}&per_page=100"

        data = get_api_data(url)

        if not data or class="hl-string">'tickets' not in data or not data[class="hl-string">'tickets']:
            break

        tickets = data[class="hl-string">'tickets']

        for ticket in tickets:
            service_request_id = ticket[class="hl-string">'id']
            created_at = parse_iso_datetime(ticket[class="hl-string">'created_at'])
            due_by = parse_iso_datetime(ticket[class="hl-string">'due_by'])
            resolved_at = parse_iso_datetime(ticket[class="hl-string">'resolved_at'])
            closed_at = parse_iso_datetime(ticket[class="hl-string">'closed_at'])

            class=class="hl-string">"hl-comment"># --- Activity: Service Request Created ---
            event_log.append({
                class="hl-string">'ServiceRequestId': service_request_id,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
                class="hl-string">'EventTime': created_at,
                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                class="hl-string">'LastDataUpdate': last_data_update,
                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                class="hl-string">'Status': ticket[class="hl-string">'status'],
                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
            })
            
            class=class="hl-string">"hl-comment"># Fetch conversations for detailed history
            conv_url = fclass="hl-string">"{BASE_URL}/tickets/{service_request_id}/conversations"
            conversations = get_api_data(conv_url)
            
            if not conversations or class="hl-string">'conversations' not in conversations:
                continue
                
            class=class="hl-string">"hl-comment"># Sort conversations chronologically
            sorted_convos = sorted(conversations[class="hl-string">'conversations'], key=lambda x: parse_iso_datetime(x[class="hl-string">'created_at']))

            initial_group_assigned = False
            initial_priority_set = False
            initial_agent_assigned = False
            triaged = False

            for conv in sorted_convos:
                conv_time = parse_iso_datetime(conv[class="hl-string">'created_at'])

                class=class="hl-string">"hl-comment"># --- Activity: Note Added ---
                if conv[class="hl-string">'body_text']:
                     event_log.append({
                        class="hl-string">'ServiceRequestId': service_request_id,
                        class="hl-string">'ActivityName': class="hl-string">'Note Added',
                        class="hl-string">'EventTime': conv_time,
                        class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                        class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                        class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                        class="hl-string">'Status': ticket[class="hl-string">'status'],
                        class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                    })

                class=class="hl-string">"hl-comment"># Process system activities from the activity log within conversations
                if class="hl-string">'activities' in conv and conv[class="hl-string">'activities']:
                    for activity in conv[class="hl-string">'activities']:
                        shipping_info = activity.get(class="hl-string">'shipping_info', {})
                        changes = shipping_info.get(class="hl-string">'changes', {})
                        
                        class=class="hl-string">"hl-comment"># --- Priority Change Activities ---
                        if class="hl-string">'priority' in changes:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Request Prioritized',
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': changes[class="hl-string">'priority'][1], class=class="hl-string">"hl-comment"># New value
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            if not initial_priority_set and not triaged:
                                initial_priority_set = True
                                triaged = True
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Request Triaged'})
                        
                        class=class="hl-string">"hl-comment"># --- Assignment Change Activities ---
                        if class="hl-string">'responder_id' in changes:
                            activity_name = class="hl-string">'Request Assigned to Agent' if not initial_agent_assigned else class="hl-string">'Request Reassigned'
                            initial_agent_assigned = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(changes[class="hl-string">'responder_id'][1]),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        if class="hl-string">'group_id' in changes:
                            activity_name = class="hl-string">'Request Reassigned' class=class="hl-string">"hl-comment"># Any group change after creation is a reassignment
                            if not initial_group_assigned and not triaged:
                                activity_name = class="hl-string">'Request Triaged'
                                initial_group_assigned = True
                                triaged = True
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': activity_name,
                                class="hl-string">'EventTime': conv_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(changes[class="hl-string">'group_id'][1]),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                        
                        class=class="hl-string">"hl-comment"># --- Status Change Activities ---
                        if class="hl-string">'status' in changes:
                            old_status, new_status = changes[class="hl-string">'status']
                            
                            if new_status == STATUS_MAPPING[class="hl-string">'Resolved']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Closed']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Closed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Requested from Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status == STATUS_MAPPING[class="hl-string">'Awaiting Customer'] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Information Provided by Requestor', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif old_status in [STATUS_MAPPING[class="hl-string">'Resolved'], STATUS_MAPPING[class="hl-string">'Closed']] and new_status == STATUS_MAPPING[class="hl-string">'Open']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Service Request Reopened', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Vendor']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'External Vendor Engaged', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
                            elif new_status in STATUS_MAPPING[class="hl-string">'Pending Approval']:
                                event_log.append({**event_log[-1], class="hl-string">'ActivityName': class="hl-string">'Internal Review Performed', class="hl-string">'EventTime': conv_time, class="hl-string">'Status': new_status})
            
            class=class="hl-string">"hl-comment"># --- Derived/Calculated Activities ---
            class=class="hl-string">"hl-comment"># --- Activity: SLA Target Breached ---
            resolution_time = closed_at or resolved_at
            if due_by and resolution_time and resolution_time > due_by:
                event_log.append({
                    class="hl-string">'ServiceRequestId': service_request_id,
                    class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                    class="hl-string">'EventTime': due_by,
                    class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                    class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                    class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                    class="hl-string">'Status': ticket[class="hl-string">'status'],
                    class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                })

            class=class="hl-string">"hl-comment"># --- Activity: Resolution Confirmed by Requestor (Inferred from survey) ---
            if ticket.get(class="hl-string">'satisfaction_ratings'):
                for rating in ticket[class="hl-string">'satisfaction_ratings']:
                    if rating.get(class="hl-string">'ratings'): class=class="hl-string">"hl-comment"># Check if there is a rating
                        rating_time = parse_iso_datetime(rating.get(class="hl-string">'created_at'))
                        if resolved_at and rating_time > resolved_at:
                            event_log.append({
                                class="hl-string">'ServiceRequestId': service_request_id,
                                class="hl-string">'ActivityName': class="hl-string">'Resolution Confirmed by Requestor',
                                class="hl-string">'EventTime': rating_time,
                                class="hl-string">'SourceSystem': class="hl-string">'Freshservice',
                                class="hl-string">'LastDataUpdate': last_data_update,
                                class="hl-string">'AssignedAgent': get_agent_name(ticket.get(class="hl-string">'responder_id')),
                                class="hl-string">'AssignedTeam': get_group_name(ticket.get(class="hl-string">'group_id')),
                                class="hl-string">'Priority': ticket[class="hl-string">'priority'],
                                class="hl-string">'Status': ticket[class="hl-string">'status'],
                                class="hl-string">'ServiceType': ticket.get(class="hl-string">'category')
                            })
                            break class=class="hl-string">"hl-comment"># Only add one confirmation event

        page += 1

    if not event_log:
        print(class="hl-string">"No events were generated. Please check your configuration and date range.")
        return

    class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'ServiceRequestId', class="hl-string">'EventTime'])
    df[class="hl-string">'EventTime'] = df[class="hl-string">'EventTime'].dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    df[class="hl-string">'LastDataUpdate'] = pd.to_datetime(df[class="hl-string">'LastDataUpdate']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    output_filename = class="hl-string">'freshservice_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {output_filename}")

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

Kroky

Ověřte, že vaše předplatné Freshservice a oprávnění správce zahrnují plánovaný export dat a doručování do vybraného poskytovatele cloudového úložiště. Názvy nabídek a možnosti exportu se mohou lišit podle tarifu a tenanta. Ověřte si proto aktuální dokumentaci pro správce a použijte [Nastavte podle svého systému], pokud váš tenant používá jiné názvy.
Ve Freshservice otevřete část pro správce a najděte nastavení plánovaného exportu dat. Vyberte zdroj dat o servisních požadavcích nebo tiketech, který obsahuje ID servisního požadavku, stav, prioritu, přiřazení, typ služby, časová razítka, pole SLA, historii konverzací nebo aktivit a informace o odpovědi žadatele. Nepředpokládejte, že aktuální export tiketů obsahuje historii změn polí.
Nastavte rozsah exportu. Pro první ověření vyberte průběžné období 3 až 6 měsíců a poté nastavte opakovaný plán podle potřeb reportingu. Zahrňte všechny záznamy servisních požadavků a historické údaje o aktivitách nebo auditu potřebné k určení změn polí, poznámek, změn stavů, výsledků SLA, schválení a potvrzení žadatele. Filtry na společnost nebo službu použijte jen tehdy, když jsou výslovně vyžadovány, a řiďte se pokyny [Filtr společnosti nebo služby podle vašeho systému].
Jako výstupní formát vyberte CSV a nastavte doručování do schváleného cloudového úložiště, například Amazon S3. Zadejte [Podrobnosti připojení ke cloudovému úložišti] a [Nastavení přihlašovacích údajů nebo role] prostřednictvím podporované konfigurace Freshservice. S vlastníkem platformy ověřte bucket, cestu, šifrování, dobu uchovávání a zásady přístupu. Nevkládejte přihlašovací údaje přímo do skriptů ani exportovaných souborů.
Proveďte zkušební export a zkontrolujte doručené soubory CSV. Zjistěte skutečné názvy exportovaných sloupců pro ID servisního požadavku, stav, prioritu, přiřazeného pracovníka, přiřazenou skupinu, typ služby, čas vytvoření, čas aktualizace, čas vyřešení, čas uzavření, termín SLA, časové razítko historie, pole historie, původní hodnotu, novou hodnotu, typ poznámky, autora poznámky, čas poznámky a odpověď žadatele nebo výsledek průzkumu. Pokud některé požadované zdrojové pole chybí, zaznamenejte toto omezení a nevymýšlejte název pole.
Načtěte soubory CSV do přípravné tabulky nebo datového rámce. V dotazu níže nahraďte odkazy na zdroje, včetně [Název tabulky tiketů], [Název tabulky historie tiketů], [Název tabulky konverzací], [Název tabulky SLA] a [Název tabulky průzkumů nebo potvrzení], skutečnými strukturami vytvořenými z exportu. Namapujte zdrojové sloupce na logická pole použitá v dotazu. Zachovejte zdrojová časová razítka a sjednoťte jejich časové pásmo, přednostně na UTC.
Nastavte přírůstkové zpracování podle [Časové razítko posledního úspěšného exportu] nebo času doručení exportního souboru. Ponechte dostatečný překryv, například 24 až 48 hodin, abyste zachytili pozdě doručenou historii a opravy. Odstraňujte duplicity podle ServiceRequestId, ActivityName, EventTime a stabilního identifikátoru zdrojové události, pokud je k dispozici. Neodstraňujte duplicity pouze podle ServiceRequestId, protože jeden požadavek musí vytvořit více řádků událostí.
Spusťte úplnou transformaci SQL. Dotaz výslovně vytváří řádky pro všech 15 požadovaných aktivit, včetně odvozených aktivit, jako je třídění, přeřazení, porušení SLA, potvrzení žadatele a uzavření. Pokud export neobsahuje historické údaje dokládající danou aktivitu, nelze ji spolehlivě vytvořit. Uveďte ji proto jako chybějící zdrojová data.
Pomocí níže uvedených kontrol ověřte počet řádků, pokrytí aktivit, časová razítka, identifikátory a vyplnění atributů. Zkontrolujte, že každý ServiceRequestId může mít více událostí seřazených podle času a že každý vytvořený řádek obsahuje EventTime.
Exportujte výsledek dotazu jako soubor CSV v kódování UTF-8 s požadovanými sloupci ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, AssignedAgent, AssignedTeam, Priority, Status a ServiceType. Nahrajte výsledný záznam událostí do ProcessMind a namapujte ServiceRequestId jako identifikátor případu, ActivityName jako aktivitu a EventTime jako časové razítko události. Podle nastavení importu ProcessMind ponechte SourceSystem a LastDataUpdate jako atributy události nebo metadata.

Konfigurace

Zdroj exportu: Vyberte datovou sadu servisních požadavků nebo tiketů ve Freshservice a případně také datové sady historie, konverzací, SLA, schválení a průzkumů. Samotný export aktuálního stavu tiketů nestačí k rekonstrukci všech požadovaných aktivit.
Plán: Nastavte opakovaný export podle cyklu provozního reportingu. Při prvním načtení použijte období 3 až 6 měsíců. Při přírůstkovém načítání ponechte překryv, abyste zachytili pozdě doručené aktualizace.
Požadované zdrojové údaje: Ověřte, že export obsahuje stabilní ID servisního požadavku, časová razítka událostí nebo aktualizací, historii stavů, priorit a přiřazení, historii skupin, poznámky nebo konverzace, informace o termínu a dokončení SLA, časová razítka vyřešení a uzavření a případné údaje o potvrzení žadatele.
Filtry: Použijte [Filtr společnosti nebo služby podle vašeho systému] pouze v případě potřeby. Vyhněte se příliš omezujícím filtrům stavů, které mohou vynechat znovu otevřené, vyřešené, uzavřené, čekající, dodavatelské, schvalovací nebo historické záznamy.
Cloudové úložiště: Nastavte schválený bucket nebo kontejner, cestu, šifrování, dobu uchovávání a zásady přístupu. Použijte spravovanou roli nebo mechanismus pro správu tajných údajů podporovaný tenantem. Nevkládejte přihlašovací údaje do souborů SQL ani CSV.
Práce se soubory: Zachovejte původní soubory CSV, časová razítka exportu, verzi schématu a metadata doručení. Pokud Freshservice rozdělí rozsáhlý export do více souborů, zpracujte všechny soubory z jednoho běhu exportu.
Časová pásma: Zaznamenejte zdrojové časové pásmo a sjednoťte EventTime na UTC. Pokud je to důležité pro audit, zachovejte původní časové razítko.
Výkon: Pokud to systém umožňuje, rozdělte zpracování podle data exportu, data události nebo ServiceRequestId. Před transformací načtěte původní soubory do přípravné vrstvy, neopakujte zbytečně prohledávání celé historie a používejte přírůstkové načítání s řízeným překryvem.
Oprávnění a licence: Předpokladem je přístup správce, oprávnění nastavit plánované exporty a číst vybraná data Freshservice, oprávnění zapisovat do cloudového úložiště a případná funkce nebo licence předplatného potřebná pro plánované doručování exportů.
Kvalita dat: Neodvozujte události pouze z aktuální hodnoty, pokud chybí historické údaje. Například aktuální priorita může doložit aktivitu Request Prioritized pouze tehdy, pokud existuje časové razítko přiřazení priority nebo záznam historie.
Mapování zdrojů: Nahraďte všechny odkazy na zdrojové objekty a sloupce v hranatých závorkách v dotazu skutečnými názvy z doručeného exportu. Logické názvy výstupních sloupců musí zůstat beze změny, aby je bylo možné namapovat v ProcessMind.

Ukázkový dotaz sql

WITH
base_requests AS (
    SELECT
        CAST(r.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(r.[Assigned Agent] AS VARCHAR(255)) AS AssignedAgent,
        CAST(r.[Assigned Team] AS VARCHAR(255)) AS AssignedTeam,
        CAST(r.[Priority] AS VARCHAR(100)) AS Priority,
        CAST(r.[Status] AS VARCHAR(100)) AS Status,
        CAST(r.[Service Type] AS VARCHAR(255)) AS ServiceType,
        CAST(r.[Created Time] AS TIMESTAMP) AS CreatedTime,
        CAST(r.[Resolved Time] AS TIMESTAMP) AS ResolvedTime,
        CAST(r.[Closed Time] AS TIMESTAMP) AS ClosedTime,
        CAST(r.[SLA Due Time] AS TIMESTAMP) AS SLADueTime,
        CAST(r.[Last Updated Time] AS TIMESTAMP) AS LastUpdatedTime
    FROM [Your ticket table name] r
    WHERE CAST(r.[Created Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(r.[Created Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
history AS (
    SELECT
        CAST(h.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(h.[Event Time] AS TIMESTAMP) AS EventTime,
        CAST(h.[Changed Field] AS VARCHAR(255)) AS ChangedField,
        CAST(h.[Old Value] AS VARCHAR(4000)) AS OldValue,
        CAST(h.[New Value] AS VARCHAR(4000)) AS NewValue,
        CAST(h.[Assigned Agent] AS VARCHAR(255)) AS AssignedAgentAtEvent,
        CAST(h.[Assigned Team] AS VARCHAR(255)) AS AssignedTeamAtEvent,
        CAST(h.[Priority] AS VARCHAR(100)) AS PriorityAtEvent,
        CAST(h.[Status] AS VARCHAR(100)) AS StatusAtEvent,
        CAST(h.[Service Type] AS VARCHAR(255)) AS ServiceTypeAtEvent
    FROM [Your ticket history table name] h
    WHERE CAST(h.[Event Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(h.[Event Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
conversations AS (
    SELECT
        CAST(c.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(c.[Created Time] AS TIMESTAMP) AS EventTime,
        CAST(c.[Author Type] AS VARCHAR(100)) AS AuthorType,
        CAST(c.[Visibility] AS VARCHAR(100)) AS Visibility,
        CAST(c.[Message Type] AS VARCHAR(100)) AS MessageType,
        CAST(c.[Message Text] AS VARCHAR(4000)) AS MessageText
    FROM [Your conversation table name] c
    WHERE CAST(c.[Created Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(c.[Created Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
sla_events AS (
    SELECT
        CAST(s.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(s.[SLA Due Time] AS TIMESTAMP) AS SLADueTime,
        CAST(s.[Resolution Time] AS TIMESTAMP) AS ResolutionTime,
        CAST(s.[SLA Breached] AS VARCHAR(20)) AS SLABreached
    FROM [Your SLA table name] s
),
confirmations AS (
    SELECT
        CAST(f.[Service Request ID] AS VARCHAR(255)) AS ServiceRequestId,
        CAST(f.[Confirmation Time] AS TIMESTAMP) AS EventTime,
        CAST(f.[Confirmation Result] AS VARCHAR(255)) AS ConfirmationResult
    FROM [Your survey or confirmation table name] f
    WHERE CAST(f.[Confirmation Time] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST(f.[Confirmation Time] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT b.ServiceRequestId, 'Service Request Created' AS ActivityName, b.CreatedTime AS EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM base_requests b WHERE b.CreatedTime IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Triaged', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND (LOWER(h.ChangedField) IN ('priority','assigned agent','owner','assigned group','group') OR LOWER(h.NewValue) IN ('triaged','in queue'))
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Prioritized', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'priority' AND COALESCE(h.OldValue, '') <> COALESCE(h.NewValue, '') AND NULLIF(TRIM(h.NewValue), '') IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Assigned to Agent', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) IN ('assigned agent','owner') AND NULLIF(TRIM(h.NewValue), '') IS NOT NULL AND (h.OldValue IS NULL OR TRIM(h.OldValue) = '')
    UNION ALL
    SELECT h.ServiceRequestId, 'Request Reassigned', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) IN ('assigned agent','owner','assigned group','group') AND COALESCE(h.OldValue, '') <> COALESCE(h.NewValue, '') AND NULLIF(TRIM(h.OldValue), '') IS NOT NULL
    UNION ALL
    SELECT h.ServiceRequestId, 'Information Requested from Requestor', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending','awaiting customer','awaiting requestor')
    UNION ALL
    SELECT h.ServiceRequestId, 'Information Provided by Requestor', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.OldValue) IN ('pending','awaiting customer','awaiting requestor') AND LOWER(h.NewValue) IN ('open','in progress')
    UNION ALL
    SELECT h.ServiceRequestId, 'External Vendor Engaged', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending vendor','awaiting third party','vendor')
    UNION ALL
    SELECT h.ServiceRequestId, 'Internal Review Performed', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) IN ('pending approval','internal review','awaiting approval')
    UNION ALL
    SELECT c.ServiceRequestId, 'Note Added', c.EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM conversations c LEFT JOIN base_requests b ON b.ServiceRequestId = c.ServiceRequestId WHERE c.EventTime IS NOT NULL AND (LOWER(COALESCE(c.MessageType, '')) IN ('note','comment','reply') OR LOWER(COALESCE(c.Visibility, '')) IN ('public','private'))
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Reopened', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.OldValue) = 'resolved' AND LOWER(h.NewValue) IN ('open','in progress')
    UNION ALL
    SELECT s.ServiceRequestId, 'SLA Target Breached', COALESCE(s.ResolutionTime, s.SLADueTime), b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM sla_events s LEFT JOIN base_requests b ON b.ServiceRequestId = s.ServiceRequestId WHERE LOWER(COALESCE(s.SLABreached, '')) IN ('true','yes','1') AND s.SLADueTime IS NOT NULL AND COALESCE(s.ResolutionTime, CURRENT_TIMESTAMP) > s.SLADueTime
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Resolved', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) = 'resolved'
    UNION ALL
    SELECT c.ServiceRequestId, 'Resolution Confirmed by Requestor', c.EventTime, b.AssignedAgent, b.AssignedTeam, b.Priority, b.Status, b.ServiceType FROM confirmations c LEFT JOIN base_requests b ON b.ServiceRequestId = c.ServiceRequestId WHERE c.EventTime IS NOT NULL AND LOWER(c.ConfirmationResult) IN ('positive','satisfied','confirmed','yes','resolved')
    UNION ALL
    SELECT h.ServiceRequestId, 'Service Request Closed', h.EventTime, h.AssignedAgentAtEvent, h.AssignedTeamAtEvent, h.PriorityAtEvent, h.StatusAtEvent, h.ServiceTypeAtEvent FROM history h WHERE h.EventTime IS NOT NULL AND LOWER(h.ChangedField) = 'status' AND LOWER(h.NewValue) = 'closed'
)
SELECT
    e.ServiceRequestId,
    e.ActivityName,
    e.EventTime,
    'Freshservice' AS SourceSystem,
    CAST('[Last data update timestamp]' AS TIMESTAMP) AS LastDataUpdate,
    e.AssignedAgent,
    e.AssignedTeam,
    e.Priority,
    e.Status,
    e.ServiceType
FROM events e
WHERE e.ServiceRequestId IS NOT NULL
  AND e.EventTime IS NOT NULL
ORDER BY e.ServiceRequestId, e.EventTime, e.ActivityName;

Chcete začít?

Prvním krokem ke zlepšení správy servisních požadavků je příprava dat. Pomůžeme vám zlepšit poskytování služeb.

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

Stáhnout šablonu

Zvyšte efektivitu správy servisních požadavků ve Freshservice

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

Začněte zkušební verzi zdarma

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

Šablona dat pro správu servisních požadavků

Šablona dat pro správu servisních požadavků

Atributy správy servisních požadavků

Aktivity při správě servisních požadavků

Návody k extrakci dat

Export dat z modulu Analytics ve Freshservice

Kroky

Konfigurace

Ukázkový dotaz sql

Python skript využívající Freshservice REST API

Kroky

Konfigurace

Ukázkový dotaz python

Plánovaný export dat z Freshservice do cloudového úložiště

Kroky

Konfigurace

Ukázkový dotaz sql

Chcete začít?

Zvyšte efektivitu správy servisních požadavků ve Freshservice