Szablon danych dotyczących obsługi incydentów
Szablon danych dotyczących obsługi incydentów
- Zalecane atrybuty do zebrania
- Działania do śledzenia podczas mapowania procesów
- Praktyczne wskazówki dotyczące eksportu danych
Atrybuty obsługi incydentów
| 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
|
|||
Działania w procesie obsługi incydentów
| 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
|
|||
Instrukcje eksportu danych
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.
Karta kredytowa nie jest wymagana. Usprawnienia można rozpocząć w kilka minut.