> Ciągłe doskonalenie procesów > Obsługa klienta > Zendesk Support > Szablon danych

Szablon danych dotyczących obsługi klienta

Zendesk Support

← Wróć do przewodnika ulepszania procesów

Atrybuty obsługi klienta(18) Aktywności w obsłudze klienta(14) Przewodniki po ekstrakcji danych(4)

Szablon danych dotyczących obsługi klienta

Ten szablon pomaga zebrać dane potrzebne do analizy procesu obsługi klienta. Zawiera listę najważniejszych atrybutów, które warto gromadzić, i aktywności do śledzenia, a także praktyczne wskazówki dotyczące ekstrakcji danych. Korzystając z tego przewodnika, można przygotować dziennik zdarzeń, który ułatwi wykrywanie problemów i usprawnianie obsługi.

Zalecane atrybuty do zebrania
Najważniejsze aktywności do śledzenia w procesie obsługi klienta
Wskazówki dotyczące ekstrakcji 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 klienta

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować obsługę klienta.

5 Wymagane 6 Zalecane 7 Opcjonalne

	Nazwa	Opis
	Czas rozpoczęcia StartTime	Znacznik czasu wskazujący, kiedy rozpoczęła się czynność lub wystąpiło zdarzenie.
Opis Czas rozpoczęcia, czyli znacznik czasu zdarzenia, określa dokładną datę i godzinę wystąpienia danej czynności. Może wskazywać na przykład, kiedy dodano komentarz klienta, przypisano konsultanta lub zmieniono status zgłoszenia na „Resolved”. Ten znacznik czasu ma podstawowe znaczenie w process mining, ponieważ określa chronologiczną kolejność zdarzeń. Służy do obliczania czasu między czynnościami, mierzenia czasu realizacji, analizy wyników względem SLA i badania dynamiki procesu obsługi. Dlaczego to ważne Ten znacznik czasu jest niezbędny do ustalania kolejności zdarzeń, obliczania czasu trwania i analizy przebiegu obsługi zgłoszenia. Skąd pobrać Zendesk Ticket Audits API, pole `created_at` dla każdego zdarzenia w ścieżce audytu. Przykłady 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Zgłoszenie klienta ServiceRequest	Unikalny identyfikator każdego zgłoszenia klienta, nazywanego również ticketem lub sprawą.
Opis Service Request to główny identyfikator sprawy, który łączy wszystkie czynności dotyczące jednego zapytania lub problemu klienta, od utworzenia zgłoszenia do jego ostatecznego rozwiązania. Każda interakcja, aktualizacja i czynność wewnętrzna są powiązane z tym unikalnym identyfikatorem. W process mining analiza zdarzeń pogrupowanych według Service Request pozwala odtworzyć pełny przebieg obsługi klienta. To podstawa obliczania ważnych wskaźników, takich jak całkowity czas rozwiązania, wykrywania odstępstw od procesu i analizy cyklu życia każdego problemu klienta. Dlaczego to ważne To niezbędny identyfikator sprawy (Case ID), który łączy wszystkie etapy procesu i umożliwia odtworzenie oraz analizę przebiegu obsługi każdego klienta. Skąd pobrać Zendesk Tickets API, pole `id`. Przykłady 102451287415332
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu ostatniego odświeżenia danych lub ich wyodrębnienia z systemu źródłowego.
Opis Ten atrybut wskazuje, kiedy dane zostały ostatnio zaktualizowane z Zendesk Support. Informuje, jak aktualny jest analizowany zbiór danych. Znajomość daty ostatniej aktualizacji pomaga analitykom i użytkownikom biznesowym ocenić, czy przeglądają najnowsze informacje o procesie. Ułatwia określenie aktualności danych i ma znaczenie przy raportowaniu oraz monitorowaniu. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak aktualna jest analiza procesu. Skąd pobrać To pole metadanych generowane i zapisywane podczas wyodrębniania danych. Zawiera znacznik czasu zadania eksportu. Przykłady 2023-10-27T02:00:00Z
	Nazwa czynności ActivityName	Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w cyklu obsługi zgłoszenia.
Opis Nazwa czynności opisuje pojedynczy etap lub ważny moment w procesie obsługi klienta, na przykład „Utworzono zgłoszenie klienta”, „Przypisano zgłoszenie konsultantowi” lub „Rozwiązano zgłoszenie klienta”. Zdarzenia mają znaczniki czasu i tworzą sekwencję działań dla każdego zgłoszenia. Ten atrybut jest niezbędny do wizualizacji przebiegu procesu, wykrywania jego wariantów oraz analizy częstotliwości i kolejności zdarzeń. Pozwala analitykom sprawdzić, jakie czynności są wykonywane, a także wykryć typowe ścieżki, wąskie gardła i odstępstwa od standardowej procedury. Dlaczego to ważne Ten atrybut określa etapy procesu, umożliwiając wizualizację mapy procesu oraz analizę jego przebiegu i wariantów. Skąd pobrać Dane pochodzą z dzienników audytu zgłoszeń Zendesk lub strumieni zdarzeń rejestrujących zmiany i czynności. Przykłady Utworzono zgłoszenie klientaPrzypisano zgłoszenie konsultantowiWysłano pierwszą publiczną odpowiedź konsultantaRozwiązano zgłoszenie klienta
	System źródłowy SourceSystem	System, z którego wyodrębniono dane i który jest ich źródłem.
Opis Ten atrybut wskazuje system źródłowy danych dotyczących zgłoszeń, w tym przypadku Zendesk Support. Pomaga zarządzać danymi i śledzić ich pochodzenie, zwłaszcza gdy łączone są dane z wielu systemów. W analizie pozwala prawidłowo przypisać dane do źródła. Ma to znaczenie dla zachowania integralności danych i zrozumienia kontekstu procesu, szczególnie w środowiskach korzystających z wielu systemów. Dlaczego to ważne Wskazuje pochodzenie danych, co ma znaczenie dla zarządzania danymi i rozróżniania danych procesowych w zintegrowanych środowiskach. Skąd pobrać To stała wartość dodawana podczas wyodrębniania danych w celu oznaczenia ich źródła. Przykłady Zendesk Support
	Czy przekroczono SLA IsSlaBreached	Wartość logiczna wskazująca, czy czas rozwiązania zgłoszenia przekroczył cel określony w SLA.
Opis Ten obliczany atrybut przyjmuje wartość prawda lub fałsz i wskazuje, czy zgłoszenie zostało rozwiązane w czasie określonym w umowie SLA. Jest wyznaczany przez porównanie rzeczywistego czasu rozwiązania z docelowym czasem SLA. Ułatwia analizę zgodności z SLA. Jest podstawową daną na dashboardzie „Realizacja SLA” i przy obliczaniu KPI „Odsetek zgłoszeń zgodnych z SLA”. Pozwala szybko podsumować i przedstawić, ile zgłoszeń spełnia wymagania dotyczące czasu obsługi, a ile nie. Dlaczego to ważne Jednoznacznie wskazuje, czy dane zgłoszenie spełniło wymagania SLA. Ułatwia monitorowanie zgodności i raportowanie. Skąd pobrać Obliczany podczas przekształcania danych przez porównanie całkowitego czasu rozwiązania z wartością SlaTargetResolutionTime. Przykłady truefalse
	Docelowy czas rozwiązania zgodny z SLA SlaTargetResolutionTime	Docelowy czas, w którym zgłoszenie powinno zostać rozwiązane zgodnie z zasadami SLA.
Opis Ten atrybut określa docelowy czas rozwiązania zgłoszenia wynikający z umowy SLA. Wartość często zależy od takich czynników jak priorytet i typ zgłoszenia czy plan obsługi klienta. To podstawowy atrybut dashboardu „Realizacja SLA”. Stanowi punkt odniesienia przy porównywaniu docelowego i rzeczywistego czasu rozwiązania. Analiza wyników względem tego celu pozwala ocenić jakość obsługi i sprawdzić, czy zobowiązania wobec klientów są dotrzymywane. Dlaczego to ważne Określa zobowiązany wobec klienta czas obsługi i stanowi punkt odniesienia przy ocenie terminowości oraz zgodności z SLA. Skąd pobrać Wartość wynika z zasad SLA przypisanych do zgłoszenia. Można ją pobrać za pośrednictwem Zendesk Ticket Metrics API. Przykłady 144002880086400
	Kanał komunikacji CommunicationChannel	Kanał, za pośrednictwem którego przesłano zgłoszenie lub prowadzono komunikację.
Opis Ten atrybut określa sposób komunikacji, na przykład przez e-mail, formularz internetowy, czat lub telefon. Pokazuje, jak klienci kontaktują się z działem obsługi. Wiedza o tym, z których kanałów klienci korzystają najczęściej, pomaga planować zasoby i poprawiać ich doświadczenia. Dashboard „Przegląd wykorzystania kanałów komunikacji” analizuje te dane, aby wskazać najpopularniejsze kanały oraz sprawdzić, czy któryś z nich wiąże się z dłuższym czasem rozwiązania zgłoszenia lub innym przebiegiem procesu. Wyniki mogą pomóc zdecydować, w które usprawnienia obsługi lub automatyzację warto inwestować. Dlaczego to ważne Pokazuje, jak klienci i konsultanci komunikują się ze sobą. Umożliwia analizę efektywności kanałów oraz ich wpływu na proces i doświadczenia klientów. Skąd pobrać Zendesk Tickets API, pole `via.channel`. Przykłady InternetE-mailAPICzat
	Priorytet Priority	Poziom priorytetu przypisany do zgłoszenia, na przykład „Niski”, „Normalny”, „Wysoki” lub „Pilny”.
Opis Priorytet określa pilność zgłoszenia i często wpływa na jego miejsce w kolejce oraz docelowy czas rozwiązania. Pomaga konsultantom w pierwszej kolejności zająć się najpilniejszymi problemami. Ten atrybut jest niezbędny do analizy wyników i SLA. Dashboard „Analiza czasu rozwiązywania zgłoszeń” wykorzystuje priorytet do podziału danych. Pokazuje, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej niż te o niższym priorytecie oraz czy zasoby są przydzielane zgodnie z potrzebami firmy. Dlaczego to ważne Określa pilność zgłoszenia. Ma to znaczenie przy analizie zgodności z SLA i szybkim reagowaniu na pilne problemy. Skąd pobrać Zendesk Tickets API, pole `priority`. Przykłady NiskiNormalnyWysokiPilny
	Przypisany konsultant AssignedAgent	Imię i nazwisko lub identyfikator konsultanta przypisanego do obsługi zgłoszenia.
Opis Ten atrybut wskazuje konsultanta odpowiedzialnego za daną czynność lub zgłoszenie w określonym momencie. W trakcie obsługi może się zmieniać, jeśli zgłoszenie zostanie ponownie przypisane. Analiza według przypisanego konsultanta pomaga zrozumieć obciążenie pracą, wyniki i efektywność poszczególnych osób. Wspiera dashboard „Obciążenie pracą i efektywność konsultantów”, umożliwiając porównanie czasu obsługi i liczby spraw przypisanych różnym konsultantom. Ułatwia to wskazanie potrzeb szkoleniowych i równomierne rozłożenie pracy. Dlaczego to ważne Wskazuje, który konsultant wykonał daną czynność, umożliwiając analizę indywidualnych wyników, rozkładu obciążenia pracą i przydziału zasobów. Skąd pobrać Zendesk Tickets API, pole `assignee_id`. Dane użytkowników można pobrać z Users API. Przykłady Jan KowalskiAnna NowakSupportBot
	Typ zgłoszenia klienta ServiceRequestType	Klasyfikacja zgłoszenia, na przykład „Pytanie”, „Incydent”, „Problem” lub „Zadanie”.
Opis Ten atrybut klasyfikuje zgłoszenie według jego charakteru. Typ jest zwykle określany podczas tworzenia lub wstępnej kwalifikacji zgłoszenia i pomaga ustalić odpowiedni workflow oraz priorytet. Podział analizy według typu zgłoszenia klienta ma podstawowe znaczenie. Umożliwia porównanie czasu rozwiązania, odsetka eskalacji i przebiegu procesu dla różnych rodzajów problemów, jak na dashboardach „Analiza czasu rozwiązywania zgłoszeń” oraz „Odsetek i przyczyny eskalacji wewnętrznych”. Dzięki temu można ustalić, które typy zgłoszeń są trudniejsze lub mniej efektywne w obsłudze. Dlaczego to ważne Klasyfikuje zgłoszenia, umożliwiając porównywanie wyników i analizę różnych typów problemów. To ważne przy ukierunkowanym usprawnianiu procesu. Skąd pobrać Zendesk Tickets API, pole `type`. Przykłady PytanieIncydentProblemZadanie
	Czas zakończenia EndTime	Znacznik czasu wskazujący, kiedy zakończono czynność lub zdarzenie.
Opis Czas zakończenia wskazuje, kiedy czynność dobiegła końca. W wielu strukturach dziennika zdarzeń za czas zakończenia bieżącej czynności można przyjąć czas rozpoczęcia następnej. W przypadku czynności opisujących stan, takich jak „Konsultant analizuje problem”, wskazuje moment zakończenia tego stanu. Ten atrybut jest niezbędny do dokładnego obliczania czasu trwania czynności, co stanowi podstawę analizy wyników. Pomaga wykryć najbardziej czasochłonne etapy oraz przeprowadzić szczegółową analizę wąskich gardeł i efektywności wykorzystania zasobów. Dlaczego to ważne Umożliwia obliczanie czasu trwania czynności, co ma zasadnicze znaczenie przy wykrywaniu wąskich gardeł i pomiarze wyników. Skąd pobrać Często wyznacza się go na podstawie czasu rozpoczęcia kolejnego zdarzenia w sekwencji dla danego Service Request. Przykłady 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Czy ponownie otwarto IsReopened	Wartość logiczna wskazująca, czy zgłoszenie ponownie otwarto po oznaczeniu go jako rozwiązane.
Opis Ten atrybut przyjmuje wartość prawda, gdy zgłoszenie wraca do statusu otwartego po wcześniejszym oznaczeniu jako rozwiązane lub zamknięte. Oznacza to, że pierwsze rozwiązanie nie wystarczyło. Pomaga śledzić ponowną pracę nad zgłoszeniem i przypadki, w których nie udało się go rozwiązać przy pierwszym kontakcie. Wspiera dashboard „Trendy ponownie otwieranych zgłoszeń” oraz KPI „Odsetek ponownie otwartych zgłoszeń”. Ułatwia zliczanie i analizę spraw wymagających dodatkowej uwagi, co często wskazuje na głębsze problemy. Dlaczego to ważne Wskazuje ponowną pracę i nieskuteczne rozwiązania, pomagając ocenić jakość i skuteczność udzielonej pomocy. Skąd pobrać Obliczany podczas przekształcania danych przez sprawdzenie, czy status zgłoszenia zmienił się z „resolved” lub „closed” na „open”. Przykłady truefalse
	Grupa konsultantów AgentGroup	Grupa lub zespół obsługi, do którego przypisano zgłoszenie.
Opis Ten atrybut wskazuje zespół konsultantów odpowiedzialny za zgłoszenie. Zgłoszenia są często kierowane do konkretnych grup na podstawie kompetencji, obszaru produktu lub języka. Analiza według grup konsultantów pozwala ocenić wyniki zespołów, rozkład obciążenia i przekazywanie zgłoszeń między zespołami. Daje szerszy obraz niż analiza pracy poszczególnych konsultantów i może pomóc wykryć problemy systemowe w konkretnych działach lub obszarach. Dlaczego to ważne Wskazuje zespół odpowiedzialny za zgłoszenie. Umożliwia analizę wyników grup, przekazywania spraw między zespołami oraz przydziału zasobów do różnych poziomów obsługi i specjalizacji. Skąd pobrać Zendesk Tickets API, pole `group_id`. Szczegóły grup można pobrać z Groups API. Przykłady Obsługa pierwszej liniiWsparcie techniczneRozliczenia
	Kategoria produktu lub usługi ProductServiceCategory	Produkt, usługa lub funkcja, której dotyczy zgłoszenie klienta.
Opis Ten atrybut pozwala dokładniej opisać zgłoszenie, przypisując je do obszaru produktu lub usługi. Kategorię często wybiera konsultant albo system ustala ją automatycznie na podstawie treści zgłoszenia. Kategoryzacja jest ważna dla dashboardów „Trafność kategoryzacji zgłoszeń” i „Czas analizy według kategorii”. Pozwala sprawdzić, które produkty generują najwięcej zgłoszeń, które sprawiają najwięcej trudności przy rozwiązywaniu oraz czy początkowa kategoria zgadza się z ostatecznym rozwiązaniem. Wyniki mogą pomóc usprawnić kierowanie zgłoszeń i szkolenia konsultantów. Dlaczego to ważne Łączy zgłoszenia z konkretnymi obszarami działalności, produktami lub usługami. Ułatwia analizę problematycznych obszarów i ich wpływu na proces. Skąd pobrać Zazwyczaj jest to niestandardowe pole zgłoszenia w Zendesk. Dokładna nazwa zależy od konfiguracji systemu. Przykłady Aplikacja mobilnaZarządzanie subskrypcjamiIntegracja APISprzęt
	Kod rozwiązania ResolutionCode	Kod lub kategoria określająca powód ostatecznego rozwiązania albo zamknięcia zgłoszenia.
Opis Kod rozwiązania opisuje w uporządkowany sposób wynik obsługi zgłoszenia. Przykładowe wartości to „Rozwiązane przez konsultanta”, „Duplikat”, „Nie wymaga działania” i „Znany problem”. Dostarcza więcej informacji niż sam status „Zamknięte”. Atrybut ten jest szczególnie przydatny w analizie przyczyn źródłowych. Na dashboardzie „Trendy ponownie otwieranych zgłoszeń” można porównać odsetek ponownie otwartych zgłoszeń według kodu rozwiązania. Dzięki temu można sprawdzić, czy niektóre sposoby rozwiązania są mniej skuteczne i powodują, że klienci ponownie kontaktują się z obsługą. Dlaczego to ważne Informuje o wyniku obsługi zgłoszenia. Pomaga analizować przyczyny źródłowe i ustalić, dlaczego zgłoszenia są ponownie otwierane. Skąd pobrać Zazwyczaj jest to niestandardowe pole zgłoszenia w Zendesk. Dokładna nazwa zależy od konfiguracji systemu. Przykłady Rozwiązanie przy pierwszym kontakciePrzekazano do zespołu drugiej liniiOczekiwanie na klientaBłąd produktu
	Liczba próśb o informacje InformationRequestCount	Łączna liczba próśb o przekazanie informacji skierowanych do klienta w ramach jednego zgłoszenia.
Opis Ten obliczany miernik zlicza wystąpienia aktywności „Poproszono klienta o informacje” dla każdego zgłoszenia. Wysoka wartość może oznaczać, że konsultanci nie zbierają wszystkich potrzebnych informacji na początku obsługi. Atrybut jest wykorzystywany na dashboardzie „Analiza ponownych próśb o informacje”. Śledzenie tej liczby pomaga wykrywać nieefektywności procesu i wskazywać obszary, w których konsultanci potrzebują szkoleń. Ograniczenie liczby próśb o informacje może znacznie skrócić czas rozwiązania i poprawić doświadczenia klientów. Dlaczego to ważne Mierzy liczbę wymian informacji z klientem. Pomaga wykryć nieefektywności, które wydłużają czas rozwiązania i pogarszają doświadczenia klientów. Skąd pobrać Obliczany przez zliczenie zdarzeń, w których ActivityName ma wartość „Information Requested From Customer”, dla każdego zgłoszenia serwisowego. Przykłady 013
	Ocena satysfakcji SatisfactionRating	Ocena wystawiona przez klienta po rozwiązaniu zgłoszenia.
Opis Ten atrybut rejestruje opinię klienta o obsłudze, zwykle zebraną w ankiecie po rozwiązaniu zgłoszenia. Typowe odpowiedzi to „Dobrze”, „Źle” lub ocena liczbowa. To bezpośredni miernik opinii klienta i jeden z mierników wyniku procesu. Służy do obliczania KPI „Ocena satysfakcji klienta”. Zestawienie ocen z danymi o procesie, takimi jak czas rozwiązania czy liczba kontaktów z konsultantem, może pokazać, które sposoby obsługi prowadzą do lepszych rezultatów dla klientów. Dlaczego to ważne Bezpośrednio mierzy opinię klienta o obsłudze i pozwala powiązać wyniki procesu z rezultatami dla klienta. Skąd pobrać Zendesk Tickets API, pole `satisfaction_rating.score`. Przykłady dobrazłazaproponowano

Wymagane Zalecane Opcjonalne

Aktywności w obsłudze klienta

To najważniejsze kroki procesu i kamienie milowe, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkryć przebieg procesu obsługi klienta.

6 Zalecane 8 Opcjonalne

	Działanie	Opis
	Ponownie otwarto zgłoszenie klienta	To zdarzenie występuje, gdy klient odpowiada na zgłoszenie o statusie „solved”. Zendesk automatycznie zmienia wtedy status na „open”, co oznacza, że problem nie został w pełni rozwiązany.
Dlaczego to ważne Ponowne otwarcia wskazują na niepowodzenie rozwiązania sprawy przy pierwszym kontakcie i niską jakość rozwiązania. Analiza ich częstotliwości i przyczyn pomaga określić, jak poprawić szkolenia konsultantów i procedury rozwiązywania zgłoszeń. Skąd pobrać To jawna zmiana statusu w Ticket Audits API, rejestrowana, gdy status zmienia się z „solved” z powrotem na „open”. Rejestrowanie Śledź zdarzenia „Change” zmieniające status z „solved” na „open”. Typ zdarzenia explicit
	Poproszono klienta o dodatkowe informacje	Zdarzenie występuje, gdy konsultant potrzebuje dodatkowych informacji od klienta, aby kontynuować obsługę, i zmienia status zgłoszenia na „pending”. Ta zmiana statusu oznacza, że proces oczekuje na odpowiedź strony zewnętrznej.
Dlaczego to ważne To zdarzenie pokazuje zależność od klienta i wstrzymuje wewnętrzne zegary SLA. Częste lub powtarzające się prośby w ramach jednego zgłoszenia mogą świadczyć o niepełnym zebraniu informacji na początku i wydłużać czas rozwiązania. Skąd pobrać To jawne zdarzenie zmiany statusu zapisane w Zendesk Ticket Audits API. Jest rejestrowane, gdy pole „status” zmienia się na „pending”. Rejestrowanie Znajdź zdarzenia „Change” w Ticket Audits, w których status zgłoszenia zmienia się na „pending”. Typ zdarzenia explicit
	Przypisano zgłoszenie konsultantowi	To zdarzenie oznacza przypisanie zgłoszenia do konkretnego konsultanta. Może nastąpić automatycznie na podstawie reguł kierowania lub ręcznie, przez lidera zespołu albo konsultanta.
Dlaczego to ważne Przypisanie zgłoszenia jest ważnym etapem z punktu widzenia odpowiedzialności i zarządzania obciążeniem pracą. Analiza czasu do przypisania i wzorców ponownego przypisywania ujawnia wąskie gardła w kwalifikacji i dystrybucji zgłoszeń. Skąd pobrać To jawne zdarzenie „Change” w Zendesk Ticket Audits API, rejestrowane za każdym razem, gdy pole „assignee_id” zostaje wypełnione lub zmienione. Rejestrowanie Śledź zmiany pola „assignee_id” w dzienniku Ticket Audits. Typ zdarzenia explicit
	Rozwiązano zgłoszenie klienta	Po przedstawieniu klientowi rozwiązania konsultant oznacza zgłoszenie jako „solved”. Jest to status tymczasowy, ponieważ klient może ponownie otworzyć zgłoszenie, zanim zostanie ono trwale zamknięte.
Dlaczego to ważne To główny punkt pomiaru czasu rozwiązania i efektywności pracy konsultanta. Oznacza moment, w którym konsultant uznaje sprawę za zakończoną. Jeśli zgłoszenie zostanie ponownie otwarte, można na tej podstawie analizować konieczność ponownej pracy. Skąd pobrać To jawna zmiana statusu zapisana w Zendesk Ticket Audits API, gdy pole „status” zostaje ustawione na „solved”. Rejestrowanie Znajdź zdarzenia „Change” w Ticket Audits, w których status zgłoszenia zmienia się na „solved”. Typ zdarzenia explicit
	Utworzono zgłoszenie klienta	To zdarzenie rozpoczyna proces obsługi klienta. W Zendesk powstaje nowe zgłoszenie z kanału takiego jak e-mail, formularz internetowy lub czat. System zapisuje je w chwili utworzenia, nadając unikalny identyfikator i znacznik czasu.
Dlaczego to ważne Jako główne zdarzenie początkowe pozwala obliczyć całkowity czas obsługi sprawy i analizować liczbę napływających zgłoszeń w czasie. Stanowi punkt odniesienia przy pomiarze KPI, takich jak czas do pierwszej odpowiedzi i całkowity czas rozwiązania. Skąd pobrać To jawne zdarzenie zapisane w Ticket Audits API Zendesk. Odpowiada zdarzeniu „Create” dla zgłoszenia i zawiera początkowy znacznik czasu jego utworzenia. Rejestrowanie Dane pochodzą ze zdarzenia utworzenia zgłoszenia w dzienniku Ticket Audits. Typ zdarzenia explicit
	Zamknięto zgłoszenie klienta	To ostatnia czynność, która oznacza trwałe zamknięcie zgłoszenia. Zwykle następuje automatycznie po upływie określonego czasu od oznaczenia zgłoszenia jako „solved”, jeśli klient nie prześle kolejnej odpowiedzi.
Dlaczego to ważne To ostateczne zdarzenie kończące cykl życia zgłoszenia. Czas od statusu „solved” do „closed” wyznacza okres, w którym zgłoszenie może zostać ponownie otwarte. Zdarzenie „closed” potwierdza, że rozwiązanie zostało zaakceptowane. Skąd pobrać To jawna zmiana statusu zapisana w Zendesk Ticket Audits API, gdy pole „status” zostaje ustawione na „closed”. Rejestrowanie Znajdź zdarzenia „Change” w Ticket Audits, w których status zgłoszenia zmienia się na „closed”. Typ zdarzenia explicit
	Klient odpowiedział	To zdarzenie występuje, gdy klient odpowiada na zgłoszenie, zwykle mające status „pending”. Zendesk automatycznie zmienia wtedy status z „pending” na „open”, sygnalizując, że konsultant może wznowić pracę.
Dlaczego to ważne To zdarzenie kończy czas oczekiwania i pozwala kontynuować proces. Analiza czasu odpowiedzi klientów może pomóc ocenić, czy prośby konsultantów są jasne. Skąd pobrać Zdarzenie odpowiada nowemu publicznemu komentarzowi użytkownika końcowego, który powoduje jawną zmianę statusu z „pending” na „open” w Zendesk Ticket Audits API. Rejestrowanie Śledź zdarzenia „Change” zmieniające status z „pending” na „open” lub wyszukaj nowe publiczne komentarze użytkownika końcowego. Typ zdarzenia explicit
	Naruszono SLA	To zdarzenie wskazuje moment, w którym zgłoszenie nie spełnia wymagań określonych w umowie SLA, na przykład dotyczących czasu do pierwszej odpowiedzi lub czasu rozwiązania. Jest obliczane na podstawie znaczników czasu zdarzeń w zgłoszeniu i porównywane z zasadami SLA.
Dlaczego to ważne Naruszenia SLA bezpośrednio wpływają na satysfakcję klientów i zgodność z warunkami umów. Analiza tego, kiedy i dlaczego do nich dochodzi, pomaga wykryć systemowe opóźnienia, niedobór zasobów lub nierealne cele dotyczące wyników. Skąd pobrać Dane można pobrać z Zendesk Ticket Metrics API, które przechowuje znaczniki czasu naruszenia SLA („breached_at”). Można je też obliczyć, porównując znaczniki czasu zdarzeń w zgłoszeniu z określonymi zasadami SLA. Rejestrowanie Użyj znacznika czasu „breached_at” z Ticket Metrics API albo oblicz naruszenie, porównując czas rozwiązania z limitem określonym w zasadach SLA. Typ zdarzenia calculated
	Otrzymano ocenę satysfakcji	To zdarzenie występuje, gdy klient wypełnia ankietę satysfakcji i przesyła ocenę, na przykład „Good” lub „Bad”. Ocena i ewentualny komentarz są zapisywane przy zgłoszeniu.
Dlaczego to ważne Bezpośrednie opinie klientów są cennym źródłem informacji o jakości obsługi i nastawieniu klientów. Analiza ocen w kontekście przebiegu procesu pozwala powiązać konkretne czynności lub konsultantów z uzyskanymi wynikami. Skąd pobrać Zdarzenie jest zapisywane jako „Change” w Zendesk Ticket Audits API, gdy pole „satisfaction_rating” zostaje uzupełnione oceną i komentarzem klienta. Rejestrowanie Przefiltruj dzienniki Ticket Audit i wyszukaj zmiany pola „satisfaction_rating”. Typ zdarzenia explicit
	Rozpoczęto eskalację wewnętrzną	To przekazanie zgłoszenia do innego zespołu wewnętrznego lub zespołu wsparcia wyższego poziomu. Zwykle można je rozpoznać po zmianie grupy przypisanej do zgłoszenia.
Dlaczego to ważne Śledzenie eskalacji pomaga wykrywać słabe punkty procesu, braki wiedzy w pierwszej linii wsparcia i złożone typy zgłoszeń. Wysoki odsetek eskalacji może wskazywać na potrzebę lepszych szkoleń lub dokumentacji procesu. Skąd pobrać Zdarzenie można wywnioskować ze zdarzenia „Change” w Zendesk Ticket Audits API, które modyfikuje pole „group_id”. Zmiana grupy oznacza przekazanie sprawy między zespołami. Rejestrowanie Monitoruj zmiany pola „group_id” w dzienniku Ticket Audits. Typ zdarzenia inferred
	Skategoryzowano i ustalono priorytet zgłoszenia	To zdarzenie występuje, gdy konsultant lub automatyzacja ustawia albo aktualizuje pola zgłoszenia, takie jak typ, kategoria i priorytet. Zmiana jest zapisywana w historii zgłoszenia.
Dlaczego to ważne Prawidłowa kategoryzacja i ustalenie priorytetu są niezbędne do sprawnego kierowania zgłoszeń i przydzielania zasobów. Analiza tego zdarzenia pomaga ocenić trafność wstępnej kwalifikacji i jej wpływ na czas rozwiązania. Skąd pobrać Zdarzenie jest rejestrowane w Zendesk Ticket Audits API jako „Change”. Można je rozpoznać po pierwszej aktualizacji pól takich jak „priority”, „type” lub niestandardowe pola związane z kategoryzacją. Rejestrowanie Przefiltruj dzienniki Ticket Audit i znajdź pierwsze zdarzenie „Change” dotyczące ważnych pól kategoryzacji po utworzeniu zgłoszenia. Typ zdarzenia explicit
	Wysłano ankietę satysfakcji	To moment, w którym do klienta automatycznie wysyłana jest ankieta satysfakcji (CSAT). Zwykle następuje to krótko po oznaczeniu zgłoszenia jako „solved”.
Dlaczego to ważne To zdarzenie rozpoczyna zbieranie opinii klientów. Informacja o tym, kiedy i czy ankieta została wysłana, pomaga właściwie interpretować wyniki satysfakcji i oceniać skuteczność programu zbierania opinii. Skąd pobrać Zdarzenie można wywnioskować z dziennika automatyzacji lub rozpoznać po dodaniu do zgłoszenia określonego tagu. Sekcja „satisfaction_rating” w Zendesk Ticket Audits API również zapisuje moment wysłania ankiety. Rejestrowanie Wyszukaj tagi takie jak „csat_sent” lub użyj znacznika czasu wskazującego, kiedy poproszono o ocenę satysfakcji. Typ zdarzenia inferred
	Wysłano pierwszą publiczną odpowiedź konsultanta	To zdarzenie oznacza pierwszą publiczną odpowiedź konsultanta skierowaną do klienta, a nie automatyczne potwierdzenie. Wskazuje, kiedy konsultant po raz pierwszy zajął się problemem klienta.
Dlaczego to ważne To ważny punkt pomiaru SLA „First Reply Time”, czyli czasu do pierwszej odpowiedzi. Wskaźnik ten pokazuje szybkość obsługi i odróżnia komunikację automatyczną od rozpoczęcia aktywnej analizy i pomocy ze strony konsultanta. Skąd pobrać Zdarzenie można zidentyfikować jako pierwszy publiczny komentarz w strumieniu Ticket Comments, którego autorem jest konsultant, a nie użytkownik systemu automatycznego. Rejestrowanie Przejrzyj komentarze do zgłoszenia, wybierz publiczne komentarze konsultantów i wskaż ten z najwcześniejszym znacznikiem czasu. Typ zdarzenia inferred
	Wysłano wstępne potwierdzenie	To automatyczna pierwsza odpowiedź wysłana klientowi w celu potwierdzenia otrzymania zgłoszenia. Zwykle odpowiada za nią reguła Zendesk, która zaraz po utworzeniu zgłoszenia wysyła wiadomość e-mail z gotowym szablonem.
Dlaczego to ważne Śledzenie tego zdarzenia jest ważne przy pomiarze szybkości pierwszej reakcji i zarządzaniu oczekiwaniami klientów. Czas od utworzenia zgłoszenia do wysłania potwierdzenia to istotny miernik satysfakcji klienta. Skąd pobrać Zdarzenie można wywnioskować na podstawie pierwszego publicznego komentarza do zgłoszenia, jeśli jego autorem jest użytkownik automatyczny lub komentarz pojawił się w ciągu kilku sekund od utworzenia zgłoszenia. Można je zidentyfikować, analizując strumień Ticket Comments. Rejestrowanie Znajdź pierwszy publiczny komentarz dodany przez automatyzację lub regułę bezpośrednio po utworzeniu zgłoszenia. Typ zdarzenia inferred

Zalecane Opcjonalne

Przewodniki po ekstrakcji danych

Jak pobrać dane z Zendesk Support

Kroki

Otwórz Zendesk Explore: Zaloguj się do instancji Zendesk. Kliknij ikonę uruchamiania produktów na górnym pasku i wybierz Explore.
Utwórz zapytanie: W Explore kliknij ikonę Queries na lewym pasku bocznym, a następnie przycisk „New query” w prawym górnym rogu.
Wybierz zestaw danych: W oknie „Choose a dataset” wybierz zestaw danych Support: Tickets. Zawiera on podstawowe atrybuty zgłoszeń i najważniejsze znaczniki czasu zdarzeń.
Dodaj miary: W kreatorze zapytań przejdź do panelu „Metrics” i kliknij „Add”. Wybierz COUNT(Tickets), aby sprawdzić liczbę rekordów.
Dodaj atrybuty do wierszy: Przejdź do panelu „Rows” i kliknij „Add”. Dodaj poniższe atrybuty. Utworzą one podstawowe kolumny eksportu w układzie szerokim.
- Ticket ID (identyfikator sprawy, ServiceRequest)
- Assignee name (AssignedAgent)
- Ticket type (ServiceRequestType)
- Ticket priority (Priority)
- Ticket channel (CommunicationChannel)
- SLA resolution time (SlaTargetResolutionTime)
- SLA breach status (IsSlaBreached)
- Full resolution time (min) (ServiceRequestResolutionTime)
Dodaj znaczniki czasu aktywności do wierszy: Dodaj poniższe atrybuty czasu do panelu „Rows”. Każdy z nich odpowiada potencjalnej aktywności. W przypadku niektórych aktywności trzeba utworzyć własny atrybut obliczany.
- Ticket created - Timestamp: dla aktywności Service Request Created i Initial Acknowledgment Sent.
- Ticket assigned - Timestamp: dla aktywności Request Assigned To Agent.
- First reply time - Timestamp: dla aktywności First Agent Public Reply Sent.
- Ticket solved - Timestamp: dla aktywności Service Request Resolved i Satisfaction Survey Sent.
- Ticket reopened - Timestamp: dla aktywności Service Request Reopened.
- Satisfaction rating received - Timestamp: dla aktywności Satisfaction Rating Received.
- Ticket closed - Timestamp: dla aktywności Service Request Closed.
Utwórz własne atrybuty obliczane dla pozostałych aktywności: Niektóre aktywności wynikają ze zmian konkretnych pól. Aby zapisać ich znaczniki czasu, trzeba utworzyć własne atrybuty. Otwórz menu Calculations (ikona kalkulatora) i wybierz „Standard calculated attribute”. Utwórz po jednym atrybucie dla każdej z poniższych aktywności. Dokładne nazwy pól i wartości należy sprawdzić w instancji Zendesk.
- Nazwa: Timestamp - Categorized and Prioritized. Formuła: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Po utworzeniu dodaj atrybut do panelu „Rows” i ustaw agregator MIN.
- Nazwa: Timestamp - Info Requested. Formuła: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Dodaj atrybut do „Rows” i ustaw agregator MIN.
- Nazwa: Timestamp - Customer Responded. Formuła: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Dodaj atrybut do „Rows” i ustaw agregator MIN.
- Nazwa: Timestamp - Escalated. Formuła: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Dodaj atrybut do „Rows” i ustaw agregator MIN.
- Nazwa: Timestamp - SLA Breach. Formuła: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Dodaj atrybut do „Rows” i ustaw agregator MIN.
Odfiltruj dane: Przejdź do panelu „Filters” i kliknij „Add”. Dodaj filtr dla Ticket created - Date i wybierz odpowiedni zakres, na przykład ostatnie 3–6 miesięcy, aby ograniczyć wielkość zestawu danych.
Uruchom i wyeksportuj raport: Kliknij „Save”, aby uruchomić zapytanie. Gdy pojawi się tabela z danymi, kliknij „Export” i wybierz format, na przykład CSV lub Excel.
Przekształć dane do formatu dziennika zdarzeń: Wyeksportowany plik ma układ szeroki: każdy wiersz odpowiada zgłoszeniu, a każda kolumna znacznikowi czasu zdarzenia. Na potrzeby process mining trzeba przekształcić go do układu długiego. Można użyć Microsoft Excel (funkcja Unpivot w Power Query), Pythona lub innego narzędzia do przygotowania danych.
- Dla każdego zgłoszenia utwórz osobny wiersz dla każdej kolumny ze znacznikiem czasu, która nie jest pusta.
- Tabela wynikowa powinna zawierać kolumny takie jak ServiceRequest, ActivityName, StartTime i pozostałe atrybuty. Wartości pozostałych atrybutów należy powielić dla każdej aktywności danego zgłoszenia.

Konfiguracja

Zestaw danych: Podstawowym zestawem danych jest Support: Tickets. Pozwala pobrać większość właściwości zgłoszeń i najważniejsze znaczniki czasu w jednym zapytaniu.
Uprawnienia: Do tworzenia i zapisywania zapytań w Zendesk Explore potrzebna jest co najmniej rola Editor lub Admin.
Zakres dat: Należy ustawić filtr zakresu dat dla Ticket created - Date. Zalecany zakres to 3–6 miesięcy, co pozwala zachować równowagę między zakresem analizy a wydajnością. Eksport milionów zgłoszeń może trwać długo lub zakończyć się niepowodzeniem.
Filtry zapytania: Warto dodać filtry dotyczące konkretnych właściwości zgłoszeń, takich jak Ticket brand, Ticket form lub Ticket group, aby skupić analizę na wybranej usłudze lub zespole.
Atrybuty obliczane: Ta metoda w dużej mierze opiera się na standardowych atrybutach obliczanych, które zapisują znaczniki czasu zdarzeń niedostępnych jako domyślne atrybuty, na przykład zmian statusu lub eskalacji. Należy upewnić się, że dostępne są uprawnienia do tworzenia tych atrybutów.

Przykładowe zapytanie config

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

**Dataset**: `Support: Tickets`

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

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

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

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

Kroki

Przygotuj dostęp do Zendesk API: Zaloguj się do Zendesk jako administrator. Otwórz Admin Center, a następnie Apps and integrations > APIs > Zendesk API. Na karcie Settings włącz Token Access. Kliknij „Add API token”, aby utworzyć token. Zapisz go w bezpiecznym miejscu, ponieważ później nie będzie ponownie wyświetlany.
Przygotuj środowisko Python: Zainstaluj Python 3.6 lub nowszy. Zainstaluj bibliotekę requests, która umożliwia wysyłanie żądań HTTP do Zendesk API. Można to zrobić w wierszu poleceń: pip install requests.
Skonfiguruj skrypt Python: Zapisz udostępniony skrypt Python w pliku, na przykład extract_zendesk_log.py. Otwórz plik w edytorze tekstu i uzupełnij zmienne zastępcze na początku: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL i API_TOKEN, wpisując dane instancji Zendesk i dane logowania.
Określ okres pobierania danych: Znajdź w skrypcie zmienną START_TIMESTAMP. Określa ona początkową datę pobierania danych historycznych i musi zawierać znacznik czasu Unix epoch. Do pierwszej analizy zaleca się ustawić wartość odpowiadającą ostatnim 3–6 miesiącom.
Uruchom skrypt: Otwórz terminal lub wiersz poleceń i przejdź do katalogu, w którym zapisano skrypt. Uruchom go poleceniem: python extract_zendesk_log.py.
Monitoruj działanie: Skrypt będzie wyświetlać w konsoli postęp, w tym liczbę przetworzonych zgłoszeń. Czas wykonania zależy od ilości pobieranych danych i limitów żądań API ustawionych przez Zendesk. Skrypt zawiera podstawową obsługę odpowiedzi informujących o osiągnięciu limitu.
Pobierz dziennik zdarzeń: Po pomyślnym zakończeniu skrypt utworzy w tym samym katalogu plik zendesk_event_log.csv. Zawiera on uporządkowany dziennik zdarzeń gotowy do analizy.
Przygotuj plik do przesłania: Otwórz zendesk_event_log.csv i sprawdź, czy został poprawnie utworzony. Upewnij się, że zawiera wymagane kolumny: ServiceRequest, ActivityName, StartTime, SourceSystem i LastDataUpdate. Plik jest gotowy do przesłania do narzędzia process mining.

Konfiguracja

Dane uwierzytelniające API: Skrypt wymaga prawidłowej subdomeny Zendesk, adresu e-mail agenta lub administratora oraz aktywnego tokenu API. Użytkownik powiązany z tymi danymi musi mieć uprawnienia do odczytu zgłoszeń, audytów zgłoszeń, użytkowników i miar zgłoszeń.
Zakres dat: Datę początkową pobierania określa zmienna START_TIMESTAMP w skrypcie. Musi zawierać znacznik czasu Unix epoch. Przed pobraniem większej ilości danych historycznych warto zacząć od krótszego okresu, na przykład 3 miesięcy, aby sprawdzić działanie skryptu i jakość wyników.
Incremental Export API: Rozwiązanie korzysta z Zendesk Incremental Export API. To wydajna, zalecana metoda pobierania dużej liczby zgłoszeń, przeznaczona do eksportu zbiorczego i ograniczająca typowe problemy z paginacją.
Wydajność i limity żądań: Zendesk stosuje limity API zależne od planu subskrypcji. Gdy limit zostanie osiągnięty, skrypt wstrzymuje działanie na czas określony w nagłówku Retry-After zwracanym przez API. W przypadku dużych instancji pobieranie może potrwać kilka godzin.
Wymagania wstępne: Ta metoda wymaga działającego środowiska Python 3.6 lub nowszego oraz zewnętrznej biblioteki requests. Do wygenerowania wymaganego tokenu API potrzebny jest dostęp administratora do instancji Zendesk.

Przykładowe zapytanie python

import requests
import json
import time
import datetime
import csv

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

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

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

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

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

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

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

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

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

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

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

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

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

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

                first_agent_reply_sent = False

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

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

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

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

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

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

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

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

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

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

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

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

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

Kroki

Sprawdź, czy konto Zendesk Support umożliwia korzystanie z Incremental Exports API oraz czy konto integracyjne ma uprawnienia do odczytu zgłoszeń, zdarzeń zgłoszeń, użytkowników, grup, komentarzy, ocen satysfakcji i danych SLA, jeśli te funkcje są włączone. Potwierdź subdomenę konta i metodę uwierzytelniania zgodnie z zatwierdzoną konfiguracją organizacji.
Wybierz początkowy czas pobierania obejmujący wymagany okres analizy. Eksport przyrostowy zgłoszeń korzysta ze znacznika czasu Unix i zwraca rekordy utworzone lub zaktualizowane od wskazanego momentu. Przy pełnym pobraniu danych historycznych użyj [Configure based on your system] jako początkowego czasu, a następnie zapisz zwrócony czas końcowy do kolejnych pobrań przyrostowych. Do regularnej analizy wybierz okres 3–6 miesięcy, jeśli historia operacyjna jest wystarczająca.
Uruchom skrypt Python do pobierania danych, podając subdomenę Zendesk, dane uwierzytelniające, początkowy znacznik czasu i opcjonalne filtry specyficzne dla firmy. Skrypt pobiera dane zgłoszeń przyrostowo, obsługuje paginację i zapisuje surowe rekordy zgłoszeń oraz dostępne szczegóły zdarzeń przed ich przekształceniem.
Jeśli odpowiedź dotycząca zgłoszenia nie zawiera wystarczających informacji o zmianach pól, przypisaniach, komentarzach lub statusie, pobierz historię audytów lub zdarzeń tego zgłoszenia. Korzystaj wyłącznie z zasobów Zendesk API włączonych na koncie i objętych uprawnieniami. Zachowaj identyfikator zgłoszenia ze źródła, identyfikator audytu, identyfikator komentarza, znacznik czasu zdarzenia, wykonawcę, nazwę pola, poprzednią wartość i nową wartość, jeśli są dostępne.
Ujednolić znaczniki czasu do UTC i przekształć wartości Unix lub ISO 8601 do spójnego formatu daty i czasu. Posortuj rekordy źródłowe według ServiceRequest, znacznika czasu zdarzenia i identyfikatora zdarzenia ze źródła. Usuń duplikaty, korzystając z najbardziej szczegółowego, stabilnego identyfikatora źródłowego, na przykład identyfikatora audytu lub komentarza.
Utwórz osobne wiersze dziennika zdarzeń dla wszystkich 14 wymaganych aktywności. Nie zakładaj, że ProcessMind wywnioskuje aktywności ze zmian statusu lub wartości pól. Zapisz Service Request Created na podstawie utworzenia zgłoszenia, Initial Acknowledgment Sent na podstawie potwierdzonej automatycznej pierwszej odpowiedzi, Request Categorized And Prioritized na podstawie zmian kategorii, typu lub priorytetu, Request Assigned To Agent na podstawie zmiany przypisanego agenta, First Agent Public Reply Sent na podstawie pierwszego kwalifikującego się publicznego komentarza agenta, Information Requested From Customer na podstawie przejścia do statusu oczekującego powiązanego z prośbą o informacje, Customer Responded na podstawie kwalifikującej się odpowiedzi klienta, Internal Escalation Triggered na podstawie zmiany przypisanej grupy, SLA Breach Occurred na podstawie potwierdzonego znacznika czasu naruszenia SLA lub jawnie obliczonego naruszenia, Service Request Resolved na podstawie przejścia do statusu rozwiązania, Service Request Reopened na podstawie przejścia ze statusu rozwiązania do otwartego wskutek odpowiedzi klienta, Satisfaction Survey Sent na podstawie potwierdzonego wysłania ankiety, Satisfaction Rating Received na podstawie przesłanej oceny, a Service Request Closed na podstawie przejścia do statusu zamkniętego lub potwierdzonego zdarzenia trwałego zamknięcia.
Wypełnij wymagane kolumny: ServiceRequest, ActivityName, StartTime, SourceSystem i LastDataUpdate. Jeśli źródło zawiera wiarygodne wartości, uzupełnij też zalecane kolumny: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime i IsSlaBreached. Dla niedostępnych atrybutów opcjonalnych użyj wartości null zamiast wymyślać dane.
Zastosuj zatwierdzone filtry specyficzne dla firmy po pobraniu danych, a przed eksportem. Zachowaj surowe identyfikatory źródłowe i znaczniki czasu w wewnętrznej kopii roboczej, aby można było skontrolować decyzje dotyczące zdarzeń i ponownie uruchomić przetwarzanie.
Sprawdź liczbę wierszy, pokrycie aktywności, kolejność znaczników czasu, obsługę duplikatów i uzupełnienie atrybutów. Upewnij się, że każdy wiersz zawiera ServiceRequest, ActivityName, StartTime, SourceSystem i LastDataUpdate.
Wyeksportuj przekształcony dziennik zdarzeń do pliku CSV w kodowaniu UTF-8 lub innym tabelarycznym formacie obsługiwanym przez ProcessMind. Nazwy kolumn muszą dokładnie odpowiadać wymaganym nazwom atrybutów, każdy wiersz ma opisywać jedno wystąpienie aktywności, a plik należy przesłać za pomocą skonfigurowanego procesu importu ProcessMind.

Konfiguracja

Metoda pobierania: Zendesk Incremental Exports API do pobierania dużej liczby zgłoszeń. Skrypt powinien pobierać dane od zapisanego znacznika czasu Unix, obsługiwać paginację i limity żądań oraz zapisywać zwrócony czas końcowy do wykorzystania przy kolejnym uruchomieniu.
Uwierzytelnianie: Skonfiguruj zatwierdzoną metodę uwierzytelniania Zendesk, subdomenę konta, dane logowania i uprawnienia API zgodnie z zasadami bezpieczeństwa organizacji. Nie umieszczaj danych logowania w systemie kontroli wersji.
Zakres dat: Do regularnej analizy procesów używaj danych z 3–6 miesięcy. Przy pierwszym pobraniu wybierz czas początkowy wcześniejszy niż wymagany okres analizy, ponieważ aktywności dotyczące zgłoszeń utworzonych wcześniej mogą wystąpić w analizowanym okresie. Przy pobieraniu przyrostowym użyj znacznika ostatniego udanego pobrania i dodaj niewielki okres nakładania się, aby uwzględnić opóźnione aktualizacje. Następnie usuń duplikaty na podstawie identyfikatorów źródłowych.
Filtry: Stosuj wyłącznie filtry obsługiwane przez zasoby Zendesk dostępne na koncie, na przykład filtry zatwierdzonej organizacji, grupy, marki, typu zgłoszenia, statusu lub pola niestandardowego. Filtry specyficzne dla firmy należy skonfigurować na podstawie systemu. Nie zakładaj, że w Zendesk istnieje pole Company Code lub Document Type.
Wymagane kolumny wynikowe: ServiceRequest, ActivityName, StartTime, SourceSystem i LastDataUpdate.
Zalecane kolumny wynikowe: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime i IsSlaBreached.
Szczegóły zdarzeń: Same rekordy zgłoszeń pobrane przyrostowo mogą nie zawierać pełnej historii zmian. W razie potrzeby pobierz autoryzowane audyty zgłoszeń, komentarze, oceny satysfakcji i zdarzenia SLA. Każdą wymaganą aktywność zapisz jako osobny wiersz.
Konfiguracja SLA: Jeśli konto udostępnia dane, korzystaj z rzeczywistych zasad SLA i znaczników czasu naruszeń. Jeśli status naruszenia jest obliczany, opisz zastosowane zasady, godziny pracy, przerwy i strefę czasową. Gdy obowiązują reguły godzin pracy, nie obliczaj naruszenia wyłącznie na podstawie czasu, który upłynął.
Wydajność: Przetwarzaj kolejne strony danych przyrostowo, strumieniowo lub partiami. Buforuj szczegóły zgłoszeń, ogranicz równoległość, uwzględniaj odpowiedzi Zendesk o limitach żądań i zapisuj postęp po pomyślnym przetworzeniu każdej strony. Unikaj wielokrotnego pobierania pełnej historii.
Przechowywanie danych: Zachowaj surowe odpowiedzi API, znaczniki postępu pobierania, metadane żądań i dzienniki przekształceń, aby można było uzgodnić dane i ponowić przetwarzanie.
Wymagania wstępne: Dostęp do Zendesk API, uprawnienia do odczytu odpowiednich zgłoszeń i zdarzeń, włączone audytowanie zgłoszeń i komentarze, jeśli są wymagane, dostęp do danych satysfakcji, jeśli potrzebne są aktywności CSAT, oraz dostęp do danych SLA, jeśli potrzebne są aktywności dotyczące naruszeń SLA. Dostępność funkcji zależy od planu Zendesk i konfiguracji konta.

Przykładowe zapytanie python

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

import requests

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

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


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


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


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


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


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        response = session.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_params, timeout=60)
            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
                time.sleep(max(retry_after, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


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


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


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


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


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


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


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


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


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


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


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


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


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


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

Kroki

Wybierz komercyjną platformę ETL lub ELT z obsługiwanym konektorem Zendesk Support. Sprawdź, czy konektor może replikować zgłoszenia, zdarzenia lub audyty zgłoszeń, komentarze, użytkowników, grupy, oceny satysfakcji, dane SLA oraz wyniki reguł i automatyzacji dostępne na koncie Zendesk.
Utwórz integrację Zendesk API, korzystając z metody uwierzytelniania zatwierdzonej przez organizację i obsługiwanej przez wybrany konektor. Przyznaj tylko uprawnienia do odczytu wymagane dla danych zgłoszeń, audytów, komentarzy, użytkowników, grup, satysfakcji i SLA. Zapisz parametry połączenia i dane logowania w bezpiecznym magazynie narzędzia.
Skonfiguruj konektor tak, aby replikował wymagane obiekty Zendesk do docelowej hurtowni danych. Korzystaj z obiektów źródłowych utworzonych przez konektor, zamiast zakładać z góry nazwy tabel lub kolumn. W dokumentacji projektu zapisz rzeczywiste mapowania obiektów i pól jako [Your table name] i [Your column name], jeśli konektor stosuje nazwy zależne od konta.
Skonfiguruj pobieranie przyrostowe z użyciem obsługiwanego przez system źródłowy znacznika czasu aktualizacji, kursora lub mechanizmu śledzenia zmian. Uwzględnij dane historyczne z wybranego okresu analizy, zwykle 3–6 miesięcy, i zachowaj identyfikator zdarzenia lub audytu ze źródła, aby usuwać duplikaty powstałe przy kolejnych aktualizacjach.
Przygotuj znormalizowany model roboczy łączący rekordy zgłoszeń z historią zgłoszeń, audytami lub zdarzeniami, komentarzami, użytkownikami, grupami, ocenami satysfakcji, rekordami SLA oraz rekordami reguł lub automatyzacji specyficznymi dla konektora. Jeśli są dostępne, zachowaj oryginalny znacznik czasu źródłowego, identyfikator rekordu źródłowego, identyfikator zgłoszenia, identyfikator wykonawcy, typ zdarzenia, nazwę pola, poprzednią wartość i nową wartość.
Przygotuj transformację zdarzeń, która zapisuje osobny wiersz dla każdej aktywności potwierdzonej w źródle. Utworzenie zgłoszenia mapuj na Service Request Created, kwalifikującą się automatyczną pierwszą odpowiedź na Initial Acknowledgment Sent, zmiany typu, kategorii lub priorytetu na Request Categorized And Prioritized, zmiany przypisanego agenta na Request Assigned To Agent, pierwszą kwalifikującą się publiczną odpowiedź agenta na First Agent Public Reply Sent, przejście do statusu oczekującego powiązane z prośbą o informacje na Information Requested From Customer, odpowiedź klienta na Customer Responded, zmianę grupy na Internal Escalation Triggered, zarejestrowane naruszenie SLA lub zdarzenie naruszenia na SLA Breach Occurred, przejście do statusu rozwiązania na Service Request Resolved, przejście ze statusu rozwiązania do otwartego wskutek odpowiedzi klienta na Service Request Reopened, zarejestrowane wysłanie ankiety na Satisfaction Survey Sent, przesłaną ocenę na Satisfaction Rating Received, a trwałe zamknięcie na Service Request Closed.
Nie twórz wierszy na podstawie samego bieżącego statusu zgłoszenia ani upływu czasu. Jeśli źródło nie rejestruje wprost wysłania ankiety, naruszenia SLA, automatycznego potwierdzenia lub trwałego zamknięcia, pomiń tę aktywność albo skorzystaj z osobnego, udokumentowanego źródła, które jawnie ją rejestruje. ProcessMind odczytuje dziennik zdarzeń bez zmian i nie uzupełnia brakujących zdarzeń.
Usuwaj duplikaty na podstawie identyfikatora zdarzenia lub audytu ze źródła, jeśli jest dostępny. Jeśli nie ma stabilnego identyfikatora, użyj udokumentowanego klucza złożonego z ServiceRequest, ActivityName, StartTime, wykonawcy i identyfikatora rekordu źródłowego. Zachowaj wszystkie prawidłowe powtórzenia aktywności, takich jak Customer Responded, Information Requested From Customer, Internal Escalation Triggered i Service Request Reopened.
Uzupełnij wymagane kolumny: ServiceRequest, ActivityName, StartTime, SourceSystem i LastDataUpdate. Dodaj AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime i IsSlaBreached, jeśli źródło udostępnia te dane. Stosuj spójny format znaczników czasu UTC i zachowaj regułę konwersji strefy czasowej ze źródła.
Wyeksportuj końcowy dziennik zdarzeń do pliku CSV zgodnego z ProcessMind lub załaduj go do skonfigurowanej lokalizacji pobierania danych ProcessMind. Każdy wiersz powinien odpowiadać jednemu wystąpieniu aktywności, ServiceRequest pełnić funkcję identyfikatora sprawy, ActivityName zawierać dokładną nazwę aktywności, a StartTime prawidłowy znacznik czasu. W każdym wierszu powinny znaleźć się wymagane atrybuty, o ile są dostępne technicznie.

Konfiguracja

Konektor i zakres źródeł: Skonfiguruj wybrane komercyjne narzędzie ETL lub ELT do obsługi Zendesk Support i wybierz obiekty źródłowe zawierające zgłoszenia, audyty lub zdarzenia zgłoszeń, komentarze, użytkowników, grupy, oceny satysfakcji, informacje SLA oraz wyniki automatyzacji lub reguł. Nazwy obiektów zależą od konektora i konta, dlatego należy korzystać z jego rzeczywistego katalogu, a nie zakładać nazw tabel.
Uwierzytelnianie i autoryzacja: Użyj metody uwierzytelniania Zendesk zatwierdzonej przez organizację. Przyznaj dostęp do odczytu wszystkich wybranych obiektów źródłowych, w tym historycznych zdarzeń zgłoszeń i danych satysfakcji klientów. Sprawdź, czy włączono dostęp do API, wymagane funkcje planu Zendesk i licencję konektora.
Zakres dat: Zacznij od danych historycznych z 3–6 miesięcy. Wydłuż okres dopiero po sprawdzeniu limitów API, pojemności hurtowni, liczby zdarzeń oraz dostępności historycznych audytów, danych SLA i ocen satysfakcji.
Ładowanie przyrostowe: W miarę możliwości korzystaj z natywnego kursora konektora, mechanizmu śledzenia zmian lub znacznika czasu aktualizacji w systemie źródłowym. Zaplanuj początkowe pobranie danych historycznych, a następnie częste pobieranie przyrostowe. Uwzględnij okres wsteczny, aby wychwycić opóźnione komentarze, oceny, wyniki SLA i aktualizacje zgłoszeń.
Filtry aktywności: Ogranicz rekordy źródłowe do wybranego okresu analizy i właściwej instancji Zendesk Support. Nie filtruj wyłącznie według bieżącego statusu zgłoszenia, ponieważ jego wcześniejsze aktywności mogły wystąpić, zanim status uległ zmianie.
Filtry firmy lub konta: Jeśli konektor udostępnia wiele instancji Zendesk, marek, organizacji lub jednostek biznesowych, zastosuj zatwierdzony filtr firmy lub konta, korzystając z rzeczywistego pola konektora. Nie zakładaj, że istnieje pole Company Code.
Mapowanie zdarzeń: Prowadź jawną tabelę mapowania typu zdarzenia źródłowego, nazwy pola, zmiany statusu, typu wykonawcy i wskaźnika automatyzacji na 14 wymaganych wartości ActivityName. Każdy zapisany wiersz musi mieć potwierdzenie w danych źródłowych.
Rozpoznawanie potwierdzeń: Mapuj zdarzenie na Initial Acknowledgment Sent tylko wtedy, gdy źródło wskazuje automatyczną pierwszą odpowiedź lub równoważne powiadomienie wygenerowane przez regułę. Nie klasyfikuj odpowiedzi agenta jako automatycznego potwierdzenia bez potwierdzenia w źródle.
Obsługa SLA: Korzystaj z jawnych rekordów naruszeń SLA lub wyników SLA udostępnianych przez konektor. Zapisz docelowy czas w SlaTargetResolutionTime, a wynik naruszenia w IsSlaBreached. Nie obliczaj naruszenia na podstawie samego upływu czasu, chyba że dostępne są kalendarz SLA, zasady, godziny pracy i wartość docelowa, a sposób obliczeń został udokumentowany.
Wydajność: Ogranicz początkowe pobieranie zakresem dat, wybieraj tylko wymagane kolumny i korzystaj z replikacji przyrostowej. Jeśli to możliwe, włącz partycjonowanie lub klastrowanie hurtowni według ServiceRequest i StartTime. Po pobraniu surowych danych zmaterializuj znormalizowany model zdarzeń. Unikaj wielokrotnego skanowania pełnej historii zgłoszeń.
Jakość danych: Zachowaj identyfikatory i znaczniki czasu ze źródła, ujednolić znaczniki czasu do UTC, standaryzuj wartości logiczne i pozostawiaj wartości null, gdy źródło nie udostępnia atrybutu. Nie zastępuj brakujących danych o agencie, kategorii, priorytecie, SLA ani kanale wartościami wymyślonymi.
Znacznik czasu odświeżenia: Ustaw LastDataUpdate na czas zakończenia pobierania lub przekształcania danych. Stosuj tę samą strefę czasową i format w całym dzienniku zdarzeń.

Przykładowe zapytanie config

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

Gotowi do rozpoczęcia?

Zacznij usprawniać obsługę klienta. Przygotuj dane, korzystając z tego szablonu, i sprawdź, jak przebiegają operacje w Zendesk Support. Analiza pomoże znaleźć możliwości poprawy i zwiększyć efektywność.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usuń wąskie gardła w obsłudze klienta i popraw CSAT

Ogranicz ponowne kontakty. Osiągnij 80% FCR i zwiększ satysfakcję klientów.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej

Szablon danych dotyczących obsługi klienta

Szablon danych dotyczących obsługi klienta

Atrybuty obsługi klienta

Aktywności w obsłudze klienta

Przewodniki po ekstrakcji danych

Interfejs Zendesk Explore do tworzenia raportów i eksportowania danych

Kroki

Konfiguracja

Przykładowe zapytanie config

Skrypt Python korzystający z Zendesk Support REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Zendesk Incremental Exports API do zbiorczego pobierania danych

Kroki

Konfiguracja

Przykładowe zapytanie python

Zewnętrzne narzędzie ETL z konektorem do Zendesk

Kroki

Konfiguracja

Przykładowe zapytanie config

Gotowi do rozpoczęcia?

Usuń wąskie gardła w obsłudze klienta i popraw CSAT