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 pobierania danych
Atrybuty obsługi klienta
| Nazwa | Opis | ||
|---|---|---|---|
|
Zgłoszenie serwisowe
ServiceRequest
|
Unikalny identyfikator sprawy lub zgłoszenia klienta, który łączy wszystkie powiązane działania. | ||
|
Opis
Zgłoszenie serwisowe, nazywane też zgłoszeniem lub sprawą, jest głównym identyfikatorem łączącym wszystkie działania związane z pojedynczym zapytaniem lub problemem klienta. W Salesforce Service Cloud odpowiada mu numer sprawy (Case Number). Ten atrybut jest niezbędny do odtworzenia pełnego przebiegu każdej interakcji z klientem. Narzędzie process mining grupuje dzięki niemu powiązane zdarzenia, takie jak „Utworzenie sprawy”, „Analiza problemu przez konsultanta” i „Rozwiązanie sprawy”, w jedną instancję procesu. Umożliwia to analizę całego przebiegu, od początku do końca.
Dlaczego to ważne
To podstawowy element process mining, ponieważ łączy wszystkie zdarzenia dotyczące tego samego problemu klienta w jedną spójną instancję procesu.
Skąd pobrać
Obiekt Salesforce Case, pole: CaseNumber
Przykłady
000010240000105800001193
|
|||
|
Czas zdarzenia
EventTime
|
Dokładny znacznik czasu wskazujący, kiedy wystąpiło działanie. | ||
|
Opis
Czas zdarzenia określa datę i godzinę zarejestrowania danego działania w systemie. Dostarcza kontekstu czasowego dla całego procesu i pozwala obliczać czas trwania, czas oczekiwania oraz czas cyklu. W analizie znaczniki czasu służą do chronologicznego uporządkowania zdarzeń dla każdego zgłoszenia serwisowego i stanowią podstawę odkrywania procesu. Są niezbędne do obliczania KPI związanych z wydajnością, na przykład czasu między „Utworzeniem sprawy” a „Wysłaniem potwierdzenia przyjęcia zgłoszenia” lub całkowitego czasu rozwiązania sprawy.
Dlaczego to ważne
Znacznik czasu pomaga zrozumieć przebieg procesu, obliczać wskaźniki wydajności i wykrywać opóźnienia między działaniami.
Skąd pobrać
Ustalane na podstawie różnych pól daty odpowiadających konkretnym zdarzeniom, takich jak CreatedDate w obiekcie Case lub CreatedDate w rekordach CaseHistory.
Przykłady
2023-04-15T10:00:00Z2023-04-15T11:23:14Z2023-04-16T09:05:30Z
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdateTime
|
Znacznik czasu wskazujący, kiedy dane dotyczące procesu zostały ostatnio odświeżone. | ||
|
Opis
Ten atrybut zapisuje znacznik czasu ostatniej ekstrakcji danych z systemu źródłowego lub ich aktualizacji. Jest to pole metadanych dotyczące całego zbioru danych, a nie pojedynczych zdarzeń. Informuje użytkowników, jak aktualne są analizowane dane. Dzięki temu można ocenić, czy wnioski i decyzje opierają się na bieżących, przydatnych informacjach, oraz określić, na ile dane są aktualne.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu można ocenić, jak bieżąca jest analiza.
Skąd pobrać
Ta wartość jest zwykle generowana i zapisywana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL).
Przykłady
2023-10-27T04:00:00Z
|
|||
|
Nazwa działania
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub kroku, który wystąpił w procesie obsługi klienta. | ||
|
Opis
Ten atrybut opisuje pojedynczy krok lub etap w cyklu obsługi zgłoszenia. Działania są węzłami na mapie procesu i oznaczają czynności wykonane przez konsultantów, systemy automatyczne lub klientów. Analiza kolejności i częstotliwości działań, takich jak „Utworzenie sprawy”, „Uruchomienie eskalacji wewnętrznej” i „Zamknięcie sprawy”, jest podstawą process mining. Pomaga odkryć rzeczywisty przebieg procesu, wykryć wąskie gardła i znaleźć odstępstwa od standardowej procedury.
Dlaczego to ważne
Działania określają kroki procesu, a ich kolejność stanowi podstawę mapy procesu i dalszych analiz.
Skąd pobrać
Zwykle ustalane na podstawie kombinacji pól, takich jak zmiany statusu w obiekcie Case (pole Status) lub rekordy w obiektach CaseHistory albo EmailMessage.
Przykłady
Utworzenie sprawyPrzypisanie sprawy do konsultantaPrzedstawienie klientowi proponowanego rozwiązaniaZamknięcie sprawy
|
|||
|
System źródłowy
SourceSystemName
|
System, z którego pochodzą dane o procesie. | ||
|
Opis
Ten atrybut wskazuje aplikację źródłową, w której wygenerowano dane. W tym przypadku jest to Salesforce Service Cloud. Jest szczególnie przydatny, gdy w celu uzyskania pełnego obrazu procesu łączy się dane z wielu systemów. Nawet przy analizie jednego systemu atrybut ten dostarcza ważnych informacji o pochodzeniu danych. Pomaga w zarządzaniu danymi, rozwiązywaniu problemów i sprawdzaniu, czy analizy opierają się na właściwym zbiorze danych.
Dlaczego to ważne
Dostarcza ważnych informacji o pochodzeniu danych, niezbędnych do zarządzania nimi oraz analiz łączących dane z wielu 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
Salesforce Service CloudSFSC
|
|||
|
Czas zakończenia
EndTime
|
Znacznik czasu wskazujący, kiedy działanie zostało zakończone. | ||
|
Opis
Czas zakończenia oznacza moment ukończenia działania. W połączeniu z czasem rozpoczęcia pozwala dokładnie obliczyć czas realizacji działania. Wiele zdarzeń w Salesforce jest chwilowych, więc czas rozpoczęcia i zakończenia jest taki sam. W przypadku działań trwających dłużej osobny czas zakończenia jest niezbędny do dokładnego pomiaru czasu poświęconego na zadanie. Ułatwia analizę wydajności, ponieważ pozwala odróżnić czas aktywnej pracy od przerw między kolejnymi krokami.
Dlaczego to ważne
Pozwala obliczyć rzeczywisty czas trwania działania, co jest niezbędne do analizy pracy konsultantów i wykrywania czasochłonnych kroków.
Skąd pobrać
W przypadku zdarzeń chwilowych jest to często ta sama wartość co StartTime. Dla działań trwających dłużej należy pobrać ją z pola wskazującego zakończenie, co może wymagać niestandardowej konfiguracji.
Przykłady
2023-04-15T10:00:00Z2023-04-15T11:55:00Z2023-04-16T14:20:00Z
|
|||
|
Docelowy czas rozwiązania zgodny z SLA
SlaTargetResolutionTime
|
Termin, do którego zgłoszenie powinno zostać rozwiązane zgodnie z SLA. | ||
|
Opis
Ten atrybut określa termin rozwiązania sprawy wynikający z umowy SLA. Zazwyczaj zależy on od takich czynników jak priorytet i typ sprawy oraz poziom obsługi klienta. Salesforce może obliczać go automatycznie za pomocą funkcji uprawnień i kamieni milowych. Ten znacznik czasu jest niezbędny do pomiaru realizacji SLA. Porównanie rzeczywistego czasu rozwiązania z wyznaczonym terminem pozwala obliczyć KPI dotyczący realizacji SLA i wskazać sprawy zagrożone przekroczeniem terminu. Dane te zasilają dashboard realizacji SLA dla spraw.
Dlaczego to ważne
Stanowi punkt odniesienia do oceny rzeczywistych wyników, dlatego jest niezbędny do obliczania zgodności z SLA i wskazywania spraw zagrożonych opóźnieniem.
Skąd pobrać
Często jest zapisywany w polu SlaExitDate obiektu Case Milestone, należącego do funkcji Entitlement Management w Salesforce.
Przykłady
2023-04-16T17:00:00Z2023-04-18T09:00:00Z2023-05-01T12:00:00Z
|
|||
|
Kanał komunikacji
CommunicationChannel
|
Kanał, za pośrednictwem którego zgłoszono sprawę, na przykład e-mail, telefon lub strona internetowa. | ||
|
Opis
Ten atrybut określa sposób, w jaki klient zgłosił sprawę. W Salesforce informacja ta jest często zapisywana w polu Case Origin. Znajomość kanału komunikacji pomaga lepiej przydzielać zasoby i usprawniać obsługę. Analiza czasu rozwiązania i przebiegu procesu według kanału pozwala ustalić, które kanały najlepiej sprawdzają się przy różnych typach problemów. Wspiera też dashboard „Efektywność kanałów komunikacji”.
Dlaczego to ważne
Umożliwia porównanie wyników różnych kanałów kontaktu z klientami, co pomaga optymalizować strategię kanałów i przydział zasobów.
Skąd pobrać
Obiekt Salesforce Case, pole: Origin
Przykłady
E-mailTelefonStrona internetowaCzat
|
|||
|
Priorytet sprawy
CasePriority
|
Poziom priorytetu przypisany do zgłoszenia serwisowego, na przykład wysoki, średni lub niski. | ||
|
Opis
Priorytet sprawy to standardowa klasyfikacja określająca pilność zgłoszenia serwisowego. Często na jego podstawie ustala się docelowy czas odpowiedzi i rozwiązania zgodnie z umowami SLA. Analiza wyników procesu według priorytetu pozwala ocenić skuteczność przyjętej strategii ustalania priorytetów. Pomaga sprawdzić, czy sprawy o wysokim priorytecie są rozwiązywane szybciej i czy spełniają wymagające cele SLA. Wspiera też dashboard „Priorytetyzacja spraw i jej wpływ”.
Dlaczego to ważne
Pozwala sprawdzić, czy proces skutecznie nadaje priorytet pilnym sprawom i realizuje różne poziomy obsługi zależnie od ich ważności.
Skąd pobrać
Obiekt Salesforce Case, pole: Priority
Przykłady
WysokiŚredniNiski
|
|||
|
Przypisany konsultant
AssignedAgent
|
Użytkownik lub kolejka, do których jest obecnie przypisane zgłoszenie serwisowe. | ||
|
Opis
Ten atrybut wskazuje konsultanta lub zespół odpowiedzialny za obsługę zgłoszenia w danym momencie. W Salesforce jest to zwykle właściciel sprawy (Case Owner). Śledzenie zmian tego atrybutu jest podstawą analizy pracy konsultantów, podziału obciążenia i przekazań spraw. Pozwala sprawdzić, ile razy sprawa została ponownie przypisana, którzy konsultanci obsługują najbardziej złożone sprawy i czy obciążenie jest równomiernie rozłożone w zespole. Atrybut ten jest wykorzystywany w dashboardach „Przekazania między konsultantami” i „Podział obciążenia pracą”.
Dlaczego to ważne
Jest niezbędny do analizy obciążenia i pracy konsultantów oraz częstotliwości przekazań, które bezpośrednio wpływają na efektywność i czas rozwiązania sprawy.
Skąd pobrać
Obiekt Salesforce Case, pole: OwnerId. Pole zawiera identyfikator użytkownika lub kolejki.
Przykłady
Sarah JonesDavid ChenKolejka wsparcia drugiej linii
|
|||
|
Rozwiązanie przy pierwszym kontakcie
IsFirstContactResolution
|
Flaga wskazująca, czy sprawę rozwiązano podczas pierwszego kontaktu z klientem. | ||
|
Opis
Ten atrybut logiczny wskazuje zgłoszenia rozwiązane bez konieczności dalszego kontaktu po pierwszym zgłoszeniu klienta. Aby go obliczyć, często analizuje się kolejność i czas działań. Wysoki odsetek spraw rozwiązanych przy pierwszym kontakcie (FCR) świadczy o sprawnej i skutecznej obsłudze klienta. Ten obliczany atrybut stanowi podstawę KPI dotyczącego odsetka takich spraw. Analiza zgłoszeń, których nie udało się rozwiązać przy pierwszym kontakcie, może wskazać możliwości poprawy szkoleń konsultantów, zawartości bazy wiedzy i projektu procesu.
Dlaczego to ważne
Bezpośrednio mierzy ważny aspekt sprawności obsługi i zadowolenia klientów. Pomaga ustalić, co sprzyja skutecznemu rozwiązywaniu problemów.
Skąd pobrać
Obliczany podczas transformacji danych na podstawie analizy dziennika zdarzeń dla danej sprawy. Częsta reguła sprawdza, czy zdarzenie „Case Resolved” wystąpiło przed zdarzeniem „Information Requested From Customer” lub kolejnym kontaktem z klientem.
Przykłady
truefalse
|
|||
|
Status SLA
SlaStatus
|
Informuje, czy sprawę rozwiązano w terminie określonym przez SLA. | ||
|
Opis
Ten atrybut klasyfikuje każdą rozwiązaną sprawę pod kątem realizacji ustalonego SLA. Jego wartość oblicza się przez porównanie rzeczywistego czasu rozwiązania z atrybutem „Docelowy czas rozwiązania zgodny z SLA”. Atrybut ten bezpośrednio zasila KPI dotyczący odsetka spraw rozwiązanych zgodnie z SLA i ułatwia monitorowanie wyników. Pozwala szybko filtrować i analizować sprawy, w których nie dotrzymano terminu, aby znaleźć częste przyczyny przekroczeń, takie jak określone typy spraw, produkty lub wąskie gardła w procesie.
Dlaczego to ważne
Jednoznacznie wskazuje, czy w przypadku danej sprawy dotrzymano SLA. To podstawa monitorowania wyników i analizy przyczyn opóźnień.
Skąd pobrać
Obliczany podczas transformacji danych przez porównanie znacznika czasu „Case Resolved” z atrybutem „SlaTargetResolutionTime”.
Przykłady
DotrzymanoPrzekroczono termin
|
|||
|
Status sprawy
CaseStatus
|
Bieżący status zgłoszenia serwisowego w cyklu obsługi, na przykład nowa, w toku lub zamknięta. | ||
|
Opis
Status sprawy wskazuje jej bieżący stan. Zmiany statusu są często głównym źródłem informacji o działaniach w procesie. Na przykład zmianę z „New” na „Working” można odwzorować jako działanie „Analiza problemu przez konsultanta”. Analiza końcowego statusu spraw pomaga zrozumieć wyniki obsługi. Status służy też do filtrowania spraw otwartych i zamkniętych oraz wykrywania tych, które zbyt długo pozostają w jednym stanie.
Dlaczego to ważne
Informuje o bieżącym stanie i wyniku sprawy. Zmiany statusu często służą do odtworzenia kolejności działań.
Skąd pobrać
Obiekt Salesforce Case, pole: Status
Przykłady
NowaW trakcie obsługiOczekiwanie na klientaZamknięta
|
|||
|
Typ sprawy
CaseType
|
Klasyfikacja zgłoszenia serwisowego, na przykład pytanie, problem lub prośba o nową funkcję. | ||
|
Opis
Typ sprawy to atrybut kategoryczny, który pomaga określić charakter zapytania lub problemu klienta. Dzięki temu można podzielić zgłoszenia na grupy i sprawdzić, jak obsługiwane są poszczególne rodzaje spraw. Analiza procesu według typu sprawy może wykazać, że niektóre zgłoszenia przebiegają inną ścieżką, wymagają więcej czasu na rozwiązanie lub częściej są przekazywane między osobami. Te informacje pomagają dostosować proces i usprawnić obsługę konkretnych kategorii spraw.
Dlaczego to ważne
Pozwala podzielić proces na kategorie zgłoszeń, sprawdzić, czy są obsługiwane w różny sposób, i wskazać obszary wymagające ukierunkowanych usprawnień.
Skąd pobrać
Obiekt Salesforce Case, pole: Type
Przykłady
ProblemProśba o nową funkcjęPytanie
|
|||
|
Czy eskalowano
IsEscalated
|
Flaga wskazująca, czy sprawa została eskalowana. | ||
|
Opis
Ten atrybut logiczny wskazuje, czy zgłoszenie serwisowe zostało eskalowane. W Salesforce można to śledzić za pomocą standardowego pola IsEscalated, które jest ustawiane automatycznie na podstawie reguł eskalacji. Flaga jest bezpośrednim źródłem danych dla dashboardu analizy eskalacji wewnętrznych i KPI dotyczącego ich odsetka. Ułatwia filtrowanie i zliczanie wszystkich eskalowanych spraw, co pozwala określić ich częstotliwość oraz przeanalizować wpływ na czas rozwiązania i złożoność procesu.
Dlaczego to ważne
Bezpośrednio mierzy liczbę eskalacji spraw, które mogą wskazywać na problemy w procesie, jego złożoność lub braki w wiedzy konsultantów.
Skąd pobrać
Obiekt Salesforce Case, pole: IsEscalated
Przykłady
truefalse
|
|||
|
Czy wystąpiła ponowna praca
IsRework
|
Flaga wskazująca, czy sprawa wymagała ponownej pracy lub powrotu do wcześniejszego etapu. | ||
|
Opis
Ten atrybut logiczny oznacza sprawy, w których wystąpiła ponowna praca, na przykład ponowne otwarcie po zamknięciu lub wielokrotne przechodzenie między etapami „Agent Investigates” i „Solution Proposed”. Aby wykryć ponowną pracę, trzeba przeanalizować sekwencję działań i znaleźć niepożądane pętle. Atrybut ten bezpośrednio zasila KPI dotyczący odsetka spraw wymagających ponownej pracy oraz dashboard przekazań spraw i ponownej pracy. Wskazanie takich spraw pozwala przeanalizować przyczyny, takie jak nieodpowiednie rozwiązania lub niepełne zebranie informacji, i podjąć działania naprawcze.
Dlaczego to ważne
Wskazuje nieefektywność procesu i niepotrzebny nakład pracy. Umożliwia analizę działań, które często trzeba powtarzać.
Skąd pobrać
Obliczany podczas transformacji danych na podstawie analizy sekwencji działań. Przykładowo sekwencja „Case Closed” -> „Case Reopened” lub „Solution Proposed” -> „Agent Investigates Issue” w ramach tej samej sprawy oznacza ponowną pracę.
Przykłady
truefalse
|
|||
|
Liczba przekazań sprawy między konsultantami
AgentHandoffCount
|
Liczba przekazań sprawy od jednego konsultanta lub kolejki do innego. | ||
|
Opis
Ta miara określa, ile razy zgłoszenie serwisowe zostało przekazane dalej przed rozwiązaniem. Oblicza się ją, zliczając różne zmiany wartości atrybutu „AssignedAgent” w cyklu życia pojedynczej sprawy. Atrybut ten stanowi podstawę KPI dotyczącego średniej liczby przekazań sprawy między konsultantami i jest prezentowany na dashboardzie przekazań spraw oraz ponownej pracy. Duża liczba przekazań często wskazuje na nieefektywny proces, niejasny podział odpowiedzialności lub braki w wiedzy. Może to wydłużać czas rozwiązania i frustrować klientów.
Dlaczego to ważne
Pozwala określić, gdzie w procesie pojawiają się utrudnienia. Nadmierna liczba przekazań często powoduje opóźnienia i niezadowolenie klientów.
Skąd pobrać
Obliczany dla każdej sprawy podczas transformacji danych. Zlicza unikalne wartości pola „AssignedAgent” dla każdego „ServiceRequest”, a następnie odejmuje jeden.
Przykłady
0135
|
|||
|
Nazwa klienta
CustomerName
|
Nazwa klienta lub konta powiązanego ze zgłoszeniem serwisowym. | ||
|
Opis
Ten atrybut wskazuje klienta, który zgłosił sprawę. W Salesforce może to być Contact (osoba) lub Account (firma). Analiza procesu z perspektywy klienta może dostarczyć przydatnych informacji. Można na przykład sprawdzić, czy określeni klienci częściej zgłaszają problemy lub dłużej czekają na ich rozwiązanie. Wyniki mogą pomóc w zarządzaniu relacjami z klientami i wskazać możliwości udzielenia im wsparcia z wyprzedzeniem.
Dlaczego to ważne
Umożliwia analizę z perspektywy klienta, dzięki której można wykrywać wzorce i różnice w wynikach dla konkretnych klientów lub ich segmentów.
Skąd pobrać
Obiekt Salesforce Case, pola: ContactId lub AccountId, które łączą odpowiednio z obiektami Contact i Account.
Przykłady
Global Tech Inc.Emily WhiteInnovate Solutions
|
|||
|
Powiązany produkt
ProductInvolved
|
Produkt lub usługa, których dotyczy zgłoszenie klienta. | ||
|
Opis
Ten atrybut łączy zgłoszenie serwisowe z konkretnym produktem lub usługą. W Salesforce zwykle jest obsługiwany przez pole odwołujące się do obiektu Product. Podział danych o procesie według produktów jest ważny przy analizie ich jakości. Pozwala ustalić, które produkty generują najwięcej zgłoszeń, jakich problemów dotyczą i czy sposób ich rozwiązywania różni się między liniami produktowymi. To istotna informacja zwrotna dla zespołów rozwijających produkty.
Dlaczego to ważne
Umożliwia analizę procesu według produktów, co pomaga wykrywać problemy z jakością lub braki we wsparciu dotyczącym konkretnych produktów.
Skąd pobrać
Obiekt Salesforce Case, pole: ProductId. Jest to standardowe, ale opcjonalne pole odwołujące się do innego obiektu.
Przykłady
Pakiet CRM AlphaNarzędzie analityczne BetaŁącznik danych Gamma
|
|||
|
Temat sprawy
CaseSubject
|
Krótki opis lub tytuł problemu albo prośby klienta. | ||
|
Opis
Temat sprawy zawiera zwięzły opis zgłoszenia w formie dowolnego tekstu. Często jest to temat wiadomości e-mail albo tytuł wpisany przez konsultanta lub klienta. Choć nie jest to pole o ustrukturyzowanej formie, które można bezpośrednio wykorzystać do analizy procesu, zawiera wiele informacji kontekstowych. Techniki eksploracji tekstu mogą pomóc kategoryzować sprawy, wykrywać nowe problemy i uzupełniać ilościową analizę procesu o kontekst jakościowy.
Dlaczego to ważne
Zapewnia szybki, ogólny kontekst sprawy. Przydaje się przy analizie szczegółowej i może być wykorzystany do eksploracji tekstu.
Skąd pobrać
Obiekt Salesforce Case, pole: Subject
Przykłady
Nie można zalogować się do portaluPytanie dotyczące zestawienia opłatProśba o dodanie funkcji do dashboardu raportowego
|
|||
Działania w procesie obsługi klienta
| Działanie | Opis | ||
|---|---|---|---|
|
Naruszenie kamienia milowego SLA
|
To zdarzenie występuje, gdy nie zostaje dotrzymane zobowiązanie dotyczące obsługi, na przykład czasu pierwszej odpowiedzi lub rozwiązania sprawy. Salesforce śledzi takie zobowiązania za pomocą procesów uprawnień i rekordów kamieni milowych. | ||
|
Dlaczego to ważne
To zdarzenie ma znaczenie przy analizie realizacji SLA i monitorowaniu zgodności. Wskazuje sprawy, w których nie spełniono oczekiwań klientów, co pozwala ukierunkować działania usprawniające proces.
Skąd pobrać
Dane pochodzą z obiektu CaseMilestone. Zdarzenie jest generowane, gdy pole IsViolated w rekordzie kamienia milowego przyjmuje wartość true.
Rejestrowanie
Zdarzenie oznacza znacznik czasu, w którym flaga IsViolated w rekordzie CaseMilestone przyjmuje wartość true.
Typ zdarzenia
explicit
|
|||
|
Przypisanie sprawy do konsultanta
|
Oznacza moment przypisania zgłoszenia do konkretnego konsultanta lub kolejki. To podstawowy krok procesu, rejestrowany jako zmiana pola właściciela sprawy. | ||
|
Dlaczego to ważne
To zdarzenie pozwala śledzić obciążenie konsultantów, opóźnienia w przypisywaniu spraw i częstotliwość przekazań. Stanowi podstawę analizy pracy konsultantów i wykrywania wąskich gardeł w procesie przydzielania spraw.
Skąd pobrać
Ustalane na podstawie zmiany pola OwnerId w obiekcie Case. Znacznik czasu tej zmiany jest zapisywany w obiekcie CaseHistory.
Rejestrowanie
Ustalenie znacznika czasu pierwszej aktualizacji pola OwnerId.
Typ zdarzenia
inferred
|
|||
|
Rozwiązanie sprawy
|
Ten etap oznacza, że konsultant zakończył pracę potrzebną do rozwiązania problemu klienta. Sprawa oczekuje teraz na ostateczne zamknięcie, które może nastąpić automatycznie po określonym czasie. | ||
|
Dlaczego to ważne
To główny punkt końcowy pomiaru czasu rozwiązania sprawy i podstawa obliczania realizacji SLA. Oznacza koniec aktywnej pracy nad sprawą.
Skąd pobrać
Ustalane na podstawie obiektu CaseHistory, gdy pole Status zmienia się na „Resolved”. Pole IsClosed może w tym momencie nadal mieć wartość false.
Rejestrowanie
Znacznik czasu zmiany statusu sprawy na „Resolved”.
Typ zdarzenia
inferred
|
|||
|
Uruchomienie eskalacji wewnętrznej
|
To zdarzenie występuje, gdy sprawa wymaga wyższego poziomu wsparcia lub specjalistycznej wiedzy i zostaje formalnie eskalowana. Można je zarejestrować bezpośrednio za pomocą reguł eskalacji Salesforce lub ustalić na podstawie zmiany pola. | ||
|
Dlaczego to ważne
Analiza eskalacji pomaga wykrywać złożone typy spraw, potrzeby szkoleniowe konsultantów pierwszej linii i problemy systemowe. Wskazuje też tarcia w procesie i ich wpływ na czas rozwiązania sprawy.
Skąd pobrać
Może to być jawne zdarzenie zapisane w rekordach CaseEscalation. Częściej ustala się je na podstawie obiektu CaseHistory, gdy pole wyboru, takie jak „IsEscalated”, przyjmuje wartość true.
Rejestrowanie
Znacznik czasu zmiany pola „IsEscalated” na true.
Typ zdarzenia
inferred
|
|||
|
Utworzenie sprawy
|
To zdarzenie oznacza oficjalny początek procesu obsługi klienta, gdy nowe zgłoszenie serwisowe, czyli sprawa, zostaje zarejestrowane w Salesforce. Jest rejestrowane w chwili utworzenia nowego rekordu w obiekcie Case, wraz z dokładnym znacznikiem czasu. | ||
|
Dlaczego to ważne
Jako główne zdarzenie początkowe jest niezbędne do obliczania całkowitego czasu obsługi sprawy i czasu jej rozwiązania. Stanowi punkt odniesienia przy pomiarze wyników względem SLA i analizie liczby spraw.
Skąd pobrać
To zdarzenie odpowiada utworzeniu rekordu w obiekcie Case. Znacznik czasu jest zapisywany w standardowym polu CreatedDate.
Rejestrowanie
Bezpośrednio ze znacznika czasu utworzenia rekordu Case.
Typ zdarzenia
explicit
|
|||
|
Zamknięcie sprawy
|
To zdarzenie oznacza ostateczny koniec cyklu obsługi zgłoszenia. Po zamknięciu sprawy nie przewiduje się dalszych działań, chyba że zostanie ona ponownie otwarta. | ||
|
Dlaczego to ważne
Jako zdarzenie końcowe wyznacza punkt końcowy do obliczenia całkowitego czasu obsługi sprawy. Czas między statusem „Resolved” a „Closed” może też ujawnić nieefektywność procesu zamykania.
Skąd pobrać
Ustalane na podstawie znacznika czasu, w którym pole IsClosed w obiekcie Case przyjmuje wartość true. W tym samym momencie wypełniane jest też pole ClosedDate.
Rejestrowanie
Znacznik czasu zmiany pola IsClosed na true, zapisany w obiekcie CaseHistory.
Typ zdarzenia
inferred
|
|||
|
Analiza problemu przez konsultanta
|
To etap, na którym konsultant aktywnie diagnozuje i analizuje problem klienta. Nie jest to jawnie rejestrowane zdarzenie. Można je ustalić, gdy status sprawy zmienia się z nowego lub otwartego na status oznaczający pracę w toku. | ||
|
Dlaczego to ważne
Znajomość czasu trwania analizy pomaga wykrywać złożone zgłoszenia oraz obszary, w których konsultantom mogą być potrzebne dodatkowe szkolenia lub zasoby. Pozwala oddzielić czas aktywnej pracy od czasu oczekiwania.
Skąd pobrać
Ustalane na podstawie obiektu CaseHistory, gdy pole Status przyjmuje wartość oznaczającą aktywną pracę, na przykład „In Progress” lub „Working”.
Rejestrowanie
Znacznik czasu zmiany statusu sprawy na wartość oznaczającą pracę w toku.
Typ zdarzenia
inferred
|
|||
|
Kategoryzacja i ustalenie priorytetu sprawy
|
To zdarzenie występuje, gdy sprawie zostają przypisane typ, kategoria i poziom priorytetu. Zwykle robi to zespół wstępnej oceny zgłoszeń lub reguły automatyzacji. Zdarzenie można ustalić na podstawie zmian odpowiednich pól sprawy. | ||
|
Dlaczego to ważne
Kategoryzacja pomaga zrozumieć rozkład spraw i skuteczność ich kierowania. Analiza tego kroku ułatwia optymalizację podziału pracy i sprawdzenie, czy sprawy o wysokim priorytecie są obsługiwane bez zbędnej zwłoki.
Skąd pobrać
Ustalane na podstawie obiektu CaseHistory przez sprawdzenie, kiedy po raz pierwszy wypełniono pola Priority, Type lub inne pola klasyfikacyjne albo zmieniono ich wartości domyślne.
Rejestrowanie
Śledzenie zmian pól takich jak Priority lub Type w obiekcie CaseHistory.
Typ zdarzenia
inferred
|
|||
|
Otrzymanie informacji od klienta
|
To zdarzenie kończy czas oczekiwania na klienta, gdy klient przekazuje wymagane informacje. Często można je ustalić, gdy po otrzymaniu wiadomości przychodzącej status sprawy zmienia się z powrotem na aktywny. | ||
|
Dlaczego to ważne
Śledzenie tego zdarzenia pozwala analizować czas odpowiedzi klientów i jego wpływ na cały cykl obsługi sprawy. Oznacza wznowienie aktywnej pracy przez konsultanta.
Skąd pobrać
Ustalane na podstawie znacznika czasu przychodzącego rekordu EmailMessage powiązanego ze sprawą albo zmiany statusu z „Waiting on Customer” z powrotem na „In Progress” w obiekcie CaseHistory.
Rejestrowanie
Znacznik czasu przychodzącej wiadomości e-mail lub zmiany statusu z wartości oznaczającej oczekiwanie.
Typ zdarzenia
inferred
|
|||
|
Ponowne otwarcie sprawy
|
Zdarzenie występuje, gdy wcześniej rozwiązana lub zamknięta sprawa zostaje ponownie aktywowana, ponieważ problem powrócił albo rozwiązanie okazało się nieskuteczne. To ważny wskaźnik ponownie wykonywanej pracy. | ||
|
Dlaczego to ważne
Ponowne otwarcie sprawy często wskazuje na niską jakość rozwiązania lub niepowodzenie w rozwiązaniu problemu przy pierwszym kontakcie. Analiza częstotliwości i przyczyn takich przypadków jest niezbędna do poprawy jakości obsługi.
Skąd pobrać
Ustalane na podstawie obiektu CaseHistory, gdy pole IsClosed zmienia się z true na false albo status zmienia się ze stanu zamkniętego lub rozwiązanego na otwarty.
Rejestrowanie
Znacznik czasu zmiany pola Status lub IsClosed ze stanu końcowego na aktywny.
Typ zdarzenia
inferred
|
|||
|
Ponowne przypisanie sprawy
|
Oznacza przekazanie sprawy innemu konsultantowi lub kolejce po jej początkowym przypisaniu. Można je ustalić na podstawie kolejnych zmian pola właściciela sprawy. | ||
|
Dlaczego to ważne
Częste ponowne przypisania mogą wskazywać na błędne skierowanie sprawy, nieefektywne procesy lub braki w wiedzy. Prowadzą do opóźnień i pogorszenia obsługi klienta. To zdarzenie pozwala określić liczbę przekazań między konsultantami.
Skąd pobrać
Ustalane na podstawie każdej zmiany pola OwnerId w obiekcie CaseHistory po początkowym przypisaniu sprawy.
Rejestrowanie
Ustalenie wszystkich aktualizacji pola OwnerId po pierwszej zmianie.
Typ zdarzenia
inferred
|
|||
|
Prośba o informacje od klienta
|
To zdarzenie występuje, gdy konsultant potrzebuje dodatkowych informacji od klienta, aby kontynuować obsługę sprawy. Zwykle można je ustalić na podstawie zmiany statusu sprawy na wartość oznaczającą oczekiwanie na klienta. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna czas oczekiwania, na który konsultant nie ma wpływu. Wyodrębnienie tego czasu jest niezbędne do rzetelnego pomiaru efektywności procesu wewnętrznego i pracy konsultantów.
Skąd pobrać
Ustalane na podstawie obiektu CaseHistory, gdy pole Status przyjmuje wartość taką jak „Waiting on Customer Response” lub „Pending”.
Rejestrowanie
Znacznik czasu zmiany statusu sprawy na wartość oznaczającą oczekiwanie.
Typ zdarzenia
inferred
|
|||
|
Przedstawienie klientowi proponowanego rozwiązania
|
Oznacza moment, w którym konsultant przedstawia klientowi możliwe rozwiązanie. To etap pojęciowy, który zwykle można ustalić na podstawie wiadomości wychodzącej lub określonej zmiany statusu. | ||
|
Dlaczego to ważne
Śledzenie tego etapu pozwala mierzyć czas od rozpoczęcia analizy do przedstawienia rozwiązania. Może też oznaczać początek pętli potwierdzeń, jeśli klient nie zaakceptuje rozwiązania.
Skąd pobrać
Ustalane na podstawie wychodzącego rekordu EmailMessage zawierającego określone słowa kluczowe lub zmiany statusu na „Solution Provided” w obiekcie CaseHistory.
Rejestrowanie
Znacznik czasu zmiany statusu lub wysłania wiadomości.
Typ zdarzenia
inferred
|
|||
|
Wysłanie ankiety satysfakcji
|
Oznacza wysłanie ankiety satysfakcji klienta (CSAT) lub ankiety Net Promoter Score (NPS). Zwykle jest to działanie automatyczne następujące po rozwiązaniu lub zamknięciu sprawy. | ||
|
Dlaczego to ważne
To zdarzenie nie należy do głównego procesu rozwiązywania sprawy, ale pomaga analizować pętlę informacji zwrotnej. Analiza czasu i częstotliwości wysyłania ankiet pozwala regularnie zbierać opinie klientów.
Skąd pobrać
Ustalane na podstawie wychodzącego rekordu EmailMessage powiązanego ze sprawą i zgodnego z szablonem ankiety. Można je też zarejestrować w chwili utworzenia rekordu SurveyInvitation.
Rejestrowanie
Ustalenie wysłania wychodzącej wiadomości e-mail z ankietą lub utworzenia rekordu SurveyInvitation.
Typ zdarzenia
inferred
|
|||
|
Wysłanie potwierdzenia przyjęcia zgłoszenia
|
To pierwsza wiadomość wysłana klientowi z potwierdzeniem otrzymania zgłoszenia serwisowego. Zwykle jest to automatyczna wiadomość e-mail uruchamiana przez reguły tworzenia sprawy. Zdarzenie można ustalić na podstawie pierwszej wiadomości wychodzącej. | ||
|
Dlaczego to ważne
Śledzenie tego zdarzenia pozwala mierzyć czas pierwszej odpowiedzi i sprawdzać, czy klienci szybko otrzymują informację o przyjęciu zgłoszenia. Ułatwia analizę KPI „Czas do potwierdzenia przyjęcia zgłoszenia” i usprawnianie komunikacji z klientami.
Skąd pobrać
Ustalane na podstawie znacznika czasu pierwszego wychodzącego rekordu EmailMessage powiązanego ze sprawą. Można je też określić na podstawie aktualizacji pola niestandardowego wywołanej przez regułę automatyzacji.
Rejestrowanie
Ustalenie znacznika czasu pierwszego wychodzącego rekordu EmailMessage powiązanego ze sprawą.
Typ zdarzenia
inferred
|
|||
Przewodniki dotyczące pobierania danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu danych, aby rozpocząć analizę process mining i znaleźć możliwości usprawnienia obsługi klienta. Zacznij ulepszać sposób świadczenia usług już dziś.
Zwiększ sprawność obsługi klienta
Rozwiązuj 80% spraw przy pierwszym kontakcie i zwiększaj wskaźnik CSAT.
Karta kredytowa nie jest wymagana