Szablon danych do zarządzania problemami

Zendesk Support
Szablon danych do zarządzania problemami

Szablon danych do zarządzania problemami

Ten szablon zawiera strukturę mapowania cyklu życia problemu w Zendesk Support. Opisuje najważniejsze atrybuty, etapy procesu i zasady ekstrakcji danych potrzebne do wykrywania wąskich gardeł w analizie przyczyn źródłowych. Korzystając z tej struktury, można utworzyć wysokiej jakości dziennik zdarzeń i uzyskać dokładniejszy obraz procesu.
  • Zalecane atrybuty do szczegółowej analizy
  • Najważniejsze czynności procesu i zmiany statusu
  • 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.

Atrybuty zarządzania problemami

Poniższe zalecane pola danych dostarczają kontekstu potrzebnego do analizy kategorii zgłoszeń, poziomów priorytetu i odpowiedzialności na każdym etapie rozwiązywania problemu.
5 Wymagane 8 Zalecane 6 Opcjonalne
Nazwa Opis
Czas rozpoczęcia
EventTimestamp
Dokładna data i godzina wystąpienia działania.
Opis

Ten atrybut zapisuje dokładny moment wykonania działania w systemie Zendesk. Dostarcza informacji o czasie, które są potrzebne do prawidłowego uporządkowania zdarzeń i obliczenia czasu między etapami.

W analizie jest niezbędny do obliczania czasu cyklu, wykrywania opóźnień, sprawdzania zgodności z SLA i przedstawiania przebiegu procesu w czasie. Bez dokładnych znaczników czasu nie można ocenić tempa rozwiązywania problemów.

Dlaczego to ważne

Umożliwia sortowanie działań i obliczanie wszystkich KPI opartych na czasie.

Skąd pobrać

Zendesk Ticket Audits, pole „created_at”

Przykłady
2023-10-12T08:30:00Z2023-10-12T09:15:22Z
Działanie
ActivityName
Nazwa zdarzenia lub działania wykonanego w ramach rekordu problemu.
Opis

Ten atrybut opisuje konkretny etap lub działanie w cyklu życia rekordu problemu. Przykłady obejmują zmianę statusu, na przykład z „Open” na „Pending”, zmianę przypisania lub określony etap workflow, taki jak „Workaround Published”.

Na mapie procesu atrybut ten odpowiada węzłom. Kolejność działań pozwala analitykom zobaczyć przepływ pracy, wykrywać wąskie gardła i mierzyć czas między poszczególnymi etapami procesu.

Dlaczego to ważne

Określa, co dzieje się w procesie, i umożliwia wizualizację jego przebiegu oraz analizę wariantów.

Skąd pobrać

Dane pochodzą z Zendesk Ticket Audits lub Ticket Metrics

Przykłady
Zarejestrowanie rekordu problemuRozpoczęcie dochodzeniaOpublikowanie obejścia
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu ostatniej modyfikacji rekordu problemu.
Opis

Ten atrybut wskazuje, kiedy dane rekordu problemu zostały ostatnio zaktualizowane w systemie źródłowym. Różni się od znacznika czasu zdarzenia, ponieważ dotyczy całego rekordu, a nie pojedynczego działania.

W analizie pomaga ocenić aktualność danych. Pozwala sprawdzić, czy zbiór danych jest bieżący i czy między systemem źródłowym a środowiskiem process mining występują opóźnienia synchronizacji.

Dlaczego to ważne

Pozwala kontrolować aktualność danych i wspiera strategie ich przyrostowego ładowania.

Skąd pobrać

Obiekt Zendesk Ticket, pole „updated_at”

Przykłady
2023-11-01T14:20:00Z
Rekord problemu
ProblemRecordId
Unikatowy identyfikator numeryczny przypisany zgłoszeniu problemu w Zendesk.
Opis

Ten atrybut jest unikatowym kluczem rekordu problemu w systemie Zendesk Support. Stanowi centralny identyfikator case w process mining, dzięki któremu wszystkie późniejsze zdarzenia, aktualizacje i interakcje można przypisać do jednej instancji procesu.

W analizie identyfikator służy do odróżniania poszczególnych przebiegów dochodzenia, od utworzenia rekordu po jego zamknięcie. Umożliwia powiązanie powiązanych incydentów i śledzenie cyklu życia problemu na kolejnych poziomach wsparcia.

Dlaczego to ważne

To podstawowy, wymagany klucz do grupowania zdarzeń w case’y na potrzeby każdej analizy process mining.

Skąd pobrać

Obiekt Zendesk Ticket, pole „id” dla typu „problem”

Przykłady
1045293849921
System źródłowy
SourceSystem
Nazwa systemu, z którego pochodzą dane.
Opis

Ten atrybut wskazuje platformę, z której pobrano dane o procesie. W tym przypadku jego wartością będzie zawsze „Zendesk Support”.

Podczas analizy danych z wielu systemów, na przykład Zendesk i Jira, pole to pozwala filtrować lub grupować dane według źródła. Ułatwia też śledzenie pochodzenia danych w widokach procesów obejmujących wiele systemów.

Dlaczego to ważne

Pozwala śledzić pochodzenie danych i obsługuje konfiguracje process mining obejmujące wiele systemów.

Skąd pobrać

Wartość ustawiana na stałe podczas ekstrakcji danych

Przykłady
Zendesk Support
Grupa wsparcia
SupportGroup
Zespół lub dział, do którego obecnie przypisano rekord problemu.
Opis

Ten atrybut wskazuje konkretną grupę agentów odpowiedzialną za problem w danym momencie. Zmienia się, gdy zgłoszenie jest przekazywane między zespołami.

W analizie jest niezbędny dla dashboardu Support Group Handover Analysis. Umożliwia pomiar wyników poszczególnych zespołów, wykrywanie wąskich gardeł przy przekazywaniu spraw i analizę rozkładu obciążenia zasobów.

Dlaczego to ważne

Umożliwia analizę organizacyjną i wykrywanie wąskich gardeł między działami.

Skąd pobrać

Obiekt Zendesk Ticket, pole „group_id” (zamienione na nazwę)

Przykłady
Wsparcie L2Zespół baz danychOperacje sieciowe
Imię i nazwisko przypisanego agenta
AssigneeName
Agent przypisany do obsługi problemu.
Opis

Ten atrybut zawiera imię i nazwisko użytkownika odpowiedzialnego obecnie za rekord problemu. Pozwala ustalić, kto wykonał poszczególne działania.

W analizie pomaga zrozumieć obciążenie pracą i wyniki poszczególnych osób. Analiza na poziomie grupy jest częstsza, ale dane o przypisanych agentach mogą wskazać potrzeby szkoleniowe lub osoby szczególnie skuteczne w rozwiązywaniu złożonych problemów.

Dlaczego to ważne

Umożliwia analizę zasobów na poziomie poszczególnych osób.

Skąd pobrać

Obiekt Zendesk Ticket, pole „assignee_id” (zamienione na imię i nazwisko)

Przykłady
Jan KowalskiAnna NowakSystem
Kategoria problemu
ProblemCategory
Klasyfikacja problemu, np. oprogramowanie, sprzęt lub sieć.
Opis

Ten atrybut określa kategorię problemu na podstawie usługi lub stosu technologicznego, którego dotyczy. Zazwyczaj jest to niestandardowe pole wyboru w formularzach Zendesk.

W analizie służy do tworzenia dashboardu „Dokładność kategoryzacji problemów”. Porównanie kategorii przypisanej na początku z ostateczną przyczyną źródłową pozwala sprawdzić, czy wstępna selekcja kieruje problemy do właściwych zespołów.

Dlaczego to ważne

Umożliwia podział danych według technologii lub usługi biznesowej.

Skąd pobrać

Niestandardowe pola zgłoszenia Zendesk

Przykłady
Baza danychInterfejs użytkownika i UXInfrastruktura sieciowa
Kategoria przyczyny źródłowej
RootCauseCategory
Ustalona przyczyna problemu, np. błąd w kodzie lub błąd konfiguracji.
Opis

Ten atrybut zapisuje ostateczną diagnozę przyczyny problemu. Zazwyczaj jest uzupełniany podczas czynności „Ustalono przyczynę źródłową”.

W analizie służy do tworzenia raportu „Dokładność kategoryzacji problemów” oraz badania trendów awarii systemów. Pomaga kierownictwu zdecydować, czy należy skupić się na jakości kodu, stabilności infrastruktury czy zarządzaniu dostawcami.

Dlaczego to ważne

Umożliwia analizę wzorców awarii i pomaga ukierunkować długoterminowe działania usprawniające.

Skąd pobrać

Niestandardowe pola zgłoszenia Zendesk

Przykłady
Błąd oprogramowaniaBłąd konfiguracjiBłąd użytkownika
Liczba powiązanych incydentów
RelatedIncidentCount
Liczba zgłoszeń incydentów powiązanych z tym rekordem problemu.
Opis

Ten atrybut zlicza zgłoszenia incydentów powiązane z danym rekordem problemu. W Zendesk powiązanie jest realizowane za pomocą pola „problem_id” w zgłoszeniach incydentów.

W analizie jest to główny miernik dla obszaru „Incident Correlation and Impact”. Pomaga ustalać priorytety problemów dotykających największej liczby użytkowników i podejmować decyzje o tym, które poprawki najbardziej ograniczą liczbę zgłoszeń.

Dlaczego to ważne

Wskazuje skalę problemu i jego wpływ na użytkowników.

Skąd pobrać

Zendesk Tickets API, liczba zgłoszeń, w których type='incident' i problem_id=ThisID

Przykłady
015342
Priorytet
Priority
Poziom pilności przypisany do rekordu problemu.
Opis

Ten atrybut określa względną ważność problemu. Zwykle przyjmuje wartość Low, Normal, High lub Urgent. Wpływa na oczekiwany poziom usług (SLA) i przydział zasobów.

W analizie służy do podziału procesu na segmenty i porównywania wyników dla różnych poziomów pilności. Można na przykład sprawdzić, czy problemy o priorytecie „Urgent” są rozwiązywane szybciej niż te o priorytecie „Low”, zgodnie z wymaganiami dashboardu Root Cause Investigation Velocity.

Dlaczego to ważne

Umożliwia podział case’ów na segmenty, aby analizować zgodność z SLA i priorytetyzację zasobów.

Skąd pobrać

Obiekt Zendesk Ticket, pole „priority”

Przykłady
PilnyWysokiNormalnyNiski
Status problemu
ProblemStatus
Bieżący stan rekordu problemu w jego cyklu życia.
Opis

Ten atrybut pokazuje bieżący status problemu, na przykład New, Open, Pending, Solved lub Closed. Odzwierciedla postęp dochodzenia.

W analizie służy do filtrowania spraw otwartych i zamkniętych. Jest niezbędny dla dashboardu Stale Problem Record Monitoring, który pomaga wykrywać aktywne sprawy, w których status nie zmienia się zgodnie z oczekiwanym przebiegiem.

Dlaczego to ważne

Umożliwia filtrowanie case’ów według stanu realizacji.

Skąd pobrać

Obiekt Zendesk Ticket, pole „status”

Przykłady
noweotwarteoczekującerozwiązanezamknięte
Termin realizacji SLA
SlaDueDate
Docelowa data i godzina rozwiązania problemu.
Opis

Ten atrybut określa termin rozwiązania problemu na podstawie konfiguracji umowy o poziomie usług. Zwykle jest obliczany na podstawie priorytetu i czasu utworzenia zgłoszenia.

W analizie termin ten porównuje się z rzeczywistym czasem rozwiązania, aby obliczyć wskaźnik Problem SLA Adherence Rate. Dashboard SLA Performance and Risk wskazuje sprawy, których termin realizacji się zbliża lub został przekroczony.

Dlaczego to ważne

Niezbędny do pomiaru zgodności i realizacji zobowiązań umownych.

Skąd pobrać

Punkt końcowy Zendesk Ticket Metrics lub SLA Policies

Przykłady
2023-12-01T17:00:00Z
Identyfikator artykułu w bazie wiedzy
KnowledgeArticleId
Identyfikator artykułu w bazie wiedzy utworzonego w związku z problemem lub powiązanego z nim.
Opis

Ten atrybut przechowuje odnośnik do artykułu w Zendesk Guide lub zewnętrznego materiału z bazy wiedzy. Wskazuje, że wnioski z rozwiązania problemu zostały udokumentowane.

W analizie obecność tego pola służy do obliczania wskaźnika „Poziom integracji z bazą wiedzy”. Pozwala sprawdzić, czy organizacja dokumentuje rozwiązania, aby można było z nich skorzystać w przyszłości.

Dlaczego to ważne

Pozwala ocenić skuteczność procesów zarządzania wiedzą.

Skąd pobrać

Niestandardowe pola zgłoszenia Zendesk lub powiązane treści

Przykłady
360045889KB-2991
Identyfikator wniosku o zmianę
ChangeRequestId
Identyfikator wniosku o zmianę powiązanego z wdrożeniem poprawki.
Opis

Ten atrybut łączy rekord problemu z rekordem zarządzania zmianą, który może znajdować się w innym systemie lub dotyczyć innego typu zgłoszenia. Oznacza to, że rozpoczęto formalny proces zmiany.

W analizie wspiera dashboard „Odsetek problemów zainicjowanych wnioskami o zmianę”. Ułatwia śledzenie przejścia od diagnozy do wdrożenia i sprawdzenie, czy ustalenie przyczyny źródłowej prowadzi do formalnych działań związanych ze zmianą.

Dlaczego to ważne

Łączy proces obsługi problemów z procesem zarządzania zmianą.

Skąd pobrać

Niestandardowe pola zgłoszenia Zendesk lub powiązane zgłoszenia

Przykłady
CR-1002CHG00394
Nieaktualny
IsStale
Flaga wskazująca, że problem nie był aktualizowany od ponad 14 dni.
Opis

Ten obliczany atrybut wskazuje rekordy, które nie były ostatnio aktualizowane. Porównuje bieżącą datę lub datę analizy z czasem ostatniej aktywności.

W analizie zasila dashboard „Monitorowanie nieaktualnych rekordów problemów”. Pomaga kierownikom szybko znaleźć zaniedbane sprawy zalegające w kolejce, które mogą wymagać zamknięcia administracyjnego lub ponownego przypisania.

Dlaczego to ważne

Pomaga wykrywać straty w procesie i zaniedbane zadania.

Skąd pobrać

Obliczane w narzędziu process mining: (Now - LastDataUpdate) > 14 dni

Przykłady
truefalse
Obejście problemu aktywne
WorkaroundActive
Flaga wskazująca, czy udostępniono lub opublikowano obejście problemu.
Opis

Ten atrybut logiczny wskazuje, czy udokumentowano tymczasowe rozwiązanie problemu. Jego wartość często ustala się na podstawie obecności czynności „Opublikowano obejście problemu” lub zaznaczenia odpowiedniego pola w formularzu.

W analizie służy do tworzenia dashboardu „Zgodność z publikowaniem obejść problemów”. Pokazuje, jak często zespół wsparcia zapewnia użytkownikom doraźną pomoc, gdy trwa poszukiwanie rozwiązania długoterminowego.

Dlaczego to ważne

Pomaga mierzyć, w jakim stopniu podczas analizy ograniczany jest wpływ problemu na użytkowników.

Skąd pobrać

Ustalane na podstawie obecności czynności „Opublikowano obejście problemu” lub niestandardowego pola

Przykłady
truefalse
Przeprowadzono PIR
HasPostImplementationReview
Flaga wskazująca, czy przeprowadzono przegląd po wdrożeniu.
Opis

Ten atrybut wskazuje, czy proces rozwiązywania problemu obejmował etap przeglądu. Jego wartość ustala się na podstawie obecności czynności „Przeprowadzono przegląd po wdrożeniu” w historii sprawy.

W analizie wspiera dashboard „Zakres przeglądów po wdrożeniu”. Jest to wskaźnik zgodności, który pozwala sprawdzić, czy organizacja wyciąga wnioski z poważnych problemów.

Dlaczego to ważne

Pozwala sprawdzić zgodność z procesami ciągłego doskonalenia.

Skąd pobrać

Ustalane na podstawie obecności czynności „Przeprowadzono przegląd po wdrożeniu”

Przykłady
truefalse
Temat problemu
ProblemSubject
Krótki opis lub tytuł rekordu problemu.
Opis

Ten atrybut zawiera opis wpisany podczas tworzenia problemu. Zwykle przedstawia objaw lub badaną usterkę.

Podczas analizy zapewnia kontekst przy przeglądaniu poszczególnych case’ów. Można też zastosować analizę tekstu, aby grupować podobne problemy lub wykrywać powtarzające się tematy, których nie obejmują pola kategorii.

Dlaczego to ważne

Zapewnia czytelny dla użytkownika kontekst poszczególnych case’ów.

Skąd pobrać

Obiekt Zendesk Ticket, pole „subject”

Przykłady
Nie można przetwarzać płatności w regionie UESkoki opóźnień na serwerze logowaniaEksport danych nie działa dla użytkowników administracyjnych
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania problemami

Rejestruj te istotne kroki procesu i zmiany statusu, aby zobaczyć cały przebieg: od pierwszego rozpoznania problemu po wdrożenie trwałego rozwiązania.
8 Zalecane 4 Opcjonalne
Działanie Opis
Opublikowanie obejścia
Udokumentowanie i udostępnienie tymczasowego rozwiązania problemu. W Zendesk jest ono często rejestrowane za pomocą określonego tagu lub niestandardowego pola wyboru informującego o dostępności obejścia.
Dlaczego to ważne

Wspiera dashboard Workaround Publication Compliance i pomaga zapewnić użytkownikom tymczasowe rozwiązanie podczas długotrwałego dochodzenia.

Skąd pobrać

Monitoruj dodanie tagu „workaround_published” lub zmianę niestandardowego pola logicznego o nazwie „Workaround”.

Rejestrowanie

Porównaj wartości pola niestandardowego lub tagu

Typ zdarzenia inferred
Potwierdzenie rozwiązania
Formalne oznaczenie problemu jako rozwiązany. W Zendesk następuje po ustawieniu standardowego statusu systemowego „Solved”, co oznacza, że poprawka została zweryfikowana, a sprawa zakończona.
Dlaczego to ważne

Główny punkt końcowy do obliczania wyników i ryzyka SLA oraz wskaźnika Problem SLA Adherence Rate.

Skąd pobrać

Dane pochodzą ze zmiany statusu zgłoszenia na „Solved”.

Rejestrowanie

Rejestrowane po zmianie statusu na Solved

Typ zdarzenia explicit
Przypisanie do grupy wsparcia
Przekazanie rekordu problemu do konkretnego zespołu technicznego lub działu. Zdarzenie jest rejestrowane po aktualizacji pola Group ID w zgłoszeniu.
Dlaczego to ważne

Niezbędne do pomiaru czasu oczekiwania między działami w dashboardzie Support Group Handover Analysis.

Skąd pobrać

Monitoruj zmiany pola „group_id” w dzienniku audytu zgłoszenia.

Rejestrowanie

Rejestrowane po wykonaniu transakcji Group Assignment Change

Typ zdarzenia explicit
Rozpoczęcie dochodzenia
Oznacza przejście ze stanu „New” do aktywnej pracy nad problemem. Wskazuje, że agent przyjął zgłoszenie i rozpoczął diagnozę.
Dlaczego to ważne

Służy do obliczania wskaźników dotyczących nieaktualnych rekordów problemów i wyznacza początek pomiaru KPI Average Root Cause Analysis Duration.

Skąd pobrać

Wnioskowane na podstawie zmiany statusu zgłoszenia z „New” na „Open” lub „Pending”.

Rejestrowanie

Porównaj pole statusu przed zmianą i po niej

Typ zdarzenia inferred
Ustalenie przyczyny źródłowej
Moment ustalenia podstawowej przyczyny problemu. Zwykle jest rejestrowany, gdy agent wypełni niestandardowe pole tekstowe „Root Cause” lub wybierze kategorię z listy.
Dlaczego to ważne

Ważny etap dla dashboardu Root Cause Investigation Velocity i pomiaru sprawności diagnozy.

Skąd pobrać

Monitoruj zmiany pól niestandardowych „Root Cause”, „RCA” lub „Problem Source” i sprawdzaj, czy zawierają wartość.

Rejestrowanie

Sprawdź, czy pola niestandardowe zostały wypełnione

Typ zdarzenia inferred
Wdrożenie trwałej poprawki
Oznacza wdrożenie rozwiązania technicznego w środowisku. Zwykle jest rejestrowane jako zmiana statusu niestandardowego lub określony tag przed pełnym rozwiązaniem zgłoszenia.
Dlaczego to ważne

Niezbędne do pomiaru czasu od diagnozy do wdrożenia w dashboardzie Fix Implementation Efficiency.

Skąd pobrać

Zdarzenie można wywnioskować z określonego tagu, na przykład „fix_deployed”, lub z niestandardowego pola statusu, jeśli jest dostępne.

Rejestrowanie

Monitoruj tagi lub niestandardowe listy statusów

Typ zdarzenia inferred
Zamknięcie rekordu problemu
Końcowe zdarzenie cyklu życia, po którym zgłoszenie zostaje zablokowane i nie można go już zmienić. W Zendesk następuje to zwykle automatycznie 4 dni po ustawieniu statusu „Solved”.
Dlaczego to ważne

Oznacza definitywny koniec cyklu życia rekordu i służy do zarządzania przechowywaniem danych oraz raportowania historycznego.

Skąd pobrać

Dane pochodzą ze zmiany statusu zgłoszenia na „Closed”.

Rejestrowanie

Rejestrowane po zmianie statusu na Closed

Typ zdarzenia explicit
Zarejestrowanie rekordu problemu
Utworzenie zgłoszenia problemu w Zendesk Support. To zdarzenie zapisuje znacznik czasu pierwszej rejestracji problemu w systemie i zwykle rozpoczyna instancję procesu.
Dlaczego to ważne

Wyznacza początek cyklu rozwiązania problemu od początku do końca i stanowi punkt odniesienia dla wszystkich późniejszych pomiarów czasu realizacji.

Skąd pobrać

Dane pochodzą ze znacznika czasu „created_at” w obiekcie zgłoszenia lub z pierwszego wpisu w dzienniku audytu zgłoszenia.

Rejestrowanie

Rejestrowane po wykonaniu transakcji Ticket Created

Typ zdarzenia explicit
Ponowne otwarcie dochodzenia dotyczącego problemu
Zdarzenie występuje, gdy rekord problemu oznaczony wcześniej jako „Solved” wraca do statusu „Open” lub innego aktywnego stanu. Może to oznaczać, że poprawka nie zadziałała lub rozwiązanie zostało odrzucone.
Dlaczego to ważne

Wspiera KPI Problem Re-opening Rate i pomaga wykrywać problemy z jakością procesu rozwiązywania.

Skąd pobrać

Wnioskowane na podstawie zmiany statusu z „Solved” na „Open”, „New” lub „Pending”.

Rejestrowanie

Porównaj pole statusu przed zmianą i po niej

Typ zdarzenia inferred
Przeprowadzenie przeglądu po wdrożeniu
Potwierdzenie, że po wdrożeniu poprawki przeprowadzono przegląd retrospektywny. Zwykle jest rejestrowane przez koordynatora procesu w polu wyboru lub polu daty.
Dlaczego to ważne

Wymagane do obliczania KPI Post-Implementation Review Frequency i monitorowania zgodności ze standardami jakości.

Skąd pobrać

Monitoruj aktualizacje niestandardowego pola wyboru „PIR Completed” lub pola daty „PIR Date”.

Rejestrowanie

Monitoruj niestandardowe pole pod kątem zakończenia przeglądu

Typ zdarzenia inferred
Przygotowanie projektu proponowanego rozwiązania
Utworzenie artykułu w bazie wiedzy na podstawie dochodzenia dotyczącego problemu. Zdarzenie można wywnioskować z użycia aplikacji Zendesk Knowledge Capture lub powiązania nowego artykułu.
Dlaczego to ważne

Wspiera KPI Knowledge Base Integration Rate i pomaga utrwalać wiedzę w organizacji.

Skąd pobrać

Monitoruj zdarzenia związane z integracją „Knowledge Capture” lub tagi takie jak „kcs_draft”.

Rejestrowanie

Wnioskuj na podstawie określonych tagów systemowych lub zdarzeń powiązania

Typ zdarzenia inferred
Rozpoczęcie obsługi wniosku o zmianę
Oznacza uruchomienie formalnego procesu zarządzania zmianą w celu rozwiązania problemu. Zdarzenie można zwykle wywnioskować z wypełnienia niestandardowego pola „Change Request ID” lub powiązania zgłoszenia typu „Change”.
Dlaczego to ważne

Pozwala śledzić wskaźnik rozpoczęcia obsługi wniosków o zmianę i łączy workflow zarządzania problemami z workflow zarządzania zmianą.

Skąd pobrać

Monitoruj aktualizacje niestandardowego pola, takiego jak „change_reference”, lub utworzenie powiązania typu „problem_change”.

Rejestrowanie

Monitoruj niestandardowe pole pod kątem wpisania zewnętrznego identyfikatora

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Zendesk Support

Gotowi do rozpoczęcia?

Zastosuj ten szablon w środowisku Zendesk, aby poprawić stabilność usług IT. Nasz zespół może pomóc dopracować ekstrakcję danych i rozpocząć analizę process mining.

Usprawnij zarządzanie problemami, aby szybciej usuwać awarie IT

Skróć cykle rozwiązywania problemów o 30% i usuń wąskie gardła w IT.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty. Konfiguracja zajmuje kilka minut.