Szablon danych dotyczących obsługi klienta

Microsoft Dynamics 365 Customer Service
Szablon danych dotyczących obsługi klienta

Szablon danych dotyczących obsługi klienta

Szablon porządkuje zbieranie danych potrzebnych do szczegółowej analizy procesu obsługi klienta. Zawiera listę atrybutów do zebrania i działań do śledzenia, a także wskazówki dotyczące skutecznego pozyskiwania tych informacji.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące ekstrakcji danych z Microsoft Dynamics 365 Customer Service
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 danych, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować proces obsługi klienta.
5 Wymagane 7 Zalecane 8 Opcjonalne
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
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi klienta

To najważniejsze kroki i etapy procesu, które warto zapisywać w dzienniku zdarzeń, aby dokładnie odtworzyć i usprawnić obsługę klienta.
6 Zalecane 7 Opcjonalne
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
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Microsoft Dynamics 365 Customer Service

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.

Rozpocznijcie okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.