Szablon danych dotyczących obsługi klienta
Szablon danych dotyczących obsługi klienta
- Zalecane atrybuty do zebrania
- Najważniejsze czynności do śledzenia
- Wskazówki dotyczące ekstrakcji danych
Atrybuty obsługi klienta
| 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
|
|||
Czynności w obsłudze klienta
| 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
|
|||
Instrukcje ekstrakcji danych
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.
Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.