> Ciągłe doskonalenie procesów > Zarządzanie zgłoszeniami serwisowymi > Zendesk Support > Szablon danych

Szablon danych do analizy obsługi zgłoszeń serwisowych

Zendesk Support

← Wróć do przewodnika ulepszania procesów

Atrybuty obsługi zgłoszeń serwisowych(21) Działania w procesie obsługi zgłoszeń serwisowych(13) Instrukcje pobierania danych(3)

Szablon danych do analizy obsługi zgłoszeń serwisowych

Ten szablon zawiera wskazówki dotyczące pozyskiwania danych potrzebnych do analizy procesu obsługi zgłoszeń serwisowych w Zendesk Support. Opisuje wymagane atrybuty, działania, które warto śledzić, oraz praktyczne sposoby pobierania tych informacji bezpośrednio z systemu. Skorzystaj z niego, aby przygotować dziennik zdarzeń na potrzeby process mining.

Zalecane atrybuty do szczegółowej analizy
Najważniejsze działania w obsłudze zgłoszeń serwisowych do śledzenia
Wskazówki dotyczące pobierania danych z Zendesk Support

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

Pobierz szablon

Atrybuty obsługi zgłoszeń serwisowych

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować obsługę zgłoszeń serwisowych w Zendesk Support.

5 Wymagane 7 Zalecane 9 Opcjonalne

	Nazwa	Opis
	Aktywność ActivityName	Nazwa czynności biznesowej lub zdarzenia, które wystąpiło w ramach obsługi zgłoszenia serwisowego.
Opis Aktywność oznacza odrębny krok lub zdarzenie w cyklu życia zgłoszenia serwisowego, na przykład „Utworzenie zgłoszenia serwisowego”, „Przypisanie zgłoszenia do agenta” lub „Rozwiązanie zgłoszenia serwisowego”. Aktywności są wyznaczane na podstawie zmian zapisanych w dzienniku audytu zgłoszenia Zendesk. Dziennik rejestruje modyfikacje pól takich jak status, osoba przypisana i priorytet, a także dodanie komentarzy. Analiza aktywności stanowi podstawę process mining. Pozwala wizualizować mapę procesu, wykrywać wąskie gardła między krokami i analizować pętle ponownej pracy. Znajomość kolejności i częstotliwości aktywności pomaga organizacjom wykrywać nieefektywności i możliwości ulepszania procesów. Dlaczego to ważne Ten atrybut określa kroki procesu, umożliwiając wizualizację map procesów oraz analizę przebiegu, wariantów i zgodności procesu. Skąd pobrać Pojęcie to wyprowadza się ze zdarzeń zapisanych w Zendesk Ticket Audits API. Na przykład zmianę pola „status” z „new” na „open” można odwzorować jako aktywność „Wstępna kwalifikacja zgłoszenia”. Przykłady Utworzono zgłoszenie serwisowePonowne przypisanie agentaRozwiązanie zgłoszenia serwisowego
	Czas rozpoczęcia EventTimestamp	Dokładna data i godzina wystąpienia aktywności.
Opis Znacznik czasu zdarzenia, czyli czas rozpoczęcia, zapisuje dokładny moment wystąpienia aktywności. Określa na przykład, kiedy przypisano agenta, wysłano publiczną odpowiedź lub zmieniono status zgłoszenia na „Resolved”. Dane pochodzą z dziennika audytu każdego zgłoszenia Zendesk. Ten atrybut jest niezbędny do analiz opartych na czasie. Służy do porządkowania zdarzeń chronologicznie, obliczania odstępów między aktywnościami, pomiaru czasu oczekiwania i analizy całkowitego czasu cyklu sprawy. Pomaga wykrywać wąskie gardła i oceniać wyniki względem celów czasowych, takich jak SLA. Dlaczego to ważne Ten znacznik czasu porządkuje zdarzenia chronologicznie i jest niezbędny do analizy czasu trwania, wyników oraz wąskich gardeł. Skąd pobrać Zendesk Ticket Audits API, pole „created_at” dla każdego zdarzenia audytu. Przykłady 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Identyfikator zgłoszenia serwisowego ServiceRequestId	Unikalny identyfikator każdego zgłoszenia serwisowego w Zendesk.
Opis Identyfikator zgłoszenia serwisowego, nazywany w Zendesk często Ticket ID, jest kluczem głównym każdej sprawy. Łączy wszystkie powiązane aktywności, komentarze i zmiany statusu, od utworzenia zgłoszenia aż do jego zamknięcia. Dzięki temu można prześledzić cały przebieg pojedynczego zgłoszenia. Ten atrybut ma podstawowe znaczenie w analizie process mining. Określa sprawę, co pozwala odtworzyć przebieg procesu, wykryć jego warianty i obliczyć miary dla poszczególnych spraw, takie jak czas cyklu. Każde zdarzenie w zbiorze danych musi być powiązane z identyfikatorem zgłoszenia serwisowego, aby można było ustalić jego kontekst w całym procesie. Dlaczego to ważne To podstawowy identyfikator sprawy, który łączy wszystkie zdarzenia z przebiegu obsługi zgłoszenia serwisowego i umożliwia analizę całego procesu. Skąd pobrać Zendesk Tickets API, pole „id”. Przykłady 102451024610247
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane z systemu źródłowego.
Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z Zendesk Support. Informuje, jak aktualne są analizowane dane, dzięki czemu użytkownicy wiedzą, na jakim stanie procesu opierają się wnioski. Informacja ta jest ważna przy bieżącym monitorowaniu i korzystaniu z dashboardów. Analitycy i użytkownicy biznesowi mogą sprawdzić, czy analizują dane zbliżone do bieżących, czy migawkę z wcześniejszego okresu. Ma to wpływ na wiarygodność wniosków. Dlaczego to ważne Informuje, jak aktualne są dane, i pozwala ocenić, na jak świeżych danych opiera się analiza. Skąd pobrać To pole metadanych, które jest generowane i dodawane do zbioru danych podczas ich pobierania. Przykłady 2023-10-27T08:00:00Z
	System źródłowy SourceSystem	Wskazuje system, z którego pobrano dane.
Opis Ten atrybut określa źródło danych o zgłoszeniach serwisowych. W tym widoku procesu jego wartością zawsze będzie „Zendesk Support”, czyli system rejestrujący wszystkie działania związane z obsługą zgłoszeń. W środowiskach z wieloma zintegrowanymi systemami pole to ma znaczenie dla śledzenia pochodzenia danych i rozwiązywania problemów. Pozwala ograniczyć analizę do właściwego systemu i odróżnić dane połączone z różnych źródeł. Dlaczego to ważne Wskazuje system źródłowy danych, ułatwia śledzenie ich pochodzenia i zapobiega pomyłkom przy łączeniu danych z wielu systemów. Skąd pobrać To stała wartość („Zendesk Support”), dodawana podczas pobierania i przekształcania danych. Przykłady Zendesk Support
	Imię i nazwisko agenta AgentName	Imię i nazwisko agenta przypisanego do zgłoszenia serwisowego w chwili wystąpienia zdarzenia.
Opis Ten atrybut wskazuje agenta wsparcia odpowiedzialnego za obsługę zgłoszenia serwisowego. W trakcie obsługi zgłoszenia agent może się zmieniać. Pole pokazuje, kto odpowiadał za każdy kolejny krok. Imię i nazwisko agenta ma znaczenie przy analizie wyników pracy. Pozwala filtrować i dzielić dane, aby ocenić rozkład obciążenia, czas rozwiązywania zgłoszeń przez poszczególnych agentów oraz częstotliwość ponownych przypisań. Ułatwia to tworzenie dashboardu wyników pracy agentów i zespołów oraz analizę wpływu poszczególnych osób na efektywność procesu. Dlaczego to ważne Ten atrybut pomaga analizować wyniki pracy agentów, rozkład obciążenia i wpływ ponownych przypisań na czas rozwiązywania zgłoszeń. Skąd pobrać Zendesk Users API, przez połączenie z polem „assignee_id” z odpowiedzi Tickets API. Przykłady Jane DoeJohn SmithEmily Jones
	Kanał zgłoszenia RequestChannel	Kanał, za pośrednictwem którego przesłano zgłoszenie serwisowe, na przykład e-mail, formularz internetowy lub telefon.
Opis Ten atrybut wskazuje, skąd pochodzi zgłoszenie serwisowe. Zendesk zapisuje, w jaki sposób utworzono zgłoszenie: przez e-mail, portal internetowy, integrację API, czat lub inny kanał. Dzięki temu wiadomo, jak klient skontaktował się z firmą. Kanał zgłoszenia jest przydatnym wymiarem analizy. Dashboard „Efektywność kanałów zgłoszeń” pozwala porównywać czas rozwiązywania, oceny satysfakcji i odsetek ponownej pracy dla różnych kanałów. Wyniki mogą pomóc usprawnić obsługę w poszczególnych kanałach i kierować użytkowników do tych, które działają najsprawniej. Dlaczego to ważne Pomaga analizować efektywność i wyniki różnych kanałów obsługi klienta oraz wskazywać obszary wymagające usprawnień. Skąd pobrać Zendesk Tickets API, obiekt „via” i jego właściwość „channel”. Przykłady strona internetowae-mailAPIczat
	Priorytet zgłoszenia RequestPriority	Poziom priorytetu przypisany do zgłoszenia serwisowego, na przykład niski, normalny, wysoki lub pilny.
Opis Priorytet zgłoszenia określa jego pilność. Od tego poziomu często zależą docelowy czas rozwiązania i zasady SLA stosowane wobec zgłoszenia. Priorytet może ustawić system lub użytkownik podczas tworzenia zgłoszenia. Agent może go później zmienić. Ten atrybut jest ważny przy segmentacji i analizie przyczyn źródłowych. Pozwala sprawdzić, czy zgłoszenia o wysokim priorytecie są rozwiązywane szybciej niż te o niskim. Jest też jednym z głównych wymiarów dashboardów „Trendy eskalacji zgłoszeń serwisowych” i „Realizacja SLA”. Dlaczego to ważne Pozwala dzielić zgłoszenia według pilności, co pomaga analizować zgodność z SLA i sprawdzać, czy pilne problemy są obsługiwane bez zbędnej zwłoki. Skąd pobrać Zendesk Tickets API, pole „priority”. Przykłady NiskiNormalnyWysokiPilny
	Przypisany zespół AssignedTeam	Zespół lub grupa wsparcia przypisana do zgłoszenia serwisowego.
Opis Ten atrybut wskazuje zespół lub grupę w organizacji wsparcia odpowiedzialną za zgłoszenie serwisowe. W Zendesk grupy te nazywane są „Groups”. Zgłoszenia często najpierw trafiają do grupy, a dopiero potem do konkretnego agenta. Analiza według przypisanego zespołu pozwala ocenić wyniki pracy i obciążenie poszczególnych zespołów. Ułatwia ustalenie, które zespoły obsługują dane rodzaje zgłoszeń, jaki jest ich średni czas rozwiązania i jak często dotrzymują SLA. To jeden z głównych wymiarów dashboardu wyników pracy agentów i zespołów. Dlaczego to ważne Umożliwia analizę wyników pracy zespołów, równoważenia obciążenia i efektywności kierowania zgłoszeń między grupami wsparcia. Skąd pobrać Zendesk Groups API, przez połączenie z polem „group_id” z odpowiedzi Tickets API. Przykłady Wsparcie pierwszego poziomuWsparcie techniczneRozliczenia
	Rodzaj zgłoszenia ServiceType	Kategoria lub rodzaj zgłoszenia serwisowego, na przykład incydent, pytanie, problem lub zadanie.
Opis Rodzaj zgłoszenia określa charakter zgłoszenia serwisowego. Zendesk używa pola „type”, aby rozróżniać rodzaje kontaktów z zespołem wsparcia. Wstępna klasyfikacja pomaga skierować zgłoszenie do właściwego zespołu i zastosować odpowiedni proces. Ten atrybut ułatwia filtrowanie i porównywanie danych. Analitycy mogą sprawdzać przebieg procesu dla różnych rodzajów zgłoszeń, które często mają odmienne ścieżki rozwiązania i SLA. To ważny wymiar dashboardu wyników pracy agentów i zespołów, który pokazuje, kto najlepiej obsługuje poszczególne rodzaje zgłoszeń. Dlaczego to ważne Pozwala osobno analizować różne procesy, na przykład obsługę incydentów i pytań, które przebiegają inaczej. Skąd pobrać Zendesk Tickets API, pole „type”. Przykłady pytanieincydentproblemzadanie
	Status zgłoszenia RequestStatus	Status zgłoszenia serwisowego w chwili wystąpienia zdarzenia, na przykład New, Open lub Pending.
Opis Status zgłoszenia wskazuje stan zgłoszenia w danym momencie. Zendesk ma kilka standardowych statusów: New, Open, Pending, On-hold, Solved i Closed. Pokazują one postęp obsługi zgłoszenia. Zmiany tego pola są główną podstawą do tworzenia aktywności w dzienniku zdarzeń. Analiza czasu spędzonego w poszczególnych statusach jest ważną częścią analizy wąskich gardeł. Pomaga wykryć, gdzie zgłoszenia utknęły, na przykład zbyt długo pozostają w stanie „Pending” lub „On-hold”. Analiza zmian statusów pomaga też wykrywać pętle ponownej pracy. Dlaczego to ważne Śledzenie statusu pozwala zrozumieć postęp obsługi zgłoszenia i ustalić, ile czasu upływa w stanie oczekiwania, a ile podczas aktywnej pracy. Skąd pobrać Zendesk Tickets API, pole „status”. Przykłady NoweOtwarteOczekująceRozwiązaneZamknięte
	Tagi zgłoszenia TicketTags	Lista tagów przypisanych do zgłoszenia serwisowego w celu jego kategoryzacji i kierowania.
Opis Tagi to elastyczne etykiety, które agenci mogą dodawać do zgłoszeń ręcznie lub automatycznie za pomocą reguł biznesowych. Uzupełniają standardowe pola, takie jak rodzaj lub priorytet, o dodatkowe informacje i kategorie. Tagi można wykorzystywać na wiele sposobów w analizie process mining. Pozwalają filtrować konkretne scenariusze, śledzić niestandardowe workflow i wykrywać przyczyny źródłowe. Na przykład tag „VIP” może służyć do analizy obsługi ważnych klientów, a tag „product_bug” do śledzenia zgłoszeń dotyczących usterek produktu. Dlaczego to ważne Ułatwia filtrowanie i analizę danych według wybranych kryteriów, w tym szczegółową analizę podprocesów i cech zgłoszeń, których nie zapisują inne pola. Skąd pobrać Zendesk Tickets API, pole „tags”. Tablica ciągów znaków. Przykłady zapytanie_sprzedażoweproblem_z_rozliczeniemprośba_o_funkcjęklient_vip
	Czas zakończenia EndTime	Dokładna data i godzina zakończenia aktywności.
Opis Czas zakończenia oznacza moment, w którym aktywność dobiegła końca. Wiele zdarzeń w Zendesk trwa chwilę, dlatego czas zakończenia jest taki sam jak czas rozpoczęcia. W przypadku aktywności związanych ze stanem, takich jak „Wstrzymanie zgłoszenia”, czas zakończenia przypada na moment wznowienia zgłoszenia. Ten atrybut jest niezbędny do obliczania czasu trwania poszczególnych aktywności, co ma znaczenie przy analizie wąskich gardeł. Porównanie czasu rozpoczęcia i zakończenia pozwala bezpośrednio zmierzyć czas realizacji danego kroku i wskazać te, które zajmują najwięcej czasu. Dlaczego to ważne Pozwala obliczyć czas trwania poszczególnych aktywności, co pomaga wykrywać wąskie gardła procesu i mierzyć efektywność na poziomie kroków. Skąd pobrać W przypadku pojedynczych zdarzeń jest to często ten sam czas co StartTime. Dla czasu trwania statusu jest to znacznik czasu kolejnego zdarzenia, które zmienia status. Przykłady 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
	Czy doszło do naruszenia SLA IsSlaBreached	Informacja, czy zgłoszenie serwisowe przekroczyło którykolwiek z celów SLA.
Opis Ten atrybut logiczny lub kategoryczny wskazuje wynik SLA dla zgłoszenia. Może przyjmować wartości takie jak „Spełnione”, „Naruszone” lub „Aktywne”. Wynik ustala się przez porównanie rzeczywistego czasu odpowiedzi lub rozwiązania z celami określonymi w zastosowanej polityce SLA. Atrybut ten jest niezbędny do analizy na dashboardzie „Realizacja SLA i analiza naruszeń”. Ułatwia zliczanie i wizualizację zgłoszeń zgodnych i niezgodnych z SLA. Dalsza analiza może skupić się na przebiegu zgłoszeń, w których doszło do naruszenia, aby ustalić przyczyny, takie jak długi czas oczekiwania lub zbyt częste zmiany przypisanego agenta. Dlaczego to ważne Bezpośrednio mierzy realizację zobowiązań dotyczących poziomu usług, co pozwala ocenić jakość obsługi i zadowolenie klientów. Skąd pobrać Pochodzi z Zendesk Ticket Metrics API, które udostępnia informacje o stanie SLA każdego zgłoszenia. Przykłady SpełnioneNaruszoneAktywne
	Czy rozwiązano przy pierwszym kontakcie IsFirstContactResolution	Informacja, czy zgłoszenie rozwiązał pierwszy przypisany agent, bez zmiany przypisania i odpowiedzi ze strony zgłaszającego.
Opis Rozwiązanie przy pierwszym kontakcie (FCR) to ważna miara pokazująca, czy problem klienta udało się rozwiązać podczas jednej interakcji. Ten obliczany atrybut logiczny przyjmuje wartość prawda, jeśli zgłoszenie rozwiązał pierwszy przypisany do niego agent, bez zmiany przypisania i po wysłaniu tylko jednej odpowiedzi przez agenta. Atrybut ten bezpośrednio zasila KPI „Odsetek rozwiązań przy pierwszym kontakcie”. Analiza zgłoszeń z FCR może wskazać, jak usprawnić proces. Z kolei analiza przypadków bez FCR pozwala znaleźć możliwości poprawy szkoleń agentów, artykułów w bazie wiedzy lub wstępnej kwalifikacji zgłoszeń. Dlaczego to ważne Mierzy zdolność do sprawnego rozwiązania problemu w ramach jednej interakcji, co wpływa zarówno na zadowolenie klientów, jak i efektywność operacyjną. Skąd pobrać To złożony atrybut obliczany na podstawie dziennika zdarzeń zgłoszenia. Wymaga sprawdzenia zmian przypisanego agenta i liczby publicznych odpowiedzi agentów. Przykłady truefalse
	Czy wystąpiła ponowna praca IsRework	Informacja, czy zgłoszenie serwisowe zostało ponownie otwarte po rozwiązaniu.
Opis Ten atrybut logiczny wskazuje zgłoszenia, przy których trzeba było ponownie wykonać pracę. Zwykle dotyczy to sytuacji, gdy status zgłoszenia zmienia się z „Rozwiązane” na otwarty. Oznacza to, że pierwotne rozwiązanie nie wystarczyło i klient wrócił do tej samej sprawy. Atrybut ten jest niezbędny do obliczenia KPI „Odsetek zgłoszeń wymagających ponownej pracy” oraz do analizy na dashboardzie „Ponowna praca i ponowne otwarcia”. Oznaczenie takich zgłoszeń pozwala analitykom wyodrębnić nieefektywne przebiegi, ustalić przyczyny ponownego otwierania spraw i poprawić wskaźnik rozwiązania przy pierwszym kontakcie. Dlaczego to ważne Wskazuje przypadki, w których rozwiązanie nie było ostateczne. Ujawnia problemy z jakością i efektywnością, które bezpośrednio wpływają na zadowolenie klientów. Skąd pobrać Obliczany na podstawie sekwencji statusów zgłoszenia w Zendesk Ticket Audits API. Zmiana statusu z „solved” na „open” oznacza konieczność ponownej pracy. Przykłady truefalse
	Imię i nazwisko osoby zgłaszającej RequestorName	Imię i nazwisko użytkownika końcowego lub klienta, który przesłał zgłoszenie serwisowe.
Opis Ten atrybut wskazuje osobę, która zgłosiła problem. Powiązanie zgłoszenia z konkretnym klientem pozwala analizować proces obsługi z perspektywy użytkownika. W analizie procesu można wykorzystać dane osoby zgłaszającej do badania wzorców dotyczących konkretnych klientów lub ich segmentów. Można na przykład sprawdzić, czy niektórzy klienci dłużej czekają na rozwiązanie albo częściej muszą ponownie zgłaszać problem. Może to wskazywać na problemy z używanym przez nich produktem lub usługą. Dlaczego to ważne Łączy proces z klientem, umożliwiając analizę problemów dotyczących konkretnych klientów, powtarzających się zgłoszeń i poziomu satysfakcji. Skąd pobrać Zendesk Users API, przez połączenie z polem „requester_id” z odpowiedzi Tickets API. Przykłady Alice JohnsonBob WilliamsCharlie Brown
	Liczba zmian przypisanego agenta AgentReassignmentCount	Łączna liczba zmian agenta przypisanego do zgłoszenia.
Opis Ten atrybut zlicza każdą zmianę wartości pola „assignee_id” w zgłoszeniu. Duża liczba zmian przypisanego agenta może wskazywać na różne problemy w procesie, takie jak błędne początkowe przypisanie, niewystarczająca wiedza agenta lub zbyt złożone zgłoszenie, którego nie może obsłużyć jedna osoba. To ważna miara efektywności procesu, która bezpośrednio zasila KPI „Odsetek zmian przypisanego agenta”. Analiza zgłoszeń z dużą liczbą takich zmian może pomóc znaleźć możliwości usprawnienia reguł przypisywania, szkoleń agentów lub zasobów bazy wiedzy, aby zgłoszenia szybciej trafiały do właściwych osób. Dlaczego to ważne Pozwala zmierzyć liczbę przekazań między pracownikami i wykryć utrudnienia w procesie. Częste zmiany przypisanego agenta zwykle powodują opóźnienia i obniżają efektywność. Skąd pobrać Obliczany przez zliczenie zmian pola „assignee_id” dla każdego zgłoszenia w Zendesk Ticket Audits API. Przykłady 013
	Nazwa zasad SLA SlaPolicyName	Nazwa zasad dotyczących poziomu usług (SLA) zastosowanych do zgłoszenia.
Opis Ten atrybut wskazuje konkretną politykę SLA, która określa docelowy czas odpowiedzi i rozwiązania zgłoszenia serwisowego. Polityka zależy zwykle od takich czynników jak priorytet i typ zgłoszenia oraz poziom subskrypcji klienta. Informacja o zastosowanej polityce SLA jest niezbędna do analizy na dashboardzie „Realizacja SLA i analiza naruszeń”. Pozwala właściwie ocenić wyniki, ponieważ poszczególne polityki mogą określać różne cele. Dzięki temu można rzetelnie sprawdzić, czy zgłoszenie spełniło przypisane mu wymagania dotyczące poziomu usług. Dlaczego to ważne Dostarcza kontekstu do analizy SLA: wskazuje zestaw celów, względem których oceniano zgłoszenie, i umożliwia rzetelne raportowanie zgodności. Skąd pobrać Zendesk Ticket Metrics API. Dane SLA są często powiązane z metrykami zgłoszenia. Przykłady Pilne, odpowiedź w ciągu 1 godzinyStandardowe, rozwiązanie w ciągu 24 godzinSLA dla klienta premium
	Ocena satysfakcji SatisfactionRating	Ocena satysfakcji wystawiona przez osobę zgłaszającą po rozwiązaniu zgłoszenia.
Opis Ten atrybut zapisuje opinię klienta o obsłudze. Zwykle jest zbierana w ankiecie po oznaczeniu zgłoszenia jako rozwiązane. Typowe oceny to „Good” i „Bad”, czasem z komentarzem. Ocena satysfakcji jest ważną miarą wyniku. Zestawienie wzorców w procesie z ocenami może pokazać, jakie działania prowadzą do zadowolenia lub niezadowolenia klientów. Analiza może na przykład wykazać silny związek między negatywnymi ocenami a częstymi ponownymi przypisaniami lub długim czasem rozwiązywania zgłoszeń. Dlaczego to ważne Łączy przebieg procesu z wynikami obsługi klienta i pomaga ustalić, które działania wpływają na satysfakcję klientów. Skąd pobrać Zendesk Tickets API, pole „satisfaction_rating.score” lub „satisfaction_rating.reason”. Przykłady DobraZłaWystawiona
	Organizacja osoby zgłaszającej RequestorOrganization	Organizacja lub firma, do której należy osoba zgłaszająca.
Opis Ten atrybut łączy zgłoszenie serwisowe z konkretną organizacją klienta. Ma to szczególne znaczenie w obsłudze B2B, gdzie umowy o poziomie usług i umowy wsparcia są często ustalane na poziomie organizacji. Analiza danych według organizacji pokazuje wyniki obsługi na poziomie firmy. Pomaga wykryć organizacje, które generują dużo zgłoszeń, mają powtarzające się problemy lub niskie oceny satysfakcji. Informacje te przydają się w zarządzaniu relacjami z klientami i ocenie ich sytuacji. Dlaczego to ważne Umożliwia analizę obsługi B2B przez grupowanie zgłoszeń według firm. Pomaga zarządzać relacjami z klientami i SLA na poziomie organizacji. Skąd pobrać Zendesk Organizations API, przez połączenie z polem „organization_id” z odpowiedzi Tickets API. Przykłady Acme CorporationGlobal Tech Inc.Innovate Solutions

Wymagane Zalecane Opcjonalne

Działania w procesie obsługi zgłoszeń serwisowych

To najważniejsze kroki i etapy procesu, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkryć przebieg obsługi zgłoszeń serwisowych.

7 Zalecane 6 Opcjonalne

	Działanie	Opis
	Ponowne otwarcie zgłoszenia serwisowego	Występuje, gdy osoba zgłaszająca odpowiada na zgłoszenie o statusie „solved”, a jego status automatycznie zmienia się z powrotem na „open”. Oznacza to, że zaproponowane rozwiązanie nie było wystarczające.
Dlaczego to ważne Ta aktywność jest głównym wskaźnikiem konieczności ponownej pracy. Analiza jej częstotliwości pomaga ocenić jakość rozwiązań i wykryć przyczyny niezadowolenia klientów. Skąd pobrać Wnioskowane na podstawie zdarzenia „Change” dotyczącego pola „status” w dzienniku audytu zgłoszenia, gdy poprzednią wartością było „solved”, a nową jest „open”. Rejestrowanie Wnioskowane na podstawie zmiany statusu z „solved” na „open”. Typ zdarzenia inferred
	Przekroczenie limitu SLA	Ta aktywność oznacza moment, w którym zgłoszenie serwisowe nie spełnia określonego celu SLA, na przykład czasu pierwszej odpowiedzi lub rozwiązania. Zendesk zapisuje jawne zdarzenie, gdy cel nie zostanie osiągnięty.
Dlaczego to ważne To ważne zdarzenie przy monitorowaniu zgodności i jeden z głównych danych wejściowych do KPI dotyczącego realizacji SLA. Wskazuje przypadki, w których nie dotrzymano zobowiązań dotyczących poziomu usług. Skąd pobrać Rejestrowane na podstawie zdarzenia „SLABreach” wśród zdarzeń zgłoszenia Zendesk lub w dzienniku audytu. Zdarzenie wskazuje, który wskaźnik SLA został przekroczony. Rejestrowanie Identyfikowane na podstawie jawnego zdarzenia „SLABreach” w danych zgłoszenia. Typ zdarzenia explicit
	Przydzielono zgłoszenie agentowi	Ta czynność występuje, gdy zgłoszenie serwisowe po raz pierwszy zostaje przydzielone konkretnemu agentowi. Jest wnioskowana na podstawie zdarzenia „Change” w dzienniku audytu zgłoszenia, w którym pole „assignee_id” zostaje uzupełnione, zastępując wartość null lub identyfikator grupy.
Dlaczego to ważne Oznacza początek aktywnej pracy agenta. Jest niezbędna do mierzenia czasu pierwszej odpowiedzi, opóźnienia do pierwszego przydziału i rozkładu obciążenia agentów. Skąd pobrać Wnioskowane na podstawie pierwszego zdarzenia „Change” dotyczącego pola „assignee_id” w dzienniku audytu zgłoszenia, w którym ustawiono identyfikator konkretnego użytkownika. Rejestrowanie Wnioskowane na podstawie pierwszego zdarzenia zmiany, które przypisuje agentowi wartość pola „assignee_id”. Typ zdarzenia inferred
	Rozwiązanie zgłoszenia serwisowego	Ta aktywność oznacza moment, w którym agent przekazał rozwiązanie i zmienił status zgłoszenia na „solved”. Z perspektywy agenta zgłoszenie jest zakończone, ale osoba zgłaszająca może je ponownie otworzyć.
Dlaczego to ważne To ważny etap oznaczający koniec aktywnej pracy agenta. Czas potrzebny na osiągnięcie tego statusu jest podstawową miarą efektywności rozwiązywania zgłoszeń. Skąd pobrać Wnioskowane na podstawie zdarzenia „Change” dotyczącego pola „status” w dzienniku audytu zgłoszenia, gdy nową wartością jest „solved”. Rejestrowanie Wnioskowane na podstawie zdarzenia „Change” w dzienniku audytu, w którym status zmienia się na „solved”. Typ zdarzenia inferred
	Utworzono zgłoszenie serwisowe	To początek obsługi zgłoszenia serwisowego, gdy zgłaszający przesyła nowe zgłoszenie dowolnym kanałem. Zdarzenie jest rejestrowane jako „Create” w dzienniku audytu zgłoszenia Zendesk i wyznacza dokładny początek procesu.
Dlaczego to ważne Ta czynność jest zdarzeniem początkowym każdego zgłoszenia serwisowego. Jest niezbędna do obliczania czasu obsługi od początku do końca i analizy liczby przyjmowanych zgłoszeń. Skąd pobrać W dzienniku audytu zgłoszenia Zendesk jest rejestrowane jako zdarzenie typu „Create”. Znacznik czasu tego zdarzenia wskazuje moment utworzenia zgłoszenia serwisowego. Rejestrowanie Dane pochodzą bezpośrednio ze zdarzenia „Create” w dzienniku audytu zgłoszenia. Typ zdarzenia explicit
	Wysłanie publicznej odpowiedzi	Ta aktywność oznacza każdą wiadomość wysłaną przez agenta do osoby zgłaszającej. W danych zgłoszenia Zendesk jest zapisywana jako jawne zdarzenie „Comment”, w którym atrybut „public” ma wartość true.
Dlaczego to ważne Zdarzenia te są niezbędne do analizy częstotliwości komunikacji, pomiaru czasu odpowiedzi agentów i ustalenia, ile interakcji potrzeba do rozwiązania zgłoszenia. Skąd pobrać W danych zgłoszenia jest to jawne zdarzenie „Comment”. Szczegóły zdarzenia zawierają atrybut „public: true”, który odróżnia je od notatek wewnętrznych. Rejestrowanie Rejestrowane na podstawie zdarzeń „Comment” w zgłoszeniu, w których flaga „public” ma wartość true. Typ zdarzenia explicit
	Zamknięcie zgłoszenia serwisowego	Oznacza ostateczne i nieodwracalne zamknięcie zgłoszenia serwisowego. Po upływie określonego czasu od ustawienia statusu „solved” zgłoszenie automatycznie przechodzi do stanu „closed” i nie można go już ponownie otworzyć.
Dlaczego to ważne Ta aktywność oznacza definitywny koniec procesu obsługi zgłoszenia serwisowego. Wyznacza końcowy punkt do obliczenia pełnego czasu obsługi sprawy. Skąd pobrać Wnioskowane na podstawie zdarzenia „Change” dotyczącego pola „status” w dzienniku audytu zgłoszenia, gdy nową wartością jest „closed”. Rejestrowanie Wnioskowane na podstawie zdarzenia „Change” w dzienniku audytu, w którym status zmienia się na „closed”. Typ zdarzenia inferred
	Dodanie notatki wewnętrznej	Agent dodał do zgłoszenia serwisowego notatkę lub komentarz widoczny tylko dla innych agentów. Jest to zapisywane jako zdarzenie „Comment”, w którym atrybut „public” ma wartość false.
Dlaczego to ważne Śledzenie notatek wewnętrznych pokazuje, jak agenci i zespoły współpracują. Współpraca może powodować opóźnienia albo pomagać szybciej rozwiązywać problemy. Skąd pobrać W danych zgłoszenia jest to jawne zdarzenie „Comment”. Szczegóły zdarzenia zawierają atrybut „public: false”, co oznacza, że jest to notatka wewnętrzna. Rejestrowanie Rejestrowane na podstawie zdarzeń „Comment” w zgłoszeniu, w których flaga „public” ma wartość false. Typ zdarzenia explicit
	Eskalacja zgłoszenia	Oznacza formalne przekazanie zgłoszenia serwisowego do zespołu wsparcia wyższego poziomu, innego zespołu lub kierownictwa. Zwykle zdarzenie jest wnioskowane na podstawie zmiany przypisanej grupy albo pola niestandardowego służącego do rejestrowania eskalacji.
Dlaczego to ważne Monitorowanie eskalacji pomaga wykrywać złożone zgłoszenia, potrzeby szkoleniowe agentów pierwszej linii oraz problemy systemowe wymagające interwencji na wyższym szczeblu. Skąd pobrać Nie jest to standardowe zdarzenie. Należy je wywnioskować ze zdarzenia „Change” dotyczącego pola „group_id”, gdy zgłoszenie zostaje przypisane do grupy eskalacyjnej, albo ze zmiany niestandardowego pola zgłoszenia używanego do śledzenia eskalacji. Rejestrowanie Wnioskowane na podstawie zmiany pola „group_id” lub niestandardowego pola „escalation”. Typ zdarzenia inferred
	Ponowne przypisanie agenta	Oznacza przekazanie obsługi zgłoszenia serwisowego od jednego agenta do drugiego. Zdarzenie jest wnioskowane na podstawie każdego kolejnego zdarzenia „Change” dotyczącego pola „assignee_id” po pierwszym przypisaniu.
Dlaczego to ważne Śledzenie ponownych przypisań jest niezbędne do obliczenia KPI dotyczącego odsetka ponownych przypisań agentów. Wskaźnik pomaga wykryć nieefektywności procesu, błędne kierowanie zgłoszeń i braki w wiedzy. Skąd pobrać Wnioskowane na podstawie zdarzeń „Change” dotyczących pola „assignee_id” w dzienniku audytu zgłoszenia, z pominięciem pierwszego przypisania. Rejestrowanie Wnioskowane na podstawie drugiego i kolejnych zdarzeń „Change” dotyczących pola „assignee_id”. Typ zdarzenia inferred
	Wstrzymanie zgłoszenia	Ta aktywność występuje, gdy status zgłoszenia serwisowego zmienia się na „on-hold”. Zwykle oznacza to, że agent czeka na informacje od osoby zgłaszającej lub strony trzeciej. Zdarzenie jest wnioskowane na podstawie zmiany statusu.
Dlaczego to ważne Pozwala oddzielnie mierzyć czas oczekiwania, na który zespół wsparcia nie ma bezpośredniego wpływu, i dokładniej określić czas obsługi zgłoszenia przez agenta. Skąd pobrać Wnioskowane na podstawie zdarzenia „Change” dotyczącego pola „status” w dzienniku audytu zgłoszenia, gdy nową wartością jest „on-hold”. Rejestrowanie Wnioskowane na podstawie zdarzenia „Change” w dzienniku audytu, w którym status zmienia się na „on-hold”. Typ zdarzenia inferred
	Zastosowano cel SLA	Oznacza moment zastosowania zasad umowy SLA do zgłoszenia serwisowego. Zdarzenie jest rejestrowane, gdy właściwości zgłoszenia spełniają warunki aktywnych zasad SLA.
Dlaczego to ważne Śledzenie momentu zastosowania SLA jest niezbędne do monitorowania zgodności, analizy potencjalnych przekroczeń i określenia oczekiwanego czasu obsługi różnych typów zgłoszeń. Skąd pobrać Dane pochodzą ze zdarzenia „SLAPolicyApplied” w dzienniku zdarzeń lub dzienniku audytu zgłoszenia Zendesk. Zdarzenie wskazuje zastosowane zasady. Rejestrowanie Wykrywane na podstawie jawnego zdarzenia „SLAPolicyApplied” w danych zgłoszenia. Typ zdarzenia explicit
	Zmieniono priorytet	Oznacza zmianę priorytetu zgłoszenia serwisowego, na przykład z „Niski”, „Normalny”, „Wysoki” lub „Pilny”. Jest rejestrowana jako zdarzenie „Change” dotyczące pola „priority” w dzienniku audytu zgłoszenia.
Dlaczego to ważne Analiza zmian priorytetu pomaga wykryć zgłoszenia, których pilność rośnie z czasem, oraz ocenić, czy priorytety są właściwie zarządzane. Skąd pobrać Zapisywane jako zdarzenie „Change” dotyczące pola „priority” w dzienniku audytu zgłoszenia Zendesk. Zawiera poprzednią i nową wartość. Rejestrowanie Wnioskowane na podstawie zdarzeń „Change” dotyczących pola „priority” w dzienniku audytu. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Zendesk Support

Kroki

Otwórz Zendesk Explore i utwórz raport podstawowy: Otwórz menu produktów Zendesk na górnym pasku po prawej stronie i wybierz Explore. Następnie kliknij ikonę Queries po lewej stronie, a potem New query. Jako źródło wybierz zestaw danych Support: Ticket updates.
Skonfiguruj miary i atrybuty zdarzeń zgłoszeń: W kreatorze zapytań dodaj miarę, na przykład COUNT(Tickets), aby zwizualizować dane. Następnie w sekcji Rows dodaj atrybuty: Ticket ID, Update - Timestamp, Updater name, Update - Field name, Update - Previous value, Update - New value, Assignee name, Group name, Ticket priority, Ticket status, Submission channel, Ticket type i Ticket tags.
Utwórz obliczany atrybut ActivityName: Aby zamienić surowe aktualizacje na znaczące działania, utwórz standardowy obliczany atrybut. Otwórz menu Calculations (ikona kalkulatora), wybierz Standard calculated attribute i nazwij atrybut ActivityName. Wklej do pola formuły logikę podaną w sekcji Query. Formuła przypisuje różnym zdarzeniom aktualizacji zgłoszenia odpowiednie nazwy działań.
Dostosuj i filtruj raport podstawowy: Dodaj nowy atrybut ActivityName do sekcji Rows. Ustaw dla niego filtr wykluczający wartości (null) i niepożądane wartości generowane przez system, aby oczyścić zestaw danych. Dodaj też filtr dla Ticket created - Date, aby ograniczyć zapytanie do możliwego do przetworzenia okresu, na przykład ostatnich 6 miesięcy.
Utwórz drugi raport dotyczący zdarzeń SLA: Utwórz kolejne zapytanie i tym razem wybierz zestaw danych Support: SLAs. Jest to konieczne, ponieważ zestaw Ticket updates nie zawiera zdarzeń SLA.
Skonfiguruj raport SLA: W zapytaniu SLA dodaj COUNT(SLA tickets) w sekcji Metrics. W sekcji Rows dodaj Ticket ID, SLA policy, SLA target, SLA updated - Timestamp, SLA status i Updater name. Nazwę działania ustalimy na etapie transformacji na podstawie wartości SLA status.
Wyeksportuj oba zestawy danych: Uruchom oba zapytania w interfejsie Explore. Po wygenerowaniu tabel kliknij Export i wybierz format CSV. Otrzymają Państwo dwa osobne pliki CSV.
Połącz i przekształć dane: Połącz oba pliki CSV za pomocą arkusza kalkulacyjnego, na przykład Microsoft Excel, lub języka skryptowego, takiego jak Python. Celem jest utworzenie jednego dziennika zdarzeń. W pliku SLA trzeba dodać kolumnę ActivityName. Jeśli SLA status ma wartość Active, działaniem jest SLA Target Applied. Jeśli ma wartość Breached, działaniem jest SLA Target Breached. Jako EventTimestamp użyj wartości SLA updated - Timestamp.
Ujednolić nagłówki kolumn: W połączonym pliku zmień nazwy kolumn tak, aby odpowiadały formatowi wymaganemu przez process mining. Na przykład zmień Ticket ID na ServiceRequestId, Update - Timestamp na EventTimestamp, a Updater name na AgentName.
Dodaj kolumny statyczne i przygotuj plik: Dodaj do końcowego pliku CSV dwie kolumny. W kolumnie SourceSystem wpisz wartość „Zendesk”. W kolumnie LastDataUpdate umieść znacznik czasu eksportu. Plik jest gotowy do przesłania.

Konfiguracja

Plan Zendesk: Do tworzenia własnych zapytań i atrybutów wymagany jest plan Zendesk Support obejmujący Zendesk Explore Professional lub Enterprise.
Uprawnienia: Potrzebne jest konto agenta z uprawnieniami do tworzenia i edytowania zapytań w Explore. Zwykle są to uprawnienia administratora lub agenta z rolą niestandardową.
Wybór zestawu danych: Ta metoda wymaga utworzenia dwóch osobnych raportów na podstawie różnych zestawów danych: Support: Ticket updates dla ogólnych zdarzeń i Support: SLAs dla zdarzeń związanych z SLA.
Filtr zakresu dat: Należy ustawić filtr zakresu dat, na przykład dla Ticket created - Date, aby ograniczyć ilość danych. Na początek zalecamy zakres od 3 do 6 miesięcy.
Obliczane atrybuty: Nazwy działań są wyznaczane za pomocą złożonego, niestandardowego obliczanego atrybutu w Explore. Należy poprawnie utworzyć formułę, aby uniknąć błędów w wynikach.
Ilość danych: Interfejs Zendesk Explore i funkcja eksportu mogą działać wolno lub przekroczyć limit czasu przy bardzo dużych zestawach danych. Jeśli eksport obejmuje ponad rok danych lub miliony zgłoszeń, warto podzielić go na krótsze okresy.

Przykładowe zapytanie config

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

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

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

Kroki

Wymagania wstępne: Upewnij się, że w systemie jest zainstalowany Python w wersji 3.6 lub nowszej. Do wygenerowania tokenu API potrzebny jest również dostęp administracyjny do instancji Zendesk Support.
Zainstaluj biblioteki Python: Otwórz terminal lub wiersz polecenia i zainstaluj wymagane biblioteki Python za pomocą pip. Biblioteka requests służy do wywoływania API, a pandas do przetwarzania danych i eksportu do pliku CSV.
```
pip install requests pandas
```
Wygeneruj token API Zendesk: Zaloguj się do Zendesk jako administrator. Przejdź do Admin Center > Apps and integrations > APIs > Zendesk API. W sekcji Token Access włącz dostęp, jeśli nie jest jeszcze aktywny, a następnie kliknij „Add API token”. Podaj opis, na przykład „ProcessMind Extraction”, i skopiuj wygenerowany token. Nie będzie można wyświetlić go ponownie.
Skonfiguruj skrypt Python: Otwórz udostępniony skrypt Python w edytorze tekstu. Uzupełnij zmienne konfiguracyjne na początku pliku: ZENDESK_SUBDOMAIN (nazwę domeny Zendesk firmy), ZENDESK_EMAIL (adres e-mail administratora powiązanego z tokenem) i ZENDESK_API_TOKEN. Ustaw też START_TIME_STR, aby określić początek okresu pobierania danych, zwykle 3–6 miesięcy wstecz.
Zapoznaj się z działaniem skryptu: Najpierw skrypt pobiera listę zgłoszeń zaktualizowanych w wybranym okresie za pomocą wydajnego Incremental Tickets API. Następnie dla każdego zgłoszenia pobiera pełną historię audytu, komentarze i metryki SLA. Przetwarza zdarzenia chronologicznie, aby odtworzyć szczegółową historię.
Przypisz zdarzeniom Zendesk nazwy działań: Skrypt zawiera logikę, która zamienia surowe zdarzenia Zendesk na wymagane działania biznesowe. Na przykład zdarzenie „Change” dotyczące pola „status” jest przypisywane do działań takich jak „Zgłoszenie serwisowe rozwiązane” lub „Zgłoszenie wstrzymane”. Zdarzenia komentarzy są sprawdzane, aby ustalić, czy oznaczają „Wysłano odpowiedź publiczną”, czy „Dodano notatkę wewnętrzną”.
Uruchom skrypt eksportujący dane: W terminalu uruchom polecenie python your_script_name.py. Skrypt będzie wyświetlać postęp pobierania danych z Zendesk API. Czas wykonania zależy od ilości danych i limitów API.
Sprawdź plik wynikowy: Po zakończeniu skrypt utworzy w tym samym katalogu plik CSV o nazwie zendesk_event_log.csv. Będzie on zawierać wyeksportowany dziennik zdarzeń z określonymi działaniami i atrybutami.
Przygotuj plik do przesłania: Otwórz plik CSV i sprawdź, czy ma prawidłowy format. Nagłówki kolumn powinny odpowiadać wymaganym atrybutom, takim jak ServiceRequestId, ActivityName, EventTimestamp, SourceSystem i LastDataUpdate. Plik jest gotowy do przesłania do ProcessMind.

Konfiguracja

Dostęp do Zendesk API: Skrypt wymaga aktywnego tokenu API powiązanego z kontem administratora lub agenta z odpowiednimi uprawnieniami. Adres e-mail użytkownika podany w konfiguracji skryptu musi należeć do osoby, która utworzyła token API.
Parametry skryptu: Przed uruchomieniem należy skonfigurować w skrypcie zmienne ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN i START_TIME_STR. Wartość START_TIME_STR powinna mieć format „YYYY-MM-DD”.
Zakres dat: Na początek zalecamy pobranie danych z ostatnich 3–6 miesięcy (START_TIME_STR). Taki zakres zapewnia reprezentatywny zestaw do analizy, nie wydłużając nadmiernie czasu działania ani nie powodując częstego osiągania limitów API. Dłuższy okres znacznie wydłuży eksport.
Incremental Exports API: Skrypt korzysta z punktu końcowego Incremental Exports (/api/v2/incremental/tickets/cursor.json), aby sprawnie pobierać tylko zgłoszenia zaktualizowane od ostatniego uruchomienia lub wskazanego czasu początkowego. To znacznie wydajniejsze niż przeszukiwanie wszystkich zgłoszeń.
Limity zapytań: Zendesk nakłada limity na korzystanie z API. Skrypt potrafi wstrzymać działanie po osiągnięciu limitu, ale eksport bardzo dużej instancji może zająć dużo czasu. Najlepiej uruchomić go poza godzinami szczytu.
Logika eskalacji: Działanie „Zgłoszenie eskalowane” jest rozpoznawane na podstawie zmiany pola group_id. Jeśli w organizacji stosowany jest inny mechanizm, na przykład niestandardowe pole zgłoszenia, należy zmodyfikować logikę skryptu, aby prawidłowo wykrywała eskalacje.

Przykładowe zapytanie python

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

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

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

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

class=class="hl-string">"hl-comment"># Set up constants and session
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

    df = pd.DataFrame(event_log)

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

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

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

Kroki

W Zendesk Admin Center zamów lub uruchom natywny eksport pełnego konta do JSON, korzystając z funkcji eksportu dostępnej w ramach subskrypcji i konfiguracji konta Zendesk. Dokładna ścieżka w menu i wymagane uprawnienia zależą od konfiguracji konta. Skorzystaj z opcji eksportu dostępnej w Admin Center i postępuj zgodnie z procedurą zatwierdzania obowiązującą w organizacji.
Wybierz zakres dat obejmujący wymagany okres analizy, najlepiej od trzech do sześciu miesięcy. Jeśli eksport natywny nie umożliwia filtrowania po dacie, pobierz pełny eksport konta i zastosuj filtr dat podczas przekształcania danych.
Pobierz i zachowaj wszystkie pliki JSON wygenerowane podczas eksportu. Zachowaj oryginalne pliki, czas eksportu, identyfikator konta oraz plik manifestu lub metadane, jeśli są dostępne. Nie nadpisuj plików źródłowych podczas przetwarzania.
Przetwórz rekordy zgłoszeń, audyty zgłoszeń, zdarzenia audytu, komentarze, użytkowników, organizacje, grupy, rekordy związane z SLA i pola niestandardowe zawarte w eksporcie. Nazwy plików i struktura JSON mogą się różnić w zależności od wersji eksportu Zendesk, dlatego przed uruchomieniem skryptu skonfiguruj ścieżki do plików źródłowych i mapowania właściwości JSON w polach konfiguracyjnych.
Ujednolić każde zdarzenie audytu zgłoszenia do wspólnego formatu zawierającego ServiceRequestId, znacznik czasu audytu, typ zdarzenia, nazwę pola, poprzednią wartość, nową wartość, identyfikator wykonawcy, informację o publicznym charakterze, status zgłoszenia, przypisanego agenta, grupę, priorytet, kanał, typ usługi, tagi, system źródłowy i LastDataUpdate.
Utwórz jeden wiersz dziennika zdarzeń dla każdego kwalifikującego się działania. Eksport musi jawnie uwzględniać wiersze dla działań: Zgłoszenie serwisowe utworzone, Zastosowano cel SLA, Przypisano zgłoszenie do agenta, Zmieniono priorytet, Zmieniono przypisanego agenta, Wysłano odpowiedź publiczną, Dodano notatkę wewnętrzną, Wstrzymano zgłoszenie, Zgłoszenie eskalowane, Naruszono cel SLA, Ponownie otwarto zgłoszenie serwisowe, Rozwiązano zgłoszenie serwisowe i Zamknięto zgłoszenie serwisowe. ProcessMind odczytuje te wiersze bez zmian i nie wyznacza dodatkowych zdarzeń.
Jeśli to możliwe, dopasuj identyfikatory agentów, grup, organizacji i zgłaszających do odpowiednich rekordów użytkowników, grup i organizacji z eksportu. Wartości AgentName i AssignedTeam ustal na podstawie przypisania obowiązującego w chwili zdarzenia. Jeśli nie można ustalić nazwy wyświetlanej, pozostaw identyfikator lub puste pole.
Zastosuj jednoznaczne reguły przypisywania działań. Zdarzenie audytu zgłoszenia typu Create oznacza utworzenie zgłoszenia serwisowego. Jawne zdarzenia audytu SLA oznaczają zastosowanie lub naruszenie celu SLA. Pierwsza kwalifikująca się zmiana przypisanego agenta oznacza przypisanie zgłoszenia do agenta, a kolejne zmiany oznaczają zmianę przypisanego agenta. Wskaźniki komentarzy publicznych i prywatnych pozwalają rozpoznać odpowiedzi i notatki. Zmiany statusu wskazują wstrzymanie, ponowne otwarcie, rozwiązanie i zamknięcie zgłoszenia. Zmiana grupy lub skonfigurowanego pola eskalacji oznacza eskalację zgłoszenia.
Posortuj wynikowe wiersze według ServiceRequestId i EventTimestamp, a przy jednakowych znacznikach czasu zachowaj kolejność zdarzeń ze źródła. Nie usuwaj zdarzeń tylko dlatego, że mają ten sam znacznik czasu. W tej samej chwili może wystąpić kilka komentarzy lub zdarzeń audytu.
Sprawdź, czy wszystkie wymagane kolumny są obecne i czy dla każdego działania istnieje co najmniej jeden kwalifikujący się wiersz, jeśli odpowiednie zdarzenie występuje w danych źródłowych. Wyeksportuj wynik jako plik CSV w kodowaniu UTF-8 lub w innym formacie dziennika zdarzeń obsługiwanym przez ProcessMind. Każdy wiersz powinien odpowiadać jednemu zdarzeniu, a wymagane kolumny to ServiceRequestId, ActivityName, EventTimestamp, SourceSystem i LastDataUpdate.

Konfiguracja

Zakres eksportu: Użyj natywnego eksportu pełnego konta Zendesk Support do JSON i zachowaj wszystkie wygenerowane pliki JSON. Eksport powinien obejmować dane zgłoszeń oraz audyty lub zdarzenia zgłoszeń. Jeśli dane SLA, komentarze, użytkownicy, organizacje, grupy lub pola niestandardowe są dostarczane osobno, uwzględnij te pliki w danych wejściowych do transformacji.
Zakres dat: Na potrzeby początkowego eksportu i walidacji wybierz okres od trzech do sześciu miesięcy. Jeśli natywny eksport obejmuje całe konto i nie można ograniczyć go datą, po przetworzeniu zastosuj filtr EventTimestamp, zachowując pełne archiwum źródłowe.
Reguły działań: Skonfiguruj jawne mapowania dla wszystkich 13 działań. Nie zakładaj, że ProcessMind wyznaczy zdarzenia przypisania, eskalacji, SLA, zmiany statusu lub komentarza na podstawie innych wierszy.
Konfiguracja SLA: Zmapuj rzeczywiste nazwy zdarzeń lub właściwości z eksportu, które konto wykorzystuje do oznaczania zastosowania celu SLA i jego naruszenia. Jeśli eksport nie zawiera jawnych zdarzeń SLA, nie twórz ich sztucznie. Skonfiguruj odpowiednie ścieżki źródłowe w polach konfiguracyjnych i opisz niedostępne działania.
Konfiguracja eskalacji: Ustal, które pole grupy lub pole niestandardowe w danym koncie oznacza eskalację. Przed uruchomieniem ustaw ESCALATION_FIELD_ID lub równoważną opcję na rzeczywisty identyfikator pola z eksportu.
Ścieżki źródłowe: Ustaw ścieżki do plików JSON i mapowania właściwości JSON w skrypcie. Nazwy plików eksportu Zendesk i struktura zagnieżdżenia mogą się różnić w zależności od wersji eksportu i konfiguracji konta.
Wymagane dane wynikowe: W każdym wierszu zdarzenia muszą być wypełnione ServiceRequestId, ActivityName, EventTimestamp, SourceSystem i LastDataUpdate. Zalecane kolumny to AgentName, AssignedTeam, RequestPriority, RequestStatus, RequestChannel, ServiceType i TicketTags.
Filtry: Zakres dat analizy, konto lub markę oraz filtry specyficzne dla firmy stosuj dopiero po potwierdzeniu, że odpowiadają im właściwości w eksporcie. Nie filtruj na podstawie nieobsługiwanych lub niezweryfikowanych nazw pól.
Wydajność: Jeśli to możliwe, przetwarzaj pliki JSON partiami. Unikaj wczytywania całego eksportu konta do pamięci, indeksuj identyfikatory zgłoszeń i audytów oraz zapisuj ujednolicone pliki pośrednie przed utworzeniem końcowego dziennika zdarzeń. Duże eksporty mogą wymagać podziału według daty lub identyfikatora zgłoszenia.
Wymagania wstępne: Dostęp administracyjny umożliwiający zamówienie lub pobranie natywnego eksportu konta, uprawnienia do danych audytów zgłoszeń oraz danych referencyjnych użytkowników i grup, subskrypcja Zendesk obejmująca funkcję eksportu, lokalne miejsce na pełny eksport oraz środowisko umożliwiające przetwarzanie JSON i zapis plików CSV w kodowaniu UTF-8.
Ochrona danych: Dane zgłaszających, agentów, organizacji, komentarzy i zgłoszeń mogą być poufne. Pliki źródłowe i przekształcone należy przechowywać zgodnie z obowiązującymi w organizacji zasadami retencji, kontroli dostępu i ochrony prywatności.

Przykładowe zapytanie config

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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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

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

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

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

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

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


if __name__ == "__main__":
    main()

Gotowi do rozpoczęcia?

Zacznij usprawniać obsługę zgłoszeń serwisowych. Skorzystaj z tego szablonu danych, aby wykryć wąskie gardła i poprawić efektywność Zendesk Support.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usprawnij obsługę zgłoszeń serwisowych. Ogranicz opóźnienia.

Ogranicz opóźnienia w realizacji zgłoszeń i frustrację użytkowników. Osiągnij 70% automatyzacji.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty płatniczej. Szybka konfiguracja.

Szablon danych do analizy obsługi zgłoszeń serwisowych

Szablon danych do analizy obsługi zgłoszeń serwisowych

Atrybuty obsługi zgłoszeń serwisowych

Działania w procesie obsługi zgłoszeń serwisowych

Instrukcje pobierania danych

Zendesk Explore: interfejs raportowania i eksportu danych

Kroki

Konfiguracja

Przykładowe zapytanie config

Eksport danych z Zendesk REST API za pomocą skryptu Python

Kroki

Konfiguracja

Przykładowe zapytanie python

Eksport pełnego konta Zendesk Support do natywnego formatu JSON

Kroki

Konfiguracja

Przykładowe zapytanie config

Gotowi do rozpoczęcia?

Usprawnij obsługę zgłoszeń serwisowych. Ogranicz opóźnienia.