Szablon danych dotyczących obsługi klienta

ServiceNow CSM
Szablon danych dotyczących obsługi klienta

Szablon danych dotyczących obsługi klienta

Ten szablon wskazuje, jakie informacje zebrać do analizy procesu obsługi klienta. Zawiera zalecane atrybuty danych, listę najważniejszych czynności do śledzenia oraz wskazówki dotyczące pobierania informacji z systemu źródłowego. Ułatwia przygotowanie danych do process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze czynności do śledzenia
  • Wskazówki dotyczące ekstrakcji danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty obsługi klienta

To zalecane pola, które warto uwzględnić w dzienniku zdarzeń, aby przeprowadzić pełną analizę obsługi klienta.
3 Wymagane 6 Zalecane 9 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładny znacznik czasu wskazujący, kiedy wystąpiło dane działanie lub zdarzenie.
Opis

Czas zdarzenia określa datę i godzinę wykonania działania. Ten znacznik czasu jest niezbędny do uporządkowania zdarzeń chronologicznie i obliczania czasu między poszczególnymi etapami procesu.

W analizie process mining atrybut ten służy do obliczania wszystkich miar opartych na czasie, w tym czasów cyklu, oczekiwania i realizacji. Pozwala wykrywać wąskie gardła przez wskazanie działań poprzedzonych długim oczekiwaniem oraz mierzyć wyniki względem umów SLA. Rzetelna analiza wymaga dokładnych i spójnych znaczników czasu.

Dlaczego to ważne

Ten znacznik czasu jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania miar efektywności, takich jak czasy cyklu i wąskie gardła.

Skąd pobrać

Zwykle odpowiada polu „sys_created_on” w tabelach audytu i historii ServiceNow, np. „sys_audit”.

Przykłady
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
Zgłoszenie serwisowe
ServiceRequest
Unikalny identyfikator każdego zgłoszenia serwisowego, sprawy lub zgłoszenia klienta.
Opis

Zgłoszenie serwisowe to główny identyfikator sprawy, który łączy wszystkie powiązane działania i zdarzenia dotyczące jednego problemu klienta, od utworzenia do zamknięcia. Stanowi wspólny punkt odniesienia przy śledzeniu całego przebiegu interakcji z klientem.

W process mining ten atrybut jest podstawą odtworzenia przebiegu procesu. Każda unikalna wartość zgłoszenia serwisowego odpowiada jednej instancji procesu, co pozwala analizować czasy cyklu, ścieżki i różnice między poszczególnymi sprawami. Dzięki temu wszystkie etapy, od pierwszego kontaktu po rozwiązanie i zamknięcie, są prawidłowo przypisane do tego samego zapytania klienta.

Dlaczego to ważne

To podstawowy identyfikator sprawy, który łączy wszystkie etapy procesu i umożliwia analizę pełnego cyklu życia każdej interakcji z działem obsługi klienta.

Skąd pobrać

Zwykle jest to pole „number” z tabeli „sn_customerservice_case” w ServiceNow CSM.

Przykłady
CS0010001CS0010045CS0010112
Nazwa działania
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w cyklu życia zgłoszenia serwisowego.
Opis

Nazwa działania opisuje etap procesu obsługi klienta, na przykład „Utworzenie zgłoszenia serwisowego”, „Przypisanie zgłoszenia agentowi” lub „Propozycja rozwiązania”. Działania są wyodrębniane z dzienników systemowych lub aktualizacji tabel, aby utworzyć chronologiczną sekwencję zdarzeń dla każdego zgłoszenia serwisowego.

Ten atrybut jest niezbędny do wizualizacji mapy procesu, wykrywania wąskich gardeł i zrozumienia przepływu pracy. Analiza kolejności i częstotliwości działań pozwala ustalić typowe ścieżki procesu, odstępstwa oraz miejsca, w których praca jest powtarzana lub przebiega nieefektywnie. Szczegółowość zdefiniowanych działań bezpośrednio wpływa na zakres wniosków, jakie można wyciągnąć z modelu procesu.

Dlaczego to ważne

Ten atrybut stanowi podstawę mapy procesu. Określa konkretne etapy i zadania, których kolejność oraz czas trwania są analizowane.

Skąd pobrać

To atrybut pojęciowy wyprowadzany z systemowych tabel audytu, np. „sys_audit”, lub przez śledzenie zmian stanu i aktualizacji ważnych pól w tabeli „sn_customerservice_case”.

Przykłady
Utworzono zgłoszenie serwisowePrzypisano zgłoszenie agentowiOczekiwanie na informacje od klientaRozwiązanie zgłoszenia serwisowego
Czy przekroczono SLA
IsSlaBreached
Wartość logiczna wskazująca, czy zgłoszenie serwisowe przekroczyło wyznaczony limit czasu określony w umowie SLA.
Opis

Ten atrybut obliczany wskazuje, czy zgłoszenie serwisowe zostało rozwiązane w uzgodnionym terminie. Przyjmuje wartość „True”, jeśli czas rozwiązania przekroczył limit SLA, a w przeciwnym razie „False”. Dzięki temu dla każdej sprawy można jednoznacznie ocenić, czy dotrzymano SLA.

Atrybut ten jest niezbędny na dashboardzie „Trendy dotrzymywania i naruszania SLA” oraz przy obliczaniu KPI „Wskaźnik dotrzymywania SLA”. Ułatwia analizę, ponieważ pozwala bezpośrednio filtrować i zliczać sprawy z przekroczonym SLA. Można dzięki temu szybko ustalić, które typy zgłoszeń, priorytety lub zespoły najczęściej wiążą się z naruszeniami SLA.

Dlaczego to ważne

Jednoznacznie wskazuje, czy sprawa została rozwiązana w terminie. To podstawowa informacja przy pomiarze i raportowaniu zgodności z SLA.

Skąd pobrać

Wartość obliczana na podstawie pola „made_sla” z tabeli „task_sla” lub przez porównanie rzeczywistego czasu rozwiązania z planowanym.

Przykłady
truefalse
Grupa przypisania
AssignmentGroup
Zespół lub dział odpowiedzialny za zgłoszenie serwisowe.
Opis

Grupa przypisania oznacza kolejkę lub zespół, do którego trafia zgłoszenie serwisowe. W zależności od rodzaju problemu zgłoszenia są często przekazywane między różnymi grupami, na przykład do zespołu wsparcia pierwszego poziomu, specjalistycznego zespołu technicznego lub działu rozliczeń.

Ten atrybut jest niezbędny do analizy przekazywania spraw między działami i wykrywania wąskich gardeł na poziomie zespołów. Pokazuje przepływ pracy między różnymi obszarami i może wskazać przeciążone zespoły lub potrzebę dodatkowych szkoleń. Wspiera dashboardy „Przekazywanie i ponowne przypisywanie spraw przez agentów” oraz „Przepływ procesu”.

Dlaczego to ważne

Wskazuje zespół odpowiedzialny za pracę, co pozwala analizować wyniki i obciążenie zespołów oraz przekazywanie spraw między działami.

Skąd pobrać

Odpowiada polu „assignment_group” w tabeli „sn_customerservice_case”.

Przykłady
Dział obsługiZapytania dotyczące rozliczeńWsparcie techniczne drugiego poziomu
Kategoria
Category
Główna klasyfikacja zgłoszenia serwisowego, na przykład „Rozliczenia” lub „Problem techniczny”.
Opis

Kategoria grupuje zgłoszenia serwisowe według rodzaju zapytania lub problemu klienta. Zwykle jest określana przy tworzeniu zgłoszenia i pomaga skierować je do właściwej grupy przypisania.

Ten atrybut jest niezbędny do podziału analizy procesu. Filtrowanie według kategorii pozwala porównywać przebieg obsługi różnych typów zgłoszeń. Na przykład proces rozwiązania problemu z rozliczeniem może znacznie różnić się od obsługi problemu technicznego. To ważny atrybut, który umożliwia filtrowanie danych w niemal każdym dashboardzie.

Dlaczego to ważne

Pozwala podzielić analizę według typu zgłoszenia i sprawdzić, czy określone kategorie częściej wiążą się z opóźnieniami, eskalacjami lub naruszeniami SLA.

Skąd pobrać

Odpowiada polu „category” w tabeli „sn_customerservice_case”.

Przykłady
Zapytanie / pomocZamówieniaProblemy z produktemRozliczenia
Priorytet
Priority
Poziom priorytetu zgłoszenia serwisowego, który wpływa na pilność jego obsługi.
Opis

Priorytet określa wagę zgłoszenia serwisowego i pilność jego obsługi. Zwykle ustala się go na podstawie wpływu problemu na klienta i jego pilności. Typowe wartości obejmują poziomy od krytycznego do niskiego.

W process mining priorytet jest wymiarem, według którego można filtrować i porównywać dane. Analitycy mogą sprawdzić, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej niż zgłoszenia o niskim priorytecie oraz czy naruszenia SLA częściej dotyczą określonych poziomów priorytetu. To podstawowy atrybut dashboardu „Pełny czas cyklu zgłoszenia serwisowego”.

Dlaczego to ważne

Pozwala podzielić zgłoszenia serwisowe według pilności i sprawdzić, czy krytyczne problemy są obsługiwane szybciej niż pozostałe.

Skąd pobrać

Odpowiada polu „priority” w tabeli „sn_customerservice_case”.

Przykłady
1 - Krytyczny2 - Wysoki3 - Umiarkowany4 - Niski
Przypisany agent
AssignedAgent
Agent obsługi klienta aktualnie odpowiedzialny za zgłoszenie serwisowe.
Opis

Ten atrybut wskazuje użytkownika odpowiedzialnego za zgłoszenie serwisowe w danym momencie. W trakcie obsługi sprawy często się zmienia, gdy zgłoszenie jest przekazywane innym agentom lub specjalistom.

Analiza przypisanego agenta pomaga zrozumieć rozkład obciążenia, wyniki pracy agentów i przekazywanie spraw. Pozwala ustalić, którzy agenci obsługują najtrudniejsze sprawy, jak często sprawy są ponownie przypisywane oraz czy praca określonych agentów wiąże się z dłuższym czasem rozwiązania lub większym zadowoleniem klientów. Atrybut ten jest niezbędny w dashboardzie „Przekazywanie i ponowne przypisywanie spraw przez agentów”.

Dlaczego to ważne

Pozwala śledzić odpowiedzialność agentów i analizować obciążenie, wyniki pracy oraz częstotliwość ponownego przypisywania spraw, które często wskazuje na utrudnienia w procesie.

Skąd pobrać

Odpowiada polu „assigned_to” w tabeli „sn_customerservice_case”.

Przykłady
Beth AnglinDavid LooAbel Tuter
Stan
State
Bieżący status lub stan zgłoszenia serwisowego w jego cyklu życia.
Opis

Atrybut stanu opisuje bieżący status operacyjny zgłoszenia serwisowego, na przykład „New”, „In Progress”, „Awaiting Info”, „Resolved” lub „Closed”. Zmiany tego pola często służą do definiowania działań w modelu procesu.

Analiza stanu pokazuje, na jakim etapie procesu znajdują się sprawy. Pozwala ustalić, jak długo sprawy pozostają w określonych stanach, takich jak „Awaiting Info”, który może być istotnym źródłem opóźnień. Pomaga też określić początek i koniec ważnych KPI, takich jak „Czas od rozwiązania do zamknięcia”.

Dlaczego to ważne

Wskazuje status zgłoszenia w danym momencie i pomaga ustalić, ile czasu sprawa pozostaje w stanach nieprowadzących do postępu, takich jak „On Hold” lub „Awaiting Information”.

Skąd pobrać

Odpowiada polu „state” w tabeli „sn_customerservice_case”.

Przykłady
NoweW tokuOczekiwanie na informacje od użytkownikaRozwiązaneZamknięte
Czy rozwiązano przy pierwszym kontakcie
IsFirstContactResolution
Wartość logiczna wskazująca, czy zgłoszenie rozwiązał pierwszy przypisany agent, bez przekazywania sprawy dalej ani eskalacji.
Opis

Ten atrybut obliczany wskazuje zgłoszenia serwisowe rozwiązane sprawnie podczas pierwszego kontaktu lub przez pierwszego agenta obsługującego sprawę. Zwykle sprawdza, czy nie było ponownych przypisań („ReassignmentCount” wynosi 0), czynności „Uruchomiono eskalację wewnętrzną” ani próśb o dodatkowe informacje od klienta.

Atrybut bezpośrednio mierzy istotny wskaźnik obsługi klienta i wspiera dashboard oraz KPI „Wskaźnik rozwiązań przy pierwszym kontakcie”. Ułatwia pomiar FCR i analizę czynników, takich jak kanał kontaktu czy kategoria zgłoszenia, które sprzyjają rozwiązaniu sprawy przy pierwszym kontakcie lub je utrudniają.

Dlaczego to ważne

Bezpośrednio mierzy sprawność pierwszej odpowiedzi. Wysoki wskaźnik FCR wiąże się zarówno z efektywnością operacyjną, jak i wysokim zadowoleniem klientów.

Skąd pobrać

To atrybut obliczany podczas transformacji danych na podstawie reguł, takich jak brak ponownych przypisań („ReassignmentCount” wynosi zero) i brak eskalacji.

Przykłady
truefalse
Czy wystąpiła ponowna praca
IsRework
Wartość logiczna wskazująca, czy wystąpiła istotna ponowna praca, na przykład ponowne otwarcie sprawy lub powtórzenie analizy.
Opis

Ten atrybut obliczany oznacza sprawy, w których występują oznaki nieefektywności lub powtarzania czynności. Może być ustawiany na przykład po zdarzeniu „Ponownie otwarto zgłoszenie serwisowe” albo gdy kluczowa sekwencja czynności, taka jak „Agent rozpoczyna analizę”, a następnie „Zaproponowano rozwiązanie”, powtarza się w tej samej sprawie.

Atrybut ułatwia szybkie wykrywanie problematycznych spraw i pomiar skali ponownej pracy w procesie. Wspiera dashboard „Miejsca częstej ponownej pracy i powtórzeń” oraz KPI „Wskaźnik ponownej pracy”. Analitycy mogą skupić się na przyczynach nieefektywności bez ręcznego wyszukiwania powtarzających się wzorców.

Dlaczego to ważne

Pomaga mierzyć nieefektywność procesu, oznaczając sprawy z powtarzającymi się pętlami lub ponownymi otwarciami. Ułatwia pomiar i ograniczanie ponownej pracy.

Skąd pobrać

To atrybut obliczany podczas transformacji danych na podstawie reguł wykrywających ponowną pracę, takich jak niezerowa wartość „ReopenCount” lub powtarzające się czynności.

Przykłady
truefalse
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane zostały ostatnio wyodrębnione z systemu źródłowego lub odświeżone.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych. Informuje o ich aktualności, dzięki czemu użytkownicy wiedzą, czy analizują dane niemal w czasie rzeczywistym, czy historyczną migawkę.

Podczas analizy te metadane pomagają określić zakres czasowy zbioru danych. Ułatwiają prawidłową interpretację dashboardów i KPI, na przykład pozwalają sprawdzić, czy dane są aktualne na ostatnią godzinę czy na poprzedni dzień.

Dlaczego to ważne

Informuje o aktualności danych, co wpływa na przydatność i terminowość wniosków z process mining.

Skąd pobrać

Ten znacznik czasu jest generowany i dodawany podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL).

Przykłady
2023-11-20T08:00:00Z
Kanał
Channel
Kanał komunikacji, za pośrednictwem którego zgłoszono sprawę serwisową.
Opis

Kanał wskazuje sposób, w jaki klient zgłosił sprawę, na przykład przez e-mail, telefon, portal internetowy lub czat. Poszczególne kanały mogą wiązać się z różnym przebiegiem obsługi i oczekiwaniami klientów.

Analiza procesu według kanału pozwala ocenić skuteczność poszczególnych sposobów komunikacji. Może na przykład pokazać, czy zgłoszenia telefoniczne częściej są rozwiązywane przy pierwszym kontakcie albo czy obsługa zgłoszeń e-mailowych trwa dłużej. Wspiera to dashboard „Skuteczność kanałów komunikacji”.

Dlaczego to ważne

Pomaga porównać efektywność i wyniki obsługi w różnych kanałach kontaktu z klientem, takich jak telefon, e-mail czy portal internetowy.

Skąd pobrać

Zwykle odpowiada polu „contact_type” w tabeli „sn_customerservice_case”.

Przykłady
TelefonE-mailSamoobsługaCzat
Klient
Customer
Nazwa lub identyfikator klienta albo firmy, która zgłosiła sprawę serwisową.
Opis

Ten atrybut wskazuje zewnętrzną stronę, osobę lub organizację, której dotyczy zgłoszenie serwisowe. Dostarcza informacji o kliencie powiązanym ze sprawą.

Atrybut klienta pozwala analizować proces obsługi z perspektywy klienta. Można sprawdzić, czy określeni klienci częściej zgłaszają problemy lub dłużej czekają na ich rozwiązanie. Dane można też połączyć z innymi informacjami o kliencie, takimi jak segment lub wartość, aby ustalić priorytety ulepszania procesów. Można na przykład sprawdzić, czy klienci o wysokiej wartości otrzymują szybszą obsługę.

Dlaczego to ważne

Łączy proces z konkretnymi klientami, umożliwiając analizę poziomu obsługi i częstotliwości problemów wśród ważnych klientów lub segmentów.

Skąd pobrać

Może to być pole „caller_id”, „opened_for” lub „account” w tabeli „sn_customerservice_case”, odwołujące się do tabel użytkowników lub firm.

Przykłady
John SmithACME CorporationGlobal Tech Inc.
Kod rozwiązania
ResolutionCode
Kod wskazujący końcowy wynik lub sposób rozwiązania zgłoszenia serwisowego.
Opis

Kod rozwiązania to ustrukturyzowana wartość wybierana przez agenta po rozwiązaniu sprawy. Określa szczegóły rozwiązania, na przykład „Rozwiązane przez użytkownika”, „Znany błąd”, „Duplikat” lub „Nie wymaga działania”.

Ten atrybut przydaje się w analizie przyczyn źródłowych. Analiza częstotliwości poszczególnych kodów rozwiązania pozwala wykrywać powtarzające się problemy, braki w wiedzy lub problemy z produktem. Na tej podstawie można wprowadzać usprawnienia ograniczające liczbę zgłoszeń określonego typu.

Dlaczego to ważne

Informuje o wynikach obsługi zgłoszeń serwisowych, co pomaga analizować przyczyny źródłowe i wykrywać powtarzające się problemy.

Skąd pobrać

Odpowiada polu „close_code” lub niestandardowemu polu kodu rozwiązania w tabeli „sn_customerservice_case”.

Przykłady
Rozwiązane (obejście problemu)Rozwiązane (trwale)Nierozwiązane (brak odpowiedzi klienta)Zamknięte/rozwiązane przez zgłaszającego
Liczba ponownych otwarć
ReopenCount
Liczba przypadków ponownego otwarcia przez klienta rozwiązanej sprawy serwisowej.
Opis

Ten licznik rejestruje, ile razy sprawa przeszła ze stanu „Resolved” lub „Closed” z powrotem do stanu „In Progress” lub „Open”. Ponowne otwarcie sprawy może oznaczać, że pierwotne rozwiązanie było nieskuteczne lub niekompletne.

Atrybut ten wyraźnie wskazuje na konieczność ponownej pracy i jakość rozwiązania za pierwszym razem. Duża liczba ponownych otwarć sygnalizuje problemy z obsługą, na przykład przedwczesne zamykanie zgłoszeń przez agentów lub niepełne rozwiązanie problemu klienta. To ważna miara skuteczności proponowanych rozwiązań.

Dlaczego to ważne

Wskazuje nieskuteczne rozwiązania i konieczność ponownej pracy. Duża liczba ponownie otwartych spraw świadczy o niskiej jakości ich rozwiązywania i prowadzi do frustracji klientów.

Skąd pobrać

Liczba ponownych otwarć jest często zapisywana w polu „reopen_count” w tabeli „sn_customerservice_case” lub w powiązanej tabeli.

Przykłady
012
Liczba ponownych przypisań
ReassignmentCount
Łączna liczba przypadków, w których zgłoszenie serwisowe przypisano innemu agentowi lub grupie.
Opis

Ten atrybut jest licznikiem zwiększanym za każdym razem, gdy zmienia się pole „assigned_to” lub „assignment_group”. Pokazuje, ile razy sprawa była przekazywana wewnątrz organizacji.

Liczba ponownych przypisań bezpośrednio wskazuje na utrudnienia w procesie. Jest ważnym źródłem danych dla dashboardu „Przekazywanie i ponowne przypisywanie spraw przez agentów” oraz KPI „Średnia liczba przekazań na zgłoszenie”. Duża liczba ponownych przypisań często oznacza problemy z początkowym kierowaniem spraw, braki w umiejętnościach agentów lub trudności z klasyfikacją zgłoszeń. Wszystkie te czynniki wydłużają czas rozwiązania.

Dlaczego to ważne

Bezpośrednio mierzy nieefektywność procesu, zliczając przekazania spraw. Duża liczba przekazań często wiąże się z dłuższym czasem rozwiązania i niezadowoleniem klientów.

Skąd pobrać

To standardowe pole miary „reassignment_count” w tabeli „task”, po której tabelę „sn_customerservice_case” rozszerza.

Przykłady
0135
System źródłowy
SourceSystem
System, z którego wyodrębniono dane.
Opis

Ten atrybut wskazuje źródło danych, co jest szczególnie ważne, gdy informacje pochodzą z wielu systemów. W tym widoku procesu jego wartością będzie zawsze „ServiceNow CSM”.

Podczas analizy pomaga w zarządzaniu danymi i rozwiązywaniu problemów. Jeśli dane pochodzą z kilku systemów, można filtrować proces, aby sprawdzić jego przebieg w konkretnym systemie lub porównać różnice między systemami.

Dlaczego to ważne

Informuje o pochodzeniu danych, co ułatwia ich interpretację w środowisku korzystającym z wielu systemów i wspiera zarządzanie danymi.

Skąd pobrać

To stała wartość dodawana podczas przekształcania danych w celu oznaczenia źródła zbioru danych.

Przykłady
ServiceNow CSM
Wymagane Zalecane Opcjonalne

Czynności w obsłudze klienta

To najważniejsze etapy i punkty kontrolne procesu, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkryć przebieg procesu.
5 Zalecane 9 Opcjonalne
Działanie Opis
Przypisano zgłoszenie agentowi
To działanie występuje, gdy zgłoszenie serwisowe zostaje przypisane konkretnemu agentowi do zbadania i rozwiązania. Jest wykrywane na podstawie zmiany pola assigned_to w rekordzie sprawy.
Dlaczego to ważne

To ważny etap przy pomiarze czasu pierwszej reakcji i rozkładu obciążenia agentów. Śledzenie zmian wartości tego pola wskazuje nieefektywności procesu i potencjalne wąskie gardła związane z dostępnością agentów.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie historii audytu (sys_audit) tabeli sn_customerservice_case przez śledzenie momentu wypełnienia lub zmiany pola assigned_to.

Rejestrowanie

Wykryj zmianę wartości pola „assigned_to” w historii audytu sprawy.

Typ zdarzenia inferred
Rozwiązanie zgłoszenia serwisowego
Ten ważny etap oznacza, że agent zakończył pracę, a problem uznaje się za rozwiązany. Jest rejestrowany, gdy stan sprawy zmienia się na „Resolved” i zostaje uzupełnione pole resolved_at.
Dlaczego to ważne

To zdarzenie kończy aktywną obsługę sprawy i jest niezbędne do obliczania czasu jej rozwiązania oraz zgodności z SLA. Stanowi punkt końcowy dla wielu KPI dotyczących efektywności.

Skąd pobrać

Zdarzenie można rozpoznać w historii audytu, gdy pole stanu w tabeli sn_customerservice_case przyjmuje wartość „Resolved”. Pole resolved_at jest zwykle uzupełniane w tym samym czasie.

Rejestrowanie

Wykryj zmianę pola „state” na „Resolved” i użyj odpowiadającego jej znacznika czasu.

Typ zdarzenia inferred
Uruchomienie eskalacji wewnętrznej
Oznacza formalne przekazanie zgłoszenia serwisowego do zespołu wsparcia wyższego poziomu lub kierownictwa w celu rozwiązania sprawy. Zdarzenie można rozpoznać po zmianie grupy przypisania na zespół wyższego poziomu lub ustawieniu odpowiedniej flagi.
Dlaczego to ważne

Śledzenie eskalacji pomaga wykrywać słabe punkty procesu, braki w wiedzy zespołu pierwszej linii oraz sprawy o wysokim stopniu złożoności. To ważny sygnał utrudnień w procesie i niezadowolenia klientów.

Skąd pobrać

Zdarzenie można rozpoznać w dzienniku audytu po zmianie pola „assignment_group” na znany zespół eskalacyjny lub po zmianie pola „escalation” w rekordzie sprawy.

Rejestrowanie

Wykryj zmianę pola „escalation” lub przekazanie sprawy do grupy „assignment_group” wyższego poziomu.

Typ zdarzenia inferred
Utworzono zgłoszenie serwisowe
To działanie rozpoczyna proces obsługi klienta. Nowa sprawa zostaje formalnie zarejestrowana w systemie. Zdarzenie jest rejestrowane w chwili dodania nowego rekordu do tabeli sn_customerservice_case.
Dlaczego to ważne

Jako punkt początkowy każdej sprawy działanie to jest niezbędne do obliczenia całkowitego czasu obsługi i analizy liczby przyjmowanych zgłoszeń. Uruchamia dalsze etapy procesu i liczniki SLA.

Skąd pobrać

Zdarzenie odpowiada utworzeniu rekordu w tabeli sn_customerservice_case. Znacznik czasu pochodzi z pola sys_created_on.

Rejestrowanie

Znacznik czasu utworzenia rekordu (sys_created_on) w tabeli sn_customerservice_case.

Typ zdarzenia explicit
Zamknięcie zgłoszenia serwisowego
To ostatnie zdarzenie oznacza formalne zamknięcie rekordu zgłoszenia serwisowego, często po okresie oczekiwania na potwierdzenie po rozwiązaniu sprawy. Jest rejestrowane, gdy stan sprawy zmienia się na „Closed” i zostaje ustawione pole closed_at.
Dlaczego to ważne

Jako ostateczny koniec procesu zdarzenie to jest niezbędne do obliczenia pełnego cyklu życia sprawy. Analiza czasu między stanami „Resolved” i „Closed” pokazuje obciążenie administracyjne lub opóźnienia.

Skąd pobrać

Zdarzenie można rozpoznać w historii audytu, gdy pole stanu w tabeli sn_customerservice_case przyjmuje wartość „Closed”. Pole closed_at jest uzupełniane w tym samym czasie.

Rejestrowanie

Wykryj zmianę pola „state” na „Closed” i użyj odpowiadającego jej znacznika czasu.

Typ zdarzenia inferred
Agent rozpoczyna analizę
To zdarzenie oznacza, że agent rozpoczął pracę nad zgłoszeniem serwisowym. Zwykle można je rozpoznać po zmianie stanu sprawy z „New” lub „Assigned” na „Work in Progress”.
Dlaczego to ważne

To zdarzenie pozwala odróżnić czas oczekiwania w kolejce od czasu aktywnej pracy. Analiza czasu od przypisania sprawy do rozpoczęcia jej analizy pokazuje, jak długo nowe sprawy czekają na podjęcie przez agentów.

Skąd pobrać

Zdarzenie można rozpoznać po zmianie pola stanu sprawy na wartość oznaczającą aktywną pracę, na przykład „Work in Progress”. Konkretne wartości stanów można skonfigurować i należy je zweryfikować.

Rejestrowanie

Wykryj zmianę pola „state” z wartości oznaczającej oczekiwanie na wartość oznaczającą aktywną pracę, np. z „New” na „Work in Progress”.

Typ zdarzenia inferred
Naruszenie SLA
Oznacza moment, w którym zgłoszenie serwisowe nie spełnia wymagań określonych w umowie SLA, na przykład dotyczących czasu rozwiązania. To zdarzenie obliczane na podstawie porównania czasu rozwiązania z planowanym terminem zakończenia SLA.
Dlaczego to ważne

Wykrywanie naruszeń SLA jest podstawą monitorowania zgodności i zarządzania wynikami. To zdarzenie pomaga ustalić, które etapy procesu lub typy spraw najczęściej prowadzą do naruszeń SLA.

Skąd pobrać

Wartość oblicza się na podstawie rekordów powiązanych ze sprawą w tabeli task_sla. Do naruszenia dochodzi, gdy pole has_breached ma wartość true lub actual_elapsed_time przekracza planned_duration.

Rejestrowanie

Sprawdź flagę „has_breached” w powiązanym rekordzie task_sla.

Typ zdarzenia calculated
Oczekiwanie na informacje od klienta
Zdarzenie występuje, gdy agent potrzebuje dodatkowych informacji od klienta, aby kontynuować pracę, i ustawia sprawę w stanie oczekiwania. Można je rozpoznać po zmianie stanu na wartość taką jak „Awaiting User Info” lub „On Hold”.
Dlaczego to ważne

To zdarzenie jest niezbędne do analizy „Czasu oczekiwania na informacje od klienta”. Pozwala oddzielić opóźnienia wynikające z zależności zewnętrznych od czasu wewnętrznej obsługi sprawy.

Skąd pobrać

Zdarzenie można rozpoznać w historii audytu tabeli sn_customerservice_case, gdy pole stanu zmienia się na wartość wskazującą, że sprawa oczekuje na informacje od klienta, np. „Awaiting Info”.

Rejestrowanie

Wykryj zmianę pola „state” na określoną wartość oznaczającą oczekiwanie na klienta.

Typ zdarzenia inferred
Otrzymanie informacji od klienta
To zdarzenie oznacza, że klient przekazał wymagane informacje, dzięki czemu agent może wznowić pracę. Można je rozpoznać po zmianie stanu sprawy z „Awaiting User Info” na stan aktywny.
Dlaczego to ważne

To zdarzenie kończy okres oczekiwania na klienta i pozwala dokładnie mierzyć czas jego odpowiedzi. Pomaga ustalić, które typy spraw lub klienci wiążą się z najdłuższymi opóźnieniami.

Skąd pobrać

Zdarzenie można rozpoznać w historii audytu tabeli sn_customerservice_case, gdy pole stanu zmienia się z „Awaiting Info” na stan aktywny, np. „Work in Progress”.

Rejestrowanie

Wykryj zmianę pola „state” z wartości oznaczającej oczekiwanie na klienta na wartość oznaczającą aktywną pracę.

Typ zdarzenia inferred
Ponowne otwarcie zgłoszenia serwisowego
Zdarzenie występuje, gdy wcześniej rozwiązane zgłoszenie serwisowe wraca do aktywnego stanu, ponieważ problem powrócił lub rozwiązanie okazało się nieskuteczne. Można je rozpoznać po zmianie stanu z „Resolved” na „Work in Progress”.
Dlaczego to ważne

Ponownie otwarte sprawy bezpośrednio wskazują na jakość rozwiązania i są główną przyczyną ponownej pracy. Analiza tych zdarzeń ma zasadnicze znaczenie dla poprawy wskaźnika rozwiązań przy pierwszym kontakcie i zadowolenia klientów.

Skąd pobrać

Zdarzenie można rozpoznać w historii audytu tabeli sn_customerservice_case, identyfikując sekwencję, w której pole stanu zmienia się z „Resolved” na stan aktywny.

Rejestrowanie

Wykryj zmianę pola „state” z „Resolved” na wartość aktywną, np. „Work in Progress”.

Typ zdarzenia inferred
Propozycja rozwiązania
To zdarzenie oznacza, że agent znalazł rozwiązanie i przekazał je klientowi do akceptacji. Zwykle można je rozpoznać po zmianie stanu na wartość taką jak „Awaiting Acceptance” lub po określonym wpisie w notatce roboczej.
Dlaczego to ważne

Ten etap oddziela analizę sprawy od potwierdzenia i jej rozwiązania. Analiza czasu oczekiwania na akceptację klienta może wskazać, jak usprawnić końcowe etapy obsługi sprawy.

Skąd pobrać

Zdarzenie można rozpoznać w dzienniku audytu tabeli sn_customerservice_case, gdy stan zmienia się na wartość oznaczającą zaproponowanie rozwiązania, np. „Proposed Solution”. Wartości mogą się różnić w zależności od wdrożenia.

Rejestrowanie

Wykryj zmianę pola „state” na wartość taką jak „Proposed Solution” lub „Awaiting Acceptance”.

Typ zdarzenia inferred
Skategoryzowano zgłoszenie i ustalono priorytet
Oznacza wstępną kwalifikację zgłoszenia, podczas której określa się jego kategorię i priorytet, aby ustalić pilność oraz sposób przekazania do obsługi. Zdarzenie jest wnioskowane na podstawie zmian pól kategorii, podkategorii lub priorytetu w historii audytu rekordu sprawy.
Dlaczego to ważne

Analiza tego działania pomaga wykryć opóźnienia we wstępnej kwalifikacji spraw i sprawdzić, czy zgłoszenia są kierowane do właściwych osób oraz obsługiwane zgodnie z ich pilnością. Wpływa to na czas do pierwszego przypisania i ogólną efektywność rozwiązywania spraw.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie historii audytu (sys_audit) tabeli sn_customerservice_case, ze szczególnym uwzględnieniem początkowego wypełnienia lub aktualizacji pól kategorii i priorytetu.

Rejestrowanie

Wykryj pierwsze ustawienie wartości lub zmianę wartości pól „category” lub „priority”.

Typ zdarzenia inferred
Wysłanie ankiety klientowi
Oznacza wysłanie ankiety satysfakcji klienta po rozwiązaniu sprawy. Zdarzenie jest zwykle rejestrowane po utworzeniu rekordu ankiety powiązanego ze sprawą.
Dlaczego to ważne

To zdarzenie pozwala zestawić przebieg procesu z opiniami klientów. Informacja o tym, kiedy i czy ankiety są wysyłane, pomaga ocenić skuteczność zbierania informacji zwrotnych.

Skąd pobrać

To jawne zdarzenie zapisywane w tabeli przeznaczonej do ankiet, takiej jak asmt_assessment_instance, która zawiera odwołanie do rekordu sprawy źródłowej.

Rejestrowanie

Utworzenie rekordu w tabeli „asmt_assessment_instance” powiązanego ze sprawą.

Typ zdarzenia explicit
Zmieniono grupę przypisania
Oznacza przekazanie odpowiedzialności za sprawę z jednego zespołu do drugiego. Zdarzenie jest wykrywane przez monitorowanie zmian pola assignment_group w rekordzie sprawy.
Dlaczego to ważne

Śledzenie zmian grup przypisania jest niezbędne do analizy przekazywania spraw między działami i wykrywania systemowych problemów z kierowaniem zgłoszeń. Częste zmiany mogą wskazywać na niejasny podział odpowiedzialności lub nieprecyzyjnie opisany proces.

Skąd pobrać

Zdarzenie jest wnioskowane na podstawie historii audytu (sys_audit) tabeli sn_customerservice_case przez śledzenie zmian pola assignment_group.

Rejestrowanie

Wykryj zmianę wartości pola „assignment_group” w historii audytu sprawy.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z ServiceNow CSM

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby przygotować dane i odkryć możliwości usprawnienia obsługi klienta. Można dzięki temu zwiększyć efektywność procesu i lepiej odpowiadać na potrzeby klientów.

Zwiększ efektywność obsługi klienta

Zwiększ zadowolenie klientów i osiągnij 80% rozwiązań przy pierwszym kontakcie.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.