Szablon danych do analizy obsługi zgłoszeń serwisowych

Freshservice
Szablon danych do analizy obsługi zgłoszeń serwisowych

Szablon danych do analizy obsługi zgłoszeń serwisowych

Ten szablon zawiera wskazówki dotyczące gromadzenia danych potrzebnych do analizy procesu obsługi zgłoszeń serwisowych. Opisuje wymagane atrybuty, działania do śledzenia oraz praktyczne sposoby pozyskiwania tych informacji z systemów źródłowych. Skorzystaj z niego, aby przygotować dziennik zdarzeń do szczegółowej analizy procesu.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące ekstrakcji danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty obsługi zgłoszeń serwisowych

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo analizować proces obsługi zgłoszeń serwisowych.
5 Wymagane 5 Zalecane 9 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładny znacznik czasu wystąpienia aktywności.
Opis

Czas zdarzenia określa datę i godzinę zarejestrowania danej aktywności w obsłudze wniosku serwisowego. Ten znacznik czasu pozwala prawidłowo ustalić kolejność zdarzeń i obliczyć odstępy między nimi.

W process mining atrybut ten służy do porządkowania aktywności w ramach każdej sprawy i stanowi podstawę analiz czasowych. Na jego podstawie można obliczać czas realizacji, czas oczekiwania między aktywnościami oraz zgodność z umowami SLA. Dokładne znaczniki czasu pomagają wykrywać wąskie gardła i oceniać wydajność procesu.

Dlaczego to ważne

Ten znacznik czasu porządkuje zdarzenia chronologicznie i stanowi podstawę analiz wydajności, w tym pomiaru czasu realizacji i wykrywania wąskich gardeł.

Skąd pobrać

Odpowiada znacznikowi czasu utworzenia aktywności lub wpisu w dzienniku audytu w Freshservice.

Przykłady
2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
Identyfikator wniosku serwisowego
ServiceRequestId
Unikalny identyfikator każdego wniosku serwisowego.
Opis

Identyfikator wniosku serwisowego to unikalny numer lub kod przypisywany każdemu nowemu wnioskowi zarejestrowanemu w Freshservice. Służy jako klucz główny, który pozwala śledzić cały cykl życia wniosku, od utworzenia do zamknięcia.

W process mining identyfikator ten pełni funkcję Case ID i ma podstawowe znaczenie. Łączy wszystkie powiązane zdarzenia, takie jak zmiany statusu, przypisania agentów i notatki. Analiza przebiegu każdego wniosku serwisowego pozwala zobrazować proces od początku do końca, wskazać typowe ścieżki oraz wykryć odstępstwa i wąskie gardła w poszczególnych sprawach.

Dlaczego to ważne

To podstawowy Case ID, który łączy powiązane zdarzenia i pozwala prześledzić przebieg pojedynczego wniosku serwisowego od początku do końca.

Skąd pobrać

To podstawowe pole obiektu zgłoszenia w Freshservice. Jest widoczne w interfejsie użytkownika i dostępne przez Freshservice API.

Przykłady
SR-12943SR-13501SR-14011
Nazwa aktywności
ActivityName
Nazwa zdarzenia lub zadania, które wystąpiło w określonym momencie obsługi wniosku serwisowego.
Opis

Nazwa aktywności opisuje konkretny krok lub zdarzenie w cyklu życia wniosku serwisowego. Dane o aktywnościach pochodzą z dzienników audytu systemu, zmian statusu lub działań użytkowników, takich jak „Przypisano wniosek do agenta”, „Dodano notatkę” czy „Rozwiązano wniosek serwisowy”.

Ten atrybut służy do budowy mapy procesu, która obrazuje przepływ wniosków serwisowych. Analiza kolejności i częstotliwości aktywności pozwala zrozumieć rzeczywisty przebieg procesu, wykryć wąskie gardła między krokami, zmierzyć czas trwania aktywności oraz znaleźć warianty niezgodne z procedurami lub nieefektywne.

Dlaczego to ważne

Ten atrybut określa kroki widoczne na mapie procesu, dzięki czemu można wizualizować i analizować workflow obsługi wniosków serwisowych.

Skąd pobrać

Dane pochodzą z pól „activities” lub „audits” powiązanych ze zgłoszeniem w Freshservice. Często trzeba przekształcić zdarzenia systemowe w nazwy aktywności zrozumiałe dla biznesu.

Przykłady
Utworzenie zgłoszenia serwisowegoPrzypisanie zgłoszenia do agentaRozwiązanie zgłoszenia serwisowegoZamknięcie zgłoszenia serwisowego
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane z systemu źródłowego zostały ostatnio odświeżone.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji zbioru danych z Freshservice. Informuje, jak aktualne są analizowane dane.

W analizie procesu ważne jest, by wiedzieć, kiedy dane zostały odświeżone. Dzięki temu użytkownicy mogą ocenić, czy pracują na najnowszych informacjach. Ma to znaczenie przy podejmowaniu bieżących decyzji operacyjnych i ocenie wiarygodności wniosków z analizy.

Dlaczego to ważne

Informuje, jak aktualne są dane, dzięki czemu analizy i decyzje można opierać na najnowszych informacjach.

Skąd pobrać

Wartość jest generowana i zapisywana w zbiorze danych podczas ekstrakcji i transformacji danych (ETL).

Przykłady
2024-05-21T02:00:00Z2024-05-20T02:00:00Z
System źródłowy
SourceSystem
Wskazuje system, z którego pobrano dane.
Opis

Ten atrybut wskazuje system źródłowy danych o procesie, w tym przypadku Freshservice. Jest szczególnie przydatny, gdy w celu uzyskania pełnego obrazu procesu łączy się dane z wielu systemów.

Przy analizie danych z jednego systemu może wydawać się zbędny, ale warto go uwzględnić z myślą o przyszłym rozwoju i zarządzaniu danymi. Pozwala ustalić pochodzenie danych i ułatwia zarządzanie przepływami integracyjnymi.

Dlaczego to ważne

Pozwala ustalić pochodzenie danych i prześledzić ich przepływ. Ma to znaczenie przy łączeniu danych z wielu systemów i zarządzaniu danymi.

Skąd pobrać

Zazwyczaj jest to stała wartość dodawana podczas ekstrakcji i transformacji danych (ETL).

Przykłady
FreshserviceFreshservice-API-v2
Priorytet
Priority
Poziom priorytetu wniosku serwisowego, na przykład niski, średni, wysoki lub pilny.
Opis

Priorytet określa wagę i pilność wniosku serwisowego. Często wpływa na docelowy czas rozwiązania sprawy i przydzielane zasoby. Może być ustawiany automatycznie na podstawie reguł lub ręcznie przez agentów.

W process mining priorytet jest ważnym wymiarem analizy. Pozwala podzielić wnioski na grupy i porównać przebieg procesu oraz jego wydajność dla spraw o wysokim i niskim priorytecie. Ma to znaczenie przy analizie zgodności z SLA i ocenie, czy priorytety są ustalane sprawnie, już na etapie wstępnej oceny.

Dlaczego to ważne

Pomaga analizować zgodność z SLA i sprawdzić, czy wnioski są oceniane oraz obsługiwane z uwzględnieniem ich znaczenia dla firmy.

Skąd pobrać

Dostępne jako pole „priority” obiektu zgłoszenia w Freshservice.

Przykłady
NiskiŚredniWysokiPilny
Przypisany agent
AssignedAgent
Imię i nazwisko agenta aktualnie przypisanego do wniosku serwisowego.
Opis

Ten atrybut wskazuje agenta wsparcia odpowiedzialnego za obsługę wniosku serwisowego w danym momencie. W trakcie obsługi wniosku przypisany agent może się zmieniać.

Analiza przypisanych agentów pozwala ocenić ich wydajność i rozkład obciążenia. Umożliwia obliczanie KPI, takich jak średni czas rozwiązania sprawy przez agenta, liczba aktywnych wniosków czy częstotliwość ponownych przypisań. Dzięki temu można wskazać agentów osiągających dobre wyniki, osoby, które mogą potrzebować dodatkowego szkolenia, oraz nierównomierny rozkład pracy.

Dlaczego to ważne

Umożliwia analizę obciążenia i wydajności agentów oraz wpływu ponownych przypisań na czas rozwiązania sprawy.

Skąd pobrać

Dostępne jako pole „agent” lub „responder” obiektu zgłoszenia w Freshservice.

Przykłady
Alice JohnsonRobert SmithNieprzypisane
Przypisany zespół
AssignedTeam
Zespół wsparcia lub grupa przypisana do obsługi wniosku serwisowego.
Opis

Ten atrybut wskazuje grupę lub zespół, na przykład „Wsparcie IT, poziom 2” albo „Zakupy sprzętu”, odpowiedzialny za obsługę wniosku serwisowego. Wniosek może zostać przypisany do zespołu, zanim zajmie się nim konkretny agent.

Analiza według przypisanego zespołu pozwala ocenić wydajność i obciążenie poszczególnych zespołów oraz wykryć wąskie gardła w konkretnych obszarach. Ułatwia też sprawdzenie, jak sprawnie zespoły obsługują wnioski, i lepsze przydzielanie zasobów w dziale wsparcia.

Dlaczego to ważne

Umożliwia analizę wydajności i obciążenia zespołów lub grup. Pomaga zarządzać zasobami i wykrywać wąskie gardła w poszczególnych obszarach.

Skąd pobrać

Dostępne jako pole „group” obiektu zgłoszenia w Freshservice.

Przykłady
Service deskOperacje siecioweWsparcie aplikacji
Rodzaj usługi
ServiceType
Rodzaj lub kategoria usługi, której dotyczy wniosek.
Opis

Rodzaj usługi określa, czego dotyczy wniosek, na przykład „Zamówienie nowego sprzętu”, „Dostęp do oprogramowania” lub „Reset hasła”. Zazwyczaj jest powiązany z pozycją katalogu usług wybraną przez użytkownika.

Ten atrybut pozwala podzielić wnioski serwisowe na grupy i porównać przebieg oraz wydajność procesu dla różnych usług. Ułatwia obliczanie KPI, takich jak „Średnia liczba aktywności dla danego rodzaju usługi”, co pomaga wskazać usługi bardziej złożone lub wymagające większych zasobów. Wyniki analizy mogą pomóc uprościć procesy i zaplanować automatyzację dla wybranych rodzajów usług.

Dlaczego to ważne

Umożliwia porównanie przebiegu i złożoności procesu w różnych kategoriach wniosków oraz wskazanie obszarów, które warto ustandaryzować lub zautomatyzować.

Skąd pobrać

W zależności od konfiguracji odpowiada polu „category”, „item” lub polu niestandardowemu obiektu zgłoszenia w Freshservice.

Przykłady
Wdrożenie nowego pracownikaWniosek o licencję na oprogramowanieDostęp do VPN
Status
Status
Bieżący status wniosku serwisowego w jego cyklu życia.
Opis

Pole statusu określa stan wniosku serwisowego w danym momencie, na przykład „Otwarte”, „Oczekujące”, „Rozwiązane” lub „Zamknięte”. Zmiany statusu są często głównym źródłem aktywności analizowanych w process mining.

Analiza statusu pozwala lepiej zrozumieć przebieg procesu i sprawdzić, ile czasu wnioski pozostają w poszczególnych stanach. Długi czas w statusie „Oczekujące” może na przykład oznaczać, że sprawa czeka na informacje od wnioskodawcy lub zewnętrznego dostawcy. Atrybut ten pomaga określić początek i koniec poszczególnych etapów procesu.

Dlaczego to ważne

Dostarcza kontekstu dla każdego zdarzenia i pozwala mierzyć czas spędzony w poszczególnych stanach, takich jak „Otwarte” lub „Oczekujące”, aby wykrywać opóźnienia.

Skąd pobrać

Dostępne jako pole „status” obiektu zgłoszenia w Freshservice.

Przykłady
OtwarteOczekująceRozwiązaneZamknięte
Czas zakończenia
EndTime
Dokładny znacznik czasu zakończenia aktywności.
Opis

Czas zakończenia to znacznik czasu ukończenia aktywności. Wiele zdarzeń w Freshservice ma taki sam czas rozpoczęcia i zakończenia, ponieważ występują w konkretnym momencie. W przypadku aktywności opartych na statusie czas zakończenia odpowiada znacznikowi czasu kolejnej zmiany statusu.

Atrybut ten pozwala obliczać czas trwania aktywności i czas oczekiwania między nimi. Różnica między StartTime a EndTime pokazuje czas realizacji konkretnego zadania. Dzięki temu można wskazać najbardziej czasochłonne aktywności i te, które warto usprawnić.

Dlaczego to ważne

Pozwala obliczać czas trwania aktywności, co pomaga wykrywać wąskie gardła i mierzyć czas realizacji poszczególnych kroków.

Skąd pobrać

To pole nie występuje bezpośrednio w dziennikach Freshservice. Należy je wyznaczyć na podstawie znacznika czasu kolejnego zdarzenia w sekwencji dla danego wniosku serwisowego.

Przykłady
2023-10-26T10:05:15Z2023-10-26T14:00:20Z2023-10-28T09:30:00Z
Czy naruszono SLA
IsSlaBreached
Wartość logiczna wskazująca, czy przekroczono termin rozwiązania wniosku określony w SLA.
Opis

Ten obliczany atrybut przyjmuje wartość prawda lub fałsz i wskazuje, czy zgłoszenie zamknięto po terminie SLA. Jest wyznaczany przez porównanie znacznika czasu zamknięcia lub rozwiązania wniosku serwisowego z wartością „SlaDueDate”.

Atrybut ten ułatwia analizę i wizualizację zgodności z SLA na dashboardzie. Pozwala łatwo filtrować i agregować wnioski, aby obliczyć ogólny KPI zgodności z SLA. Podział według tego atrybutu pomaga szybko wyodrębnić wnioski, w których naruszono SLA, i porównać ich przebieg z wnioskami rozwiązanymi w terminie.

Dlaczego to ważne

Ułatwia analizę zgodności z SLA, oznaczając wnioski, w których nie dotrzymano wyznaczonych terminów, i pozwalając je filtrować oraz agregować.

Skąd pobrać

Pole obliczane podczas transformacji danych przez porównanie końcowego znacznika czasu rozwiązania z polem „SlaDueDate”.

Przykłady
truefalse
Czy wystąpiły poprawki
IsRework
Wartość logiczna wskazująca, czy wniosek wymagał poprawek.
Opis

Ten obliczany wskaźnik przyjmuje wartość prawda, jeśli w obsłudze wniosku serwisowego wystąpiły zdarzenia wskazujące na konieczność poprawek. Przykłady to ponowne otwarcie po rozwiązaniu („Ponownie otwarto wniosek serwisowy”), wielokrotne przypisania lub ponowne prośby o informacje od użytkownika („Poproszono wnioskodawcę o informacje”).

Atrybut ten ułatwia analizę nieefektywności procesu. Pozwala wyodrębnić sprawy wymagające poprawek i porównać ich mapy procesu oraz czas realizacji ze sprawami bez poprawek. Wspiera dashboard „Analiza poprawek we wnioskach serwisowych” i pomaga oszacować wpływ nieefektywnego przekazywania spraw lub niekompletnych informacji na początku procesu.

Dlaczego to ważne

Ułatwia oznaczanie i analizowanie spraw z nieefektywnymi pętlami lub powtarzającymi się krokami oraz szacowanie kosztów niskiej jakości.

Skąd pobrać

Wartość oblicza się podczas transformacji danych, stosując reguły biznesowe do sekwencji aktywności dla każdego „ServiceRequestId”.

Przykłady
truefalse
Dział wnioskodawcy
RequestorDepartment
Dział, do którego należy wnioskodawca.
Opis

Ten atrybut określa dział organizacyjny użytkownika, który złożył wniosek serwisowy, na przykład sprzedaż, finanse lub dział kadr. Informacje te są zazwyczaj pobierane z profilu użytkownika w systemie.

Analiza wydajności procesu według działu jest częstym wymaganiem. Może pokazać, czy w niektórych działach czas rozwiązania spraw jest dłuższy lub czy mają one szczególne potrzeby. Wnioski z analizy mogą pomóc w przydzielaniu zasobów, planowaniu szkoleń lub tworzeniu usług dopasowanych do potrzeb danego działu.

Dlaczego to ważne

Pozwala analizować proces według jednostki biznesowej i wykrywać problemy lub różnice w wydajności charakterystyczne dla poszczególnych działów.

Skąd pobrać

Informacja jest powiązana z profilem wnioskodawcy. W Freshservice może znajdować się w domyślnym polu „department” lub w niestandardowym polu użytkownika.

Przykłady
FinanseMarketingTechnologia informacyjna
Kanał
Channel
Sposób lub kanał, za pośrednictwem którego złożono wniosek serwisowy.
Opis

Kanał wskazuje, w jaki sposób utworzono wniosek serwisowy, na przykład przez portal samoobsługowy, e-mail, telefon lub czat. Informacja ta pomaga zrozumieć preferencje użytkowników i ocenić skuteczność poszczególnych kanałów.

Analiza procesu według kanału może ujawnić istotne różnice. Wnioski złożone przez portal mogą być na przykład bardziej kompletne i szybciej rozwiązywane niż te przesłane e-mailem, które mogą wymagać dodatkowej wymiany informacji. Wyniki analizy mogą pomóc w promowaniu sprawniejszych kanałów.

Dlaczego to ważne

Pomaga sprawdzić, czy kanał zgłoszenia wpływa na sprawność procesu, czas rozwiązania sprawy lub ilość wymaganych poprawek.

Skąd pobrać

Dostępne jako pole „source” obiektu zgłoszenia w Freshservice.

Przykłady
E-mailPortalTelefonCzat
Liczba ponownych przypisań
ReassignmentCount
Łączna liczba przypisań wniosku serwisowego do innego agenta lub zespołu.
Opis

Ten obliczany atrybut zlicza zdarzenia „Ponownie przypisano wniosek” lub podobne dla każdego wniosku serwisowego. Duża liczba ponownych przypisań często wskazuje na problemy z wstępną oceną, niewłaściwym kierowaniem spraw według kompetencji lub nierównym obciążeniem pracą.

Atrybut ten wspiera dashboard „Wydajność agentów i rozkład obciążenia” oraz KPI „Średnia liczba ponownych przypisań na agenta i wniosek”. Analiza tego wskaźnika pomaga wykryć problemy w procesie, przez które zgłoszenia są wielokrotnie przekazywane między osobami. Wydłuża to czas rozwiązania sprawy i frustruje zarówno agentów, jak i wnioskodawców.

Dlaczego to ważne

Mierzy nieefektywność kierowania spraw i utrudnienia w procesie. Wysoka wartość może wskazywać na problemy ze wstępną oceną lub obciążeniem agentów, które powodują opóźnienia.

Skąd pobrać

Wartość oblicza się podczas transformacji danych, zliczając określone zdarzenia zmiany przypisania dla każdego „ServiceRequestId”.

Przykłady
013
Nazwa polityki SLA
SlaPolicyName
Nazwa polityki Service Level Agreement (SLA) przypisanej do wniosku.
Opis

Ten atrybut wskazuje politykę SLA określającą docelowy czas odpowiedzi i rozwiązania wniosku serwisowego. Polityki są zazwyczaj ustalane na podstawie takich czynników jak priorytet, rodzaj usługi lub grupa wnioskodawcy.

Informacja o przypisanej polityce SLA jest niezbędna do analizy zgodności z SLA i naruszeń na dashboardzie. Pozwala dokładnie mierzyć wyniki względem ustalonych celów i sprawdzić, które polityki są najczęściej naruszane. Może to skłonić do przeglądu wydajności procesu lub realności samych celów SLA.

Dlaczego to ważne

Wskazuje cele obsługi, względem których mierzony jest wniosek. To podstawa rzetelnego raportowania zgodności z SLA.

Skąd pobrać

Informacja ta jest częścią danych SLA powiązanych ze zgłoszeniem. Może wymagać pobrania danych z określonych pól lub punktów końcowych API dotyczących SLA.

Przykłady
Incydenty o wysokim priorytecie, 4 godz.Standardowe wnioski, 3 dniWsparcie VIP, 1 godz.
Termin SLA
SlaDueDate
Termin, do którego zgodnie z SLA wniosek serwisowy powinien zostać rozwiązany.
Opis

Ten atrybut określa termin rozwiązania wniosku serwisowego zgodnie z obowiązującą polityką SLA. Jest to obliczany znacznik czasu, zależny od daty utworzenia wniosku, jego priorytetu i godzin pracy określonych w SLA.

Dane te są niezbędne do monitorowania bieżących wyników i późniejszej analizy zgodności z SLA. Porównanie rzeczywistego czasu rozwiązania z wartością SlaDueDate pozwala ustalić, czy cel został osiągnięty, czy SLA zostało naruszone. Na tej podstawie oblicza się KPI dotyczący poziomu zgodności z SLA.

Dlaczego to ważne

To docelowy termin rozwiązania sprawy. Na jego podstawie można ustalić, czy wniosek serwisowy został obsłużony zgodnie z SLA.

Skąd pobrać

To pole obliczane w Freshservice, widoczne w zgłoszeniu jako „Due by”. Jest dostępne przez API.

Przykłady
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
Wnioskodawca
Requestor
Użytkownik, który złożył wniosek serwisowy.
Opis

Ten atrybut wskazuje osobę, zwykle pracownika, która złożyła wniosek serwisowy. Informuje, kto korzysta z service desk i jakie ma potrzeby.

Wnioskodawca nie zawsze jest głównym wymiarem analizy przebiegu procesu, ale analiza według osoby lub jej działu może ujawnić powtarzające się wzorce. Może na przykład pokazać, że wnioski z konkretnego działu często są niekompletne, co wskazuje na potrzebę dodatkowego szkolenia. Atrybut ten jest też przydatny w analizie doświadczeń użytkowników.

Dlaczego to ważne

Dostarcza informacji o osobie składającej wniosek i pozwala analizować wzorce według użytkownika, działu lub lokalizacji.

Skąd pobrać

Dostępne jako pole „requester” obiektu zgłoszenia w Freshservice.

Przykłady
John DoeJane SmithKonto serwisowe
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi zgłoszeń serwisowych

Poniżej przedstawiono najważniejsze etapy i kamienie milowe procesu, które należy uwzględnić w dzienniku zdarzeń, aby prawidłowo odkrywać i analizować przebieg obsługi zgłoszeń serwisowych.
6 Zalecane 9 Opcjonalne
Działanie Opis
Przekroczenie terminu SLA
Zdarzenie obliczane w chwili, gdy czas rozwiązania zgłoszenia serwisowego przekracza wyznaczony termin SLA. Nie jest to bezpośrednie zdarzenie systemowe. Wynika z porównania czasu rozwiązania z terminem SLA.
Dlaczego to ważne

Zdarzenie to bezpośrednio mierzy realizację zobowiązań dotyczących poziomu usług i stanowi ważny KPI dla kierownictwa. Pomaga wskazać typy zgłoszeń lub priorytety najbardziej narażone na przekroczenie terminu.

Skąd pobrać

Zdarzenie oblicza się przez porównanie znacznika czasu rozwiązania ze znacznikiem „Termin SLA”. Jeśli zgłoszenie rozwiązano później, zdarzenie zostaje zarejestrowane.

Rejestrowanie

Porównaj znacznik czasu rozwiązania ze znacznikiem terminu SLA. Jeśli resolved_at > sla_due_by, utwórz to zdarzenie.

Typ zdarzenia calculated
Przypisanie zgłoszenia do agenta
Oznacza moment przypisania zgłoszenia serwisowego do konkretnego agenta. To ważny etap, który można wykryć, śledząc zmiany pola „Przypisany agent” lub „Właściciel” zgłoszenia.
Dlaczego to ważne

To działanie ma znaczenie przy analizie obciążenia agentów i wykrywaniu wąskich gardeł w procesie przypisywania zgłoszeń. Czas od utworzenia zgłoszenia do jego przypisania jest ważnym wskaźnikiem efektywności.

Skąd pobrać

Działanie wnioskowane na podstawie dziennika aktywności zgłoszenia lub historii audytu pól, przez monitorowanie zmian pola „Agent” lub „Osoba przypisana”.

Rejestrowanie

Zapisz znacznik czasu wypełnienia pola „Przypisany agent” lub zmiany jego wartości.

Typ zdarzenia inferred
Rozwiązanie zgłoszenia serwisowego
Ten ważny etap oznacza moment, w którym agent przedstawił rozwiązanie i uznaje pracę za zakończoną. Można go wywnioskować ze zmiany statusu zgłoszenia na „Rozwiązane”.
Dlaczego to ważne

To działanie oznacza koniec aktywnej pracy nad zgłoszeniem. Czas do tego momentu jest ważną miarą wydajności agenta i procesu, a także podstawą obliczeń SLA.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian statusu zgłoszenia. Odpowiada znacznikowi czasu pierwszego ustawienia statusu „Rozwiązane”.

Rejestrowanie

Zapisz znacznik czasu pierwszej zmiany statusu zgłoszenia na „Rozwiązane”.

Typ zdarzenia inferred
Utworzenie zgłoszenia serwisowego
To działanie rozpoczyna cykl obsługi zgłoszenia serwisowego. Nowe zgłoszenie zostaje zarejestrowane w Freshservice, na przykład przez katalog usług, e-mail lub inny kanał. Zdarzenie jest rejestrowane w chwili utworzenia rekordu zgłoszenia, któremu przypisywany jest unikalny identyfikator.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Pomiar czasu od tego działania do kolejnych etapów pozwala określić całkowity czas obsługi i wykryć początkowe opóźnienia.

Skąd pobrać

To zdarzenie jest jawnie rejestrowane w Freshservice. Można je znaleźć w dzienniku aktywności lub historii audytu zgłoszenia. Zwykle odpowiada znacznikowi czasu utworzenia zgłoszenia.

Rejestrowanie

Użyj znacznika czasu utworzenia zgłoszenia z danych zgłoszeń Freshservice.

Typ zdarzenia explicit
Zaangażowanie zewnętrznego dostawcy
To działanie oznacza przekazanie zgłoszenia zewnętrznemu dostawcy lub innej firmie w celu rozwiązania sprawy. Można je wywnioskować ze zmiany statusu na przykład na „Oczekiwanie na dostawcę” lub „Oczekiwanie na stronę trzecią”.
Dlaczego to ważne

Współpraca z dostawcą może znacznie wydłużyć obsługę. Śledzenie tego działania jest niezbędne do oceny pracy dostawcy i jego wpływu na całkowity czas obsługi zgłoszenia.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian statusu zgłoszenia. Należy znaleźć status skonfigurowany specjalnie do śledzenia zależności od zewnętrznych dostawców.

Rejestrowanie

Wykryj zmianę pola statusu zgłoszenia na wartość oznaczającą oczekiwanie na stronę trzecią.

Typ zdarzenia inferred
Zamknięcie zgłoszenia serwisowego
To ostatnie działanie oznacza koniec cyklu obsługi zgłoszenia serwisowego. Zwykle następuje automatycznie po upływie określonego czasu od ustawienia statusu „Rozwiązane”, jeśli zgłoszenie nie zostało ponownie otwarte.
Dlaczego to ważne

To zdarzenie oznacza definitywny koniec instancji procesu. Czas między statusami „Rozwiązane” i „Zamknięte” to okres, w którym zgłaszający może potwierdzić rozwiązanie.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian statusu zgłoszenia. Odpowiada znacznikowi czasu zmiany statusu na „Zamknięte”.

Rejestrowanie

Zapisz znacznik czasu zmiany statusu zgłoszenia na „Zamknięte”.

Typ zdarzenia inferred
Dodanie notatki
Oznacza każdą publiczną lub prywatną notatkę dodaną do zgłoszenia serwisowego przez agenta lub zgłaszającego. To jawne zdarzenie rejestrowane w historii rozmowy lub dzienniku aktywności zgłoszenia.
Dlaczego to ważne

Analiza częstotliwości i czasu dodawania notatek może ujawnić wzorce komunikacji, sprawność współpracy i miejsca, w których pojawiają się niejasności.

Skąd pobrać

Notatka jest jawnie rejestrowana w historii rozmowy dotyczącej zgłoszenia w Freshservice. Każda notatka ma znacznik czasu i autora.

Rejestrowanie

Wyodrębnij każdy wpis z historii rozmowy lub komentarzy dotyczących zgłoszenia.

Typ zdarzenia explicit
Ponowne otwarcie zgłoszenia serwisowego
To działanie następuje, gdy zgłaszający informuje, że problem nadal występuje po oznaczeniu zgłoszenia jako „Rozwiązane”. Zgłoszenie wraca wtedy do stanu otwartego. Można to wywnioskować ze zmiany statusu z „Rozwiązane” na „Otwarte” lub „W trakcie”.
Dlaczego to ważne

Ponownie otwarte zgłoszenia często wskazują na niski odsetek rozwiązań przy pierwszym kontakcie i niezadowolenie klientów. Śledzenie tych powrotów do wcześniejszych etapów pomaga poprawić jakość rozwiązań.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian statusu zgłoszenia w dzienniku aktywności. Oznacza bezpośrednią zmianę statusu z „Rozwiązane” na „Otwarte”.

Rejestrowanie

Wykryj zmianę statusu ze stanu rozwiązania na stan otwarty.

Typ zdarzenia inferred
Potwierdzenie rozwiązania przez zgłaszającego
To działanie oznacza wyraźne potwierdzenie zgłaszającego, że przedstawione rozwiązanie spełnia jego oczekiwania. Można je wywnioskować z pozytywnej odpowiedzi w ankiecie lub konkretnego komentarza przed zamknięciem zgłoszenia.
Dlaczego to ważne

Potwierdzenie dostarcza bezpośredniej informacji o jakości rozwiązania. Niski odsetek potwierdzeń może oznaczać, że rozwiązania nie odpowiadają w pełni na potrzeby użytkowników, nawet jeśli zgłoszenia nie są ponownie otwierane.

Skąd pobrać

Bezpośrednie rejestrowanie tego działania jest trudne i może wymagać niestandardowej konfiguracji. Można je wywnioskować z odpowiedzi w ankiecie satysfakcji powiązanej ze zgłoszeniem lub z przypisania konkretnego tagu.

Rejestrowanie

Wymaga analizy powiązanych danych, takich jak odpowiedzi w ankietach satysfakcji lub tagi dodane po rozwiązaniu zgłoszenia.

Typ zdarzenia inferred
Prośba o informacje skierowana do zgłaszającego
Oznacza moment, w którym przypisany agent potrzebuje dodatkowych informacji od zgłaszającego i wstrzymuje dalszą obsługę. Można to wywnioskować ze zmiany statusu zgłoszenia na „Oczekujące” lub „Oczekiwanie na klienta”.
Dlaczego to ważne

To działanie wskazuje częste źródło opóźnień i ponownej pracy. Analiza jego częstotliwości pomaga znaleźć możliwości ulepszenia formularzy zgłoszeń i wstępnego zbierania danych.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian statusu zgłoszenia. Należy szukać statusu takiego jak „Oczekiwanie na odpowiedź klienta” lub „Oczekiwanie na informacje”.

Rejestrowanie

Wykryj zmianę pola statusu zgłoszenia na wartość oznaczającą oczekiwanie na informacje od użytkownika.

Typ zdarzenia inferred
Przekazanie informacji przez zgłaszającego
To działanie następuje, gdy zgłaszający przekazuje potrzebne informacje, dzięki czemu agent może wznowić pracę. Zwykle można je wywnioskować ze zmiany statusu zgłoszenia z „Oczekujące” na „Otwarte”.
Dlaczego to ważne

To działanie zamyka etap oczekiwania na informacje. Czas od wysłania prośby do otrzymania odpowiedzi jest ważnym okresem oczekiwania, który warto analizować i skracać.

Skąd pobrać

Działanie wnioskowane na podstawie zmiany statusu z „Oczekujące” na „Otwarte” lub „W trakcie”, często wywołanej odpowiedzią zgłaszającego.

Rejestrowanie

Wykryj zmianę statusu zgłoszenia z oczekującego na otwarty.

Typ zdarzenia inferred
Przeprowadzenie wewnętrznej weryfikacji
Oznacza, że proponowane rozwiązanie lub realizacja zgłoszenia wymaga wewnętrznej weryfikacji albo zatwierdzenia przed dalszymi działaniami. Można to wywnioskować ze zmiany statusu na przykład na „Oczekiwanie na zatwierdzenie” lub „Weryfikacja wewnętrzna”.
Dlaczego to ważne

Wewnętrzne weryfikacje mogą tworzyć wąskie gardła, zwłaszcza w przypadku złożonych zgłoszeń lub spraw o dużym wpływie. Pomiar czasu ich trwania pomaga usprawnić proces zatwierdzania.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian statusu zgłoszenia. Wymaga używania w workflow osobnego statusu, takiego jak „Oczekiwanie na zatwierdzenie wewnętrzne”.

Rejestrowanie

Wykryj zmianę pola statusu zgłoszenia na wartość oznaczającą wewnętrzną weryfikację lub zatwierdzenie.

Typ zdarzenia inferred
Ustalono priorytet zgłoszenia
To działanie następuje, gdy zgłoszeniu serwisowemu zostaje przypisany priorytet, na przykład niski, średni lub wysoki. Można je wykryć na podstawie zmiany pola „Priorytet” w historii zgłoszenia.
Dlaczego to ważne

Ustalanie priorytetów ma zasadnicze znaczenie dla przydziału zasobów i dotrzymywania celów SLA. Analiza tego działania pomaga sprawdzić, czy zgłoszenia są oceniane prawidłowo i na czas.

Skąd pobrać

Działanie wnioskowane na podstawie historii zmian pól zgłoszenia w Freshservice. Należy znaleźć aktualizacje pola „Priorytet” i zapisać znacznik czasu zmiany.

Rejestrowanie

Wykryj zmianę pola „Priorytet” z wartości pustej lub poprzedniej i zapisz znacznik czasu.

Typ zdarzenia inferred
Wstępna ocena zgłoszenia
Oznacza wstępną ocenę i kategoryzację nowego zgłoszenia serwisowego. Działanie to zwykle wnioskuje się na podstawie pierwszego ustawienia priorytetu lub przypisania zgłoszenia do grupy. Oznacza to, że zgłoszenie zostało sprawdzone i trafia do kolejki.
Dlaczego to ważne

Śledzenie wstępnej oceny pozwala mierzyć sprawność zespołu pierwszej linii. Opóźnienia na tym etapie mogą znacznie wydłużyć cały czas obsługi i prowadzić do przekroczeń SLA.

Skąd pobrać

Działanie wnioskowane na podstawie dziennika aktywności. Można je rozpoznać po znaczniku czasu pierwszego zdarzenia „Ustawiono priorytet” lub „Przypisano do grupy” po utworzeniu zgłoszenia.

Rejestrowanie

Wskaż wcześniejszy znacznik czasu zmiany pola priorytetu lub pola grupy przypisania.

Typ zdarzenia inferred
Zmiana przypisania zgłoszenia
To działanie rejestruje każdą zmianę agenta lub grupy przypisanej do zgłoszenia po jego pierwszym przypisaniu. Można je wykryć na podstawie kolejnych aktualizacji pól „Przypisany agent” lub „Przypisana grupa”.
Dlaczego to ważne

Częste zmiany przypisania mogą wskazywać na problemy z wstępną oceną, dopasowaniem kompetencji agentów lub równoważeniem obciążenia. To działanie jest ważne przy obliczaniu KPI liczby zmian przypisania agenta i analizie ponownej pracy.

Skąd pobrać

Zdarzenie wnioskowane na podstawie historii zmian pól zgłoszenia. Jest rejestrowane za każdym razem, gdy po pierwszym ustawieniu zmienia się pole „Przypisany agent” lub „Przypisana grupa”.

Rejestrowanie

Wykryj każdą zmianę pola „Przypisany agent” lub „Przypisana grupa” po pierwszym przypisaniu.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Freshservice

Jak zacząć?

Przygotowanie danych to pierwszy krok do usprawnienia procesu obsługi zgłoszeń serwisowych. Możemy pomóc Państwu usprawnić świadczenie usług.

Usprawnij obsługę zgłoszeń serwisowych w Freshservice

Ogranicz opóźnienia i frustrację użytkowników, osiągnij 70% automatyzacji.

Rozpocznij bezpłatny okres próbny

Nie trzeba podawać danych karty kredytowej. Konfiguracja zajmuje kilka minut.