Szablon danych dotyczących obsługi klienta
Szablon danych dotyczących obsługi klienta
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Instrukcje ekstrakcji danych
Atrybuty obsługi klienta
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiło określone działanie lub zdarzenie. | ||
|
Opis
Czas zdarzenia, czyli znacznik czasu, określa dokładną datę i godzinę wykonania działania. Pozwala uporządkować zdarzenia chronologicznie i obliczać czas między kolejnymi krokami procesu. Każde zarejestrowane działanie musi mieć przypisany znacznik czasu. W analizie ten atrybut służy do tworzenia osi czasu dla każdego zgłoszenia serwisowego. Jest podstawą obliczania wszystkich KPI związanych z czasem, takich jak czas rozwiązania, czas do pierwszej odpowiedzi i czas trwania wąskich gardeł. Dokładne znaczniki czasu są niezbędne do oceny wyników procesu i wykrywania opóźnień.
Dlaczego to ważne
Ten znacznik czasu jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczania mierników czasu, takich jak czas realizacji i zgodność z SLA.
Skąd pobrać
Odpowiada polom „created_at” lub „updated_at” powiązanym ze zdarzeniami zgłoszenia, odpowiedziami lub zmianami statusu w API Freshdesk.
Przykłady
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
Działanie
Activity
|
Nazwa konkretnego zdarzenia biznesowego lub kroku, który wystąpił w procesie obsługi klienta. | ||
|
Opis
Atrybut „Działanie” opisuje odrębną czynność lub zmianę statusu w cyklu życia zgłoszenia serwisowego. Rejestruje ważne zdarzenia biznesowe, takie jak „Utworzenie zgłoszenia”, „Przypisanie zgłoszenia”, „Wysłanie pierwszej odpowiedzi” i „Rozwiązanie zgłoszenia”. Działania te tworzą węzły na mapie procesu. Analiza kolejności i częstotliwości działań stanowi podstawę process mining. Umożliwia wizualizację przebiegu procesu, wskazanie częstych i rzadkich ścieżek oraz wykrywanie odstępstw od standardowych procedur. Znajomość działań pomaga wykrywać nieefektywne etapy, pętle ponownej pracy, takie jak „Ponowne otwarcie zgłoszenia”, oraz problemy ze zgodnością.
Dlaczego to ważne
Ten atrybut określa kroki na mapie procesu i umożliwia wizualizację oraz analizę jego przebiegu od początku do końca.
Skąd pobrać
Wyznaczane na podstawie typów zdarzeń w Freshdesk. Mogą to być zmiany statusu z punktu końcowego API „Tickets” oraz konkretne zdarzenia, takie jak notatki lub odpowiedzi z punktu końcowego „Conversations”.
Przykłady
Utworzenie zgłoszeniaWysłanie pierwszej odpowiedziZmiana statusu na „Pending”Rozwiązanie zgłoszeniaZamknięcie zgłoszenia
|
|||
|
Zgłoszenie serwisowe
ServiceRequest
|
Unikalny identyfikator pojedynczego zapytania lub problemu klienta, nazywanego zwykle zgłoszeniem lub sprawą. | ||
|
Opis
Zgłoszenie serwisowe to główny identyfikator case, który łączy wszystkie działania związane z pojedynczą interakcją z klientem. Każde nowe zapytanie, zgłoszenie problemu lub prośba klienta otrzymuje unikalny identyfikator zgłoszenia serwisowego. Identyfikator pozostaje taki sam przez cały cykl życia zgłoszenia, od utworzenia i przypisania po rozwiązanie i zamknięcie. W process mining ten atrybut ma podstawowe znaczenie przy odtwarzaniu przebiegu obsługi każdej sprawy od początku do końca. Grupując powiązane zdarzenia pod jednym identyfikatorem zgłoszenia serwisowego, analitycy mogą wizualizować przebieg procesu, mierzyć czas realizacji oraz wykrywać różnice i wąskie gardła dotyczące poszczególnych spraw.
Dlaczego to ważne
To podstawowy identyfikator case, który łączy powiązane zdarzenia w jedną instancję procesu i pozwala prześledzić całą obsługę każdego zgłoszenia klienta.
Skąd pobrać
To główny identyfikator zgłoszenia w Freshdesk, zwykle dostępny w polu „id” punktu końcowego API „Tickets”.
Przykłady
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
Priorytet
Priority
|
Priorytet przypisany do zgłoszenia serwisowego, na przykład „Niski”, „Średni”, „Wysoki” lub „Pilny”. | ||
|
Opis
Atrybut Priorytet określa pilność zgłoszenia serwisowego i często wpływa na docelowy czas reakcji oraz rozwiązania. Priorytet może być ustawiany automatycznie na podstawie reguł albo ręcznie przez agenta podczas wstępnej oceny zgłoszenia. Atrybut ten jest potrzebny do analizy realizacji SLA i przydziału zasobów. Po przefiltrowaniu mapy procesu według priorytetu analitycy mogą sprawdzić, czy zgłoszenia o wysokim priorytecie są rzeczywiście obsługiwane szybciej niż te o niskim priorytecie. Można też ustalić, jak często zmienia się priorytet, co stanowi formę ponownej pracy, i jaki ma to wpływ na proces.
Dlaczego to ważne
Przydatny przy analizie SLA i ocenie, czy zasoby są właściwie przydzielane, aby pilne zgłoszenia obsługiwać szybciej niż te o niższym priorytecie.
Skąd pobrać
Odpowiada polu „priority” w obiekcie „Tickets” w Freshdesk.
Przykłady
NiskiŚredniWysokiPilny
|
|||
|
Przypisany pracownik
AssignedAgent
|
Imię i nazwisko lub identyfikator pracownika obsługi klienta odpowiedzialnego za zgłoszenie w chwili wystąpienia zdarzenia. | ||
|
Opis
Ten atrybut wskazuje pracownika przypisanego do obsługi zgłoszenia serwisowego. Osoba odpowiedzialna może się zmieniać w trakcie obsługi zgłoszenia z powodu ponownego przypisania lub eskalacji. Analiza danych według przypisanego pracownika ma znaczenie dla dashboardów służących do monitorowania wyników. Umożliwia pomiar indywidualnych KPI, takich jak średni czas rozwiązania, liczba zgłoszeń i odsetek ponownie otwieranych zgłoszeń. Pomaga wskazać pracowników osiągających najlepsze wyniki, określić potrzeby szkoleniowe i ocenić wpływ przekazywania zgłoszeń na całkowity czas ich rozwiązania.
Dlaczego to ważne
Umożliwia analizę wyników poszczególnych pracowników, wskazanie osób osiągających najlepsze wyniki, potrzeb szkoleniowych i wpływu ponownego przypisywania zgłoszeń.
Skąd pobrać
Odpowiada polu „responder_id” w obiekcie „Tickets” w Freshdesk. Można je połączyć z danymi pracowników.
Przykłady
Anna KowalskaRobert NowakMaria Wiśniewska
|
|||
|
Rodzaj zgłoszenia serwisowego
ServiceRequestType
|
Klasyfikacja zgłoszenia serwisowego, na przykład „Pytanie”, „Incydent”, „Problem” lub „Prośba o funkcję”. | ||
|
Opis
Rodzaj zgłoszenia serwisowego to pole klasyfikacji, które określa charakter zapytania klienta. Klasyfikację zwykle ustala się podczas tworzenia zgłoszenia lub w trakcie wstępnej oceny. Pomaga ona skierować sprawę do odpowiedniego zespołu lub pracownika. W analizie ten atrybut pozwala podzielić proces na segmenty i sprawdzić, jak obsługiwane są różne rodzaje zgłoszeń. Ułatwia odpowiedź na pytania: „Czy rozwiązanie incydentów trwa dłużej niż odpowiedź na pytania?” oraz „Które rodzaje zgłoszeń są najczęściej ponownie otwierane?”. Taki podział pomaga wykrywać wąskie gardła charakterystyczne dla danego rodzaju spraw i odpowiednio usprawniać workflow.
Dlaczego to ważne
Umożliwia podział procesu na segmenty i porównanie wyników oraz workflow dla różnych rodzajów spraw klientów, na przykład incydentów i pytań.
Skąd pobrać
Prawdopodobnie odpowiada polu „type” w obiekcie „Tickets” w Freshdesk.
Przykłady
PytanieZgłoszenie incydentuProblemProśba o nową funkcję
|
|||
|
Status
Status
|
Bieżący lub historyczny status zgłoszenia serwisowego, na przykład „Otwarte”, „Oczekujące”, „Rozwiązane” lub „Zamknięte”. | ||
|
Opis
Atrybut Status określa stan zgłoszenia serwisowego w danym momencie. Zmiany statusu często wyznaczają ważne etapy procesu. Na przykład status zmienia się z „Otwarte” na „Oczekujące”, gdy trzeba poczekać na informacje od klienta, albo z „Oczekujące” na „Otwarte”, gdy klient odpowie. Śledzenie zmian statusu pozwala zrozumieć cykl życia zgłoszenia. Pokazuje, ile czasu zgłoszenia pozostają w poszczególnych stanach, co pomaga wykrywać wąskie gardła. Długi czas w statusie „Oczekujące” może na przykład oznaczać opóźnienia w uzyskiwaniu informacji od klientów.
Dlaczego to ważne
Śledzenie zmian statusu pomaga zrozumieć cykl życia zgłoszenia i sprawdzić, jak długo sprawy pozostają w określonych stanach, takich jak „Oczekujące” lub „Wstrzymane”.
Skąd pobrać
Odpowiada polu „status” w obiekcie „Tickets” w Freshdesk. Historyczne statusy trzeba odtworzyć na podstawie dzienników aktywności.
Przykłady
OtwarteOczekująceRozwiązaneZamknięte
|
|||
|
Czas do pierwszej odpowiedzi
FirstResponseTime
|
Czas od utworzenia zgłoszenia do pierwszej odpowiedzi agenta dla klienta. | ||
|
Opis
Czas do pierwszej odpowiedzi pokazuje, jak szybko klient otrzymuje pierwszą odpowiedź od agenta, która nie jest automatyczna. Oblicza się go jako różnicę między znacznikiem czasu aktywności „First Response Sent” a znacznikiem czasu aktywności „Ticket Created”. To KPI mierzy szybkość reakcji zespołu i ma duży wpływ na satysfakcję klienta. Krótki czas do pierwszej odpowiedzi daje klientowi pewność, że zgłoszenie zostało przyjęte i jest obsługiwane. Analiza tego wskaźnika pomaga sprawdzić, czy dotrzymywane są SLA dotyczące pierwszej odpowiedzi i czy klienci otrzymują ją bez zbędnej zwłoki.
Dlaczego to ważne
Mierzy szybkość reakcji zespołu, która wpływa na satysfakcję klienta i pozwala ocenić, czy obsługa rozpoczyna się bez zbędnej zwłoki.
Skąd pobrać
Pole wyliczane jako czas między zdarzeniami „Ticket Created” i „First Response Sent”.
Przykłady
3000009000001800000
|
|||
|
Czy SLA zostało naruszone
IsSlaBreached
|
Wartość logiczna wskazująca, czy czas rozwiązania zgłoszenia serwisowego przekroczył limit SLA. | ||
|
Opis
Ten wyliczany atrybut jasno wskazuje, czy dla danego zgłoszenia dotrzymano SLA. Powstaje przez porównanie rzeczywistego „ResolutionTime” z „SlaTargetResolutionTime”. Jeśli rzeczywisty czas jest dłuższy od docelowego, wartość atrybutu wynosi true. Atrybut ułatwia analizę i prezentację zgodności z SLA na dashboardzie. Pozwala szybko policzyć i odfiltrować zgłoszenia, w których przekroczono limit, a następnie sprawdzić skalę problemu i przeanalizować przebieg tych spraw, by znaleźć przyczyny źródłowe. Wspiera dashboard i KPI „Przegląd zgodności z SLA”.
Dlaczego to ważne
Ułatwia analizę zgodności z SLA, oznaczając każde zgłoszenie, w którym nie dotrzymano terminu. Pozwala też szukać przyczyn przekroczeń.
Skąd pobrać
Pole wyliczane przez porównanie rzeczywistego znacznika czasu rozwiązania z polem „SlaTargetResolutionTime” lub „due_by” w Freshdesk.
Przykłady
truefalse
|
|||
|
Czy zgłoszenie otwarto ponownie
IsReopened
|
Wartość logiczna wskazująca, czy rozwiązane zgłoszenie serwisowe zostało kiedykolwiek otwarte ponownie. | ||
|
Opis
Ten atrybut na poziomie sprawy przyjmuje wartość true, jeśli w dowolnym momencie cyklu życia zgłoszenia serwisowego wystąpiła aktywność „Ticket Reopened”. Ułatwia identyfikację i analizę spraw wymagających ponownej pracy. Wysoki odsetek ponownie otwieranych zgłoszeń może oznaczać, że pierwsze rozwiązanie było nieskuteczne lub niepełne, co prowadzi do strat czasu i frustracji klientów. Po odfiltrowaniu takich zgłoszeń można zbadać przyczyny, na przykład najczęstsze powody ponownego otwarcia, zespoły lub agentów z najwyższym odsetkiem oraz rodzaje zgłoszeń, których dotyczy to najczęściej.
Dlaczego to ważne
Wskazuje sprawy wymagające ponownej pracy, co pomaga ocenić jakość rozwiązania i sprawność procesu. Analiza tych spraw ułatwia poprawę skuteczności rozwiązania problemu przy pierwszym kontakcie.
Skąd pobrać
Pole wyliczane. Dla zgłoszenia serwisowego przyjmuje wartość true, jeśli w jego przypadku występuje zdarzenie, dla którego Activity = „Ticket Reopened”.
Przykłady
truefalse
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane z systemu źródłowego. | ||
|
Opis
Ten atrybut zapisuje datę i godzinę ostatniego wyodrębnienia lub aktualizacji zbioru danych z Freshdesk. Informuje, jak aktualne są analizowane dane, co ma znaczenie przy podejmowaniu trafnych decyzji biznesowych we właściwym czasie. Analitycy korzystają z tych informacji, aby ustalić okres objęty danymi i sprawdzić, czy pracują na najnowszych dostępnych informacjach. To ważne metadane w każdym dashboardzie lub raporcie process mining. Dzięki nim osoby korzystające z analizy wiedzą, kiedy dane zostały zebrane.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu analizy i decyzje można opierać na bieżących informacjach.
Skąd pobrać
To pole metadanych generowane podczas ekstrakcji danych, zawierające znacznik czasu pobrania.
Przykłady
2023-12-01T08:00:00Z
|
|||
|
Docelowy czas rozwiązania według SLA
SlaTargetResolutionTime
|
Uzgodniony w umowie lub wyznaczony czas na rozwiązanie zgłoszenia serwisowego. | ||
|
Opis
Atrybut określa docelowy czas, w którym należy rozwiązać zgłoszenie serwisowe zgodnie z umową o gwarantowanym poziomie świadczenia usług (SLA). Wartość docelowa często zależy od priorytetu lub rodzaju zgłoszenia. To jedna z danych potrzebnych do obliczenia zgodności z SLA. Porównanie rzeczywistego czasu rozwiązania z wartością docelową pozwala ustalić, czy SLA zostało „Dotrzymane”, czy „Naruszone”. Analiza realizacji SLA dla różnych rodzajów zgłoszeń, zespołów i agentów jest ważną częścią zarządzania usługami.
Dlaczego to ważne
Stanowi punkt odniesienia przy pomiarze zgodności z SLA, czyli jednym z podstawowych wskaźników wyników zespołu obsługi klienta.
Skąd pobrać
Może być dostępny w polu takim jak „fr_due_by” (pierwsza odpowiedź) lub „due_by” (rozwiązanie) w obiekcie „Tickets” w Freshdesk. W przeciwnym razie trzeba go wyliczyć na podstawie reguł SLA.
Przykłady
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
Kanał komunikacji
CommunicationChannel
|
Kanał, za pośrednictwem którego zgłoszono sprawę, na przykład „E-mail”, „Telefon”, „Czat” lub „Portal internetowy”. | ||
|
Opis
Atrybut wskazuje źródło lub kanał kontaktu z klientem. W zależności od kanału proces może przebiegać inaczej, a czas rozwiązania sprawy może się różnić. Na przykład zgłoszenie przesłane przez czat może mieć krótszy oczekiwany czas rozwiązania niż zgłoszenie wysłane e-mailem. Analiza procesu według kanału komunikacji pomaga lepiej przydzielać zasoby i oceniać skuteczność poszczególnych kanałów. Pokazuje, które z nich wiążą się z szybszym rozwiązywaniem spraw lub wyższą satysfakcją klientów. Na tej podstawie można podejmować decyzje o promowaniu kanałów lub inwestowaniu w ich rozwój.
Dlaczego to ważne
Ułatwia analizę wyników i sprawności procesu w różnych kanałach kontaktu z klientem, takich jak e-mail, telefon czy czat.
Skąd pobrać
Odpowiada polu „source” w obiekcie „Tickets” w Freshdesk.
Przykłady
E-mailTelefonPortal internetowyCzat
|
|||
|
Liczba przekazań między agentami
AgentTransferCount
|
Łączna liczba zmian agenta przypisanego do zgłoszenia serwisowego. | ||
|
Opis
Ta miara na poziomie sprawy zlicza zmiany agenta przypisanego do zgłoszenia. Oblicza się ją, zliczając wystąpienia aktywności „Ticket Reassigned” dla każdego zgłoszenia serwisowego. Częste przekazywanie sprawy między agentami, nazywane też „ping-pongiem”, może znacznie wydłużyć obsługę i pogorszyć doświadczenia klienta, ponieważ przy każdym przekazaniu część kontekstu może zostać utracona. Analiza liczby przekazań pomaga wykryć problemy z początkowym kierowaniem zgłoszeń, braki kompetencyjne agentów lub nadmierną złożoność procesu. Celem jest zwykle ograniczenie niepotrzebnych przekazań, aby poprawić sprawność obsługi i satysfakcję klientów.
Dlaczego to ważne
Mierzy częstotliwość przekazywania spraw wewnątrz zespołu. Takie przekazania mogą powodować opóźnienia i frustrację klientów. Analiza pomaga poprawić skuteczność obsługi na pierwszym poziomie.
Skąd pobrać
Pole wyliczane. Liczba aktywności „Ticket Reassigned” dla każdego unikalnego zgłoszenia serwisowego.
Przykłady
0132
|
|||
|
Nazwa klienta
CustomerName
|
Nazwa lub identyfikator klienta, który zgłosił sprawę serwisową. | ||
|
Opis
Atrybut wskazuje klienta powiązanego ze zgłoszeniem serwisowym. Pozwala analizować proces z perspektywy klienta i śledzić wszystkie jego kontakty w czasie. Analiza danych według klientów może ujawnić, którzy z nich zgłaszają najwięcej spraw lub najczęściej mają ponownie otwierane zgłoszenia. Informacje te mogą pomóc w działaniach na rzecz sukcesu klienta i wskazać klientów zagrożonych odejściem z powodu złej obsługi. Są też potrzebne do zrozumienia całej ścieżki klienta obejmującej wiele zgłoszeń serwisowych.
Dlaczego to ważne
Pozwala analizować proces z perspektywy klienta i wykrywać osoby często zgłaszające sprawy oraz klientów, u których problemy powracają.
Skąd pobrać
Informacja jest powiązana przez pole „requester_id” w obiekcie „Tickets”, które łączy się z obiektem „Contacts” lub „Users” w Freshdesk.
Przykłady
Jan KowalskiAnna NowakGlobal Tech Inc.
|
|||
|
Ocena satysfakcji
SatisfactionRating
|
Ocena satysfakcji wystawiona przez klienta po rozwiązaniu zgłoszenia. | ||
|
Opis
Ocena satysfakcji to miara wyniku, którą zwykle zbiera się w ankiecie wysyłanej po rozwiązaniu zgłoszenia. Może mieć postać wyniku liczbowego albo oceny opisowej, takiej jak „Zadowolony”, „Neutralny” lub „Niezadowolony”. Atrybut ten pozwala powiązać przebieg procesu z oceną klienta. Analiza wariantów procesu, po których klienci wystawiają niskie oceny, pomaga wykryć konkretne działania lub opóźnienia pogarszające ich doświadczenia. Dzięki temu można bezpośrednio zestawić sprawność procesu z satysfakcją klientów.
Dlaczego to ważne
Łączy przebieg procesu z oceną klienta i pomaga ustalić, które działania w procesie wiążą się z wysoką lub niską satysfakcją.
Skąd pobrać
Dane pochodzą z funkcji ocen satysfakcji w Freshdesk. Można je pobrać za pośrednictwem punktu końcowego API „Surveys” lub „Satisfaction Ratings”.
Przykłady
5314
|
|||
|
Produkt
Product
|
Produkt lub usługa, których dotyczy zgłoszenie klienta. | ||
|
Opis
Atrybut określa produkt lub linię usług, których dotyczy zgłoszenie serwisowe. Zwykle jest to pole niestandardowe skonfigurowane w Freshdesk, które pomaga kategoryzować zgłoszenia na potrzeby ich kierowania i raportowania. Filtrowanie procesu według produktu pozwala wykrywać problemy dotyczące konkretnych produktów. Można na przykład sprawdzić, czy dany produkt generuje nieproporcjonalnie dużo zgłoszeń do pomocy technicznej albo czy premiera nowego produktu powoduje wzrost liczby zapytań. Wyniki takiej analizy mogą pomóc zespołom odpowiedzialnym za rozwój i zarządzanie produktami.
Dlaczego to ważne
Pozwala filtrować proces według obszaru produktu i sprawdzać, które produkty generują najwięcej zgłoszeń do pomocy technicznej lub mają najdłuższy czas rozwiązania.
Skąd pobrać
Zwykle jest to pole niestandardowe. Dokładne miejsce zależy od konfiguracji Freshdesk. Pole prawdopodobnie znajduje się w części „custom_fields” odpowiedzi API obiektu „Tickets”.
Przykłady
Platforma AlphaAplikacja mobilna BetaSubskrypcja Gamma
|
|||
|
Przypisana grupa
AssignedGroup
|
Zespół lub dział, do którego przypisano zgłoszenie serwisowe. | ||
|
Opis
Atrybut Przypisana grupa wskazuje zespół agentów odpowiedzialny za obsługę danego zgłoszenia serwisowego. Zgłoszenia są często kierowane do wyspecjalizowanych grup zależnie od ich rodzaju lub złożoności, na przykład do „Wsparcia technicznego” albo „Działu rozliczeń”. Atrybut ten pomaga analizować przekazywanie spraw między działami i wyniki pracy poszczególnych zespołów. Pokazuje, które grupy obsługują najwięcej zgłoszeń, w których sprawy są rozwiązywane najdłużej i jak często zgłoszenia trafiają między grupami. Te informacje pomagają usprawniać strukturę zespołów i workflow.
Dlaczego to ważne
Umożliwia analizę wyników pracy zespołów i działów, pokazuje przekazywanie spraw oraz wąskie gardła charakterystyczne dla poszczególnych grup.
Skąd pobrać
Odpowiada polu „group_id” w obiekcie „Tickets” w Freshdesk.
Przykłady
Wsparcie L1Wsparcie techniczne L2RozliczeniaSukces klienta
|
|||
|
System źródłowy
SourceSystem
|
System, z którego wyodrębniono dane. W tym przypadku jest to Freshdesk. | ||
|
Opis
Ten atrybut wskazuje aplikację źródłową, z której pochodzą dane o procesie. W tej analizie jego wartość będzie stała, na przykład „Freshdesk”, co oznacza, że wszystkie zdarzenia pochodzą z platformy obsługi klienta Freshdesk. Choć może się wydawać prosty, atrybut ten ma znaczenie dla zarządzania danymi i łączenia informacji z wielu systemów. Pozwala ustalić pochodzenie danych i zapewnia kontekst, dzięki czemu analitycy wiedzą, jakie dane analizują. Pomaga to zachować integralność danych i budować zaufanie do wyników analizy.
Dlaczego to ważne
Dostarcza informacji o pochodzeniu danych, co ma znaczenie dla zarządzania nimi i łączenia danych z wielu systemów źródłowych.
Skąd pobrać
To stała wartość „Freshdesk”, dodawana podczas przekształcania danych w celu wskazania ich źródła.
Przykłady
Freshdesk
|
|||
Działania w obsłudze klienta
| Działanie | Opis | ||
|---|---|---|---|
|
Przypisanie zgłoszenia
|
Oznacza przypisanie zgłoszenia do konkretnego pracownika lub grupy. Zdarzenie jest jawnie rejestrowane w historii zgłoszenia za każdym razem, gdy pole przypisanego pracownika lub grupy zostaje uzupełnione albo zmienione. | ||
|
Dlaczego to ważne
Śledzenie przypisań pomaga analizować obciążenie pracowników, wykrywać nieefektywne kierowanie zgłoszeń i mierzyć KPI dotyczące czasu do przypisania. Pokazuje, jak rozdzielana jest praca i gdzie występują opóźnienia przed jej rozpoczęciem.
Skąd pobrać
Dane pochodzą z dziennika „Ticket Activities”, w którym zmiany pól „Agent” lub „Group” są rejestrowane wraz ze znacznikiem czasu.
Rejestrowanie
Zdarzenie jest rejestrowane po zmianie pola „Assigned to” dla pracownika lub grupy.
Typ zdarzenia
explicit
|
|||
|
Rozwiązanie zgłoszenia
|
Oznacza ważny moment, w którym pracownik przekazuje rozwiązanie i zmienia status zgłoszenia na „Resolved”. Jest to jawna zmiana statusu zapisana w historii zgłoszenia. | ||
|
Dlaczego to ważne
To działanie oznacza koniec aktywnej pracy nad zgłoszeniem i stanowi podstawę do pomiaru czasu jego rozwiązania. Jest ważne przy analizie wyników pracy zespołu i efektywności całego procesu.
Skąd pobrać
Dane pochodzą z dziennika „Ticket Activities”, który rejestruje zmianę statusu na „Resolved” wraz ze znacznikiem czasu.
Rejestrowanie
Zdarzenie jest rejestrowane po zmianie pola „Status” zgłoszenia na „Resolved”.
Typ zdarzenia
explicit
|
|||
|
Utworzenie zgłoszenia
|
To pierwsze zdarzenie w cyklu obsługi klienta. Oznacza moment formalnego zarejestrowania zgłoszenia w Freshdesk. System rejestruje je, gdy powstaje nowe zgłoszenie, przesłane e-mailem, przez portal, telefonicznie lub za pośrednictwem integracji API. | ||
|
Dlaczego to ważne
To działanie rozpoczyna każdy case. Jest niezbędne do obliczania całkowitego czasu rozwiązania zgłoszenia oraz analizy liczby zgłoszeń według kanału lub rodzaju.
Skąd pobrać
To jawne zdarzenie w dzienniku „Ticket Activities” w Freshdesk. Jest rejestrowane automatycznie po utworzeniu nowego zgłoszenia.
Rejestrowanie
Rejestrowane bezpośrednio w historii aktywności zgłoszenia w chwili jego utworzenia.
Typ zdarzenia
explicit
|
|||
|
Wysłanie pierwszej odpowiedzi
|
Oznacza pierwszą publiczną odpowiedź pracownika wysłaną klientowi po utworzeniu zgłoszenia. Freshdesk rejestruje to zdarzenie, aby mierzyć „First Response Time” na potrzeby monitorowania SLA. | ||
|
Dlaczego to ważne
To ważny punkt pomiaru szybkości reakcji na potrzeby klienta i zgodności z SLA. Analiza czasu do tego działania pomaga wykrywać opóźnienia w pierwszym kontakcie z klientem.
Skąd pobrać
Freshdesk śledzi to zdarzenie na potrzeby SLA. Odpowiada ono znacznikowi czasu pierwszego publicznego komentarza dodanego przez pracownika.
Rejestrowanie
Ustalane na podstawie pierwszej publicznej odpowiedzi pracownika w historii rozmowy dotyczącej zgłoszenia.
Typ zdarzenia
explicit
|
|||
|
Zamknięcie zgłoszenia
|
To ostatnie działanie, oznaczające trwałe zamknięcie zgłoszenia. Często system wykonuje je automatycznie po upływie określonego czasu od zmiany statusu na „Resolved”, jeśli klient nie odpowie. | ||
|
Dlaczego to ważne
To działanie oznacza definitywny koniec obsługi zgłoszenia. Stanowi końcowy punkt odniesienia przy dokładnym obliczaniu czasu procesu od początku do końca.
Skąd pobrać
Dane pochodzą z dziennika „Ticket Activities”, który rejestruje końcową zmianę statusu na „Closed”. Często uruchamia ją automatyzacja systemowa.
Rejestrowanie
Zdarzenie jest rejestrowane po zmianie pola „Status” zgłoszenia na „Closed”.
Typ zdarzenia
explicit
|
|||
|
Dodanie notatki wewnętrznej
|
Pracownik dodaje do zgłoszenia prywatną notatkę przeznaczoną do współpracy z innymi pracownikami. Jest to jawne zdarzenie rejestrowane w historii aktywności zgłoszenia i widoczne tylko dla pracowników. | ||
|
Dlaczego to ważne
Śledzenie notatek wewnętrznych pomaga analizować współpracę i wykrywać sprawy wymagające długich konsultacji w zespole. Duża liczba takich notatek przed rozwiązaniem zgłoszenia może wskazywać na złożony problem lub brak potrzebnej wiedzy.
Skąd pobrać
Rejestrowane jako „Private Note” w historii rozmowy dotyczącej zgłoszenia. Można je odróżnić od publicznych odpowiedzi dla klienta.
Rejestrowanie
Zdarzenie jest rejestrowane, gdy pracownik dodaje notatkę oznaczoną jako „Private”.
Typ zdarzenia
explicit
|
|||
|
Naruszenie SLA
|
Zdarzenie obliczane, gdy czas odpowiedzi na zgłoszenie lub jego rozwiązania przekracza limit określony w zasadach SLA. Freshdesk śledzi status SLA i oznacza zgłoszenia jako „violated”. Na tej podstawie można wyznaczyć to działanie. | ||
|
Dlaczego to ważne
To działanie wspiera analizę zgodności z SLA, wskazując dokładnie, kiedy i gdzie nie dotrzymano uzgodnionego poziomu obsługi. Pomaga wykrywać systemowe przyczyny opóźnień.
Skąd pobrać
Zdarzenie jest wnioskowane lub obliczane na podstawie statusu „SLA” zgłoszenia. Działanie można wygenerować, gdy status SLA zmieni się na „Violated”, albo porównując znaczniki czasu odpowiedzi i rozwiązania z limitami SLA.
Rejestrowanie
Wyznaczane na podstawie danych zgłoszenia, gdy „Time to Resolve” przekracza „SLA Target Resolution Time”.
Typ zdarzenia
calculated
|
|||
|
Odpowiedź klienta
|
Oznacza nową odpowiedź lub wiadomość od klienta. Jest to jawne zdarzenie w wątku rozmowy dotyczącej zgłoszenia, które zwykle zmienia jego status z „Pending” na „Open”. | ||
|
Dlaczego to ważne
To działanie pomaga zrozumieć przebieg wymiany wiadomości z klientem i mierzyć czas oczekiwania na odpowiedź. Uruchamia też ponownie wstrzymane liczniki SLA, wpływając na mierniki zgodności.
Skąd pobrać
Rejestrowane jako nowy wpis w wątku rozmowy dotyczącej zgłoszenia. Zdarzenie jest powiązane z kartą kontaktu klienta.
Rejestrowanie
Nowa publiczna wiadomość dodana do zgłoszenia przez kontakt klienta.
Typ zdarzenia
explicit
|
|||
|
Ponowne otwarcie zgłoszenia
|
To działanie występuje, gdy klient odpowiada na zgłoszenie o statusie „Resolved”, a system automatycznie zmienia jego status z powrotem na „Open”. Zdarzenie jest jawnie rejestrowane przez system. | ||
|
Dlaczego to ważne
Wysoki odsetek ponownie otwieranych zgłoszeń wskazuje, że początkowe rozwiązania nie są skuteczne, co prowadzi do ponownej pracy i niezadowolenia klientów. Analiza tego działania jest niezbędna do oceny ponownie otwieranych zgłoszeń i zwiększenia odsetka spraw rozwiązywanych przy pierwszym kontakcie.
Skąd pobrać
Zdarzenie jest rejestrowane, gdy odpowiedź klienta powoduje automatyczną zmianę statusu z „Resolved” na „Open”. Zmiana statusu jest zapisywana w dzienniku „Ticket Activities”.
Rejestrowanie
Zmiana statusu z „Resolved” na „Open” spowodowana kontaktem z klientem.
Typ zdarzenia
explicit
|
|||
|
Ponowne przypisanie zgłoszenia
|
Występuje, gdy po pierwszym przypisaniu zgłoszenie zostaje przekazane innemu pracownikowi lub grupie. Zdarzenie jest jawnie rejestrowane w dzienniku aktywności zgłoszenia jako zmiana osoby odpowiedzialnej. | ||
|
Dlaczego to ważne
Częste ponowne przypisania lub częste przekazywanie zgłoszeń między pracownikami mogą wskazywać na błędne początkowe kierowanie albo rozproszenie wiedzy. Analiza pomaga znaleźć możliwości zwiększenia odsetka spraw rozwiązywanych przy pierwszym kontakcie.
Skąd pobrać
Śledzone na podstawie zmian pól „Agent” lub „Group” w dzienniku „Ticket Activities” po pierwszym przypisaniu.
Rejestrowanie
Kolejna zmiana pola „Assigned to” po dokonaniu pierwszego przypisania.
Typ zdarzenia
explicit
|
|||
|
Wysłanie ankiety satysfakcji
|
Oznacza wysłanie ankiety satysfakcji klienta, zwykle uruchamiane przez regułę automatyzacji po rozwiązaniu zgłoszenia. Zdarzenie może być rejestrowane, jeśli działanie automatyzacji zapisuje się w historii zgłoszenia. | ||
|
Dlaczego to ważne
Oznacza początek zbierania opinii. Powiązanie odpowiedzi z ankiet z wariantami procesu może pokazać, jak jego przebieg wpływa na zadowolenie klientów.
Skąd pobrać
Zwykle uruchamia je „Automation Rule”. To, czy będzie widoczne jako osobne zdarzenie w dzienniku aktywności zgłoszenia, zależy od konfiguracji rejestrowania automatyzacji w Freshdesk.
Rejestrowanie
Zdarzenie rejestrowane przez regułę automatyzacji po rozwiązaniu zgłoszenia.
Typ zdarzenia
explicit
|
|||
|
Zmiana priorytetu zgłoszenia
|
Zdarzenie występuje, gdy pracownik lub reguła automatyzacji zmienia priorytet zgłoszenia, na przykład z „Low” na „High”. Zmiana jest jawnie rejestrowana w dzienniku aktywności zgłoszenia. | ||
|
Dlaczego to ważne
Zmiana priorytetu może oznaczać eskalację lub ponowną ocenę pilności sprawy. Analiza takich zmian pomaga ustalić przyczyny eskalacji i ich wpływ na czas rozwiązania zgłoszenia.
Skąd pobrać
Dane pochodzą z dziennika „Ticket Activities”, który rejestruje wszystkie zmiany właściwości zgłoszenia, w tym pola „Priority”.
Rejestrowanie
Zdarzenie jest rejestrowane po zmianie wartości pola „Priority”.
Typ zdarzenia
explicit
|
|||
|
Zmiana statusu na „Pending”
|
To działanie występuje, gdy pracownik czeka na informacje od klienta i zmienia status zgłoszenia na „Pending”. Zdarzenie jest jawnie rejestrowane w historii aktywności jako zmiana statusu. | ||
|
Dlaczego to ważne
Wskazuje okresy, w których proces jest wstrzymany do czasu otrzymania informacji z zewnątrz. Analiza czasu spędzonego w tym statusie pomaga określić opóźnienia po stronie klienta i ocenić zgodność z SLA, ponieważ w tym stanie liczniki SLA często są wstrzymywane.
Skąd pobrać
Dane pochodzą z dziennika „Ticket Activities”, który rejestruje wszystkie zmiany statusu, w tym przejście do „Pending”.
Rejestrowanie
Zdarzenie jest rejestrowane po zmianie pola „Status” zgłoszenia na „Pending”.
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Jak zacząć?
Zacznij usprawniać obsługę klienta, poznając dokładnie przebieg procesów. Ten szablon to pierwszy krok do optymalizacji opartej na danych.
Usprawnij obsługę klienta w Freshdesk
Rozwiązuj 80% zgłoszeń przy pierwszym kontakcie i zadbaj o zadowolenie klientów.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.