> Ciągłe doskonalenie procesów > Zarządzanie incydentami > Freshservice > Szablon danych

Szablon danych do zarządzania incydentami

Freshservice

← Wróć do przewodnika ulepszania procesów

Atrybuty zarządzania incydentami(19) Działania w procesie obsługi incydentów(14) Instrukcje ekstrakcji danych(3)

Szablon danych do zarządzania incydentami

Ten szablon ułatwia przygotowanie danych do analizy obsługi incydentów. Zawiera listę najważniejszych atrybutów do zebrania i działań do śledzenia, a także praktyczne wskazówki dotyczące pobierania tych informacji z systemu źródłowego. Dzięki niemu można sprawniej przygotować dane do analizy.

Zalecane atrybuty do zebrania
Najważniejsze działania do śledzenia
Wskazówki dotyczące ekstrakcji danych

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty zarządzania incydentami

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować proces obsługi incydentów.

5 Wymagane 7 Zalecane 7 Opcjonalne

	Nazwa	Opis
	Identyfikator incydentu IncidentId	Unikalny identyfikator rekordu incydentu, używany jako klucz główny do śledzenia całego cyklu życia incydentu.
Opis Identyfikator incydentu stanowi podstawę analizy zarządzania incydentami. Pełni funkcję identyfikatora sprawy i łączy powiązane czynności, znaczniki czasu oraz zmiany atrybutów w jedną historię. W process mining każdy wpis w dzienniku zdarzeń jest powiązany z identyfikatorem incydentu. Dzięki temu można odtworzyć przebieg procesu od początku do końca dla każdego incydentu. Jest to niezbędne do obliczania czasu cyklu, analizowania wariantów procesu i wykrywania wąskich gardeł w poszczególnych sprawach. Bez unikalnego identyfikatora nie dałoby się odróżnić incydentów ani prześledzić ich przebiegu od zgłoszenia do rozwiązania. Dlaczego to ważne Jednoznacznie identyfikuje każdy incydent, umożliwiając śledzenie i analizę całego jego cyklu życia, od utworzenia do zamknięcia. Skąd pobrać To podstawowy identyfikator zgłoszenia. W Freshservice Tickets API jest dostępny w obiekcie zgłoszenia jako pole „id”. Przykłady INC-10234INC-10235INC-10236
	Nazwa czynności ActivityName	Nazwa konkretnej czynności biznesowej lub zdarzenia, które wystąpiło w danym momencie cyklu życia incydentu.
Opis Nazwa czynności opisuje pojedynczy krok lub zdarzenie w procesie zarządzania incydentami, na przykład „Przypisanie incydentu do grupy”, „Zmiana statusu na oczekujący” lub „Rozwiązanie incydentu”. Czynności te są wyznaczane na podstawie zmian danych incydentu w czasie. Ten atrybut ma podstawowe znaczenie dla process mining, ponieważ określa węzły na odkrytej mapie procesu. Analiza kolejności i częstotliwości czynności pozwala zobrazować rzeczywisty przebieg rozwiązywania incydentów, wykryć typowe ścieżki i odstępstwa od standardowej procedury oraz wskazać pętle ponownej pracy, takie jak częste ponowne przypisania. Dlaczego to ważne Określa kroki na mapie procesu, dzięki czemu można zobrazować i analizować przebieg rozwiązywania incydentów, wąskie gardła oraz odstępstwa. Skąd pobrać Ten atrybut nie jest bezpośrednim polem w Freshservice. Wyznacza się go na podstawie zmian właściwości zgłoszenia, takich jak status, priorytet, przypisanie agenta lub grupy oraz dodanie notatek. Przykłady Zgłoszono incydentPrzypisano incydent do grupyDodano notatkę o rozwiązaniuRozwiązano incydent
	Ostatnia aktualizacja danych LastDataUpdate	Znacznik czasu wskazujący, kiedy dane dotyczące procesu zostały ostatnio odświeżone lub pobrane.
Opis Ten atrybut zawiera znacznik czasu ostatniej aktualizacji całego zbioru danych z systemu źródłowego. To pole metadanych dotyczy całego zbioru, a nie poszczególnych zdarzeń, ale dla zachowania spójności często umieszcza się je na poziomie zdarzenia. Informacja ta pozwala ocenić aktualność danych i ustalić, jaki okres obejmują dashboardy i KPI. Dzięki niej użytkownicy wiedzą, jak świeże są wyniki i czy analiza uwzględnia najnowsze incydenty. Dlaczego to ważne Informuje o aktualności danych i pozwala ustalić, jaki okres obejmuje analiza. Skąd pobrać To znacznik czasu w metadanych, generowany podczas pobierania danych (ETL). Przykłady 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	System źródłowy SourceSystem	System, z którego pobrano dane, zazwyczaj „Freshservice”.
Opis Ten atrybut wskazuje źródło danych. W tym przypadku będzie to zawsze „Freshservice”, ale pole jest istotne w środowiskach, w których łączy się dane z wielu systemów, aby uzyskać pełny obraz procesu. Uwzględnienie atrybutu systemu źródłowego to dobra praktyka w zakresie zarządzania danymi i ich identyfikowalności. Pozwala ustalić pochodzenie danych, co ułatwia ich weryfikację i rozwiązywanie problemów. Przydaje się też przy rozszerzaniu projektu process mining o inne systemy do zarządzania usługami lub operacjami. Dlaczego to ważne Ułatwia identyfikowalność danych i zarządzanie nimi, ponieważ jasno wskazuje źródło danych dotyczących zarządzania incydentami. Skąd pobrać Zazwyczaj jest to stała wartość dodawana podczas transformacji danych (ETL) w celu oznaczenia zbioru danych. Przykłady FreshserviceFreshservice-EUFreshservice-PROD
	Znacznik czasu zdarzenia EventTimestamp	Dokładna data i godzina wystąpienia czynności lub zdarzenia.
Opis Znacznik czasu zdarzenia, czyli czas rozpoczęcia, wskazuje dokładny moment wykonania czynności. Każda czynność w cyklu życia incydentu, od utworzenia do zamknięcia, ma przypisany znacznik czasu. Ten atrybut jest niezbędny w analizach process mining opartych na czasie. Służy do porządkowania zdarzeń chronologicznie, obliczania czasu między czynnościami, mierzenia całkowitego czasu cyklu sprawy i analizowania czasu oczekiwania. Jest też podstawą dashboardów monitorujących realizację SLA, opóźnienia przy przekazywaniu obsługi i łączny czas rozwiązania. Dlaczego to ważne Pozwala ustalić chronologiczną kolejność zdarzeń, niezbędną do obliczania czasu trwania, analizy czasu cyklu i oceny przebiegu procesu. Skąd pobrać Wartość wyznacza się na podstawie różnych pól ze znacznikami czasu w Freshservice, takich jak „created_at” i „updated_at”, oraz znaczników czasu w konwersacji lub dziennikach audytowych zgłoszenia. Przykłady 2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
	Docelowy czas rozwiązania według SLA ResolutionSlaTargetTime	Znacznik czasu określający termin rozwiązania incydentu zgodnie z obowiązującą polityką SLA.
Opis Ten atrybut przechowuje dokładną datę i godzinę, do której należy rozwiązać incydent. Termin wynika z umowy o gwarantowanym poziomie świadczenia usług (SLA) przypisanej do zgłoszenia i zazwyczaj zależy między innymi od priorytetu. Docelowy czas jest niezbędny do obliczania KPI „Odsetek realizacji SLA” i zasilania dashboardu „Wyniki SLA”. Porównanie rzeczywistego czasu rozwiązania z terminem pozwala ustalić, czy incydent rozwiązano na czas, czy doszło do naruszenia SLA. To podstawa pomiaru zgodności z poziomem usług. Dlaczego to ważne Określa termin rozwiązania, niezbędny do obliczania zgodności z SLA i wykrywania incydentów zagrożonych opóźnieniem. Skąd pobrać Dostępny w Freshservice Tickets API jako pola „fr_due_by” (pierwsza odpowiedź) i „due_by” (rozwiązanie). Przykłady 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-05T17:00:00Z
	Kategoria incydentu IncidentCategory	Kategoria używana do klasyfikowania incydentu, na przykład sprzęt, oprogramowanie lub sieć.
Opis Kategoria incydentu pozwala klasyfikować zgłoszenia według rodzaju problemu. Taka hierarchiczna klasyfikacja ułatwia przekazanie incydentu do właściwego zespołu i analizę trendów. Atrybut ten służy w dashboardzie „Dokładność kategoryzacji incydentów” do sprawdzania, czy błędna kategoryzacja na początku procesu wydłuża czas rozwiązania z powodu ponownych przypisań. Grupowanie incydentów według kategorii pozwala wykrywać powtarzające się problemy, ustalić, na co zespół wsparcia poświęca najwięcej czasu, i odpowiednio zaplanować usprawnienia. Dlaczego to ważne Umożliwia analizę trendów dotyczących incydentów i pomaga ustalić, czy błędna kategoryzacja opóźnia ich rozwiązanie. Skąd pobrać To domyślne pole w Freshservice, które można dostosować. Jest dostępne w Tickets API jako „category”, a powiązane pola to „sub_category” i „item_category”. Przykłady SprzętOprogramowanieProblem z sieciąDostęp do konta
	Priorytet incydentu IncidentPriority	Poziom priorytetu incydentu, który określa pilność odpowiedzi i rozwiązania.
Opis Priorytet incydentu określa wymagane tempo i zakres działań związanych z jego obsługą. Zazwyczaj przyjmuje wartości takie jak niski, średni, wysoki i pilny, a często wpływa też na cele SLA. W process mining priorytet jest ważnym wymiarem filtrowania i analizy. Pozwala porównać procesy rozwiązywania incydentów o wysokim i niskim priorytecie oraz sprawdzić, czy krytyczne problemy są obsługiwane sprawnie. Dashboardy często pokazują czas cyklu i realizację SLA w podziale na priorytety, dostarczając kierownikom wsparcia informacji przydatnych w podejmowaniu decyzji. Dlaczego to ważne Pozwala skupić analizę na najpilniejszych incydentach i jest niezbędny do oceny realizacji SLA oraz przydziału zasobów. Skąd pobrać Dostępny w Freshservice Tickets API jako pole „priority”. Wartości są liczbowe, na przykład 1 oznacza niski priorytet, a 4 pilny. Przykłady NiskiŚredniWysokiPilny
	Przypisana grupa AssignedGroup	Grupa wsparcia lub zespół, któremu przypisano obsługę incydentu.
Opis Przypisana grupa wskazuje zespół odpowiedzialny za incydent, na przykład „Wsparcie pierwszej linii”, „Zespół sieci” lub „Administratorzy baz danych”. Zmiana tego atrybutu oznacza eskalację lub przekazanie sprawy między zespołami o różnych kompetencjach. Analiza przypisanej grupy pomaga zrozumieć opóźnienia przy przekazywaniu spraw. Process mining pozwala zobrazować przepływ incydentów między grupami, wskazać typowe ścieżki eskalacji i zmierzyć czas oczekiwania na podjęcie działania przez każdą grupę. Ułatwia to wykrywanie wąskich gardeł w organizacji i możliwości usprawnienia współpracy między zespołami. Dlaczego to ważne Pokazuje, który zespół odpowiada za incydent, co ma znaczenie przy analizie przekazań, eskalacji i opóźnień między zespołami. Skąd pobrać Dostępny w Freshservice Tickets API jako pole „group_id”. Ten identyfikator można połączyć z Groups API, aby uzyskać nazwę grupy. Przykłady Centrum obsługi ITOperacje siecioweWsparcie infrastruktury
	Przypisany agent AssignedAgent	Imię i nazwisko lub identyfikator agenta wsparcia, któremu przypisano rozwiązanie incydentu.
Opis Przypisany agent to pracownik service desk odpowiedzialny za incydent w danym momencie. Zmiany tego atrybutu oznaczają przekazanie odpowiedzialności między agentami. Atrybut ten jest niezbędny do analizy efektywności. Pozwala tworzyć dashboardy pokazujące obciążenie agentów, średni czas rozwiązania incydentu przez agenta i odsetek spraw rozwiązanych przy pierwszym kontakcie. Ułatwia też analizę przekazań między agentami, które mogą powodować opóźnienia i obniżać efektywność. Śledzenie przypisań pomaga kierownikom określić potrzeby szkoleniowe i docenić członków zespołu osiągających dobre wyniki. Dlaczego to ważne Umożliwia analizę efektywności agentów, rozkładu obciążenia pracą oraz wpływu przekazywania spraw na czas rozwiązania. Skąd pobrać Dostępny w Freshservice Tickets API jako pole „responder_id”. Ten identyfikator można połączyć z Agents API, aby uzyskać imię i nazwisko agenta. Przykłady Jan KowalskiAnna NowakSupportBot
	Status incydentu IncidentStatus	Bieżący status incydentu w jego cyklu życia, na przykład „Open”, „Pending”, „Resolved” lub „Closed”.
Opis Status incydentu wskazuje jego bieżący stan. Zmiany statusu są ważnymi zdarzeniami, na których opiera się odkryta mapa procesu, na przykład przejście z „In Progress” do „Pending” lub z „Resolved” do „Closed”. Ten atrybut pomaga zrozumieć przebieg incydentu. Analiza czasu spędzonego w każdym statusie pozwala wykryć wąskie gardła, na przykład incydenty zbyt długo oczekujące na odpowiedź użytkownika. Status jest też niezbędny do określenia początku i końca przy obliczaniu czasu cyklu. Dlaczego to ważne Pozwala śledzić przebieg incydentu i wskazywać etapy, na których często dochodzi do opóźnień. Skąd pobrać Dostępny w Freshservice Tickets API jako pole „status”. Wartości są liczbowe. Przykłady OtwarteW trakcieOczekująceRozwiązaneZamknięte
	Waga incydentu IncidentSeverity	Poziom wagi incydentu, wskazujący jego wpływ na działalność firmy.
Opis Waga incydentu określa jego wpływ na działalność firmy. Zazwyczaj przyjmuje wartości: niska, średnia, wysoka lub krytyczna. Waga jest powiązana z priorytetem, ale opisuje wpływ, podczas gdy priorytet określa pilność. Ostateczny priorytet często zależy od wagi i wpływu incydentu. Analiza według wagi pozwala ocenić, jak organizacja radzi sobie z incydentami o poważnych konsekwencjach biznesowych. Dashboardy wykorzystują ten atrybut do podziału czasu rozwiązania i realizacji SLA, aby sprawdzić, czy najpoważniejsze problemy otrzymują odpowiednią uwagę i zasoby przez cały cykl życia. Dlaczego to ważne Mierzy wpływ incydentu na działalność firmy, dzięki czemu można skupić analizę na problemach powodujących największe straty. Skąd pobrać To domyślne pole w Freshservice, dostępne w Tickets API jako „impact”. Wartości są liczbowe. Przykłady NiskiŚredniWysoki
	Czy doszło do naruszenia SLA IsSlaBreached	Obliczany wskaźnik przyjmuje wartość prawda, jeśli incydentu nie rozwiązano w wyznaczonym terminie SLA.
Opis Ten atrybut logiczny jest obliczanym wskaźnikiem, który informuje, czy czas rozwiązania incydentu przekroczył termin SLA. Wyznacza się go przez porównanie rzeczywistego znacznika czasu rozwiązania z polem „ResolutionSlaTargetTime”. Wskaźnik ten bezpośrednio zasila KPI „Odsetek realizacji SLA” i dashboard „Wyniki SLA”. Upraszcza analizę, ponieważ dla każdego incydentu pokazuje jednoznaczny wynik realizacji SLA. Ułatwia agregowanie danych, analizę trendów oraz szybkie ustalenie liczby i odsetka incydentów, które nie spełniły zobowiązań dotyczących poziomu usług. Dlaczego to ważne Bezpośrednio mierzy zgodność z SLA dla każdego incydentu, ułatwiając obliczanie ogólnego poziomu realizacji i wskazywanie problematycznych obszarów. Skąd pobrać To pole obliczane podczas transformacji danych przez porównanie znacznika czasu zdarzenia „Incident Resolved” z polem „ResolutionSlaTargetTime”. Przykłady truefalse
	Czy ponownie otwarto IsReopened	Obliczany wskaźnik przyjmuje wartość prawda, jeśli incydent ponownie otwarto po jego rozwiązaniu lub zamknięciu.
Opis Ten atrybut logiczny wskazuje incydenty, które zostały ponownie otwarte. Przyjmuje wartość prawda, jeśli po zmianie statusu incydentu na „Resolved” lub „Closed” status wrócił do stanu otwartego lub „In Progress”. Wskaźnik ten jest niezbędny do obliczania KPI „Odsetek ponownie otwartych incydentów” i zasilania dashboardu „Powtarzające się incydenty”. Wysoki odsetek może wskazywać na niską jakość początkowego rozwiązania, niepełną analizę przyczyny źródłowej lub przedwczesne zamknięcie. Analiza takich przypadków pomaga poprawić jakość i trwałość rozwiązań. Dlaczego to ważne Wskazuje problemy w procesie rozwiązywania incydentów, pokazując przypadki, w których początkowa poprawka nie zadziałała i konieczna była ponowna praca. Skąd pobrać To pole obliczane na podstawie sekwencji czynności w dzienniku zdarzeń. Przyjmuje wartość prawda, jeśli wystąpi czynność taka jak „Ponowne otwarcie incydentu” albo jeśli po czynności oznaczającej zamknięcie dla tego samego identyfikatora incydentu pojawi się czynność wskazująca stan otwarty. Przykłady truefalse
	Dział zgłaszającego RequestersDepartment	Dział, do którego należy użytkownik zgłaszający incydent.
Opis Ten atrybut wskazuje dział zgłaszającego, na przykład sprzedaż, finanse lub IT. Informacje te są zazwyczaj pobierane z profilu użytkownika w Freshservice. Analiza incydentów według działu zgłaszającego może wykazać, czy niektóre jednostki biznesowe są szczególnie narażone na problemy lub czy występują trudności charakterystyczne dla danego działu. Daje to kontekst biznesowy i pomaga ustalać priorytety napraw dotyczących działów o szczególnym znaczeniu. Dlaczego to ważne Dostarcza kontekstu biznesowego i pozwala analizować trendy dotyczące incydentów oraz ich wpływ na poszczególne działy. Skąd pobrać Informacja jest powiązana ze zgłaszającym. Można ją pobrać z punktu końcowego API „Requesters”, używając pola „requester_id” ze zgłoszenia, a następnie odczytując „department_id” i nazwę działu. Przykłady SprzedażMarketingFinanseZasoby ludzkie
	Kanał zgłoszenia ReportingChannel	Sposób lub kanał, za pośrednictwem którego zgłoszono incydent, na przykład e-mail, portal lub telefon.
Opis Kanał zgłoszenia, nazywany też źródłem, wskazuje, w jaki sposób incydent trafił do systemu wsparcia. Typowe kanały to e-mail, portal samoobsługowy, telefon i czat. Analiza tego atrybutu pomaga ocenić skuteczność poszczególnych kanałów. Dashboard „Efektywność kanałów zgłoszeń” porównuje liczbę incydentów i średni czas ich rozwiązania w podziale na kanały. Pozwala ustalić, które metody sprawdzają się najlepiej, a które wymagają usprawnień. Na przykład zgłoszenia z portalu mogą być rozwiązywane szybciej, jeśli od początku zawierają bardziej uporządkowane informacje. Dlaczego to ważne Pomaga wskazać najskuteczniejsze kanały zgłoszeń i możliwości usprawnienia przyjmowania incydentów. Skąd pobrać Dostępny w Freshservice Tickets API jako pole „source”. Wartości są liczbowe. Przykłady E-mailPortalTelefonCzat
	Liczba przekazań obsługi HandoffCount	Liczba przekazań incydentu między agentami lub grupami.
Opis Liczba przekazań obsługi to obliczany wskaźnik określający, ile razy zmieniono przypisanie incydentu w jego cyklu życia. Każda zmiana atrybutu „AssignedAgent” lub „AssignedGroup” zwiększa tę wartość. Duża liczba przekazań często wskazuje na nieefektywny proces, błędne początkowe przypisanie lub brak odpowiednich kompetencji agenta. Wskaźnik ten zasila KPI „Liczba przekazań incydentu” i dashboard „Analiza opóźnień przy przekazywaniu obsługi”. Pomaga wskazać incydenty lub ścieżki procesu, w których częste przekazania powodują opóźnienia. Dlaczego to ważne Pozwala zmierzyć ponowną pracę i liczbę ponownych przypisań oraz wykryć problemy wynikające z błędnego kierowania zgłoszeń lub braków wiedzy. Skąd pobrać To obliczany wskaźnik, który wyznacza się, zliczając różne wartości lub zmiany pól „AssignedAgent” i „AssignedGroup” w cyklu życia pojedynczego incydentu. Przykłady 0125
	Przekazano obejście WorkaroundProvided	Wskaźnik określający, czy użytkownik otrzymał tymczasowe obejście problemu przed ostatecznym rozwiązaniem.
Opis Ten atrybut logiczny wskazuje, czy wdrożono tymczasową poprawkę lub obejście, aby ograniczyć wpływ incydentu podczas opracowywania trwałego rozwiązania. Informacja ta jest często rejestrowana za pomocą pola wyboru lub określonego statusu. W process mining atrybut ten służy w dashboardzie „Wskaźniki skuteczności obejść problemów”. Pozwala porównać czas rozwiązania incydentów z obejściem i bez niego. Dzięki temu można ocenić, czy tymczasowe poprawki skutecznie ograniczają zakłócenia w działalności firmy i skracają czas rozwiązania odczuwany przez użytkownika. Dlaczego to ważne Pomaga ocenić, czy tymczasowe obejścia ograniczają wpływ incydentu i pozwalają użytkownikowi szybciej odczuć poprawę. Skąd pobrać Zazwyczaj jest to niestandardowe pole logiczne (pole wyboru). Należy sprawdzić, czy istnieje w konfiguracji „Ticket Fields” w Freshservice. Przykłady truefalse
	Przyczyna źródłowa RootCause	Podstawowa przyczyna incydentu ustalona po przeprowadzeniu analizy.
Opis Atrybut „Przyczyna źródłowa” wskazuje problem, który doprowadził do incydentu. Zazwyczaj agenci wsparcia uzupełniają tę informację podczas rozwiązywania incydentu lub po jego zakończeniu, w ramach analizy przyczyny źródłowej (RCA). Atrybut ten jest niezbędny w dashboardzie „Powtarzające się incydenty i ich przyczyny” oraz przy obliczaniu KPI „Odsetek ukończonych analiz przyczyn źródłowych”. Analiza najczęstszych przyczyn pozwala przejść od doraźnego usuwania incydentów do proaktywnego zarządzania problemami. Umożliwia wdrażanie trwałych rozwiązań, które zapobiegają kolejnym incydentom i ograniczają powtarzające się problemy. Dlaczego to ważne Ułatwia proaktywne zarządzanie problemami przez wskazywanie i eliminowanie przyczyn powtarzających się incydentów. Skąd pobrać Często jest to pole niestandardowe w Freshservice, ponieważ domyślne funkcje mogą być ograniczone. W konfiguracji „Ticket Fields” należy sprawdzić, czy istnieje pole „Root Cause” lub podobne. Przykłady Błąd oprogramowaniaBłąd konfiguracji sieciProblem ze szkoleniem użytkownikaAwaria sprzętu

Wymagane Zalecane Opcjonalne

Działania w procesie obsługi incydentów

To najważniejsze kroki i punkty kontrolne, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu i identyfikować wąskie gardła.

7 Zalecane 7 Opcjonalne

	Działanie	Opis
	Dodano notatkę o rozwiązaniu	Zdarzenie występuje, gdy agent dokumentuje rozwiązanie incydentu, dodając notatkę. W Freshservice jest to osobne działanie wykonywane przed zmianą statusu na „Rozwiązany”. Działanie i treść notatki są rejestrowane.
Dlaczego to ważne To zdarzenie oznacza ustalenie rozwiązania. Czas między dodaniem notatki a zmianą statusu na „Rozwiązany” może wskazywać na dodatkowy czas potrzebny na wewnętrzną weryfikację lub dokumentację. Skąd pobrać Dane pochodzą ze znacznika czasu dodania notatki o rozwiązaniu do incydentu. Jest on rejestrowany w historii rozmowy. Rejestrowanie Znajdź znacznik czasu wpisu „Notatka o rozwiązaniu” w historii rozmowy dotyczącej incydentu. Typ zdarzenia explicit
	Przypisano incydent do grupy	Oznacza pierwsze przypisanie incydentu do grupy wsparcia. Może ono nastąpić automatycznie na podstawie reguł kierowania zgłoszeń lub ręcznie przez dyspozytora. Zdarzenie można wykryć, śledząc pierwsze wypełnienie pola „Grupa” w dzienniku audytu incydentu.
Dlaczego to ważne Śledzenie przypisań pozwala mierzyć czas pierwszej reakcji i wykrywać wąskie gardła w procesie kierowania zgłoszeń. Ułatwia ocenę, jak sprawnie incydenty trafiają do właściwego zespołu. Skąd pobrać Zdarzenie można ustalić na podstawie pierwszego wpisu w dzienniku aktywności incydentu, który wypełnia lub zmienia pole „Grupa”. Rejestrowanie Znajdź pierwszy znacznik czasu, przy którym wypełniono pole „Grupa” dla incydentu. Typ zdarzenia inferred
	Rozwiązano incydent	Oznacza moment, w którym agent wdrożył poprawkę i uznaje incydent za rozwiązany. Zdarzenie występuje, gdy status incydentu zmienia się na „Rozwiązany”. W Freshservice jest to ważny etap, który zatrzymuje zegar SLA.
Dlaczego to ważne To ważny etap przy mierzeniu czasu rozwiązania (TTR). Okres między zmianą statusu na „Rozwiązany” a zamknięciem zgłoszenia pomaga analizować opóźnienia w potwierdzaniu rozwiązania przez użytkownika i zasady automatycznego zamykania. Skąd pobrać Zdarzenie można ustalić na podstawie dziennika aktywności incydentu, sprawdzając, kiedy pole „Status” zmieniono na „Rozwiązany”. Rejestrowanie Użyj znacznika czasu wpisu w dzienniku aktywności dotyczącego zmiany statusu na „Rozwiązany”. Typ zdarzenia inferred
	Ustalono priorytet incydentu	Zdarzenie występuje, gdy priorytet incydentu zostaje ustawiony lub zmieniony. Poziom priorytetu określa pilność obsługi i cele SLA dotyczące rozwiązania. Zdarzenie można wykryć, śledząc zmiany pola „Priorytet” w historii incydentu.
Dlaczego to ważne Błędne lub opóźnione ustalenie priorytetu może prowadzić do przekroczenia SLA i nieefektywnego przydziału zasobów. Analiza tego zdarzenia pomaga zapewnić natychmiastową obsługę incydentów krytycznych. Skąd pobrać Zdarzenie można ustalić na podstawie dziennika aktywności incydentu, który rejestruje wszystkie zmiany pola „Priorytet”. Rejestrowanie Użyj znaczników czasu z dziennika audytu, przy których ustawiono lub zmieniono wartość pola „Priorytet”. Typ zdarzenia inferred
	Zamknięcie incydentu	Oznacza formalne, ostateczne zamknięcie rekordu incydentu. Zwykle następuje automatycznie po upływie określonego czasu w statusie „Resolved”, ale agent może też zamknąć incydent ręcznie. To zdarzenie kończy cykl życia incydentu.
Dlaczego to ważne Ta czynność stanowi ostateczny koniec procesu. Czas do jej wystąpienia obejmuje cały cykl życia incydentu, w tym okres oczekiwania na potwierdzenie użytkownika. Skąd pobrać Ustala się to na podstawie dziennika aktywności incydentu, sprawdzając, kiedy pole „Status” zmieniło wartość na „Closed”. Rejestrowanie Należy użyć znacznika czasu z wpisu w dzienniku aktywności dotyczącego zmiany statusu na „Closed”. Typ zdarzenia inferred
	Zgłoszono incydent	Utworzenie nowego rekordu incydentu w Freshservice. To początek cyklu życia incydentu. Zgłoszenie zwykle tworzy użytkownik końcowy przez portal lub e-mail albo agent centrum obsługi, działając w jego imieniu. Zdarzenie jest rejestrowane wraz ze znacznikiem czasu utworzenia.
Dlaczego to ważne To podstawowe zdarzenie rozpoczynające cały proces. Analiza czasu od tego momentu do rozwiązania incydentu pozwala mierzyć łączny czas obsługi i realizację SLA. Skąd pobrać Dane pochodzą ze znacznika czasu utworzenia w tabeli incydentów. Freshservice rejestruje go dla każdego nowego zgłoszenia. Rejestrowanie Użyj znacznika czasu „Utworzono” z głównego rekordu incydentu. Typ zdarzenia explicit
	Zmieniono status na „W toku”	To zdarzenie oznacza formalne rozpoczęcie aktywnej analizy i pracy nad incydentem. Występuje, gdy agent zmienia status incydentu na „W toku”. Jest to standardowa zmiana statusu rejestrowana w historii aktywności zgłoszenia.
Dlaczego to ważne Ten etap pozwala odróżnić czas oczekiwania od czasu aktywnej pracy. Analiza czasu, przez jaki incydent ma status „W toku”, pomaga ocenić nakład pracy potrzebny do jego rozwiązania. Skąd pobrać Zdarzenie można ustalić na podstawie dziennika aktywności incydentu, sprawdzając, kiedy pole „Status” zmieniono na „W toku”. Rejestrowanie Przefiltruj dziennik aktywności, aby znaleźć zmianę statusu na „W toku”, i użyj jej znacznika czasu. Typ zdarzenia inferred
	Ponowne otwarcie incydentu	Zdarzenie występuje, gdy incydent oznaczony wcześniej jako „Resolved” wraca do statusu otwartego, zwykle dlatego, że użytkownik nie akceptuje rozwiązania. Można je rozpoznać po zmianie statusu z „Resolved” na „Open” lub „In Progress”.
Dlaczego to ważne Wysoki odsetek ponownie otwartych incydentów może wskazywać na problemy z jakością rozwiązania lub niekompletne poprawki. To ważny wskaźnik przy analizie ponownej pracy i efektywności agentów. Skąd pobrać Ustala się to na podstawie dziennika aktywności incydentu, wykrywając zmianę statusu z „Resolved” na status aktywny. Rejestrowanie W dzienniku aktywności należy wyszukać zmianę pola „Status” z „Resolved” na „Open” lub „In Progress”. Typ zdarzenia inferred
	Ponownie przypisano incydent	Oznacza przekazanie incydentu innemu agentowi lub grupie. Jest to przekazanie sprawy w toku jej rozwiązywania. Zdarzenie można wykryć, śledząc kolejne zmiany pól „Agent” lub „Grupa” po pierwszym przypisaniu.
Dlaczego to ważne Częste ponowne przypisania, czyli przekazania sprawy, często wskazują na nieefektywność procesu, braki w wiedzy lub błędne przypisanie początkowe. Analiza tych zdarzeń pomaga wykrywać i ograniczać opóźnienia. Skąd pobrać Zdarzenie można ustalić na podstawie dziennika aktywności incydentu, śledząc każdą zmianę pól „Agent” lub „Grupa” po pierwszym przypisaniu. Rejestrowanie Wykryj zmiany pól „Agent” lub „Grupa” w historii audytu zgłoszenia. Typ zdarzenia inferred
	Przekazano obejście	To zdarzenie oznacza przekazanie użytkownikowi tymczasowego rozwiązania, które ogranicza skutki incydentu. Jego rejestrowanie może wymagać odpowiedniej konfiguracji systemu, na przykład dedykowanego pola wyboru, określonego typu notatki lub wyszukiwania słów kluczowych w notatkach agentów.
Dlaczego to ważne Analiza tego zdarzenia pomaga ocenić, czy obejścia ograniczają wpływ incydentu na działalność firmy i jak wiążą się z czasem jego ostatecznego rozwiązania. Wspiera dashboard wskaźników skuteczności obejść. Skąd pobrać To zdarzenie prawdopodobnie nie jest rejestrowane wprost. Można je ustalić, oznaczając notatki zawierające słowa takie jak „obejście” albo śledząc zmianę niestandardowego pola wyboru „Przekazano obejście”. Rejestrowanie Zdarzenie można ustalić na podstawie zmiany niestandardowego pola lub analizy słów kluczowych w notatkach agentów. Typ zdarzenia inferred
	Przekroczono cel SLA	To zdarzenie obliczane, które występuje, gdy czas obsługi incydentu przekracza określony cel SLA dotyczący reakcji lub rozwiązania. Freshservice wewnętrznie śledzi status SLA. Zdarzenie można ustalić, porównując znaczniki czasu z zasadami SLA.
Dlaczego to ważne Zdarzenie bezpośrednio mierzy realizację zobowiązań dotyczących poziomu usług. Ustalenie, kiedy i dlaczego dochodzi do przekroczeń, jest niezbędne do monitorowania wyników SLA i ciągłego doskonalenia. Skąd pobrać Ustala się to przez porównanie znacznika czasu rozwiązania lub odpowiedzi z terminem określonym w SLA. Freshservice często oznacza zgłoszenia statusem „SLA Violated”. Rejestrowanie Ustala się to przez porównanie znaczników czasu „Resolved at” i „Due by” albo wykrycie zmiany pola „SLA Status” na „Violated”. Typ zdarzenia calculated
	Przypisano agenta do incydentu	To zdarzenie oznacza przypisanie konkretnego agenta do obsługi incydentu, czyli wskazanie osoby odpowiedzialnej za zgłoszenie. Historia aktywności zgłoszenia zawiera informację, komu i kiedy je przypisano.
Dlaczego to ważne Dane te pozwalają analizować obciążenie agentów, ich wyniki oraz czas od przypisania incydentu do grupy do podjęcia go przez konkretnego agenta. Są też niezbędne do tworzenia dashboardów dotyczących pracy agentów. Skąd pobrać Zdarzenie można śledzić na podstawie zmian pola „Agent” w dzienniku aktywności lub ścieżce audytu incydentu. Rejestrowanie Znajdź znaczniki czasu odpowiadające zmianom pola „Agent”. Typ zdarzenia inferred
	Wysłano pierwszą odpowiedź	To pierwsza wiadomość agenta do użytkownika po zgłoszeniu incydentu. Może to być publiczna notatka lub bezpośrednia odpowiedź. Freshservice rejestruje komunikację agentów wraz ze znacznikami czasu.
Dlaczego to ważne Realizacja SLA dotyczącego pierwszej odpowiedzi to ważny KPI wpływający na zadowolenie klientów. Analiza tego zdarzenia pozwala mierzyć, jak szybko agenci podejmują obsługę nowych incydentów. Skąd pobrać Zdarzenie można ustalić, znajdując znacznik czasu pierwszej publicznej notatki lub odpowiedzi agenta w historii rozmowy dotyczącej incydentu. Rejestrowanie Przefiltruj historię rozmowy dotyczącej incydentu i znajdź najwcześniejszy wpis agenta. Typ zdarzenia explicit
	Zmieniono status na „Oczekuje”	Oznacza wstrzymanie procesu rozwiązywania incydentu, zwykle w oczekiwaniu na informacje od użytkownika lub strony trzeciej. Zdarzenie można ustalić na podstawie zmiany statusu na dowolny stan „Oczekuje”. Czas spędzony w tym stanie często nie jest uwzględniany przy obliczaniu SLA.
Dlaczego to ważne Ustalenie czasu spędzonego w stanach oczekiwania pomaga zrozumieć opóźnienia i zależności od podmiotów zewnętrznych. Pozwala oddzielić czas pracy agenta od czasu oczekiwania. Skąd pobrać Zdarzenie można ustalić na podstawie dziennika aktywności incydentu, gdy pole „Status” zmieni się na wartość taką jak „Oczekuje” lub „Oczekuje na odpowiedź użytkownika”. Rejestrowanie Przefiltruj dziennik aktywności, aby znaleźć zmiany statusu na dowolny stan oczekiwania, i użyj przypisanych im znaczników czasu. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Freshservice

Kroki

Otwórz Freshservice Analytics: Zaloguj się do instancji Freshservice na konto z uprawnieniami do przeglądania i tworzenia raportów. W menu głównym przejdź do modułu Analytics.
Utwórz raport: Kliknij przycisk New Report. Wpisz opisową nazwę, na przykład „Dziennik zdarzeń obsługi incydentów”. Po wyświetleniu prośby o wybór źródła danych wybierz moduł Incident Management.
Wybierz widżet raportu: W edytorze raportu dodaj widżet i wybierz typ Table. Będzie on podstawą dziennika zdarzeń.
Dodaj podstawowe kolumny danych: Z panelu źródeł danych po prawej stronie przeciągnij odpowiednie pola do konfiguracji kolumn tabeli. Zacznij od Incident ID, Created at, Agent, Group, Priority, Severity, Status i Category.
Dodaj dane o działaniach: Aby zarejestrować poszczególne zdarzenia, połącz dane lub uwzględnij dane o działaniach związanych ze zgłoszeniem. Dodaj źródło danych Activities do widżetu. Wybierz z niego Performed at (timestamp zdarzenia) oraz Activity description lub podobne pola opisujące zmianę.
Utwórz obliczaną kolumnę „ActivityName”: To najważniejszy krok. Utwórz obliczaną kolumnę lub pole formuły. Użyj zagnieżdżonych instrukcji IF albo funkcji CASE, aby przekształcić surowe dane o działaniach w wymagane wartości ActivityName. Szczegółową logikę dla wszystkich 14 działań opisano w sekcji Query.
Skonfiguruj „EventTimestamp”: Utwórz kolejną obliczaną kolumnę EventTimestamp. Powinna ona pobierać timestamp Created at dla działania „Incident Reported”, a dla pozostałych zdarzeń timestamp Performed at danego działania.
Ustaw filtry raportu: Skonfiguruj filtry, aby ograniczyć zakres danych. Ustaw co najmniej filtr zakresu dat dla pola Created at. Zalecany jest okres od 3 do 6 ostatnich miesięcy. Dodaj też filtr uwzględniający tylko zgłoszenia, w których pole „Ticket Type” ma wartość „Incident”.
Uruchom raport i sprawdź wyniki: Uruchom raport, aby wyświetlić podgląd danych. Sprawdź, czy kolumny ActivityName i EventTimestamp są prawidłowo wypełnione. W razie potrzeby popraw formuły i filtry.
Zapisz i wyeksportuj raport: Gdy wyniki będą gotowe, zapisz raport. Wybierz opcję Export, a następnie format CSV.
Zaplanuj eksport (opcjonalnie): Aby regularnie analizować dane, można zaplanować automatyczne uruchamianie i eksport raportu. Ustaw harmonogram, na przykład codzienny lub cotygodniowy, i wybierz dostarczanie pliku CSV na adres e-mail lub do innej lokalizacji.
Przygotuj dane do przesłania: Otwórz wyeksportowany plik CSV. Zmień nazwy nagłówków kolumn na zgodne z wymaganym schematem ProcessMind: IncidentId, ActivityName, EventTimestamp, AssignedAgent, AssignedGroup itd. Dodaj statyczne kolumny SourceSystem (z wartością „Freshservice”) i LastDataUpdate (z bieżącym timestampem). Plik jest gotowy do przesłania.

Konfiguracja

Moduł Analytics: Ta metoda ekstrakcji wymaga dostępu do modułu Freshservice Analytics, dostępnego w planach wyższych poziomów, na przykład Pro i Enterprise.
Wymagane uprawnienia: Konto użytkownika musi mieć rolę z uprawnieniami do tworzenia, edytowania i uruchamiania raportów w module Analytics.
Zakres dat: Aby kontrolować ilość danych, należy ustawić filtr zakresu dat dla daty utworzenia incydentu. Zalecany jest ruchomy okres od 3 do 6 miesięcy, który zapewnia równowagę między kontekstem historycznym a wydajnością.
Filtry raportu: Zawsze ustaw filtr „Ticket Type” równy „Incident”, aby wykluczyć z analizy procesu zgłoszenia serwisowe i inne typy zgłoszeń.
Pola obliczane: Metoda w dużej mierze opiera się na polach obliczanych (formułach), które wyznaczają ActivityName i EventTimestamp dla każdego zdarzenia. Przydatna będzie znajomość edytora formuł Freshservice.
Ilość danych: Ekstrakcja tworzy wiele wierszy dla każdego incydentu, po jednym na każde działanie. W dużych instancjach Freshservice plik CSV może być bardzo obszerny, co wydłuża generowanie raportu i eksport.

Przykładowe zapytanie 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'

Kroki

Wymagania wstępne: Zainstaluj Python 3.6 lub nowszy oraz biblioteki requests i pandas. Można je zainstalować poleceniem pip: pip install requests pandas.
Utwórz klucz API: Zaloguj się do instancji Freshservice jako administrator. Otwórz ustawienia profilu, klikając zdjęcie profilowe w prawym górnym rogu. Przejdź do sekcji „API Key” i skopiuj osobisty klucz API. Traktuj go jak hasło.
Przygotuj skrypt: Zapisz udostępniony kod Python w pliku extract_freshservice_incidents.py na komputerze.
Skonfiguruj parametry: Otwórz plik skryptu w edytorze tekstu. Zmień wartości zastępcze FRESHSERVICE_DOMAIN (np. „yourcompany.freshservice.com”), API_KEY (na skopiowany klucz) i START_DATE_STR (na początek wybranego okresu ekstrakcji w formacie „YYYY-MM-DD”).
Sprawdź działanie skryptu: Skrypt najpierw pobiera wszystkie zgłoszenia incydentów utworzone po wskazanej dacie początkowej. Następnie przechodzi przez kolejne strony wyników zwracanych przez API. Dla każdego zgłoszenia wykonuje drugie wywołanie API, aby pobrać szczegółową historię działań.
Utwórz dziennik zdarzeń: Skrypt przetwarza podstawowe dane zgłoszenia i jego historię działań, aby utworzyć rekordy dla każdego z 14 wymaganych działań biznesowych. Na przykład „Incident Reported” powstaje na podstawie daty utworzenia zgłoszenia, a „Status Changed to In Progress” na podstawie odpowiedniego wpisu w historii działań.
Wyznacz zdarzenia złożone: Skrypt wyznacza między innymi zdarzenie „SLA Target Breached”, sprawdzając, czy doszło do naruszenia SLA dotyczącego rozwiązania zgłoszenia. Jeśli tak, tworzy zdarzenie z timestampem równym dacie due_by, wskazującym moment naruszenia.
Uruchom skrypt: Otwórz terminal lub wiersz polecenia, przejdź do katalogu, w którym zapisano skrypt, i uruchom polecenie: python extract_freshservice_incidents.py.
Monitoruj działanie: Skrypt będzie wyświetlać postęp w konsoli, w tym liczbę przetworzonych zgłoszeń. W zależności od ich liczby i limitów API może to potrwać.
Sprawdź wyniki: Po zakończeniu skrypt utworzy w tym samym katalogu plik CSV o nazwie freshservice_incident_event_log.csv. Będzie on zawierał kompletny dziennik zdarzeń.
Przygotuj plik do przesłania: Otwórz plik CSV w arkuszu kalkulacyjnym i sprawdź, czy kolumny (IncidentId, ActivityName, EventTimestamp itd.) są prawidłowo wypełnione. Plik jest gotowy do przesłania do ProcessMind lub innego narzędzia process mining.

Konfiguracja

FRESHSERVICE_DOMAIN: Adres URL Freshservice Państwa firmy, na przykład mycompany.freshservice.com. To wymagany parametr skryptu.
API_KEY: Osobisty klucz API użytkownika z uprawnieniami do odczytu wszystkich danych o incydentach. To wymagany parametr.
START_DATE_STR: Data początkowa ekstrakcji danych w formacie „YYYY-MM-DD”. Do analizy zaleca się początkowo pobrać dane z okresu od 3 do 6 miesięcy.
PAGE_SIZE: Wartość 100, czyli maksymalna dozwolona przez Freshservice API. Ogranicza liczbę wywołań API i poprawia wydajność. Zasadniczo nie zaleca się jej zmieniać.
Limity API: Po przetworzeniu każdego zgłoszenia skrypt wykonuje podstawowe wywołanie time.sleep(1), aby przestrzegać limitów Freshservice API. W instancjach o dużym wolumenie może być konieczna zmiana tej wartości, aby uniknąć błędów.
Wymagane uprawnienia: Użyty klucz API musi należeć do konta użytkownika, na przykład dedykowanego konta serwisowego, z uprawnieniami co najmniej roli „SD Agent”. Dzięki temu będzie można uzyskać dostęp do wszystkich wymaganych pól zgłoszeń i dzienników działań w różnych grupach service desk.

Przykładowe zapytanie 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()

Kroki

Sprawdź, czy plan Freshservice i uprawnienia administratora pozwalają korzystać z reguł Workflow Automator, akcji webhook, dostępu do incydentów i historii działań zgłoszeń. Uzgodnij z zespołem odbierającym adres endpointu, metodę uwierzytelniania, wymagania TLS i zasady przechowywania danych.
Przed skonfigurowaniem automatyzacji określ format zdarzenia. Każde wywołanie webhooka powinno zawierać jeden obiekt JSON z polami IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory i ResolutionSlaTargetTime. Skonfiguruj odbiornik tak, aby zachowywał oryginalny payload webhooka i timestamp dostarczenia.
Utwórz regułę Workflow Automator dla tworzenia incydentu. Ustaw jej uruchamianie przy utworzeniu incydentu, a następnie dodaj akcję webhook wysyłającą działanie Incident Reported. Ustaw EventTimestamp na timestamp utworzenia incydentu, a ActivityName na Incident Reported.
Utwórz reguły aktualizacji dotyczące przypisania, priorytetu, statusu, komunikacji, notatek, SLA i zamknięcia. Skonfiguruj warunki na podstawie pól incydentu i historii działań dostępnych na koncie Freshservice. Każda reguła musi wysyłać osobne zdarzenie webhook przy wystąpieniu odpowiedniego działania. Nie należy zakładać, że ProcessMind odtworzy działania na podstawie końcowego stanu incydentu.
Skonfiguruj jawne mapowanie działań. Wysyłaj Incident Assigned to Group, gdy pole Group otrzyma pierwszą wartość; Agent Assigned to Incident, gdy pole Agent otrzyma pierwszą wartość; Incident Prioritized, gdy pole Priority zostanie ustawione lub zmienione; First Response Sent, gdy zostanie zarejestrowana pierwsza kwalifikująca się publiczna odpowiedź lub notatka agenta; Incident Reassigned, gdy po początkowym przypisaniu zmieni się Agent lub Group; Status Changed to In Progress i Status Changed to Pending przy odpowiednich zmianach statusu; Workaround Provided tylko wtedy, gdy ustawiono skonfigurowany wskaźnik obejścia problemu; Resolution Note Added po dodaniu notatki o rozwiązaniu; Incident Resolved po zmianie statusu na Resolved; SLA Target Breached po spełnieniu skonfigurowanego warunku naruszenia SLA; Incident Reopened po zmianie statusu z Resolved na otwarty; oraz Incident Closed po zmianie statusu na Closed.
Skonfiguruj treść żądania webhooka w formacie JSON. Uwzględnij identyfikator incydentu, nazwę działania, timestamp zdarzenia, system źródłowy, datę ostatniej aktualizacji danych i zalecane atrybuty kontekstowe. Użyj zmiennych webhooka udostępnionych na koncie Freshservice. Jeśli wymaganej zmiennej nie ma w edytorze webhooków, uzupełnij ją w usłudze odbierającej, korzystając z zatwierdzonego interfejsu Freshservice, albo pozostaw pustą. Nie należy wpisywać wartości na podstawie przypuszczeń.
Skonfiguruj obsługę idempotencji i dostarczania po stronie endpointu. Użyj stabilnego identyfikatora zdarzenia, jeśli Freshservice go udostępnia. W przeciwnym razie utwórz klucz deduplikacji z pól IncidentId, ActivityName, EventTimestamp i identyfikatora dostarczenia źródłowego. Zwracaj pomyślną odpowiedź HTTP dopiero po trwałym zapisaniu payloadu.
Przetestuj każdą regułę na kontrolowanych incydentach. Utwórz incydent, przypisz grupę i agenta, zmień priorytet i status, wyślij kwalifikującą się odpowiedź, dodaj obejście problemu i notatkę o rozwiązaniu, jeśli zostały skonfigurowane, a następnie rozwiąż, otwórz ponownie i zamknij incydent. Osobno przetestuj naruszenie SLA, korzystając z kontrolowanej polityki lub kolejki testowej. Sprawdź, czy każde oczekiwane działanie dotarło jako osobny payload webhooka.
Zapisuj payloady webhooków w trwałym obszarze pośrednim, ujednolić strefę czasową timestampów i przekształć każdy payload w jeden wiersz dziennika zdarzeń. Zachowaj osobny wiersz dla każdego jawnego działania z webhooka. W polu LastDataUpdate umieść timestamp odświeżenia danych podczas ekstrakcji lub przyjęcia, a nie timestamp zdarzenia biznesowego.
Sprawdź przygotowany dziennik zdarzeń, usuń wyłącznie dokładne duplikaty dostarczeń i zachowaj prawidłowo powtarzające się działania, takie jak wielokrotne zmiany priorytetu lub statusu. Upewnij się, że każdy wiersz zawiera IncidentId, ActivityName, EventTimestamp, SourceSystem i LastDataUpdate.
Wyeksportuj ujednolicony dziennik zdarzeń do CSV lub innego formatu obsługiwanego przez ProcessMind. Użyj dokładnych nazw kolumn: IncidentId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, AssignedAgent, AssignedGroup, IncidentPriority, IncidentSeverity, IncidentStatus, IncidentCategory i ResolutionSlaTargetTime. Prześlij plik lub połącz przygotowane źródło zdarzeń z ProcessMind, mapując IncidentId jako identyfikator case, a ActivityName jako pole działania.

Konfiguracja

Zakres wyzwalaczy: Skonfiguruj osobne reguły Workflow Automator dla tworzenia incydentu i każdego warunku aktualizacji. Jedna ogólna reguła aktualizacji może powodować duplikaty lub niejednoznaczne zdarzenia, jeśli odbiornik nie stosuje ścisłego mapowania działań.
Payload webhooka: W każdym payloadzie uwzględnij wszystkie wymagane atrybuty. Dodaj zalecane atrybuty, jeśli są dostępne w chwili zdarzenia. Zachowaj surowy payload na potrzeby audytu i ponownego przetwarzania.
Znaczenie działań: Początkowe przypisanie grupy i agenta należy odróżnić od późniejszych zmian. Późniejsze zmiany oznaczają Incident Reassigned, a pierwsze przypisanie powinno być rejestrowane jako odpowiednie działanie początkowe.
Obsługa statusów: Mapuj dokładne wartości statusów skonfigurowane na koncie Freshservice. Jeśli konto używa niestandardowych statusów oczekujących lub otwartych, skonfiguruj dla nich jawne mapowania.
Pierwsza odpowiedź: Określ, czy kwalifikuje się odpowiedź publiczna, notatka publiczna czy inny rodzaj komunikacji. Stosuj tę definicję konsekwentnie i rejestruj zdarzenie tylko dla pierwszej kwalifikującej się komunikacji w danym incydencie.
Wykrywanie obejścia problemu: Skonfiguruj dedykowane pole, pole wyboru, typ notatki lub zatwierdzoną regułę opartą na słowach kluczowych. Bez takiej konfiguracji nie można wiarygodnie wykryć działania Workaround Provided.
Naruszenie SLA: Skonfiguruj jawny wyzwalacz naruszenia SLA albo osobny zaplanowany proces porównujący bieżący czas z ResolutionSlaTargetTime. Sam końcowy stan incydentu nie wystarczy do odtworzenia timestampu naruszenia.
Zakres dat: Do wstępnej walidacji użyj danych o incydentach z około 3 do 6 miesięcy. W przypadku przetwarzania w czasie rzeczywistym rozpocznij pobieranie przed początkiem analizowanego okresu i zachowuj historię webhooków na potrzeby ponownego przetwarzania.
Filtry: Stosuj wyłącznie zatwierdzone filtry dotyczące firmy, obszaru roboczego, działu, usługi, kategorii lub daty. Nie zakładaj nazw pól ani składni filtrów Freshservice, których nie udostępnia konfiguracja konta.
Wydajność: Przetwarzaj webhooki asynchronicznie, umieszczaj przychodzące żądania w kolejce, zapisuj dane w systemach dalszego przetwarzania partiami i indeksuj IncidentId oraz EventTimestamp. Unikaj synchronicznego wzbogacania danych podczas odbierania webhooka.
Niezawodność: Skonfiguruj ponawianie prób, obsługę wiadomości niedostarczonych, monitorowanie i eliminowanie duplikatów. Rejestruj nieudane dostarczenia i ponawiaj je po usunięciu problemu.
Wymagania wstępne: Dostęp administratora, dostępność Workflow Automator, uprawnienia do webhooków, endpoint HTTPS, konfiguracja uwierzytelniania, odpowiednie możliwości planu Freshservice oraz zgodny z ProcessMind proces przyjmowania lub przesyłania danych.
Bezpieczeństwo: Korzystaj z HTTPS, w miarę możliwości ogranicz dostęp przychodzący, regularnie zmieniaj dane uwierzytelniające, ogranicz liczbę wrażliwych pól i chroń opisy incydentów oraz notatki, jeśli są uwzględniane w payloadach.

Przykładowe zapytanie 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
};

Jak zacząć?

Skorzystaj z tego szablonu, aby prawidłowo przygotować dane i uzyskać przydatne informacje o workflow obsługi incydentów. Zacznij już dziś analizować możliwości skrócenia czasu rozwiązywania zgłoszeń.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Ogranicz naruszenia SLA, usprawnij obsługę incydentów

Dołącz do firm, które skracają MTTR o 35% i zapobiegają kosztownym naruszeniom SLA.

Rozpocznij bezpłatny okres próbny

Bezpłatny okres próbny trwa 14 dni. Nie trzeba podawać danych karty płatniczej.

Szablon danych do zarządzania incydentami

Szablon danych do zarządzania incydentami

Atrybuty zarządzania incydentami

Działania w procesie obsługi incydentów

Instrukcje ekstrakcji danych

Eksport danych z modułu Freshservice Analytics do CSV

Kroki

Konfiguracja

Przykładowe zapytanie config

Ekstrakcja danych za pomocą skryptu Python i Freshservice REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Przesyłanie danych w czasie rzeczywistym za pomocą webhooków Workflow Automator

Kroki

Konfiguracja

Przykładowe zapytanie config

Jak zacząć?

Ogranicz naruszenia SLA, usprawnij obsługę incydentów