Szablon danych dotyczących obsługi incydentów

Zendesk Support
Szablon danych dotyczących obsługi incydentów

Szablon danych dotyczących obsługi incydentów

Ten szablon przedstawia dane potrzebne do analizy procesu obsługi incydentów. Zawiera listę atrybutów do zebrania, działań do śledzenia oraz praktyczne wskazówki dotyczące eksportu danych z Zendesk Support. Dzięki niemu projekt process mining można rozpocząć od uporządkowanego i kompletnego zbioru danych.
  • Zalecane atrybuty do zebrania
  • Działania do śledzenia podczas mapowania procesów
  • Praktyczne wskazówki dotyczące eksportu danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty obsługi incydentów

Poniżej przedstawiono zalecane pola, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować proces obsługi incydentów.
5 Wymagane 7 Zalecane 11 Opcjonalne
Nazwa Opis
Incident ID
TicketId
Unikatowy identyfikator systemowy każdego zgłoszenia incydentu.
Opis

Incident ID to klucz główny, który jednoznacznie identyfikuje każdą sprawę dotyczącą incydentu w Zendesk Support. W analizie process mining pełni funkcję CaseId i łączy wszystkie powiązane działania, zmiany statusu oraz komunikację, od utworzenia incydentu do jego zamknięcia.

Ten identyfikator jest niezbędny do odtworzenia pełnego przebiegu każdego incydentu. Umożliwia agregowanie danych o zdarzeniach i śledzenie takich mierników jak całkowity czas rozwiązania, liczba przekazań oraz realizacja umów o gwarantowanym poziomie usług dla poszczególnych spraw. Grupując zdarzenia według tego identyfikatora, analitycy mogą wizualizować przebieg procesu, wykrywać typowe ścieżki i znajdować odstępstwa od standardowej procedury.

Dlaczego to ważne

To niezbędny identyfikator, który łączy wszystkie zdarzenia dotyczące jednego incydentu. Pozwala prześledzić cały cykl życia sprawy i dokładnie analizować wyniki procesu.

Skąd pobrać

Zendesk Tickets API (/api/v2/tickets/{id}), pole id.

Przykłady
19428230113521941055
Timestamp zdarzenia
EventTimestamp
Dokładna data i godzina wystąpienia działania.
Opis

Ten timestamp wskazuje dokładny moment wystąpienia zdarzenia w cyklu życia incydentu, na przykład dodania komentarza lub zmiany statusu. Pozwala ustalić chronologiczną kolejność wszystkich działań w ramach sprawy.

Atrybut ten jest podstawą analizy process mining w ujęciu czasowym. Służy do obliczania czasu między działaniami, wykrywania czasu oczekiwania, mierzenia całkowitego czasu obsługi sprawy i analizowania wyników procesu w różnych okresach. Dokładne timestampy są niezbędne do utworzenia animowanej mapy procesu, która pokazuje przebieg spraw w czasie, oraz dashboardów z KPI, takimi jak średni czas rozwiązania.

Dlaczego to ważne

Timestampy określają chronologię działań. Umożliwiają obliczanie czasu trwania, wykrywanie wąskich gardeł i analizowanie wyników procesu w czasie.

Skąd pobrać

Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), pole created_at dla każdego zdarzenia audytowego.

Przykłady
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
Działanie
ActivityName
Nazwa działania biznesowego lub zdarzenia, które wystąpiło w określonym momencie cyklu życia incydentu.
Opis

Ten atrybut opisuje konkretny krok lub działanie w procesie obsługi incydentu, na przykład „Utworzenie incydentu”, „Przypisanie zgłoszenia do agenta” lub „Rozwiązanie incydentu”. Działania są wyznaczane na podstawie dziennika zdarzeń lub danych ze ścieżki audytowej Zendesk, w których zapisywane są zmiany w systemie.

W process mining sekwencja działań tworzy mapę procesu, która stanowi podstawę analizy. Analiza ich przebiegu pozwala organizacjom odkryć rzeczywiste ścieżki obsługi incydentów, znaleźć wąskie gardła między krokami, zmierzyć liczbę powrotów do wcześniejszych działań, na przykład ponownego otwarcia rozwiązania zgłoszenia, oraz sprawdzić zgodność z określonym standardowym procesem.

Dlaczego to ważne

Kolejność działań określa przebieg procesu. To podstawa analizy process mining, która pozwala wykrywać nieefektywności, odstępstwa i możliwości usprawnień.

Skąd pobrać

Wyznaczane na podstawie zdarzeń z Zendesk Ticket Audits API. Na przykład zdarzenie Change dotyczące pola status można odwzorować jako „Zmiana statusu”.

Przykłady
Utworzenie incydentuPrzypisanie zgłoszenia do agentaZmiana statusu na oczekującyRozwiązanie incydentuZamknięcie incydentu
Ostatnia aktualizacja danych
LastDataUpdate
Timestamp wskazujący, kiedy ostatnio odświeżono dane dotyczące tego procesu.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych z systemu źródłowego. Zazwyczaj jest to jedna wartość przypisana do całego zbioru danych z danego cyklu odświeżania.

Informacja ta ma znaczenie dla zarządzania danymi i osób korzystających z analizy process mining. Pokazuje, jak aktualne są dane, i pomaga ustalić, czy analiza obejmuje najnowsze dostępne informacje. Jest to szczególnie ważne przy monitorowaniu wyników operacyjnych i podejmowaniu decyzji na podstawie analizy.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak aktualna jest analiza i kiedy ostatnio pobrano dane.

Skąd pobrać

Timestamp wygenerowany przez proces ETL lub potok danych po zakończeniu odświeżania danych.

Przykłady
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
System źródłowy
SourceSystem
System, z którego pobrano dane o incydentach.
Opis

Ten atrybut wskazuje źródło danych o procesie. W tym widoku jego wartość jest stała, na przykład „Zendesk Support”, co oznacza, że wszystkie zdarzenia i atrybuty pochodzą z tego systemu.

W środowiskach, w których łączy się dane z wielu systemów, to pole pozwala rozróżnić ich źródła. Pomaga zachować integralność danych i prowadzić analizy dla poszczególnych źródeł, na przykład porównać proces obsługi incydentów w Zendesk z procesem w innym narzędziu ITSM.

Dlaczego to ważne

Wskazuje źródło danych, co ma znaczenie dla zarządzania danymi i analiz łączących informacje z wielu systemów źródłowych.

Skąd pobrać

Wartość stała ustawiana podczas przekształcania danych w celu wskazania ich źródła.

Przykłady
Zendesk SupportZendesk
Czas zakończenia zdarzenia
EventEndTime
Znacznik czasu wskazujący, kiedy zakończyło się działanie.
Opis

Czas zakończenia zdarzenia wskazuje, kiedy dane działanie dobiegło końca. W danych dziennika zdarzeń czas zakończenia jednego działania często ustala się na podstawie czasu rozpoczęcia kolejnego działania w danym case. W przypadku ostatniego działania w case czas zakończenia może być taki sam jak czas rozpoczęcia.

Atrybut ten jest niezbędny do obliczania czasu trwania poszczególnych działań (ProcessingTime) i czasu oczekiwania między nimi. To podstawa analizy wąskich gardeł. Pozwala sprawdzić nie tylko, ile trwa dany krok, ale też jak długo case pozostawał bezczynny przed jego rozpoczęciem.

Dlaczego to ważne

Pozwala obliczać czas trwania działań i czas oczekiwania, co jest podstawą szczegółowej analizy wąskich gardeł i opóźnień w procesie.

Skąd pobrać

Obliczany jako czas rozpoczęcia kolejnego zdarzenia w tym samym case. Czas zakończenia ostatniego zdarzenia może być taki sam jak czas jego rozpoczęcia lub odpowiadać chwili zamknięcia case.

Przykłady
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
Kanał zgłoszenia
Channel
Kanał, którym zgłoszono incydent, na przykład „E-mail”, „Internet” lub „API”.
Opis

Ten atrybut wskazuje, w jaki sposób użytkownik końcowy lub system utworzył zgłoszenie incydentu. Znajomość kanału ułatwia analizę źródeł incydentów i dostosowanie procesu wsparcia.

Analiza incydentów według kanału może ujawnić różnice w ich obsłudze. Na przykład zgłoszenia telefoniczne mogą być rozwiązywane szybciej niż te przesłane e-mailem. Dane te wspierają dashboard „Liczba obsługiwanych incydentów” oraz pomagają planować zasoby i usprawniać poszczególne kanały.

Dlaczego to ważne

Ułatwia analizę liczby incydentów i wyników procesu według źródła, a także usprawnianie poszczególnych kanałów i przydzielanie zasobów.

Skąd pobrać

Zendesk Tickets API, pole via.channel.

Przykłady
internete-mailAPItelefon
Priorytet
TicketPriority
Priorytet przypisany do incydentu, na przykład „Niski”, „Normalny”, „Wysoki” lub „Pilny”.
Opis

Priorytet incydentu określa, jak szybko należy zareagować i rozwiązać problem. Wpływa na ustalanie kolejności pracy i przydział zasobów w zespole wsparcia.

W analizie procesów priorytet służy do podziału incydentów na grupy, aby porównać ich przebieg i wyniki. Można na przykład sprawdzić, czy incydenty „Pilne” są rozwiązywane szybciej niż te o „Niskim” priorytecie. Priorytet pomaga też monitorować zgodność z SLA, ponieważ wymagania SLA często zależą od poziomu priorytetu. KPI „Wskaźnik zmian priorytetu” opiera się na śledzeniu zmian tego pola.

Dlaczego to ważne

Atrybut ten pozwala dzielić dane na grupy, oceniać skuteczność ustalania priorytetów i monitorować zgodność z SLA dla różnych poziomów pilności.

Skąd pobrać

Zendesk Tickets API, pole priority. Zmiany są rejestrowane w Ticket Audits API.

Przykłady
niskinormalnywysokipilny
Przypisana grupa
AssignedGroup
Zespół wsparcia lub grupa przypisana obecnie do incydentu.
Opis

Ten atrybut wskazuje zespół odpowiedzialny za incydent. Zgłoszenia często przechodzą między różnymi poziomami wsparcia lub wyspecjalizowanymi grupami, na przykład z „Wsparcia L1” do „Zespołu sieciowego”.

To ważny wymiar analizy przekazywania pracy i wykrywania wąskich gardeł. Śledząc przepływ incydentów między grupami, analitycy mogą mierzyć zależności między zespołami, obliczać czas oczekiwania w kolejkach poszczególnych grup i usprawniać reguły kierowania zgłoszeń. Atrybut ten wspiera dashboard „Analiza przekazań i ponownej pracy”.

Dlaczego to ważne

Pokazuje, który zespół odpowiada za incydent. Ułatwia analizę przekazań między zespołami, wykrywanie wąskich gardeł w poszczególnych zespołach i pomiar czasu oczekiwania w kolejkach.

Skąd pobrać

Zendesk Tickets API, pole group_id. Zmiany są rejestrowane w Ticket Audits API.

Przykłady
Wsparcie L1Zespół sieciowy L2Infrastruktura L3Rozliczenia
Przypisany agent
Assignee
Agent wsparcia przypisany obecnie do obsługi incydentu.
Opis

Ten atrybut wskazuje agenta odpowiedzialnego za incydent w danym momencie. Zmiana osoby przypisanej do zgłoszenia oznacza przekazanie pracy.

Analiza przypisanych agentów pomaga ocenić rozkład obciążenia, indywidualne wyniki i sposób współpracy. Śledzenie zmian tego pola jest niezbędne do obliczenia KPI „Średnia liczba przekazań na incydent” i wykrywania sytuacji, w których incydenty często przechodzą między osobami. Może to wskazywać na braki w wiedzy lub nieefektywne kierowanie zgłoszeń.

Dlaczego to ważne

Wskazuje agenta odpowiedzialnego za incydent, co pozwala analizować obciążenie pracą i śledzić przekazania oraz wykrywać nieefektywności procesu.

Skąd pobrać

Zendesk Tickets API, pole assignee_id. Zmiany są rejestrowane w Ticket Audits API.

Przykłady
John SmithJane DoeAutomatyzacja Service Desk
Status SLA
SlaStatus
Bieżący status umowy o gwarantowanym poziomie usług (SLA) dla incydentu.
Opis

Ten atrybut wskazuje, czy incydent jest na dobrej drodze do spełnienia wymagań SLA, czy zostały one już przekroczone, czy też pomiar czasu SLA jest wstrzymany. Zendesk automatycznie śledzi wskaźniki SLA na podstawie skonfigurowanych zasad.

Atrybut ten jest podstawą dashboardu „Monitorowanie zgodności z SLA”. Bezpośrednio pokazuje, jak realizowane są zobowiązania dotyczące poziomu usług. Analiza tego, kiedy i dlaczego dochodzi do naruszeń SLA, pomaga wykrywać słabe punkty procesu i poprawiać niezawodność usług. Atrybut wspiera KPI „Wskaźnik dotrzymania SLA dla incydentów”.

Dlaczego to ważne

Bezpośrednio pokazuje, jak realizowane są zobowiązania dotyczące poziomu usług. Ułatwia analizę naruszeń SLA i bieżące monitorowanie zgodności.

Skąd pobrać

Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), dane wyliczane na podstawie pól takich jak sla_policy, breached_at itp.

Przykłady
AktywnyWstrzymanyPrzekroczonyZrealizowany
Status zgłoszenia
TicketStatus
Status zgłoszenia dotyczącego incydentu w chwili wystąpienia zdarzenia, na przykład „otwarty”, „oczekujący” lub „rozwiązany”.
Opis

Ten atrybut pokazuje stan zgłoszenia dotyczącego incydentu na różnych etapach jego cyklu życia. Standardowe statusy Zendesk to new, open, pending, on-hold, solved i closed. Śledzenie zmian tego pola to podstawowy sposób wyznaczania działań na potrzeby process mining.

Analiza statusu zgłoszenia jest niezbędna do zrozumienia procesu. Pozwala ustalić, ile czasu incydenty spędzają w poszczególnych stanach. Status „Pending” często oznacza oczekiwanie na odpowiedź klienta. Status jest też ważny przy określaniu zakończenia sprawy i obliczaniu czasu jej rozwiązania.

Dlaczego to ważne

Śledzenie zmian statusu pozwala zrozumieć przebieg procesu, wykrywać czas oczekiwania oraz określić początek i koniec cyklu życia incydentu.

Skąd pobrać

Zendesk Tickets API, pole status. Zmiany są rejestrowane w Ticket Audits API.

Przykłady
nowyotwartyoczekującyrozwiązanyzamknięty
Czas trwania case
CaseDuration
Łączny czas od utworzenia incydentu do jego ostatecznego zamknięcia.
Opis

Ta wyliczana miara pokazuje całkowity czas obsługi pojedynczego incydentu. Oblicza się ją jako różnicę między znacznikiem czasu pierwszego zdarzenia, na przykład „Utworzono incydent”, a znacznikiem czasu ostatniego zdarzenia, na przykład „Zamknięto incydent”.

Czas trwania case to podstawowy KPI ogólnej efektywności procesu. Dashboardy wykorzystują go do prezentowania średniego czasu obsługi, wykrywania długo trwających spraw i analizowania trendów. Daje ogólny obraz tego, jak szybko proces pozwala obsłużyć i rozwiązać incydenty.

Dlaczego to ważne

To ważny KPI służący do pomiaru ogólnego tempa procesu i wykrywania czynników wydłużających czas rozwiązania incydentów.

Skąd pobrać

Obliczany dla każdego identyfikatora incydentu jako różnica między znacznikiem czasu ostatniego i pierwszego zdarzenia.

Przykłady
25920060480086400
Czy zautomatyzowane
IsAutomated
Wartość logiczna wskazująca, czy działanie wykonał system automatyczny, czy agent.
Opis

Ten wyliczany atrybut pozwala odróżnić zdarzenia wywołane przez użytkowników od tych, które wynikają z automatyzacji systemowych, wyzwalaczy lub integracji API. Zazwyczaj ustala się go, sprawdzając, czy autorem zdarzenia jest znany użytkownik systemowy.

Informacja o stopniu automatyzacji jest ważna w analizie procesów. Pomaga ocenić skuteczność reguł automatyzacji, wykrywać zadania wykonywane ręcznie, które można zautomatyzować, oraz mierzyć wpływ automatyzacji na efektywność i czas rozwiązania. Atrybut ten pozwala porównywać przebieg działań automatycznych i ręcznych.

Dlaczego to ważne

Odróżnia działania ludzi od działań systemu, co pozwala analizować wpływ automatyzacji na efektywność procesu i wskazywać kolejne możliwości automatyzacji.

Skąd pobrać

Ustalany przez sprawdzenie, czy autor zdarzenia (author_id w Ticket Audits API) jest znanym użytkownikiem systemowym lub automatyzacją.

Przykłady
truefalse
Kategoria przyczyny źródłowej
RootCauseCategory
Ogólna kategoria przyczyny źródłowej incydentu.
Opis

Ten atrybut służy do klasyfikowania podstawowej przyczyny incydentu. Zazwyczaj jest uzupełniany pod koniec cyklu życia incydentu, często w ramach analizy po incydencie lub zarządzania problemami, i zapisywany w polu niestandardowym.

Dane te są potrzebne do dashboardu „Trafność identyfikacji przyczyn źródłowych” i KPI „Pokrycie analizą przyczyn źródłowych”. Analiza incydentów według przyczyny pomaga wykrywać powtarzające się problemy, planować trwałe poprawki i ograniczać liczbę przyszłych incydentów. Pozwala skupić się na zapobieganiu problemom, zamiast jedynie reagować na nie po wystąpieniu.

Dlaczego to ważne

Ułatwia zapobieganie problemom dzięki klasyfikacji przyczyn incydentów, wykrywaniu trendów i ograniczaniu ryzyka ich ponownego wystąpienia.

Skąd pobrać

Zazwyczaj jest to niestandardowe pole zgłoszenia. Konfigurację można sprawdzić w sekcji Ticket Fields w Zendesk Admin Center.

Przykłady
Błąd oprogramowaniaAwaria sprzętuBłąd użytkownikaAwaria sieci
Liczba przekazań
HandoffCount
Łączna liczba przekazań incydentu innemu agentowi lub grupie.
Opis

Ta wyliczana miara pokazuje, ile razy zmieniła się osoba lub grupa odpowiedzialna za incydent. Każda zmiana pola Assignee lub AssignedGroup zwiększa wartość dla danego case.

Przekazywanie zgłoszeń często powoduje nieefektywność i opóźnienia w zarządzaniu incydentami. Duża liczba przekazań może wskazywać na niejasne reguły kierowania, braki w wiedzy zespołów wsparcia lub zbyt złożony proces. Miara ta stanowi podstawę KPI „Średnia liczba przekazań na incydent” i jest niezbędna w dashboardzie „Analiza przekazań i ponownej pracy”.

Dlaczego to ważne

Pokazuje utrudnienia w procesie wynikające z przekazywania zgłoszeń i pomaga wykrywać nieefektywne kierowanie oraz braki w wiedzy, które wydłużają czas rozwiązania.

Skąd pobrać

Obliczana przez zliczenie zmian pól AssignedGroup lub Assignee dla danego incydentu.

Przykłady
0135
Ocena satysfakcji
SatisfactionRating
Ocena satysfakcji wystawiona przez użytkownika końcowego po rozwiązaniu incydentu.
Opis

Ten atrybut zawiera opinię klienta o obsłudze, zazwyczaj zebraną w ankiecie po rozwiązaniu zgłoszenia. W Zendesk najczęściej stosowane oceny to „Dobrze” i „Źle”.

Ocena satysfakcji nie mierzy bezpośrednio efektywności procesu, ale pokazuje jego wynik. W process mining można zestawić ją z wariantami procesu, aby sprawdzić, które ścieżki rozwiązania wiążą się z wyższą satysfakcją klientów. Można na przykład sprawdzić, czy incydenty przekazywane między wieloma osobami otrzymują niższe oceny.

Dlaczego to ważne

Dostarcza miary wyniku, którą można zestawić z charakterystyką procesu, aby sprawdzić, jak jego przebieg wpływa na satysfakcję użytkowników.

Skąd pobrać

Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), pole satisfaction_rating.score.

Przykłady
dobrazłazaoferowanonie zaoferowano
Organizacja klienta
Organization
Organizacja lub firma, do której należy osoba zgłaszająca incydent.
Opis

Ten atrybut łączy incydent z organizacją klienta. Jest szczególnie przydatny w obsłudze B2B, gdzie poziomy usług i procesy wsparcia mogą różnić się w zależności od klienta.

Analiza incydentów według organizacji pomaga zespołom wsparcia monitorować sytuację klientów, wykrywać powtarzające się problemy dotyczące konkretnych firm i sprawdzać, czy wywiązuje się ze zobowiązań umownych. Atrybut ten pozwala filtrować dashboardy i raporty, aby oceniać wyniki z perspektywy klienta.

Dlaczego to ważne

Umożliwia analizę dla poszczególnych klientów, monitorowanie poziomu usług, wykrywanie trendów dotyczących ważnych klientów i skuteczniejsze zarządzanie relacjami.

Skąd pobrać

Zendesk Tickets API, pole organization_id.

Przykłady
Global Tech Inc.Innovate SolutionsData Corp
Rozwiązanie przy pierwszym kontakcie
IsFirstContactResolution
Wartość logiczna wskazująca, czy incydent rozwiązał pierwszy przypisany agent lub grupa, bez przekazywania go dalej.
Opis

Rozwiązanie przy pierwszym kontakcie (FCR) to ważna miara efektywności centrum wsparcia i satysfakcji klientów. Ten wyliczany atrybut wskazuje incydenty rozwiązane bez przekazania ich innemu agentowi lub zespołowi.

Zazwyczaj sprawdza się, czy zgłoszenie uzyskało status „Rozwiązany”, pozostając przypisane do początkowego agenta i grupy. W process mining pozwala to bezpośrednio obliczyć wskaźnik FCR i porównać ścieżki incydentów rozwiązanych przy pierwszym kontakcie ze ścieżkami wymagającymi eskalacji. Dzięki temu można wskazać, jak zwiększyć możliwości zespołu pierwszej linii wsparcia.

Dlaczego to ważne

Bezpośrednio mierzy efektywność pierwszego kontaktu z zespołem wsparcia i pomaga wskazać możliwości wcześniejszego rozwiązania sprawy.

Skąd pobrać

Wyliczana wartość logiczna. Przyjmuje wartość true, jeśli status zgłoszenia to „solved” lub „closed”, a przez cały cykl życia incydentu przypisany był tylko jeden agent lub jedna grupa.

Przykłady
truefalse
Tagi
Tags
Lista tagów przypisanych do incydentu w celu jego klasyfikacji i dodania kontekstu.
Opis

Tagi to elastyczne etykiety, które można dodawać do zgłoszeń, aby uzupełnić kontekst, ułatwić klasyfikację lub kierowanie. Agenci mogą dodawać je ręcznie, a wyzwalacze i automatyzacje mogą przypisywać je automatycznie.

Tagi dostarczają wielu danych do analizy process mining. Można na ich podstawie tworzyć szczegółowe segmenty, na przykład filtrować incydenty związane z konkretnym wdrożeniem produktu („launch_q4”) lub znaną awarią („outage_20231027”). Dzięki temu można prowadzić szczegółowe analizy wykraczające poza standardowe pola zgłoszenia.

Dlaczego to ważne

Pozwala elastycznie klasyfikować i filtrować incydenty, umożliwiając szczegółową analizę uwzględniającą kontekst, którego nie da się uchwycić wyłącznie za pomocą standardowych pól.

Skąd pobrać

Zendesk Tickets API, pole tags.

Przykłady
vip_usernetwork_issueoutage_20231027billing_related
Typ zgłoszenia
TicketType
Klasyfikacja zgłoszenia, na przykład „Incydent”, „Problem”, „Pytanie” lub „Zadanie”.
Opis

To pole klasyfikuje zgłoszenie według jego charakteru. Proces zarządzania incydentami obejmuje zgłoszenia typu „Incydent”, czyli nieplanowane przerwy w działaniu usługi IT lub obniżenie jej jakości.

W analizie atrybut ten służy głównie jako filtr, który pozwala uwzględnić w widoku procesu tylko incydenty. Można go też wykorzystać w szerszej analizie ITSM, aby porównać obsługę incydentów, problemów i zgłoszeń serwisowych.

Dlaczego to ważne

Pozwala filtrować dane i skupić analizę na incydentach, tak aby odpowiadała ona cyklowi obsługi incydentu.

Skąd pobrać

Zendesk Tickets API, pole type.

Przykłady
incydentproblempytaniezadanie
Waga incydentu
Severity
Wpływ incydentu na działalność firmy.
Opis

Waga incydentu określa jego wpływ na działalność firmy. Często łączy się ją z priorytetem, aby ustalić ogólną pilność. Zazwyczaj jest konfigurowana w Zendesk jako pole niestandardowe.

Analiza wagi incydentów pomaga ocenić ich znaczenie. Atrybut ten pozwala dzielić dane na grupy w dashboardach, takich jak „Monitorowanie zgodności z SLA” i „Wskaźniki skuteczności ustalania priorytetów”. Porównanie przebiegu procesu dla różnych poziomów wagi może pokazać, czy incydenty o dużym wpływie są obsługiwane wystarczająco szybko i przy użyciu odpowiednich zasobów.

Dlaczego to ważne

Wskazuje wpływ incydentu na działalność firmy, co pozwala skupić analizę na najpoważniejszych problemach i sprawdzić, czy są sprawnie rozwiązywane.

Skąd pobrać

Zazwyczaj jest to pole niestandardowe. Konfigurację można sprawdzić w sekcji Ticket Fields w Zendesk Admin Center.

Przykłady
1 - Krytyczny2 - Wysoki3 - Średni4 - Niski
Zgłaszający
Submitter
Użytkownik końcowy lub system, który pierwotnie zgłosił incydent.
Opis

Ten atrybut wskazuje osobę lub podmiot, który utworzył zgłoszenie. Nie należy go mylić ze zgłaszającym problem, ponieważ agent może utworzyć zgłoszenie w czyimś imieniu.

Analiza danych o osobie zgłaszającej pomaga ustalić, kto informuje o problemach. Po połączeniu z danymi o organizacji może pokazać, czy określeni klienci lub grupy użytkowników zgłaszają wiele incydentów. Takie informacje mogą pomóc w planowaniu działań zapobiegawczych i szkoleń.

Dlaczego to ważne

Wskazuje źródło zgłoszenia incydentu. Analiza tego atrybutu może ujawnić wzorce związane z konkretnymi użytkownikami, działami lub systemami automatycznymi.

Skąd pobrać

Zendesk Tickets API, pole submitter_id.

Przykłady
alice.jones@example.combob.williams@example.comMonitor systemu
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi incydentów

To ważne kroki i punkty kontrolne procesu, które należy zapisać w dzienniku zdarzeń, aby prawidłowo odkryć i przeanalizować jego przebieg.
6 Zalecane 7 Opcjonalne
Działanie Opis
Ponowne przypisanie zgłoszenia
Występuje, gdy po początkowym przypisaniu odpowiedzialność za zgłoszenie zostaje przeniesiona z jednego agenta lub grupy do innego. Jest to jawne zdarzenie zapisywane w historii audytowej zgłoszenia.
Dlaczego to ważne

Ponowne przypisania są ważne przy analizie przekazań i powtarzanych działań. Częste zmiany mogą wskazywać na błędne początkowe skierowanie zgłoszenia, złożone problemy lub wąskie gardła w procesie.

Skąd pobrać

Dane pochodzą z dziennika audytowego zgłoszenia. Wyszukiwane jest zdarzenie 'Change' dotyczące pola 'assignee_id' lub 'group_id', które wystąpiło po pierwszym wypełnieniu tego pola.

Rejestrowanie

Identyfikowane na podstawie kolejnego zdarzenia 'Change' dotyczącego pola 'assignee_id' lub 'group_id'.

Typ zdarzenia explicit
Przypisanie zgłoszenia do agenta
To działanie występuje, gdy zgłoszenie zostaje przypisane konkretnemu agentowi. Jest jawnie rejestrowane w historii audytowej zgłoszenia i oznacza, że dana osoba przejęła za nie odpowiedzialność.
Dlaczego to ważne

Ten etap pozwala mierzyć czas do pierwszego przypisania i analizować przekazania, powtarzane działania oraz wskaźnik spraw rozwiązanych przy pierwszym kontakcie.

Skąd pobrać

Dane pochodzą z dziennika audytowego zgłoszenia, gdy pole 'assignee_id' zostaje wypełnione lub zmienione. Pierwsze przypisanie to ważny etap przy obliczaniu KPI.

Rejestrowanie

Identyfikowane na podstawie zdarzenia 'Change' dotyczącego pola 'assignee_id' w dzienniku audytowym zgłoszenia.

Typ zdarzenia explicit
Rozwiązanie incydentu
Ten ważny etap następuje, gdy agent wdroży rozwiązanie i oznaczy zgłoszenie jako 'solved'. Jest to jawne działanie rejestrowane w dzienniku audytowym jako zmiana statusu zgłoszenia.
Dlaczego to ważne

To podstawowe działanie oznaczające rozwiązanie incydentu i ważny punkt przy pomiarze czasu do rozwiązania. Czas między tym zdarzeniem a „Zamknięciem incydentu” oznacza okres oczekiwania na potwierdzenie użytkownika lub automatyczne zamknięcie.

Skąd pobrać

Dane pochodzą z dziennika audytowego zgłoszenia. Zdarzenie 'Change' jest rejestrowane, gdy nowa wartość pola 'status' to 'solved'.

Rejestrowanie

Identyfikowane na podstawie zdarzenia 'Change', które zmienia pole 'status' na 'solved'.

Typ zdarzenia explicit
Utworzenie incydentu
Początek cyklu życia incydentu, gdy w Zendesk zostaje utworzone nowe zgłoszenie. Zdarzenie jest rejestrowane w dzienniku audytowym zgłoszenia i stanowi punkt początkowy każdego przypadku.
Dlaczego to ważne

To podstawowe działanie rozpoczynające proces. Analiza czasu od tego zdarzenia do kolejnych pozwala mierzyć całkowity czas obsługi zgłoszenia i czas do pierwszej odpowiedzi.

Skąd pobrać

To jawne zdarzenie zapisane w dzienniku audytowym zgłoszenia w Zendesk. Każde nowe zgłoszenie generuje zdarzenie „Create” z odpowiednim timestampem.

Rejestrowanie

Bezpośrednio ze zdarzenia utworzenia zgłoszenia w dzienniku audytowym.

Typ zdarzenia explicit
Zamknięcie incydentu
Oznacza koniec cyklu życia incydentu, gdy zgłoszenie zostaje trwale zamknięte. W Zendesk często następuje to automatycznie po określonym czasie od rozwiązania zgłoszenia i jest rejestrowane jako końcowa zmiana statusu.
Dlaczego to ważne

To końcowe działanie w procesie. Całkowity czas procesu oblicza się od „Utworzenia incydentu” do tego zdarzenia, co daje pełny obraz czasu cyklu.

Skąd pobrać

Dane pochodzą z dziennika audytowego zgłoszenia. Zdarzenie 'Change' jest rejestrowane, gdy nowa wartość pola 'status' to 'closed'.

Rejestrowanie

Identyfikowane na podstawie zdarzenia 'Change', które zmienia pole 'status' na 'closed'.

Typ zdarzenia explicit
Zmiana statusu na otwarty
Oznacza, że agent rozpoczął pracę nad incydentem. Zdarzenie jest zwykle wywnioskowane ze zmiany pola 'status' zgłoszenia z 'new' na 'open', która oznacza początek analizy i diagnozy problemu.
Dlaczego to ważne

To zdarzenie oznacza przejście od oczekiwania w kolejce do aktywnej pracy. Czas, przez jaki zgłoszenie ma status 'new' przed zmianą na 'open', jest ważnym miernikiem czasu do pierwszej reakcji.

Skąd pobrać

Wnioskowane na podstawie dziennika audytowego zgłoszenia. Wyszukiwane jest zdarzenie 'Change', w którym nowa wartość pola 'status' to 'open', a poprzednia to 'new'.

Rejestrowanie

Wnioskowane na podstawie zmiany pola statusu z 'new' na 'open'.

Typ zdarzenia inferred
Dodanie notatki wewnętrznej
To działanie oznacza współpracę wewnątrz zespołu. Agent dodaje prywatną notatkę do zgłoszenia, aby przekazać informacje innym członkom zespołu. Zdarzenie jest jawnie rejestrowane, gdy komentarz nie jest publiczny.
Dlaczego to ważne

Analiza notatek wewnętrznych może ujawnić, które problemy wymagają współpracy. Ich nadmierna liczba może jednak wskazywać na braki w wiedzy lub nieefektywności procesu.

Skąd pobrać

Dane pochodzą z komentarzy do zgłoszenia. Komentarz jest uznawany za notatkę wewnętrzną, gdy jego atrybut 'public' ma wartość false.

Rejestrowanie

Zdarzenie jest rejestrowane po dodaniu do zgłoszenia nowego komentarza z wartością 'public: false'.

Typ zdarzenia explicit
Naruszenie celu SLA
Oznacza moment, w którym zgłoszenie nie spełnia wymagań określonych w umowie o gwarantowanym poziomie usług, na przykład dotyczących czasu pierwszej odpowiedzi lub rozwiązania. Zdarzenie jest obliczane na podstawie definicji zasad SLA i timestampów aktualizacji zgłoszenia.
Dlaczego to ważne

To zdarzenie wspiera monitorowanie zgodności z SLA. Ustalenie, kiedy i dlaczego dochodzi do naruszeń, jest podstawą poprawy niezawodności obsługi i zaufania klientów.

Skąd pobrać

To zdarzenie obliczane. Można je wyznaczyć na podstawie danych 'sla_policy_metrics' powiązanych ze zgłoszeniem, wykorzystując timestamp 'breached_at' dla każdego celu SLA.

Rejestrowanie

Wyznaczane na podstawie timestampu 'breached_at' w danych o miernikach SLA zgłoszenia.

Typ zdarzenia calculated
Ocena satysfakcji użytkownika
Oznacza moment, w którym użytkownik końcowy ocenia otrzymaną pomoc. Jest to jawne zdarzenie rejestrowane w Zendesk po rozwiązaniu zgłoszenia.
Dlaczego to ważne

Analiza ocen satysfakcji dostarcza informacji o pracy agentów i skuteczności procesu. Pozwala powiązać mierniki procesu z wynikami obsługi klienta.

Skąd pobrać

Dane pochodzą z ocen satysfakcji powiązanych ze zgłoszeniem. Zazwyczaj obejmują ocenę („good” lub „bad”) i opcjonalny komentarz.

Rejestrowanie

Zdarzenie jest rejestrowane po przesłaniu oceny satysfakcji dotyczącej zgłoszenia.

Typ zdarzenia explicit
Przypisanie zgłoszenia do grupy
Początkowe skierowanie incydentu do konkretnej grupy wsparcia lub jego wstępna selekcja. Zwykle jest to pierwszy krok przydzielania odpowiedzialności. Zdarzenie jest zapisywane w historii audytowej zgłoszenia jako jawna zmiana.
Dlaczego to ważne

Śledzenie przypisań do grup pozwala ocenić sprawność wstępnej selekcji i wykryć opóźnienia przed skierowaniem zgłoszenia do właściwego zespołu.

Skąd pobrać

Dane pochodzą z dziennika audytowego zgłoszenia. Zdarzenie jest rejestrowane za każdym razem, gdy pole 'group_id' zostaje ustawione lub zmienione. Pierwsza taka zmiana po utworzeniu zgłoszenia oznacza początkowe przypisanie.

Rejestrowanie

Identyfikowane na podstawie zdarzenia 'Change' dotyczącego pola 'group_id' w dzienniku audytowym zgłoszenia.

Typ zdarzenia explicit
Ustalenie priorytetu
Incydentowi zostaje przypisany priorytet, na przykład niski, normalny, wysoki lub pilny. Jest to jawnie rejestrowane jako zmiana i określa pilność zgłoszenia oraz wymagany czas reakcji.
Dlaczego to ważne

Śledzenie tego, kiedy i jak ustalany jest priorytet, ma znaczenie dla dashboardu „Skuteczność ustalania priorytetów”. Pomaga dopilnować, by pilne problemy były obsługiwane bez zwłoki.

Skąd pobrać

Dane pochodzą ze zdarzenia 'Change' dotyczącego pola 'priority' w dzienniku audytowym zgłoszenia. Można też śledzić kolejne zmiany, aby obliczyć KPI dotyczący częstotliwości zmian priorytetu.

Rejestrowanie

Identyfikowane na podstawie zdarzenia 'Change' dotyczącego pola 'priority' w dzienniku audytowym zgłoszenia.

Typ zdarzenia explicit
Wysłanie publicznej odpowiedzi
Wiadomość wysłana przez agenta wsparcia do użytkownika końcowego. Jest to jawne zdarzenie w Zendesk, rejestrowane za każdym razem, gdy do zgłoszenia zostaje dodany publiczny komentarz.
Dlaczego to ważne

Śledzenie publicznych odpowiedzi pomaga zrozumieć częstotliwość komunikacji. Odpowiedzi mogą też stanowić ważny element analizy opóźnień w potwierdzeniu przez użytkownika.

Skąd pobrać

Dane pochodzą z komentarzy do zgłoszenia. Komentarz jest uznawany za publiczny, gdy jego atrybut 'public' ma wartość true.

Rejestrowanie

Zdarzenie jest rejestrowane po dodaniu do zgłoszenia nowego komentarza z wartością 'public: true'.

Typ zdarzenia explicit
Zmiana statusu na oczekujący
Oznacza wstrzymanie procesu w oczekiwaniu na odpowiedź osoby zgłaszającej. Zdarzenie jest wywnioskowane ze zmiany pola 'status' zgłoszenia na 'pending'.
Dlaczego to ważne

To działanie jest niezbędne do obliczenia czasu oczekiwania na potwierdzenie od użytkownika. Długi czas w tym stanie może znacznie wydłużyć całkowity czas rozwiązania i wskazywać na opóźnienia w komunikacji.

Skąd pobrać

Wnioskowane na podstawie dziennika audytowego zgłoszenia. Wyszukiwane jest zdarzenie 'Change', w którym nowa wartość pola 'status' to 'pending'.

Rejestrowanie

Wnioskowane na podstawie zmiany pola statusu na 'pending'.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje eksportu danych

Jak pobrać dane z Zendesk Support

Jak rozpocząć?

Skorzystaj z tego szablonu, aby usprawnić przygotowanie danych i lepiej poznać wyniki obsługi incydentów. Można od razu przystąpić do analizy procesu.

Usprawnij obsługę incydentów i szybciej rozwiązuj zgłoszenia

Skróć MTTR o 35%, ogranicz powtarzające się incydenty i zwiększ satysfakcję klientów.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Usprawnienia można rozpocząć w kilka minut.