Szablon danych do analizy obsługi zgłoszeń serwisowych
Szablon danych do analizy obsługi zgłoszeń serwisowych
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych
Atrybuty obsługi zgłoszeń serwisowych
| 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
|
|||
Działania w procesie obsługi zgłoszeń serwisowych
| 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
|
|||
Instrukcje ekstrakcji danych
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.
Nie trzeba podawać danych karty kredytowej. Konfiguracja zajmuje kilka minut.