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

Šablona dat pro správu incidentů

Freshservice

Atributy správy incidentů(19) Aktivity při správě incidentů(14) Návody k extrakci dat(3)

Šablona dat pro správu incidentů

Tato šablona vám pomůže připravit data pro analýzu správy incidentů. Uvádí základní atributy, které je třeba shromažďovat, důležité aktivity, které je vhodné sledovat, a praktický postup, jak tyto informace získat ze zdrojového systému. Usnadní vám přípravu dat.

Doporučené atributy ke shromáždění
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 incidentů

Toto jsou doporučená datová pole pro záznam událostí, která vám umožní důkladně analyzovat proces správy incidentů.

5 Povinné 7 Doporučené 7 Volitelné

	Název	Popis
	ID incidentu IncidentId	Jedinečný identifikátor každého záznamu incidentu, který slouží jako primární klíč pro sledování celého životního cyklu incidentu.
Popis ID incidentu je základem analýzy správy incidentů. Slouží jako ID případu a propojuje související aktivity, časová razítka a změny atributů do jednoho celku. V process mining se každá položka záznamu událostí přiřazuje k ID incidentu. Díky tomu lze rekonstruovat celý průběh procesu u každého incidentu. To je nezbytné pro výpočet doby průchodu, analýzu variant procesu a hledání úzkých míst v jednotlivých případech. Bez jedinečného identifikátoru by nebylo možné rozlišit jednotlivé incidenty ani analyzovat jejich průběh od nahlášení po vyřešení. Proč je to důležité Jednoznačně identifikuje každý incident a umožňuje sledovat a analyzovat celý jeho životní cyklus od vytvoření po uzavření. Kde data získat Jde o hlavní identifikátor tiketu. Ve Freshservice Tickets API je dostupný v objektu tiketu jako pole „id“. Příklady INC-10234INC-10235INC-10236
	Časové razítko události EventTimestamp	Přesné datum a čas, kdy k aktivitě nebo události došlo.
Popis Časové razítko události, označované také jako čas zahájení, udává přesný okamžik, kdy aktivita proběhla. Každá aktivita v životním cyklu incidentu, od vytvoření po uzavření, má přiřazené časové razítko. Tento atribut je nezbytný pro všechny časové analýzy v process mining. Slouží k seřazení událostí podle času, výpočtu doby mezi aktivitami, měření celkové doby průchodu případu a analýze čekání. Je také základem dashboardů, které sledují plnění SLA, prodlevy při předávání a celkovou dobu řešení. Proč je to důležité Určuje časové pořadí událostí, které je nezbytné pro výpočet dob, analýzu doby průchodu a vyhodnocení výkonnosti procesu. Kde data získat Odvozuje se z různých časových polí ve Freshservice, například „created_at“ a „updated_at“, a z časových razítek v konverzaci nebo protokolech auditu tiketu. Příklady 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Název aktivity ActivityName	Název konkrétní obchodní aktivity nebo události, ke které v určitém okamžiku životního cyklu incidentu došlo.
Popis Název aktivity popisuje jednotlivý krok nebo událost v procesu správy incidentů, například „Incident Assigned to Group“, „Status Changed to Pending“ nebo „Incident Resolved“. Aktivity se odvozují ze změn údajů o incidentu v čase. Tento atribut je pro process mining zásadní, protože určuje uzly v objevené mapě procesu. Analýza pořadí a četnosti aktivit umožňuje organizacím zobrazit skutečný proces řešení incidentů, najít obvyklé postupy, odhalit odchylky od standardního postupu a určit opakované kroky, například časté změny přiřazení. Proč je to důležité Určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat průběh řešení incidentů, úzká místa i odchylky. Kde data získat Tento atribut není ve Freshservice samostatným polem. Odvozuje se ze změn vlastností tiketu, například stavu, priority, přiřazení pracovníka podpory nebo skupiny a přidání poznámek. Příklady Incident nahlášenIncident přiřazen skupiněPřidána poznámka k řešeníIncident vyřešen
	Poslední aktualizace dat LastDataUpdate	Časové razítko označující, kdy byla data pro tento proces naposledy obnovena nebo získána.
Popis Tento atribut udává, kdy byla celá datová sada naposledy aktualizována ze zdrojového systému. Jde o metadata platná pro celou datovou sadu, nikoli pro jednotlivé události. Kvůli jednotnosti se však často uvádějí i na úrovni události. Při analýze tato informace pomáhá určit aktuálnost dat a časové období, které dashboardy a KPI pokrývají. Uživatelé tak vědí, jak čerstvé jsou získané poznatky, a mohou posoudit, zda analýza zahrnuje i nejnovější incidenty. Proč je to důležité Informuje uživatele o aktuálnosti dat a o časovém období, které analýza pokrývá. Kde data získat Jde o časové razítko metadat vytvořené při získávání dat (ETL). Příklady 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého byla data získána, obvykle „Freshservice“.
Popis Tento atribut určuje původ dat. V tomto případě bude jeho hodnota vždy „Freshservice“, ale v prostředích, kde se pro celkový pohled na proces kombinují data z více systémů, jde o důležité pole. Uvedení atributu zdrojového systému je osvědčeným postupem pro správu a dohledatelnost dat. Jasně ukazuje původ dat, což usnadňuje jejich ověřování a řešení problémů. Pomáhá také při budoucím rozšíření projektu process mining o další systémy pro správu služeb nebo provozní systémy. Proč je to důležité Zajišťuje dohledatelnost a správu dat tím, že jasně označuje původ údajů o správě incidentů. Kde data získat Obvykle jde o statickou hodnotu, která se přidává při transformaci dat (ETL) za účelem označení datové sady. Příklady FreshserviceFreshservice-EUFreshservice-PROD
	Cílový čas SLA pro vyřešení ResolutionSlaTargetTime	Časové razítko termínu, do kterého má být incident podle pravidel SLA vyřešen.
Popis Tento atribut uchovává konkrétní datum a čas, které představují termín pro vyřešení incidentu. Termín určuje pravidlo SLA použité pro tiket a obvykle závisí na faktorech, jako je priorita. Cílový čas je nezbytný pro výpočet KPI „Míra plnění SLA“ a pro dashboard „Výkonnost SLA“. Porovnáním skutečného času vyřešení s cílovým časem lze zjistit, zda byl incident vyřešen včas, nebo zda došlo k porušení SLA. Jde o základní údaj pro měření dodržování úrovně služeb. Proč je to důležité Určuje termín vyřešení, který je potřeba pro výpočet plnění SLA a odhalení incidentů ohrožených zpožděním. Kde data získat Ve Freshservice Tickets API jsou dostupná pole „fr_due_by“ (první odpověď) a „due_by“ (vyřešení). Příklady 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Kategorie incidentu IncidentCategory	Kategorie používaná ke klasifikaci incidentu, například hardware, software nebo síť.
Popis Kategorie incidentu slouží k třídění incidentů podle typu nahlášeného problému. Tato hierarchická klasifikace pomáhá předat incident správnému týmu a je důležitá pro analýzu trendů. Tento atribut se používá v dashboardu „Přesnost kategorizace incidentů“, který pomáhá zjistit, zda nesprávné počáteční zařazení prodlužuje řešení kvůli změnám přiřazení. Seskupení incidentů podle kategorie umožňuje organizacím odhalit opakující se problémy, zjistit, na co se vynakládá nejvíce úsilí podpory, a cíleně plánovat zlepšení. Proč je to důležité Umožňuje analyzovat trendy incidentů a zjistit, zda nesprávná kategorizace nezpůsobuje prodlevy při řešení. Kde data získat Ve Freshservice jde o výchozí, ale upravitelné pole. V Tickets API je dostupné jako „category“; související pole jsou „sub_category“ a „item_category“. Příklady HardwareSoftwareProblém se sítíPřístup k účtu
	Priorita incidentu IncidentPriority	Úroveň priority incidentu, která určuje naléhavost jeho reakce a řešení.
Popis Priorita incidentu určuje, jak rychle a s jakým zaměřením je třeba incident řešit. Obvykle se používá škála jako Nízká, Střední, Vysoká a Naléhavá a podle priority se často stanovují cíle SLA. V process mining slouží priorita jako důležitý rozměr pro filtrování a analýzu. Umožňuje porovnat řešení incidentů s vysokou a nízkou prioritou a ověřit, zda se kritické problémy řeší efektivně. Dashboardy často rozdělují metriky, jako je doba průchodu a plnění SLA, podle priority, aby vedoucím podpory poskytly podklady pro další kroky. Proč je to důležité Pomáhá zaměřit analýzu na nejzávažnější incidenty a je nezbytná pro vyhodnocení plnění SLA a rozdělení zdrojů. Kde data získat Ve Freshservice Tickets API je dostupná jako pole „priority“. Hodnoty jsou číselné, například 1 pro nízkou a 4 pro naléhavou prioritu. Příklady NízkáStředníVysokáNaléhavá
	Přiřazená skupina AssignedGroup	Skupina nebo tým podpory, který právě řeší incident.
Popis Přiřazená skupina označuje tým odpovědný za incident, například „Level 1 Support“, „Network Team“ nebo „Database Admins“. Změny tohoto atributu signalizují eskalaci nebo předání mezi různými odbornými týmy. Analýza přiřazené skupiny je důležitá pro pochopení prodlev při předávání. Process mining může zobrazit, jak incidenty přecházejí mezi skupinami, ukázat obvyklé cesty eskalace a změřit, jak dlouho se čeká na zásah jednotlivých skupin. To pomáhá odhalit úzká místa v organizaci a možnosti, jak zlepšit spolupráci mezi týmy. Proč je to důležité Sleduje, který tým za incident odpovídá, což je důležité při analýze předávání, eskalací a prodlev mezi týmy. Kde data získat Ve Freshservice Tickets API je dostupný jako pole „group_id“. Toto ID lze propojit s Groups API a získat název skupiny. Příklady Servisní podporaProvoz sítěPodpora infrastruktury
	Přiřazený pracovník podpory AssignedAgent	Jméno nebo ID pracovníka podpory, který právě řeší incident.
Popis Přiřazený pracovník podpory označuje zaměstnance servisního oddělení, který v daném okamžiku odpovídá za incident. Změny tohoto atributu představují předání odpovědnosti mezi pracovníky. Tento atribut je důležitý pro analýzu výkonnosti. Umožňuje vytvářet dashboardy, které sledují vytížení pracovníků, průměrnou dobu řešení na pracovníka a podíl incidentů vyřešených při prvním kontaktu. Slouží také k analýze předávání mezi pracovníky, které může způsobovat prodlevy a neefektivitu. Sledování přiřazení pomáhá vedoucím určit potřeby školení a ocenit členy týmu s dobrými výsledky. Proč je to důležité Umožňuje analyzovat výkonnost a vytížení pracovníků podpory i vliv předávání incidentů na dobu řešení. Kde data získat Ve Freshservice Tickets API je dostupný jako pole „responder_id“. Toto ID lze propojit s Agents API a získat jméno pracovníka podpory. Příklady John DoeJane SmithSupportBot
	Stav incidentu IncidentStatus	Aktuální stav incidentu v jeho životním cyklu, například Open, Pending, Resolved nebo Closed.
Popis Stav incidentu označuje jeho aktuální fázi. Změny stavu jsou důležité události, které tvoří základ objevené mapy procesu, například přechod z „In Progress“ na „Pending“ nebo z „Resolved“ na „Closed“. Tento atribut je zásadní pro pochopení průběhu incidentu. Analýza doby strávené v jednotlivých stavech pomáhá odhalit úzká místa, například incidenty, které příliš dlouho čekají ve stavu „Pending“ na odpověď uživatele. Stav je také důležitý pro určení začátku a konce při výpočtu doby průchodu. Proč je to důležité Sleduje průběh incidentu v jeho životním cyklu a pomáhá určit fáze, ve kterých často dochází ke zpoždění. Kde data získat Ve Freshservice Tickets API je dostupný jako pole „status“. Hodnoty jsou číselné. Příklady OtevřenýProbíháČeká na vyřízeníVyřešenýUzavřený
	Závažnost incidentu IncidentSeverity	Úroveň závažnosti incidentu, která vyjadřuje jeho dopad na provoz.
Popis Závažnost incidentu vyjadřuje jeho dopad na provoz a obvykle se označuje jako nízká, střední, vysoká nebo kritická. Souvisí s prioritou, ale zaměřuje se na dopad, zatímco priorita vyjadřuje naléhavost. Výslednou prioritu často určuje kombinace závažnosti a dopadu. Analýza podle závažnosti ukazuje, jak organizace zvládá incidenty s významnými důsledky pro provoz. V dashboardech se podle ní rozdělují doby řešení a plnění SLA. Díky tomu lze zajistit, aby se nejzávažnějším problémům během celého životního cyklu věnovala odpovídající pozornost a zdroje. Proč je to důležité Měří dopad incidentu na provoz a umožňuje zaměřit analýzu na omezení nejzávažnějších problémů. Kde data získat Jde o výchozí pole ve Freshservice, které je dostupné v Tickets API jako „impact“. Jeho hodnoty jsou číselné. Příklady NízkáStředníVysoká
	Byl znovu otevřen IsReopened	Vypočítaný příznak, který má hodnotu true, pokud byl incident po vyřešení nebo uzavření znovu otevřen.
Popis Tento logický atribut označuje incidenty, které byly znovu otevřeny. Hodnota true se nastaví, pokud se po dosažení stavu „Resolved“ nebo „Closed“ stav incidentu změní zpět na otevřený stav nebo na stav „In Progress“. Tento příznak je důležitý pro výpočet KPI „Míra znovu otevřených incidentů“ a pro dashboard „Opakující se incidenty“. Vysoký podíl znovu otevřených incidentů může ukazovat na nízkou kvalitu původního řešení, neúplnou analýzu příčiny nebo předčasné uzavření. Analýza těchto případů pomáhá zlepšit kvalitu a trvalost oprav. Proč je to důležité Odhaluje nedostatky v procesu řešení a upozorňuje na incidenty, u kterých původní oprava nefungovala a bylo nutné práci opakovat. Kde data získat Jde o vypočítané pole odvozené z pořadí aktivit v záznamu událostí. Má hodnotu true, pokud dojde k aktivitě, jako je „Incident Reopened“, nebo pokud po aktivitě v uzavřeném stavu následuje u stejného ID incidentu aktivita v otevřeném stavu. Příklady truefalse
	Došlo k porušení SLA IsSlaBreached	Vypočítaný příznak, který má hodnotu true, pokud incident nebyl vyřešen do stanoveného cílového času SLA.
Popis Tento logický atribut je vypočítaná metrika, která označuje, zda doba řešení incidentu překročila cílový čas SLA. Určuje se porovnáním skutečného časového razítka vyřešení s hodnotou „ResolutionSlaTargetTime“. Příznak se přímo používá pro KPI „Míra plnění SLA“ a dashboard „Výkonnost SLA“. Zjednodušuje analýzu tím, že pro každý incident poskytuje jednoznačný výsledek plnění SLA. Usnadňuje tak souhrnné vyhodnocení a analýzu trendů. Pomáhá rychle zjistit počet a podíl incidentů, u kterých nebyly dodrženy závazky úrovně služeb. Proč je to důležité Přímo měří plnění SLA u každého incidentu, takže lze snadno vypočítat celkovou míru plnění a určit problematické oblasti. Kde data získat Jde o vypočítané pole, které vzniká při transformaci dat porovnáním časového razítka „Incident Resolved“ s polem „ResolutionSlaTargetTime“. Příklady truefalse
	Kanál nahlášení ReportingChannel	Způsob nebo kanál, kterým byl incident nahlášen, například e-mail, portál nebo telefon.
Popis Kanál nahlášení, označovaný také jako zdroj, určuje, jak se incident dostal do systému podpory. Mezi běžné kanály patří e-mail, samoobslužný portál, telefon nebo chat. Analýza tohoto atributu pomáhá vyhodnotit efektivitu jednotlivých kanálů. Dashboard „Efektivita kanálů nahlášení“ porovnává počet incidentů a průměrnou dobu řešení podle kanálu. Ukazuje tak, které způsoby fungují nejlépe a kde je prostor pro zlepšení procesu. Incidenty nahlášené přes portál se například mohou vyřešit rychleji, pokud už při nahlášení obsahují strukturované informace. Proč je to důležité Pomáhá určit nejefektivnější kanály nahlášení a odhalit možnosti, jak zlepšit příjem incidentů. Kde data získat Ve Freshservice Tickets API je dostupný jako pole „source“. Hodnoty jsou číselné. Příklady E-mailPortálTelefonChat
	Oddělení žadatele RequestersDepartment	Oddělení, do kterého patří uživatel, jenž incident nahlásil.
Popis Tento atribut označuje obchodní oddělení žadatele, například „Sales“, „Finance“ nebo „IT“. Údaj se obvykle získává z uživatelského profilu ve Freshservice. Analýza incidentů podle oddělení žadatele může ukázat, zda některé organizační jednotky postihují problémy častěji nebo zda se v nich vyskytují specifické potíže. Poskytuje důležitý kontext pro pochopení dopadu incidentů na provoz a pomáhá určit prioritu oprav, které se týkají zásadních oddělení. Proč je to důležité Poskytuje kontext z provozu a umožňuje analyzovat trendy incidentů i jejich dopad na jednotlivá oddělení. Kde data získat Tato informace je propojena s žadatelem tiketu. Lze ji získat z koncového bodu API „Requesters“ pomocí hodnoty „requester_id“ z tiketu a následně načíst „department_id“ a název oddělení. Příklady ProdejMarketingFinanceLidské zdroje
	Počet předání HandoffCount	Počet předání incidentu mezi různými pracovníky podpory nebo skupinami.
Popis Počet předání je vypočítaná metrika, která udává, kolikrát se během životního cyklu incidentu změnilo jeho přiřazení. Každá změna atributu „AssignedAgent“ nebo „AssignedGroup“ tento počet zvýší. Vysoký počet předání často ukazuje na neefektivní proces, nesprávné počáteční směrování nebo nedostatečné znalosti pracovníků podpory. Tato metrika přímo podporuje KPI „Počet předání incidentu“ a dashboard „Analýza prodlev při předávání“. Pomáhá najít incidenty nebo postupy s nadměrným počtem předání, která způsobují zpoždění. Proč je to důležité Vyjadřuje opakovanou práci a změny přiřazení a pomáhá odhalit neefektivitu způsobenou nesprávným směrováním nebo nedostatkem znalostí. Kde data získat Jde o vypočítanou metriku, která se odvozuje počítáním různých hodnot nebo změn v polích „AssignedAgent“ a „AssignedGroup“ během životního cyklu jednoho incidentu. Příklady 0125
	Poskytnuto náhradní řešení WorkaroundProvided	Příznak označující, zda uživatel před konečným vyřešením dostal dočasné náhradní řešení.
Popis Tento logický atribut označuje, zda bylo zavedeno dočasné řešení, které zmírnilo dopad incidentu během přípravy trvalé opravy. Obvykle se sleduje pomocí zaškrtávacího pole nebo konkrétního stavu. V process mining tento atribut podporuje dashboard „Metriky účinnosti náhradních řešení“. Umožňuje porovnat dobu řešení incidentů s náhradním řešením a bez něj. Lze tak zjistit, zda dočasné opravy skutečně omezují narušení provozu a zkracují dobu řešení z pohledu uživatele. Proč je to důležité Pomáhá měřit, zda dočasná náhradní řešení omezují dopad incidentů a zkracují dobu, po kterou uživatelé čekají na vyřešení. Kde data získat Obvykle jde o vlastní logické pole (zaškrtávací políčko). Jeho existenci je nutné ověřit v nastavení Freshservice „Ticket Fields“. Příklady truefalse
	Příčina incidentu RootCause	Základní důvod nebo příčina incidentu zjištěná při šetření.
Popis Atribut Příčina incidentu zachycuje základní problém, který vedl k incidentu. Pracovníci podpory tuto informaci obvykle doplňují během řešení nebo po něm v rámci analýzy příčiny (RCA). Tento atribut je důležitý pro dashboard „Opakující se incidenty a jejich příčiny“ a KPI „Míra dokončení analýzy příčin“. Analýza častých příčin umožňuje organizacím přejít od reaktivního řešení incidentů k proaktivní správě problémů. Zavedením trvalých řešení lze předcházet dalším incidentům a omezit jejich opakování. Proč je to důležité Podporuje proaktivní správu problémů tím, že pomáhá odhalit a odstranit příčiny opakujících se incidentů. Kde data získat Ve Freshservice jde často o vlastní pole, protože výchozí funkce mohou být omezené. V nastavení „Ticket Fields“ ověřte, zda existuje pole „Root Cause“ nebo podobné. Příklady Chyba v softwaruChyba konfigurace sítěNedostatečné proškolení uživatelePorucha hardwaru

Povinné Doporučené Volitelné

Aktivity při správě incidentů

Zachyťte tyto důležité kroky a milníky procesu v záznamu událostí, abyste mohli přesně zjistit průběh procesu a odhalit úzká místa.

7 Doporučené 7 Volitelné

	Aktivita	Popis
	Incident nahlášen	Označuje vytvoření nového záznamu incidentu ve Freshservice. Jde o začátek životního cyklu incidentu. Obvykle ho spustí koncový uživatel přes portál nebo e-mail, případně pracovník servisního střediska, který založí požadavek za uživatele. Událost se zaznamená s časem vytvoření.
Proč je to důležité Tato aktivita je hlavní počáteční událostí celého procesu. Doba od jejího zahájení do vyřešení je zásadní pro měření celkové doby průchodu procesem a plnění SLA. Kde data získat Získává se z časového údaje vytvoření v tabulce incidentů. Freshservice tento údaj zaznamenává u každého nového požadavku. Zachycení Použijte časové razítko „Created at“ z hlavního záznamu incidentu. Typ události explicit
	Incident přiřazen skupině	Označuje první přiřazení incidentu podpůrné skupině. Může k němu dojít automaticky podle pravidel směrování nebo ručně při třídění požadavků. Aktivitu lze zachytit sledováním prvního vyplnění pole „Group“ v protokolu změn incidentu.
Proč je to důležité Sledování přiřazení je důležité pro měření doby první reakce a odhalování úzkých míst při rozdělování požadavků. Pomáhá zjistit, jak efektivně se incidenty směrují ke správným týmům. Kde data získat Odvozuje se z první položky v protokolu aktivit incidentu, která vyplní nebo změní pole „Group“. Zachycení Najděte první časový údaj, kdy je u incidentu vyplněno pole „Group“. Typ události inferred
	Incident vyřešen	Označuje okamžik, kdy pracovník provedl opravu a považuje incident za vyřešený. Zaznamená se při změně stavu incidentu na „Resolved“. Ve Freshservice jde o důležitý milník, kterým se zastaví měření SLA.
Proč je to důležité Tento milník je zásadní pro měření doby do vyřešení (TTR). Doba mezi stavy „Resolved“ a „Closed“ je důležitá při analýze čekání na potvrzení uživatelem a pravidel automatického uzavírání. Kde data získat Odvozuje se z protokolu aktivit incidentu podle okamžiku, kdy se pole „Status“ změní na „Resolved“. Zachycení Použijte časový údaj položky v protokolu aktivit, která zaznamenává změnu stavu na „Resolved“. Typ události inferred
	Incidentu nastavena priorita	K této aktivitě dochází při nastavení nebo změně priority incidentu. Priorita určuje naléhavost řešení a cíle SLA. Změny se zachycují sledováním pole „Priority“ v historii incidentu.
Proč je to důležité Nesprávné nebo opožděné určení priority může vést k nedodržení SLA a neefektivnímu přidělování zdrojů. Analýza této aktivity pomáhá zajistit, aby se kritickým incidentům věnovala okamžitá pozornost. Kde data získat Odvozuje se z protokolu aktivit incidentu, který zaznamenává všechny změny pole „Priority“. Zachycení Použijte časové údaje z protokolu změn, kdy byla hodnota pole „Priority“ nastavena nebo změněna. Typ události inferred
	Přidána poznámka k řešení	K této aktivitě dochází, když pracovník zdokumentuje řešení incidentu přidáním poznámky k řešení. Ve Freshservice jde o samostatnou akci před změnou stavu na „Resolved“. Akce i její obsah se zaznamenávají.
Proč je to důležité Tento krok označuje nalezení řešení. Doba mezi ním a změnou stavu incidentu na „Resolved“ může ukazovat na čas potřebný pro interní kontrolu nebo dokumentaci. Kde data získat Zaznamená se čas přidání poznámky k řešení incidentu, který je uložen v historii konverzace. Zachycení V protokolu konverzace incidentu najděte časový údaj položky „Resolution Note“. Typ události explicit
	Stav změněn na In Progress	Tato aktivita označuje oficiální začátek aktivního šetření a práce na incidentu. Zaznamená se, když pracovník změní stav incidentu na „In Progress“. Jde o běžnou změnu stavu, která se ukládá do historie aktivit požadavku.
Proč je to důležité Tento milník pomáhá rozlišit dobu čekání od aktivní práce. Doba, po kterou je incident ve stavu „In Progress“, je důležitá pro pochopení náročnosti jeho řešení. Kde data získat Odvozuje se z protokolu aktivit incidentu podle okamžiku, kdy se pole „Status“ změní na „In Progress“. Zachycení V protokolu aktivit vyhledejte změnu stavu na „In Progress“ a použijte její časový údaj. Typ události inferred
	Uzavřený incident	Označuje konečné formální uzavření záznamu incidentu. Obvykle k němu dojde automaticky po uplynutí stanovené doby ve stavu „Resolved“, případně jej může pracovník podpory uzavřít ručně. Tato událost označuje konec životního cyklu incidentu.
Proč je to důležité Tato aktivita představuje konec procesu. Celková doba do této události odpovídá délce celého životního cyklu incidentu včetně čekání na potvrzení od uživatele. Kde data získat Událost se odvodí ze záznamu aktivit incidentu podle aktualizace pole „Status“ na „Closed“. Zachycení Použijte časové razítko záznamu ve výpisu aktivit, který zachycuje změnu stavu na „Closed“. Typ události inferred
	Incident přiřazen pracovníkovi	Tato aktivita označuje přiřazení incidentu konkrétnímu pracovníkovi. Znamená, že pracovník přebírá za požadavek odpovědnost. Přiřazení se zaznamená v historii aktivit požadavku včetně jména pracovníka a času přiřazení.
Proč je to důležité Díky tomu můžete analyzovat vytížení a výkon pracovníků i dobu od přiřazení skupině do převzetí incidentu konkrétním pracovníkem. Tyto údaje jsou důležité pro dashboardy výkonu pracovníků. Kde data získat Sleduje se podle změn pole „Agent“ v protokolu aktivit nebo v historii změn incidentu. Zachycení Najděte časové údaje odpovídající změnám pole „Agent“. Typ události inferred
	Incident znovu přiřazen	Označuje předání incidentu jinému pracovníkovi nebo skupině. Jde o předání v průběhu řešení. Událost se odvozuje ze změn polí „Agent“ nebo „Group“ po prvním přiřazení.
Proč je to důležité Časté změny přiřazení neboli předávání často ukazují na neefektivní proces, nedostatek znalostí nebo nesprávné počáteční směrování. Analýza těchto událostí pomáhá odhalit a omezit zpoždění. Kde data získat Odvozuje se z protokolu aktivit incidentu sledováním změn polí „Agent“ nebo „Group“ po prvním přiřazení. Zachycení V historii změn požadavku zjistěte změny polí „Agent“ nebo „Group“. Typ události inferred
	Odeslána první odpověď	Tato aktivita označuje první zprávu pracovníka uživateli po nahlášení incidentu. Může jít o veřejnou poznámku nebo přímou odpověď. Freshservice zaznamenává veškerou komunikaci pracovníků včetně časových údajů.
Proč je to důležité Plnění SLA pro první odpověď je důležitým KPI spokojenosti zákazníků. Tato aktivita umožňuje měřit a analyzovat, jak rychle pracovníci reagují na nové incidenty. Kde data získat Určí se podle času první veřejné poznámky nebo odpovědi pracovníka v historii konverzace incidentu. Zachycení Vyhledejte v historii konverzace incidentu nejstarší záznam vytvořený pracovníkem. Typ události explicit
	Poskytnuto náhradní řešení	Tato aktivita označuje sdělení dočasného řešení uživateli, které má zmírnit dopad incidentu. Její zaznamenávání často vyžaduje konkrétní nastavení systému, například vyhrazené zaškrtávací pole, určitý typ poznámky nebo vyhledávání klíčových slov v poznámkách pracovníků.
Proč je to důležité Pomáhá vyhodnotit, jak náhradní řešení omezují dopad na provoz firmy a jak souvisejí s konečnou dobou vyřešení. Podporuje dashboard metrik účinnosti náhradních řešení. Kde data získat Pravděpodobně nejde o výslovně zaznamenanou událost. Lze ji odvodit například označením poznámek obsahujících výrazy jako „workaround“ nebo sledováním změn vlastního zaškrtávacího pole „Workaround Provided“. Zachycení Odvozuje se ze změny vlastního pole nebo analýzy klíčových slov v poznámkách pracovníků. Typ události inferred
	Překročen cíl SLA	Jde o vypočítanou událost, ke které dojde, když uplynulá doba řešení incidentu překročí stanovený cíl SLA pro reakci nebo vyřešení. Freshservice sleduje stav SLA interně. Událost lze odvodit porovnáním časových údajů s pravidly SLA.
Proč je to důležité Přímo měří plnění závazků týkajících se úrovně služeb. Zjištění, kdy a proč dochází k nedodržení SLA, je zásadní pro dashboard výkonu SLA a průběžné zlepšování. Kde data získat Vypočítá se porovnáním času vyřešení nebo odpovědi s termínem stanoveným SLA. Freshservice často označuje tikety jako „SLA Violated“. Zachycení Určí se porovnáním časového razítka „Resolved at“ s časovým razítkem „Due by“ nebo podle změny pole „SLA Status“ na „Violated“. Typ události calculated
	Stav změněn na Pending	Označuje přerušení řešení, obvykle kvůli čekání na informace od uživatele nebo třetí strany. Odvozuje se ze změny stavu na některý ze stavů „Pending“. Doba v tomto stavu se často nezapočítává do výpočtu SLA.
Proč je to důležité Sledování doby ve stavech čekání je důležité pro pochopení závislostí na externích stranách a souvisejících zpoždění. Pomáhá oddělit dobu práce pracovníka od doby čekání. Kde data získat Odvozuje se z protokolu aktivit incidentu, když se pole „Status“ změní například na „Pending“ nebo „Awaiting User Response“. Zachycení V protokolu aktivit vyhledejte změny stavu na některý ze stavů čekání a použijte odpovídající časový údaj. Typ události inferred
	Znovu otevřený incident	K této události dojde, když se incident, který byl dříve označen jako „Resolved“, vrátí do otevřeného stavu. Obvykle se tak stane, když uživatel s řešením nesouhlasí. Událost lze odvodit ze změny stavu z „Resolved“ zpět na „Open“ nebo „In Progress“.
Proč je to důležité Vysoký podíl znovu otevřených incidentů může ukazovat na nedostatečnou kvalitu řešení nebo neúplné opravy. Jde o důležitou metriku pro analýzu opakované práce a výkonu pracovníků podpory. Kde data získat Událost se odvodí ze záznamu aktivit incidentu podle změny stavu z „Resolved“ na aktivní stav. Zachycení Ve záznamu aktivit vyhledejte změnu pole „Status“ z „Resolved“ na „Open“ nebo „In Progress“. Typ události inferred

Doporučené Volitelné

Návody k extrakci dat

Jak získat data z Freshservice

Kroky

Přejděte do Freshservice Analytics: Přihlaste se do své instance Freshservice pomocí účtu, který má oprávnění zobrazovat a vytvářet reporty. V hlavní nabídce otevřete modul Analytika.
Vytvořte nový report: Klikněte na tlačítko Nový report. Zadejte výstižný název, například „Záznam událostí správy incidentů“. Po výzvě k výběru zdroje dat zvolte modul Správa incidentů.
Vyberte widget reportu: V editoru reportu přidejte nový widget a zvolte typ Tabulka. Ta bude základem záznamu událostí.
Přidejte hlavní datové sloupce: V panelu zdrojů dat vpravo přetáhněte potřebná pole do nastavení sloupců tabulky. Začněte poli ID incidentu, Vytvořeno, Agent, Skupina, Priorita, Závažnost, Stav a Kategorie.
Přidejte údaje o aktivitách: Chcete-li zachytit jednotlivé události, musíte propojit data nebo zahrnout údaje z aktivit tiketu. Přidejte do widgetu zdroj dat Aktivity. Z něj přidejte pole Provedeno (časové razítko události) a Popis aktivity nebo podobná pole, která popisují provedenou změnu.
Vytvořte vypočítaný sloupec „ActivityName“: Jde o nejdůležitější krok. Vytvořte nový vypočítaný sloupec nebo pole se vzorcem. Pomocí vnořených příkazů IF nebo funkce CASE převeďte nezpracovaná data o aktivitách na požadované hodnoty ActivityName. Podrobnou logiku pro všech 14 aktivit najdete v části Dotaz.
Nastavte „EventTimestamp“: Vytvořte další vypočítaný sloupec pro EventTimestamp. U aktivity „Nahlášen incident“ má sloupec použít časové razítko z pole Vytvořeno. U všech ostatních událostí má použít časové razítko Provedeno z dané aktivity.
Nastavte filtry reportu: Pomocí filtrů omezte data. Nastavte alespoň filtr časového období pro pole „Vytvořeno“. Doporučujeme zvolit poslední 3 až 6 měsíců. Přidejte také filtr, který zahrne pouze tikety, u nichž je „Typ tiketu“ nastaven na „Incident“.
Spusťte report a upravte ho: Spusťte report a zobrazte náhled dat. Zkontrolujte, zda se sloupce ActivityName a EventTimestamp správně vyplňují. Podle potřeby upravte vzorce a filtry.
Uložte a exportujte report: Až budete s výsledkem spokojeni, report uložte. Zvolte možnost Exportovat a jako formát vyberte CSV.
Naplánujte export (volitelné): Pro průběžnou analýzu můžete nastavit automatické spouštění a export reportu. Zvolte plán, například denní nebo týdenní, a nechte si soubor CSV doručovat e-mailem nebo na jiné místo.
Připravte data k nahrání: Otevřete exportovaný soubor CSV. Přejmenujte záhlaví sloupců podle požadovaného schématu ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup atd. Přidejte statické sloupce SourceSystem s hodnotou „Freshservice“ a LastDataUpdate s aktuálním časovým razítkem. Soubor je nyní připraven k nahrání.

Konfigurace

Modul Analytics: Tato extrakce vyžaduje přístup k modulu Freshservice Analytics, který je dostupný ve vyšších tarifech, například Pro nebo Enterprise.
Potřebná oprávnění: Váš uživatelský účet musí mít roli s oprávněním vytvářet, upravovat a spouštět reporty v modulu Analytics.
Časové období: Nastavte filtr podle data vytvoření incidentu, abyste omezili objem dat. Doporučujeme průběžné období 3 až 6 měsíců, které vyvažuje historický kontext a rychlost zpracování.
Filtry reportu: Vždy nastavte filtr 'Ticket Type' equals 'Incident', aby analýza procesu nezahrnovala servisní požadavky ani jiné typy požadavků.
Vypočítaná pole: Tato metoda se ve velké míře opírá o vypočítaná pole (vzorce), která určují ActivityName a EventTimestamp pro každou událost. Znalost editoru vzorců Freshservice se vám bude hodit.
Objem dat: U každého incidentu vznikne několik řádků, jeden pro každou aktivitu. Ve velkých instancích Freshservice může být výsledný soubor CSV velmi rozsáhlý, což prodlouží generování reportu i export.

Ukázkový dotaz config

// This is a conceptual configuration for the Freshservice Analytics report builder, not an executable script.
// The logic should be implemented using the UI's formula fields and widget settings.

REPORT_WIDGET_TYPE: Table

DATA_SOURCES:
  - Primary: Incidents
  - Additional: Ticket Activities

COLUMNS_AND_DERIVATION_LOGIC:

1.  **IncidentId**
    - Source: Incidents."ID"

2.  **ActivityName** (Calculated Column using a Formula)
    - This formula combines multiple IF conditions to generate the activity name based on the activity type and data changes. The logic below represents a CASE statement structure.
    - **WHEN** Activity Type is 'Created': 'Incident Reported'
    - **WHEN** Activity Field is 'Group' and it is the first update to this field for the ticket: 'Incident Assigned to Group'
    - **WHEN** Activity Field is 'Agent' and it is the first update to this field for the ticket: 'Agent Assigned to Incident'
    - **WHEN** Activity Field is 'Priority': 'Incident Prioritized'
    - **WHEN** Activity Type is 'First Response Sent': 'First Response Sent'
    - **WHEN** Activity Field is 'Group' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Agent' and it is NOT the first update: 'Incident Reassigned'
    - **WHEN** Activity Field is 'Status' and New Value is 'In Progress': 'Status Changed to In Progress'
    - **WHEN** Activity Field is 'Status' and New Value is 'Pending': 'Status Changed to Pending'
    - **WHEN** Activity Note contains 'Workaround Provided' or a specific workaround tag is added: 'Workaround Provided'
    - **WHEN** Activity Type is 'Resolution Note Added': 'Resolution Note Added'
    - **WHEN** Activity Field is 'Status' and New Value is 'Resolved': 'Incident Resolved'
    - **WHEN** Activity Type is 'SLA Violated' and SLA Type is 'Resolution': 'SLA Target Breached'
    - **WHEN** Activity Field is 'Status' and Old Value was 'Resolved' and New Value is 'Open': 'Incident Reopened'
    - **WHEN** Activity Field is 'Status' and New Value is 'Closed': 'Incident Closed'

3.  **EventTimestamp** (Calculated Column using a Formula)
    - **IF** ActivityName is 'Incident Reported', THEN use Incidents."Created at"
    - **ELSE**, use Ticket Activities."Performed at"

4.  **SourceSystem** (Calculated Column)
    - Value: 'Freshservice'

5.  **LastDataUpdate** (Calculated Column)
    - Value: Use a formula function that returns the current timestamp of the report execution.

6.  **AssignedAgent**
    - Source: Ticket Activities."Performed By" if available, otherwise the current Incidents."Agent"

7.  **AssignedGroup**
    - Source: The value of the 'Group' field at the time of the activity.

8.  **IncidentPriority**
    - Source: The value of the 'Priority' field at the time of the activity.

9.  **IncidentSeverity**
    - Source: The value of the 'Severity' field at the time of the activity.

10. **IncidentStatus**
    - Source: The new value from the 'Status' field change activity.

11. **IncidentCategory**
    - Source: The value of the 'Category' field at the time of the activity.

12. **ResolutionSlaTargetTime**
    - Source: Incidents."Resolution due by"

REPORT_FILTERS:
  - Incidents."Created at" BETWEEN '[Specify Start Date]' AND '[Specify End Date]'
  - Incidents."Type" EQUALS 'Incident'

Kroky

Předpoklady: Ověřte, že máte nainstalovaný Python 3.6 nebo novější a knihovny requests a pandas. Nainstalujete je příkazem pip: pip install requests pandas.
Vytvořte API klíč: Přihlaste se do své instance Freshservice jako správce. Kliknutím na profilový obrázek v pravém horním rohu otevřete nastavení profilu. Přejděte do části 'API Key' a zkopírujte svůj osobní API klíč. Zacházejte s ním jako s heslem.
Připravte skript: Uložte poskytnutý kód Python do souboru extract_freshservice_incidents.py na svém počítači.
Nastavte parametry: Otevřete skript v textovém editoru. Nahraďte zástupné hodnoty FRESHSERVICE_DOMAIN (například 'yourcompany.freshservice.com'), API_KEY (právě zkopírovaným klíčem) a START_DATE_STR (začátkem požadovaného období extrakce ve formátu 'YYYY-MM-DD').
Seznamte se s logikou skriptu: Skript nejprve načte všechny incidenty vytvořené po zadaném datu. Prochází jednotlivé stránky výsledků vrácených rozhraním API. U každého požadavku provede druhé volání API, aby získal podrobnou historii aktivit.
Vytvoření záznamu událostí: Skript zpracuje základní data požadavku a jeho záznam aktivit, aby vytvořil záznamy pro každou ze 14 požadovaných obchodních aktivit. Například 'Incident Reported' se vytvoří podle data založení požadavku, zatímco 'Status Changed to In Progress' se odvodí z konkrétní položky v záznamu aktivit.
Odvození složitějších událostí: Skript odvodí například události 'SLA Target Breached'. Zkontroluje, zda došlo k porušení SLA pro řešení požadavku. Pokud ano, vytvoří událost s časovým razítkem podle data due_by, které označuje okamžik porušení.
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_freshservice_incidents.py.
Sledujte průběh: Skript bude v konzoli zobrazovat průběžné informace o počtu zpracovaných požadavků. Doba zpracování závisí na jejich počtu a limitech volání API.
Zkontrolujte výstup: Po dokončení skript ve stejné složce vytvoří soubor CSV freshservice_incident_event_log.csv. Obsahuje úplný záznam událostí.
Připravte soubor k nahrání: Otevřete soubor CSV v tabulkovém procesoru a ověřte, že jsou sloupce IncidentId, ActivityName, EventTimestamp atd. správně vyplněné. Soubor je připraven k nahrání do ProcessMind nebo jiného nástroje process mining.

Konfigurace

FRESHSERVICE_DOMAIN: Konkrétní adresa Freshservice vaší společnosti, například mycompany.freshservice.com. Tento parametr je ve skriptu povinný.
API_KEY: Osobní API klíč uživatele s dostatečnými oprávněními ke čtení všech údajů o incidentech. Tento parametr je povinný.
START_DATE_STR: Počáteční datum extrakce dat ve formátu 'YYYY-MM-DD'. Pro smysluplnou analýzu doporučujeme nejprve extrahovat data za období 3 až 6 měsíců.
PAGE_SIZE: Nastavte hodnotu 100, což je maximum povolené rozhraním Freshservice API. Omezíte tak počet volání API a zrychlíte zpracování. Tuto hodnotu obvykle nedoporučujeme měnit.
Omezení rychlosti API: Skript po zpracování každého požadavku provede základní volání time.sleep(1), aby dodržel limity Freshservice API. U instancí s velkým objemem dat může být nutné tuto hodnotu upravit, aby nedocházelo k chybám.
Potřebná oprávnění: Použitý API klíč musí patřit uživatelskému účtu, například vyhrazenému servisnímu účtu, s oprávněními alespoň na úrovni role 'SD Agent'. Jen tak získá přístup ke všem potřebným polím požadavků a záznamům aktivit napříč skupinami servisního střediska.

Ukázkový dotaz python

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

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your Freshservice domain
FRESHSERVICE_DOMAIN = class="hl-string">"[your_domain].freshservice.com"
class=class="hl-string">"hl-comment"># Replace with your Freshservice API Key
API_KEY = class="hl-string">"[your_api_key]"
class=class="hl-string">"hl-comment"># Set the start date for the extraction (YYYY-MM-DD)
START_DATE_STR = class="hl-string">"2023-01-01"

class=class="hl-string">"hl-comment"># --- Constants ---
BASE_URL = fclass="hl-string">"https протокол://{FRESHSERVICE_DOMAIN}/api/v2"
PAGE_SIZE = 100
OUTPUT_FILENAME = class="hl-string">"freshservice_incident_event_log.csv"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def create_event(incident_id, activity_name, event_timestamp, ticket_data, source_system, last_data_update):
    class="hl-string">"""Helper function to create a structured event dictionary."""
    class=class="hl-string">"hl-comment"># Use latest known values for attributes if available
    sla_policy = ticket_data.get(class="hl-string">'sla_policy', {})
    resolution_due = None
    if sla_policy and sla_policy.get(class="hl-string">'resolution_sla', {}):
        resolution_due = sla_policy.get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'due_by')

    return {
        class="hl-string">"IncidentId": incident_id,
        class="hl-string">"ActivityName": activity_name,
        class="hl-string">"EventTimestamp": event_timestamp,
        class="hl-string">"SourceSystem": source_system,
        class="hl-string">"LastDataUpdate": last_data_update,
        class="hl-string">"AssignedAgent": ticket_data.get(class="hl-string">'responder_id'),
        class="hl-string">"AssignedGroup": ticket_data.get(class="hl-string">'group_id'),
        class="hl-string">"IncidentPriority": ticket_data.get(class="hl-string">'priority'),
        class="hl-string">"IncidentSeverity": ticket_data.get(class="hl-string">'impact'), class=class="hl-string">"hl-comment"># Impact is often used for Severity
        class="hl-string">"IncidentStatus": ticket_data.get(class="hl-string">'status'),
        class="hl-string">"IncidentCategory": ticket_data.get(class="hl-string">'category'),
        class="hl-string">"ResolutionSlaTargetTime": resolution_due
    }

def get_all_tickets(session, start_date):
    class="hl-string">"""Fetches all tickets from Freshservice updated since the start date, handling pagination."""
    tickets = []
    page = 1
    while True:
        params = {
            class="hl-string">"updated_since": start_date + class="hl-string">"T00:00:00Z",
            class="hl-string">"per_page": PAGE_SIZE,
            class="hl-string">"page": page,
            class="hl-string">"order_type": class="hl-string">"asc" class=class="hl-string">"hl-comment"># Process tickets in chronological order
        }
        try:
            response = session.get(fclass="hl-string">"{BASE_URL}/tickets", params=params)
            response.raise_for_status()
            data = response.json().get(class="hl-string">"tickets", [])
            if not data:
                break
            tickets.extend(data)
            print(fclass="hl-string">"Fetched page {page}, {len(data)} tickets...")
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return tickets

def get_ticket_activities(session, ticket_id):
    class="hl-string">"""Fetches all activities (audit log) for a specific ticket."""
    try:
        response = session.get(fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/activities")
        response.raise_for_status()
        return response.json().get(class="hl-string">"activities", [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching activities for ticket {ticket_id}: {e}")
        return []

def main():
    class="hl-string">"""Main function to run the extraction process."""
    session = requests.Session()
    session.auth = (API_KEY, class="hl-string">'X') class=class="hl-string">"hl-comment"># class="hl-string">'X' is a placeholder password
    session.headers.update({class="hl-string">'Content-Type': class="hl-string">'application/json'})

    last_data_update = datetime.datetime.now(datetime.timezone.utc).isoformat()
    source_system = class="hl-string">'Freshservice'
    event_log = []

    print(class="hl-string">"Starting Freshservice incident extraction...")
    all_tickets = get_all_tickets(session, START_DATE_STR)
    print(fclass="hl-string">"Total tickets to process: {len(all_tickets)}")

    for i, ticket in enumerate(all_tickets):
        incident_id = ticket[class="hl-string">'id']
        print(fclass="hl-string">"Processing ticket {i+1}/{len(all_tickets)}: ID {incident_id}")

        class=class="hl-string">"hl-comment"># 1. Incident Reported
        event_log.append(create_event(incident_id, class="hl-string">"Incident Reported", ticket[class="hl-string">'created_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Fetch detailed activities for more events
        activities = get_ticket_activities(session, incident_id)
        
        assigned_group_done = False
        agent_assigned_done = False
        first_response_done = False

        for activity in sorted(activities, key=lambda x: x[class="hl-string">'performed_at']):
            activity_ts = activity[class="hl-string">'performed_at']
            class=class="hl-string">"hl-comment"># 2. Incident Assigned to Group (first occurrence)
            if not assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Assigned to Group", activity_ts, ticket, source_system, last_data_update))
                assigned_group_done = True
            
            class=class="hl-string">"hl-comment"># 3. Agent Assigned to Incident (first occurrence)
            if not agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Agent Assigned to Incident", activity_ts, ticket, source_system, last_data_update))
                agent_assigned_done = True

            class=class="hl-string">"hl-comment"># 4. Incident Prioritized
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'priority' in activity.get(class="hl-string">'changes', {}):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Prioritized", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 5. First Response Sent (first public note by an agent)
            if not first_response_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'private') is False and activity.get(class="hl-string">'performer_type') == class="hl-string">'User':
                event_log.append(create_event(incident_id, class="hl-string">"First Response Sent", activity_ts, ticket, source_system, last_data_update))
                first_response_done = True

            class=class="hl-string">"hl-comment"># 6. Incident Reassigned (subsequent assignments)
            if (assigned_group_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'group_id' in activity.get(class="hl-string">'changes', {})) or \
               (agent_assigned_done and activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'responder_id' in activity.get(class="hl-string">'changes', {})):
                event_log.append(create_event(incident_id, class="hl-string">"Incident Reassigned", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># Status Changes
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Update' and class="hl-string">'status' in activity.get(class="hl-string">'changes', {}):
                new_status = activity[class="hl-string">'changes'][class="hl-string">'status'][1]
                class=class="hl-string">"hl-comment"># 7. Status Changed to In Progress
                if new_status == 3: class=class="hl-string">"hl-comment"># Assuming 3 is class="hl-string">'In Progress'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to In Progress", activity_ts, ticket, source_system, last_data_update))
                class=class="hl-string">"hl-comment"># 8. Status Changed to Pending
                elif new_status == 6: class=class="hl-string">"hl-comment"># Assuming 6 is class="hl-string">'Pending'
                    event_log.append(create_event(incident_id, class="hl-string">"Status Changed to Pending", activity_ts, ticket, source_system, last_data_update))

            class=class="hl-string">"hl-comment"># 9. Workaround Provided (Keyword search in notes)
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and class="hl-string">'workaround' in activity.get(class="hl-string">'note', {}).get(class="hl-string">'body_text', class="hl-string">'').lower():
                event_log.append(create_event(incident_id, class="hl-string">"Workaround Provided", activity_ts, ticket, source_system, last_data_update))
            
            class=class="hl-string">"hl-comment"># 10. Resolution Note Added
            if activity[class="hl-string">'activity_type'] == class="hl-string">'Note' and activity.get(class="hl-string">'note', {}).get(class="hl-string">'note_type') == class="hl-string">'resolution':
                event_log.append(create_event(incident_id, class="hl-string">"Resolution Note Added", activity_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 11. Incident Resolved
        if ticket.get(class="hl-string">'resolved_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Resolved", ticket[class="hl-string">'resolved_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 12. SLA Target Breached
        if ticket.get(class="hl-string">'sla_policy') and ticket[class="hl-string">'sla_policy'].get(class="hl-string">'violation_details', {}).get(class="hl-string">'resolution_sla', {}).get(class="hl-string">'is_violated'):
            breach_time = ticket[class="hl-string">'sla_policy'][class="hl-string">'violation_details'][class="hl-string">'resolution_sla'][class="hl-string">'due_by']
            event_log.append(create_event(incident_id, class="hl-string">"SLA Target Breached", breach_time, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 13. Incident Reopened
        if ticket.get(class="hl-string">'reopened'):
            class=class="hl-string">"hl-comment"># Finding the exact reopened timestamp can be tricky, we approximate from class="hl-string">'stats'
            reopen_ts = ticket.get(class="hl-string">'stats', {}).get(class="hl-string">'reopened_at', ticket[class="hl-string">'updated_at'])
            event_log.append(create_event(incident_id, class="hl-string">"Incident Reopened", reopen_ts, ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># 14. Incident Closed
        if ticket.get(class="hl-string">'closed_at'):
            event_log.append(create_event(incident_id, class="hl-string">"Incident Closed", ticket[class="hl-string">'closed_at'], ticket, source_system, last_data_update))

        class=class="hl-string">"hl-comment"># Be respectful of API rate limits
        time.sleep(1)

    class=class="hl-string">"hl-comment"># Convert to DataFrame and save
    if event_log:
        df = pd.DataFrame(event_log)
        df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(OUTPUT_FILENAME, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
        print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events for {df['IncidentId'].nunique()} incidents.")
        print(fclass="hl-string">"Event log saved to {OUTPUT_FILENAME}")
    else:
        print(class="hl-string">"No events were generated.")

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

Kroky

Ověřte, že váš tarif Freshservice a oprávnění správce umožňují používat pravidla Workflow Automator, akce webhooků, přístup k incidentům a historii aktivit požadavků. S přijímajícím týmem ověřte cílový endpoint, způsob ověřování, požadavky na TLS a zásady uchovávání dat.
Než nastavíte automatizaci, definujte formát události. Každé doručení webhooku musí obsahovat jeden objekt JSON s poli IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory a ResolutionSlaTargetTime. Nastavte příjemce tak, aby uchovával původní obsah webhooku i čas jeho doručení.
Vytvořte pravidlo Workflow Automator pro založení incidentu. Nastavte jeho spuštění při vytvoření incidentu a přidejte akci webhooku, která odešle aktivitu Incident Reported. Pole EventTimestamp nastavte na čas vytvoření incidentu a ActivityName na Incident Reported.
Vytvořte pravidla pro změny přiřazení, priority, stavu, komunikace, poznámek, SLA a uzavření. Podmínky nastavte podle polí incidentu a historie aktivit dostupných ve vašem účtu Freshservice. Každé pravidlo musí při odpovídající aktivitě odeslat samostatnou událost webhooku. Nespoléhejte na to, že ProcessMind odvodí aktivity z konečného snímku incidentu.
Nastavte jednoznačné mapování aktivit. Při prvním vyplnění pole Group odešlete Incident Assigned to Group, při prvním vyplnění pole Agent odešlete Agent Assigned to Incident a při nastavení nebo změně Priority odešlete Incident Prioritized. Aktivitu First Response Sent odešlete při zaznamenání první odpovídající veřejné odpovědi nebo poznámky řešitele. Změna pole Agent nebo Group po prvním přiřazení znamená Incident Reassigned. Odpovídající změny stavu mapujte na Status Changed to In Progress a Status Changed to Pending. Workaround Provided odešlete pouze tehdy, když je nastaven příslušný indikátor náhradního řešení. Při přidání poznámky k řešení odešlete Resolution Note Added, při změně stavu na Resolved Incident Resolved, při splnění nastavené podmínky porušení SLA SLA Target Breached, při změně stavu z Resolved na otevřený Incident Reopened a při změně stavu na Closed Incident Closed.
Nastavte tělo požadavku webhooku ve formátu JSON. Zahrňte identifikátor incidentu, název aktivity, čas události, zdrojový systém, čas poslední aktualizace dat a doporučené kontextové atributy. Použijte proměnné webhooku dostupné ve vašem účtu Freshservice. Pokud editor webhooku nenabízí požadovanou proměnnou, doplňte ji v přijímající službě prostřednictvím schváleného rozhraní Freshservice, nebo ponechte hodnotu prázdnou, místo abyste ji odhadovali.
Na endpointu nastavte idempotenci a zpracování doručení. Pokud Freshservice poskytuje stabilní identifikátor události, použijte jej. Jinak vytvořte deduplikační klíč z IncidentId, ActivityName, EventTimestamp a identifikátoru zdrojového doručení. Úspěšnou odpověď HTTP vraťte až poté, co bude obsah bezpečně uložen.
Otestujte každé pravidlo na testovacích incidentech. Založte incident, přiřaďte skupinu a řešitele, změňte prioritu a stav, odešlete odpovídající odpověď, přidejte náhradní řešení a poznámku k řešení, pokud jsou nastavené, a poté incident vyřešte, znovu otevřete a uzavřete. Porušení SLA otestujte samostatně pomocí testovací politiky nebo fronty. Ověřte, že každá očekávaná aktivita dorazí jako samostatný obsah webhooku.
Ukládejte obsah webhooků do trvalého úložiště pro přípravu dat, sjednoťte časová razítka do jednoho časového pásma a každý obsah převeďte na jeden řádek záznamu událostí. Zachovejte jeden řádek pro každou výslovně zaznamenanou aktivitu webhooku. LastDataUpdate vyplňujte časem aktualizace při extrakci nebo příjmu dat, nikoli časem obchodní události.
Ověřte připravený záznam událostí, odstraňte pouze přesné duplicity doručení a ponechte oprávněně opakované aktivity, například vícenásobné změny priority nebo stavu. Zkontrolujte, že každý řádek obsahuje IncidentId, ActivityName, EventTimestamp, SourceSystem a LastDataUpdate.
Exportujte normalizovaný záznam událostí do CSV nebo jiného formátu podporovaného ProcessMind. Použijte přesné názvy sloupců IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory a ResolutionSlaTargetTime. Nahrajte soubor nebo připojte připravený zdroj událostí k ProcessMind a namapujte IncidentId jako identifikátor případu a ActivityName jako pole aktivity.

Konfigurace

Rozsah spouštění: Nastavte samostatná pravidla Workflow Automator pro založení incidentu a každou podmínku aktualizace. Jedno obecné pravidlo pro aktualizace může vytvářet duplicitní nebo nejednoznačné události, pokud příjemce přesně nemapuje aktivity.
Obsah webhooku: V každém obsahu uveďte všechny povinné atributy. Pokud jsou v době události dostupné, přidejte i doporučené atributy. Původní obsah uchovejte pro audit a opakované zpracování.
Význam aktivit: První přiřazení skupiny a řešitele musí být odlišeno od pozdějších změn. Pozdější změny vytvářejí Incident Reassigned, první vyplnění odpovídající aktivitu prvního přiřazení.
Zpracování stavů: Mapujte přesné hodnoty stavů nastavené v účtu Freshservice. Pokud účet používá vlastní stavy čekání nebo otevření, nastavte pro ně konkrétní mapování.
První odpověď: Určete, zda se počítá veřejná odpověď, veřejná poznámka nebo jiný typ komunikace. Definici používejte jednotně a událost odešlete pouze při první odpovídající komunikaci u každého incidentu.
Rozpoznání náhradního řešení: Nastavte vyhrazené pole, zaškrtávací políčko, typ poznámky nebo schválené pravidlo pro klíčová slova. Bez takového nastavení nelze aktivitu Workaround Provided spolehlivě rozpoznat.
Porušení SLA: Nastavte výslovný spouštěč porušení SLA nebo samostatný plánovaný proces, který porovná aktuální čas s ResolutionSlaTargetTime. Z konečného snímku incidentu nelze čas porušení zpětně určit.
Časové období: Pro počáteční ověření použijte incidenty přibližně za poslední 3 až 6 měsíců. Při provozu v reálném čase začněte data přijímat před začátkem sledovaného období a uchovávejte historii webhooků pro opakované zpracování.
Filtry: Používejte pouze schválené filtry podle společnosti, pracovního prostoru, oddělení, služby, kategorie nebo data. Nepředpokládejte názvy polí ani syntaxi filtrů Freshservice, které nejsou dostupné v nastavení účtu.
Výkon: Zpracovávejte webhooky asynchronně, příchozí požadavky zařazujte do fronty, následné zápisy provádějte dávkově a indexujte IncidentId a EventTimestamp. Při příjmu webhooku se vyhněte synchronním voláním pro doplnění dat.
Spolehlivost: Nastavte opakované pokusy, zpracování nedoručených zpráv, monitorování a potlačení duplicit. Neúspěšná doručení zaznamenávejte a po opravě je zpracujte znovu.
Předpoklady: Přístup správce, dostupný Workflow Automator, oprávnění pro webhooky, endpoint HTTPS, nastavení ověřování, dostatečné možnosti tarifu Freshservice a kompatibilní postup pro ukládání nebo nahrávání dat do ProcessMind.
Zabezpečení: Používejte HTTPS, pokud možno omezte příchozí přístup, pravidelně měňte přihlašovací údaje, omezte citlivá pole a chraňte popisy incidentů a poznámky, pokud je zahrnete do obsahu webhooků.

Ukázkový dotaz config

const REQUIRED_ACTIVITIES = [
  "Incident Reported",
  "Incident Assigned to Group",
  "Agent Assigned to Incident",
  "Incident Prioritized",
  "First Response Sent",
  "Incident Reassigned",
  "Status Changed to In Progress",
  "Status Changed to Pending",
  "Workaround Provided",
  "Resolution Note Added",
  "Incident Resolved",
  "SLA Target Breached",
  "Incident Reopened",
  "Incident Closed"
];

const REQUIRED_COLUMNS = [
  "IncidentId",
  "ActivityName",
  "EventTimestamp",
  "SourceSystem",
  "LastDataUpdate",
  "AssignedAgent",
  "AssignedGroup",
  "IncidentPriority",
  "IncidentSeverity",
  "IncidentStatus",
  "IncidentCategory",
  "ResolutionSlaTargetTime"
];

function normalizeTimestamp(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  const date = new Date(value);
  if (Number.isNaN(date.getTime())) {
    throw new Error("Invalid timestamp: " + String(value));
  }
  return date.toISOString();
}

function textOrNull(value) {
  if (value === null || value === undefined || value === "") {
    return null;
  }
  return String(value);
}

function getField(payload, names) {
  for (const name of names) {
    if (payload[name] !== undefined && payload[name] !== null) {
      return payload[name];
    }
  }
  return null;
}

function normalizeWebhookPayload(payload, receivedAt) {
  const incidentId = getField(payload, ["IncidentId", "incident_id", "ticket_id", "id"]);
  const activityName = getField(payload, ["ActivityName", "activity_name"]);
  const eventTimestamp = getField(payload, ["EventTimestamp", "event_timestamp", "timestamp", "created_at", "updated_at"]);

  if (incidentId === null || incidentId === "") {
    throw new Error("IncidentId is required");
  }
  if (activityName === null || activityName === "") {
    throw new Error("ActivityName is required");
  }
  if (!REQUIRED_ACTIVITIES.includes(String(activityName))) {
    throw new Error("Unsupported ActivityName: " + String(activityName));
  }
  if (eventTimestamp === null || eventTimestamp === "") {
    throw new Error("EventTimestamp is required");
  }

  const row = {
    IncidentId: textOrNull(incidentId),
    ActivityName: textOrNull(activityName),
    EventTimestamp: normalizeTimestamp(eventTimestamp),
    SourceSystem: textOrNull(getField(payload, ["SourceSystem", "source_system"])) || "Freshservice",
    LastDataUpdate: normalizeTimestamp(getField(payload, ["LastDataUpdate", "last_data_update"])) || normalizeTimestamp(receivedAt),
    AssignedAgent: textOrNull(getField(payload, ["AssignedAgent", "assigned_agent", "agent"])),
    AssignedGroup: textOrNull(getField(payload, ["AssignedGroup", "assigned_group", "group"])),
    IncidentPriority: textOrNull(getField(payload, ["IncidentPriority", "incident_priority", "priority"])),
    IncidentSeverity: textOrNull(getField(payload, ["IncidentSeverity", "incident_severity", "severity"])),
    IncidentStatus: textOrNull(getField(payload, ["IncidentStatus", "incident_status", "status"])),
    IncidentCategory: textOrNull(getField(payload, ["IncidentCategory", "incident_category", "category"])),
    ResolutionSlaTargetTime: normalizeTimestamp(getField(payload, ["ResolutionSlaTargetTime", "resolution_sla_target_time"]))
  };

  for (const column of REQUIRED_COLUMNS) {
    if (!(column in row)) {
      throw new Error("Missing output column: " + column);
    }
  }
  return row;
}

function deduplicateRows(rows) {
  const seen = new Set();
  return rows.filter((row) => {
    const key = [
      row.IncidentId,
      row.ActivityName,
      row.EventTimestamp,
      row.SourceSystem
    ].join("|");
    if (seen.has(key)) {
      return false;
    }
    seen.add(key);
    return true;
  });
}

async function processWebhookBatch(webhookPayloads, receivedAt) {
  const rows = webhookPayloads.map((payload) => normalizeWebhookPayload(payload, receivedAt));
  const deduplicatedRows = deduplicateRows(rows);
  deduplicatedRows.sort((left, right) => {
    if (left.IncidentId !== right.IncidentId) {
      return left.IncidentId.localeCompare(right.IncidentId);
    }
    return left.EventTimestamp.localeCompare(right.EventTimestamp);
  });
  return deduplicatedRows;
}

module.exports = {
  REQUIRED_ACTIVITIES,
  REQUIRED_COLUMNS,
  normalizeWebhookPayload,
  deduplicateRows,
  processWebhookBatch
};

Chcete začít?

Pomocí této šablony správně připravíte data a získáte užitečný přehled o workflow správy incidentů. Začněte zkracovat dobu řešení ještě dnes.

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

Stáhnout šablonu

Předcházejte nedodržení SLA a zlepšete správu incidentů

Přidejte se k firmám, které zkracují MTTR o 35 % a předcházejí nákladnému nedodržení SLA.

Spustit bezplatnou zkušební verzi

Zkušební verze na 14 dní zdarma, bez nutnosti zadávat platební kartu.

Šablona dat pro správu incidentů

Šablona dat pro správu incidentů

Atributy správy incidentů

Aktivity při správě incidentů

Návody k extrakci dat

Export dat z modulu Freshservice Analytics do CSV

Kroky

Konfigurace

Ukázkový dotaz config

Extrakce pomocí Python skriptu přes Freshservice REST API

Kroky

Konfigurace

Ukázkový dotaz python

Předávání dat v reálném čase pomocí webhooků Workflow Automator

Kroky

Konfigurace

Ukázkový dotaz config

Chcete začít?

Předcházejte nedodržení SLA a zlepšete správu incidentů