Szablon danych dotyczących obsługi klienta
Szablon danych dotyczących obsługi klienta
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych z Microsoft Dynamics 365 Customer Service
Atrybuty obsługi klienta
| Nazwa | Opis | ||
|---|---|---|---|
|
Zgłoszenie serwisowe
ServiceRequest
|
Unikalny identyfikator zgłoszenia klienta, nazywanego również sprawą lub zgłoszeniem. | ||
|
Opis
Zgłoszenie serwisowe jest głównym identyfikatorem, który łączy wszystkie czynności dotyczące pojedynczego zapytania lub problemu klienta. W process mining pełni funkcję identyfikatora sprawy, zapewniając pełny i spójny obraz każdej interakcji z klientem, od utworzenia sprawy do jej zamknięcia. Analiza według zgłoszenia serwisowego pozwala śledzić cały przebieg obsługi, mierzyć czas rozwiązania i wykrywać powtarzające się wzorce w podobnych sprawach.
Dlaczego to ważne
To podstawowy identyfikator sprawy, który łączy wszystkie powiązane zdarzenia w jedną instancję procesu i umożliwia analizę procesu od początku do końca.
Skąd pobrać
To klucz główny encji Case (incident) w Microsoft Dynamics 365 Customer Service.
Przykłady
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Czas rozpoczęcia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiła czynność. | ||
|
Opis
Ten atrybut zapisuje dokładną datę i godzinę wystąpienia konkretnej czynności. Jest niezbędny do prawidłowego ustalenia kolejności zdarzeń oraz do wszystkich analiz opartych na czasie, w tym obliczania czasu cyklu, czasu trwania i przerw między czynnościami. Dokładny i spójny znacznik czasu ma zasadnicze znaczenie dla rzetelności analizy process mining.
Dlaczego to ważne
Znacznik czasu porządkuje zdarzenia chronologicznie i umożliwia obliczanie czasu trwania, co jest niezbędne do analizy wydajności i wykrywania wąskich gardeł.
Skąd pobrać
Odpowiada polom takim jak 'createdon' lub 'modifiedon' w encji Case (incident) albo w powiązanych encjach aktywności (np. Email, Task, Phone Call).
Przykłady
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Czynność
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego, które wystąpiło w określonym momencie w ramach zgłoszenia serwisowego. | ||
|
Opis
Ten atrybut opisuje pojedynczy krok lub zmianę statusu w procesie obsługi klienta, na przykład „Utworzenie sprawy”, „Analiza problemu przez konsultanta” lub „Rozwiązanie sprawy”. Czynności tworzą podstawę mapy procesu i umożliwiają wizualizację oraz analizę jego przebiegu. Każda czynność połączona ze znacznikiem czasu tworzy zdarzenie określające kolejność działań w procesie.
Dlaczego to ważne
Czynności określają kolejne kroki procesu. Analiza ich kolejności i częstotliwości jest niezbędna do zrozumienia przebiegu procesu, wykrywania odstępstw i znajdowania wąskich gardeł.
Skąd pobrać
Zwykle atrybut powstaje przez przypisanie zmian statusu (statuscode) lub konkretnych zdarzeń z powiązanych encji, takich jak Tasks, Emails lub Phone Calls, do ujednoliconej nazwy czynności.
Przykłady
Utworzenie sprawyAnaliza problemu przez konsultantaPrzedstawienie klientowi proponowanego rozwiązaniaZamknięcie sprawy
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego. | ||
|
Opis
Ten atrybut wskazuje, kiedy dane zostały ostatnio pobrane z Microsoft Dynamics 365. Pozwala ocenić ich aktualność i jest niezbędny do raportowania oraz monitorowania. Dzięki niemu użytkownicy wiedzą, jak aktualne są dane podczas interpretowania dashboardów i analiz.
Dlaczego to ważne
Informuje użytkowników o aktualności danych, co pomaga podejmować na czas trafne decyzje biznesowe na podstawie analizy procesu.
Skąd pobrać
Wartość jest generowana i zapisywana w zbiorze danych podczas ich ekstrakcji.
Przykłady
2023-10-27T08:00:00Z
|
|||
|
System źródłowy
SourceSystem
|
Wskazuje system źródłowy, z którego wyodrębniono dane. | ||
|
Opis
Ten atrybut określa źródło danych o zdarzeniach. W tym procesie będzie to zawsze Microsoft Dynamics 365 Customer Service. W środowiskach korzystających z wielu systemów pole to pozwala rozróżniać źródła danych i śledzić ich pochodzenie.
Dlaczego to ważne
Zapewnia przejrzystą informację o pochodzeniu danych, niezbędną do zarządzania danymi i rozwiązywania problemów z niespójnością, zwłaszcza w analizach łączących dane z różnych systemów.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć źródło zbioru danych.
Przykłady
Microsoft Dynamics 365 Customer Service
|
|||
|
Docelowy czas rozwiązania według SLA
SlaTargetResolutionTime
|
Docelowy czas rozwiązania zgłoszenia serwisowego uzgodniony w umowie. | ||
|
Opis
Ten atrybut określa docelowy czas rozwiązania zgłoszenia serwisowego zgodnie z obowiązującą umową Service Level Agreement (SLA). Jest to punkt odniesienia do pomiaru rzeczywistych wyników. Wartość ta jest niezbędna w dashboardzie monitorowania zgodności z SLA oraz do obliczania KPI „Wskaźnik zgodności z SLA”. Wskazuje, w których obszarach procesu nie są dotrzymywane zobowiązania dotyczące obsługi.
Dlaczego to ważne
To podstawowy punkt odniesienia przy ocenie realizacji zobowiązań dotyczących obsługi. Umożliwia bezpośrednią analizę zgodności z SLA i przypadków przekroczenia ustalonych terminów.
Skąd pobrać
Wartość wynika z konfiguracji SLA w Dynamics 365 i jest powiązana ze sprawą za pośrednictwem encji SLA KPI Instances.
Przykłady
2592008640014400
|
|||
|
Imię i nazwisko konsultanta
AgentName
|
Imię i nazwisko konsultanta obsługi klienta lub użytkownika odpowiedzialnego za daną czynność. | ||
|
Opis
Ten atrybut wskazuje konkretnego konsultanta lub użytkownika systemu, który wykonał czynność, na przykład pobrał element z kolejki lub rozwiązał sprawę. Jest niezbędny do analizy wyników pracy konsultantów, rozkładu obciążenia i przydziału zasobów. Śledzenie czynności na poziomie konsultanta pozwala wskazać osoby osiągające najlepsze wyniki, potrzeby szkoleniowe i nierównomierne obciążenie pracą.
Dlaczego to ważne
Umożliwia analizę wyników pracy poszczególnych osób i zespołów, pomaga równoważyć obciążenie pracą oraz wskazuje możliwości coachingu, który może poprawić jakość obsługi.
Skąd pobrać
Odpowiada polu 'Owner' (ownerid) w encji Case (incident), powiązanemu z encją System User (systemuser).
Przykłady
Alice SmithBob JohnsonSystem
|
|||
|
Kanał
Channel
|
Kanał komunikacji, za pośrednictwem którego zgłoszono sprawę. | ||
|
Opis
Ten atrybut wskazuje źródło kontaktu z klientem, na przykład telefon, e-mail, portal internetowy lub czat. Poszczególne kanały często wiążą się z innym przebiegiem procesu, oczekiwaniami klientów i stopniem złożoności spraw. Analiza procesu według kanału pomaga usprawnić workflow i przydział zasobów dla każdego z nich.
Dlaczego to ważne
Pokazuje, jak różne kanały kontaktu z klientem wpływają na sprawność procesu, czas rozwiązania sprawy i satysfakcję klientów.
Skąd pobrać
Odpowiada polu 'Case Origin' (caseorigincode) w encji Case (incident).
Przykłady
TelefonE-mailInternetCzat
|
|||
|
Nazwa klienta
CustomerName
|
Nazwa klienta lub konta powiązanego ze zgłoszeniem serwisowym. | ||
|
Opis
Ten atrybut wskazuje klienta, który zgłosił sprawę. Umożliwia analizę procesu z perspektywy klienta i pomaga ustalić, którzy klienci zgłaszają najwięcej spraw, najdłużej czekają na ich rozwiązanie lub mają najbardziej złożone problemy. Jest niezbędny do zarządzania relacjami z klientami i doskonalenia obsługi poszczególnych klientów.
Dlaczego to ważne
Umożliwia analizę na poziomie klienta, wykrywanie powtarzających się wzorców, poprawę obsługi ważnych klientów i zrozumienie ich ścieżki.
Skąd pobrać
To pole odnośnika 'Customer' (customerid) w encji Case (incident), które może wskazywać rekord Account lub Contact.
Przykłady
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Priorytet
Priority
|
Poziom priorytetu przypisany do zgłoszenia serwisowego, określający jego pilność. | ||
|
Opis
Ten atrybut określa pilność zgłoszenia serwisowego. Zwykle stosuje się poziomy: niski, normalny, wysoki i pilny. Priorytet wyznacza kolejność obsługi spraw i często wpływa na cele SLA. Analiza jego wpływu na przebieg procesu, przydział zasobów i czas rozwiązania pomaga zapewnić szybką obsługę pilnych problemów.
Dlaczego to ważne
Pomaga ustalić, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej i zgodnie z wyznaczonymi celami oraz jak poziomy priorytetu wpływają na ogólną wydajność procesu.
Skąd pobrać
Odpowiada polu 'Priority' (prioritycode) w encji Case (incident).
Przykłady
NiskiNormalnyWysoki
|
|||
|
Przyczyna statusu
StatusReason
|
Podaje dokładniejszą przyczynę bieżącego statusu zgłoszenia serwisowego. | ||
|
Opis
Sprawa może mieć ogólny status, taki jak 'Active' lub 'Resolved', a przyczyna statusu podaje bardziej szczegółowe informacje, na przykład 'Information Provided' lub 'Problem Solved'. Ten atrybut pomaga zrozumieć, jak i dlaczego sprawy przechodzą przez kolejne etapy. Pozwala na przykład odróżnić sprawy rozwiązane od anulowanych przez klienta, co jest niezbędne do rzetelnej analizy wyników.
Dlaczego to ważne
Dostarcza szczegółowych informacji o wyniku sprawy i przyczynach zmian jej statusu. Umożliwia dokładniejszą analizę ścieżek rozwiązania i przyczyn źródłowych.
Skąd pobrać
Odpowiada polu 'Status Reason' (statuscode) w encji Case (incident).
Przykłady
W tokuWstrzymanaProblem rozwiązanyPrzekazano informacje
|
|||
|
Typ zgłoszenia serwisowego
ServiceRequestType
|
Główna kategoria lub klasyfikacja zgłoszenia serwisowego. | ||
|
Opis
Ten atrybut klasyfikuje zgłoszenie serwisowe według jego rodzaju, na przykład „Pytanie o rozliczenie”, „Pomoc techniczna” lub „Opinia o produkcie”. Umożliwia podział analizy procesu i porównanie obsługi różnych typów zgłoszeń. Analiza według typu może wykazać, że niektóre kategorie wymagają więcej czasu na rozwiązanie, częściej są eskalowane lub przebiegają inną ścieżką.
Dlaczego to ważne
Podział procesu na kategorie pozwala wykryć wąskie gardła charakterystyczne dla danego typu zgłoszenia, określić potrzeby dotyczące zasobów i znaleźć możliwości usprawnień. Ułatwia też lepsze kierowanie i obsługę zgłoszeń.
Skąd pobrać
Informacje te są często przechowywane w polu 'Subject' (subjectid) lub niestandardowym polu kategorii w encji Case (incident).
Przykłady
Pytanie o rozliczeniePomoc technicznaOpinia o produkcieObsługa konta
|
|||
|
Czy przekroczono SLA
IsSlaBreached
|
Obliczana flaga wskazująca, czy czas obsługi zgłoszenia przekroczył limit SLA. | ||
|
Opis
Ta flaga logiczna jest wyznaczana przez porównanie rzeczywistego czasu rozwiązania zgłoszenia z wartością „SLA Target Resolution Time”. Przyjmuje wartość true, jeśli rzeczywisty czas jest dłuższy od limitu. Atrybut ten służy do analizy dashboardu monitorowania zgodności z SLA oraz do obliczania KPI dotyczącego wskaźnika zgodności z SLA. Dla każdego zgłoszenia jasno wskazuje, czy limit został dotrzymany.
Dlaczego to ważne
Jednoznacznie wskazuje, czy w przypadku danego zgłoszenia dotrzymano SLA. Ułatwia filtrowanie i agregowanie danych oraz analizę przyczyn przekroczeń.
Skąd pobrać
Obliczany przez porównanie wartości „ServiceRequestCycleTime” z „SlaTargetResolutionTime”.
Przykłady
truefalse
|
|||
|
Czy sprawa została eskalowana
IsEscalated
|
Flaga określająca, czy zgłoszenie serwisowe zostało przekazane do wyższej instancji. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy zgłoszenie serwisowe zostało eskalowane. Do eskalacji dochodzi, gdy wsparcie pierwszej linii nie może rozwiązać problemu i potrzebna jest pomoc bardziej doświadczonego zespołu lub specjalisty. Śledzenie tej flagi jest niezbędne do analizy dashboardu ścieżek eskalacji wewnętrznej i KPI dotyczącego wskaźnika eskalacji wewnętrznych. Pozwala ustalić przyczyny eskalacji oraz słabe punkty wsparcia pierwszej linii.
Dlaczego to ważne
Bezpośrednio mierzy częstotliwość eskalacji. Wskazuje problemy z rozwiązywaniem spraw przy pierwszym kontakcie oraz obszary, w których warto usprawnić proces lub podnieść kompetencje konsultantów.
Skąd pobrać
Odpowiada polu „Is Escalated” (isescalated) w encji Case (incident).
Przykłady
truefalse
|
|||
|
Czy wystąpiła ponowna praca
IsRework
|
Obliczana flaga wskazująca, czy w sprawie wystąpiły czynności wymagające ponownego wykonania. | ||
|
Opis
Ta flaga logiczna wskazuje sprawy, w których wystąpiły pętle ponownej pracy lub powtarzające się czynności, na przykład kilka zdarzeń „Information Requested From Customer” albo zdarzenie „Case Reactivated” po rozwiązaniu sprawy. Jest obliczana na podstawie sekwencji działań, które mogą świadczyć o nieefektywności lub nieprawidłowym rozwiązaniu problemu za pierwszym razem. Atrybut ten służy do analizy dashboardu ponownej pracy i powtarzających się kontaktów.
Dlaczego to ważne
Pomaga określić skalę nieefektywności procesu i wskazać jej źródła. Analitycy mogą skupić się na przyczynach powtarzania pracy i marnowania wysiłku.
Skąd pobrać
Obliczany przez wykrywanie określonych sekwencji działań, na przykład Resolved -> Reactivated, lub powtarzających się czynności w sprawie za pomocą analityki process mining.
Przykłady
truefalse
|
|||
|
Identyfikator artykułu w bazie wiedzy
KnowledgeArticleId
|
Identyfikator artykułu z bazy wiedzy powiązanego ze zgłoszeniem serwisowym. | ||
|
Opis
Ten atrybut przechowuje identyfikator artykułu z bazy wiedzy, który wykorzystano lub powiązano ze zgłoszeniem podczas jego rozwiązywania. Pokazuje, jak skutecznie konsultanci korzystają z bazy wiedzy, aby rozwiązywać problemy klientów. Dane te są potrzebne do analizy dashboardu wykorzystania artykułów z bazy wiedzy i powiązanego z nim KPI. Pomagają ocenić przydatność i kompletność bazy wiedzy.
Dlaczego to ważne
Pokazuje, jak często wykorzystywana jest baza wiedzy. Pomaga ustalić, czy konsultanci korzystają z dostępnych zasobów, aby szybciej i bardziej konsekwentnie rozwiązywać problemy.
Skąd pobrać
Informacje te znajdują się w relacji między encjami Case (incident) i Knowledge Article (knowledgearticle).
Przykłady
KA-01337KA-02048
|
|||
|
Powiązany produkt
ProductInvolved
|
Produkt powiązany ze zgłoszeniem serwisowym klienta. | ||
|
Opis
Ten atrybut wskazuje konkretny produkt lub usługę, których dotyczy problem klienta. Umożliwia podział procesu obsługi według produktów i pomaga ustalić, czy niektóre z nich generują więcej zgłoszeń, wiążą się z bardziej złożonymi problemami lub wymagają specjalistycznych kompetencji konsultantów. Analiza wspiera ulepszanie produktów i planowanie zasobów.
Dlaczego to ważne
Umożliwia analizę procesu dla poszczególnych produktów, dzięki czemu można wykrywać powtarzające się problemy, ulepszać dokumentację wsparcia i skuteczniej przydzielać specjalistów.
Skąd pobrać
Odpowiada polu odnośnika „Product” (productid) w encji Case (incident).
Przykłady
Drukarka Alpha-100Oprogramowanie CRM ZetaPakiet danych Omega
|
|||
|
Rozwiązanie przy pierwszym kontakcie
IsFirstContactResolution
|
Flaga wskazująca, czy zgłoszenie rozwiązano przy pierwszym kontakcie. | ||
|
Opis
Ten obliczany atrybut wskazuje zgłoszenia serwisowe rozwiązane bez dalszych kontaktów z klientem ani znacznych opóźnień wymagających przekazania sprawy innemu konsultantowi. Ustalenie dokładnych kryteriów może być złożone, ale zwykle obejmuje krótki czas obsługi oraz brak ponownego otwarcia sprawy lub kolejnych zapytań klienta po pierwszym kontakcie. Atrybut ten stanowi podstawę KPI dotyczącego wskaźnika rozwiązań przy pierwszym kontakcie.
Dlaczego to ważne
To ważny miernik sprawności obsługi i satysfakcji klientów. Pokazuje, czy problemy można rozwiązać szybko i w całości.
Skąd pobrać
Obliczany na podstawie kolejności i czasu działań zapisanych w dzienniku zdarzeń dla każdej sprawy.
Przykłady
truefalse
|
|||
|
Wynik CSAT
CustomerSatisfactionScore
|
Ocena zadowolenia klienta wystawiona po rozwiązaniu sprawy. | ||
|
Opis
Ten atrybut przechowuje liczbową lub opisową ocenę z ankiety satysfakcji klienta (CSAT), zwykle zbieranej po zamknięciu zgłoszenia serwisowego. Bezpośrednio pokazuje, jak klient ocenia jakość obsługi. Dane te są potrzebne do analizy dashboardu trendów satysfakcji klientów i KPI dotyczącego średniego wyniku CSAT po rozwiązaniu sprawy. Pozwalają powiązać wyniki procesu z doświadczeniami klientów.
Dlaczego to ważne
Bezpośrednio mierzy satysfakcję klientów. Pozwala zestawić przebieg procesu z opiniami klientów i wskazać obszary do poprawy.
Skąd pobrać
Dane pochodzą zwykle z powiązanej encji ankiety, takiej jak Customer Voice, i są łączone z encją Case (incident).
Przykłady
5341
|
|||
|
Zespół odpowiedzialny
OwnerTeam
|
Zespół, który obecnie odpowiada za zgłoszenie serwisowe. | ||
|
Opis
Ten atrybut wskazuje zespół odpowiedzialny za zgłoszenie serwisowe. Właścicielem zgłoszenia może być pojedynczy konsultant lub zespół (kolejka). Analiza według zespołów pomaga ocenić ich wyniki, rozkład obciążenia między poziomami wsparcia i specjalizacjami oraz różnice w przebiegu procesu między zespołami.
Dlaczego to ważne
Umożliwia analizę wyników na poziomie zespołów, co pomaga skutecznie zarządzać poziomami wsparcia i grupami specjalistycznymi.
Skąd pobrać
Pochodzi z pola „Owner” (ownerid) encji Case (incident), gdy właścicielem jest rekord Team, a nie System User.
Przykłady
Wsparcie pierwszej liniiDział rozliczeńSpecjaliści techniczni
|
|||
Działania w procesie obsługi klienta
| Działanie | Opis | ||
|---|---|---|---|
|
Eskalacja sprawy
|
Oznacza formalne przekazanie sprawy do zespołu wsparcia wyższego poziomu lub innego zespołu. Może to być jawne działanie użytkownika, który przypisuje sprawę do wyznaczonej kolejki lub użytkownika obsługującego eskalacje. | ||
|
Dlaczego to ważne
Monitorowanie eskalacji jest niezbędne do obliczania KPI „Wskaźnik eskalacji wewnętrznych” i ustalania przyczyn problemów, których nie może rozwiązać wsparcie pierwszej linii. Pozwala wykryć słabe punkty procesu i potrzeby szkoleniowe.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola 'ownerid' na wyznaczoną kolejkę lub zespół obsługujący eskalacje. Może to być również jawne działanie niestandardowe, które oznacza sprawę jako eskalowaną.
Rejestrowanie
Ustal znacznik czasu zmiany pola 'ownerid' na znaną kolejkę obsługującą eskalacje.
Typ zdarzenia
inferred
|
|||
|
Przypisanie sprawy
|
Ta czynność oznacza przypisanie sprawy do konkretnej kolejki lub użytkownika. System jawnie rejestruje zmiany właściciela sprawy, które można śledzić w dziennikach audytu. | ||
|
Dlaczego to ważne
Śledzenie przypisań jest niezbędne do analizy rozkładu obciążenia pracą, wykrywania opóźnień związanych z przypisywaniem i oceny sprawności kierowania spraw. Pozwala ustalić, jak szybko sprawy trafiają do właściwego zespołu lub osoby.
Skąd pobrać
Zdarzenie można zarejestrować, śledząc zmiany pola 'ownerid' w encji 'Incident'. Znacznik czasu zmiany jest dostępny w dziennikach historii audytu.
Rejestrowanie
Wyodrębnij z dzienników audytu zmiany pola 'ownerid' wraz ze znacznikami czasu.
Typ zdarzenia
explicit
|
|||
|
Rozwiązanie sprawy
|
To ważny etap, który oznacza, że konsultant uznaje problem klienta za rozwiązany. W Dynamics 365 jest to jawne działanie, które tworzy powiązany ze sprawą rekord aktywności 'Case Resolution'. | ||
|
Dlaczego to ważne
Jako główne zdarzenie końcowe oznaczające pomyślne zakończenie sprawy, ta czynność pozwala obliczać czas rozwiązania i wskaźniki skuteczności. Jest składnikiem niemal każdego KPI obsługi klienta.
Skąd pobrać
Zdarzenie odpowiada utworzeniu rekordu aktywności 'Resolution' (Case Resolution). Znacznik czasu 'actualend' tego rekordu oznacza moment rozwiązania sprawy.
Rejestrowanie
Użyj znacznika czasu 'actualend' lub 'createdon' powiązanego rekordu aktywności 'Resolution'.
Typ zdarzenia
explicit
|
|||
|
Uruchomienie licznika SLA
|
Oznacza uruchomienie licznika Service Level Agreement (SLA) dla sprawy. Licznik mierzy czas względem określonego wskaźnika obsługi, takiego jak 'First Response By' lub 'Resolve By'. To jawne zdarzenie obsługiwane przez mechanizm SLA w Dynamics 365. | ||
|
Dlaczego to ważne
Ta czynność jest niezbędna do monitorowania zgodności z SLA i ustalenia, kiedy zaczyna się odliczanie czasu na realizację zobowiązań dotyczących obsługi. Umożliwia bezpośrednią analizę tego, czy cele obsługi są osiągane.
Skąd pobrać
Zdarzenie jest rejestrowane w encji 'SLA KPI Instance', powiązanej z encją 'Incident'. Początek oznacza znacznik czasu 'createdon' odpowiedniego rekordu SLA KPI Instance.
Rejestrowanie
Użyj znacznika czasu utworzenia rekordu 'SLA KPI Instance' powiązanego ze sprawą.
Typ zdarzenia
explicit
|
|||
|
Utworzenie sprawy
|
To zdarzenie rozpoczyna proces obsługi klienta. W systemie powstaje nowy rekord sprawy. Utworzenie jest rejestrowane jako jawne zdarzenie z konkretnym znacznikiem czasu, gdy rekord encji 'Incident' zostaje po raz pierwszy zapisany. | ||
|
Dlaczego to ważne
Jako główne zdarzenie początkowe ta czynność pozwala obliczyć całkowity czas obsługi sprawy i analizować zmiany liczby spraw. Stanowi punkt odniesienia dla dalszej analizy procesu.
Skąd pobrać
Zdarzenie jest rejestrowane na podstawie znacznika czasu 'createdon' dla każdej nowej encji 'Incident' (Case).
Rejestrowanie
Użyj znacznika czasu 'createdon' rekordu Incident.
Typ zdarzenia
explicit
|
|||
|
Zamknięcie sprawy
|
To końcowe, administracyjne zamknięcie rekordu sprawy. Może nastąpić równocześnie z jej rozwiązaniem lub później. Zdarzenie jest rejestrowane, gdy stan sprawy zmienia się na 'Closed'. | ||
|
Dlaczego to ważne
Oznacza ostateczny koniec procesu w systemie. Czas między zmianą statusu na 'Resolved' i 'Closed' może wskazywać na obciążenie administracyjne lub opóźnienia w finalizowaniu rekordów.
Skąd pobrać
Zdarzenie jest rejestrowane, gdy pole 'statecode' w encji 'Incident' zmienia się na 'Canceled' (2) lub niestandardowy status zamknięcia. Znacznik czasu jest dostępny w historii audytu.
Rejestrowanie
Śledź znacznik czasu zmiany 'statecode' na końcowy status (np. Canceled/Closed).
Typ zdarzenia
explicit
|
|||
|
Analiza problemu przez konsultanta
|
Oznacza aktywną pracę konsultanta nad zrozumieniem i zdiagnozowaniem problemu klienta. Jest to czynność wywnioskowana, często na podstawie powiązania przez konsultanta artykułu z bazy wiedzy ze sprawą, co wskazuje na przeprowadzenie analizy. | ||
|
Dlaczego to ważne
Śledzenie tej czynności pomaga ocenić wykorzystanie zasobów wiedzy i ich wpływ na czas rozwiązania sprawy. Pokazuje, czy konsultanci korzystają z dostępnych narzędzi, aby sprawnie rozwiązywać problemy.
Skąd pobrać
Czynność jest wywnioskowana na podstawie utworzenia rekordu w encji 'IncidentKnowledgeBaseRecord', która łączy artykuł z bazy wiedzy ze sprawą. Wykorzystywany jest znacznik czasu utworzenia tego rekordu.
Rejestrowanie
Użyj znacznika czasu powiązania artykułu z bazy wiedzy z encją Incident.
Typ zdarzenia
inferred
|
|||
|
Pobranie elementu kolejki przez konsultanta
|
To zdarzenie występuje, gdy konsultant samodzielnie pobiera sprawę ze wspólnej kolejki, aby rozpocząć jej obsługę. Jest to działanie użytkownika, odrębne od przypisania sprawy do kolejki przez system. | ||
|
Dlaczego to ważne
Ta czynność pozwala zmierzyć, jak długo sprawa czeka w kolejce, zanim konsultant rozpocznie pracę. Pomaga wykrywać wąskie gardła w kolejkach i oceniać aktywność konsultantów.
Skąd pobrać
Zdarzenie jest śledzone, gdy użytkownik aktualizuje pole 'workedbyid' w encji 'QueueItem' powiązanej ze sprawą albo gdy właściciel sprawy zmienia się z kolejki na użytkownika.
Rejestrowanie
Ustal znacznik czasu, w którym pole 'workedbyid' w QueueItem zostaje wypełnione.
Typ zdarzenia
explicit
|
|||
|
Ponowne otwarcie sprawy
|
Występuje, gdy wcześniej rozwiązana sprawa zostaje ponownie otwarta automatycznie lub ręcznie, zwykle dlatego, że klient odpowiedział albo zgłosił, że problem nie został rozwiązany. Jest to standardowe działanie systemu, które zmienia status sprawy z 'Resolved' na 'Active'. | ||
|
Dlaczego to ważne
Ta czynność pomaga wykrywać ponowną pracę i analizować „Wskaźnik rozwiązania przy pierwszym kontakcie”. Duża liczba ponownie otwieranych spraw może wskazywać, że początkowe rozwiązania były niepełne lub nieskuteczne.
Skąd pobrać
Zdarzenie jest rejestrowane, gdy pole 'statecode' w encji 'Incident' zmienia się z 'Resolved' (1) z powrotem na 'Active' (0). Znacznik czasu tej zmiany jest zapisywany w historii audytu.
Rejestrowanie
Śledź w dziennikach audytu znacznik czasu zmiany 'statecode' z Resolved na Active.
Typ zdarzenia
explicit
|
|||
|
Prośba o informacje od klienta
|
Ta czynność oznacza, że konsultant potrzebuje dodatkowych informacji od klienta, aby kontynuować obsługę. Można ją wywnioskować na przykład ze zmiany statusu sprawy na oczekującą lub z wysłania wiadomości e-mail z osi czasu sprawy. | ||
|
Dlaczego to ważne
Ta informacja jest niezbędna do pomiaru opóźnień zależnych od klienta i analizy KPI „Czas oczekiwania na informacje od klienta”. Pozwala oddzielić czas procesu poświęcony na oczekiwanie na informacje z zewnątrz.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola 'statuscode' w encji 'Incident' na wartość taką jak 'On Hold' z przyczyną 'Waiting for Customer'. Wykorzystywany jest znacznik czasu tej zmiany statusu.
Rejestrowanie
Śledź znacznik czasu zmiany statuscode na wyznaczony status oczekiwania na klienta.
Typ zdarzenia
inferred
|
|||
|
Przedstawienie klientowi proponowanego rozwiązania
|
Ta czynność oznacza, że konsultant opracował rozwiązanie i przekazał je klientowi. Zwykle można ją wywnioskować z wysłania wiadomości e-mail z osi czasu sprawy lub zmiany statusu na 'Pending Customer Confirmation'. | ||
|
Dlaczego to ważne
Ten etap oznacza przejście od analizy do rozwiązania sprawy. Analiza czasu między przedstawieniem rozwiązania a jego potwierdzeniem może ujawnić opóźnienia w odpowiedzi klienta lub problemy z proponowanym rozwiązaniem.
Skąd pobrać
Zdarzenie można wywnioskować ze znacznika czasu wychodzącej aktywności 'Email' powiązanej ze sprawą lub ze zmiany statuscode na status poprzedzający rozwiązanie.
Rejestrowanie
Użyj znacznika czasu wychodzącej wiadomości e-mail lub zmiany statusu na 'Solution Proposed'.
Typ zdarzenia
inferred
|
|||
|
Wysłanie ankiety satysfakcji
|
Oznacza wysłanie ankiety satysfakcji klienta, zwykle automatycznie po rozwiązaniu sprawy. Zdarzenie jest zazwyczaj rejestrowane jako wychodząca wiadomość e-mail lub aktywność ankiety Customer Voice. | ||
|
Dlaczego to ważne
Ta czynność łączy proces operacyjny z wynikami dotyczącymi doświadczeń klientów. Umożliwia analizę ocen satysfakcji w kontekście ścieżki, którą przeszła sprawa.
Skąd pobrać
Zdarzenie można wywnioskować z utworzenia wychodzącej aktywności 'Email' zawierającej link do ankiety lub rekordu aktywności 'Customer Voice survey invite' powiązanego ze sprawą.
Rejestrowanie
Użyj znacznika czasu utworzenia aktywności związanej z ankietą.
Typ zdarzenia
inferred
|
|||
|
Zmiana kategorii sprawy
|
To zdarzenie występuje, gdy konsultant zmienia kategorię lub temat sprawy po jej utworzeniu. System jawnie rejestruje tę zmianę w dzienniku audytu. | ||
|
Dlaczego to ważne
Śledzenie zmian kategorii jest niezbędne do obliczania KPI „Wskaźnik zmiany kategorii zgłoszeń”. Częste zmiany mogą wskazywać na problemy z wstępną kwalifikacją, które prowadzą do błędnego kierowania spraw i opóźnień.
Skąd pobrać
Zdarzenie jest rejestrowane w historii audytu encji 'Incident', w szczególności przez śledzenie zmian pola 'subjectid' lub innych niestandardowych pól kategorii.
Rejestrowanie
Wyodrębnij z dzienników audytu zmiany pola 'subjectid' wraz ze znacznikami czasu.
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Skorzystajcie z tego szablonu danych, aby szybciej rozpocząć analizę procesu i usprawnić obsługę klienta. Już dziś zacznijcie optymalizować workflow, by poprawić doświadczenia klientów.
Usprawnijcie obsługę klienta: zwiększcie FCR i obniżcie koszty
Wskażcie wąskie gardła i osiągnijcie 80% spraw rozwiązanych przy pierwszym kontakcie, by zwiększyć zadowolenie klientów.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.