Datová šablona pro zákaznický servis
Datová šablona pro zákaznický servis
- Doporučené atributy ke sběru
- Důležité činnosti ke sledování
- Pokyny k extrakci dat
Atributy zákaznického servisu
| Název | Popis | ||
|---|---|---|---|
|
Čas události
EventTime
|
Přesné časové razítko určující, kdy došlo ke konkrétní aktivitě nebo události. | ||
|
Popis
Čas události zaznamenává datum a čas provedení aktivity. Toto časové razítko je nezbytné pro chronologické řazení událostí a výpočet doby mezi jednotlivými kroky procesu. V analýze process mining se tento atribut používá k výpočtu všech časových ukazatelů, včetně doby průchodu, čekání a zpracování. Pomáhá odhalit úzká místa tím, že ukáže aktivity, kterým předcházejí dlouhé prodlevy, a umožňuje měřit výkonnost vůči dohodám o úrovni služeb (SLA). Pro spolehlivou analýzu jsou nezbytná přesná a jednotná časová razítka.
Proč je to důležité
Toto časové razítko je důležité pro správné řazení událostí a výpočet všech ukazatelů výkonnosti, například doby průchodu a úzkých míst.
Kde data získat
Obvykle odpovídá poli „sys_created_on“ v auditních a historických tabulkách ServiceNow, například „sys_audit“.
Příklady
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
Servisní požadavek
ServiceRequest
|
Jedinečný identifikátor každého servisního požadavku, případu nebo tiketu zákazníka. | ||
|
Popis
Servisní požadavek je hlavní identifikátor případu, který propojuje všechny související aktivity a události týkající se jednoho problému zákazníka, od vytvoření až po uzavření. Umožňuje sledovat celý průběh zákaznické interakce. V process mining je tento atribut nezbytný pro rekonstrukci toku procesu. Každá jedinečná hodnota servisního požadavku představuje jednu instanci procesu, takže lze analyzovat dobu průchodu, jednotlivé cesty a odchylky pro každý případ. Díky tomu se všechny kroky od prvního kontaktu až po konečné vyřešení a uzavření správně přiřadí ke stejnému zákaznickému požadavku.
Proč je to důležité
Jde o základní ID případu, které propojuje všechny kroky procesu a umožňuje analyzovat celý životní cyklus každé zákaznické interakce se servisní podporou.
Kde data získat
Obvykle jde o pole „number“ v tabulce „sn_customerservice_case“ v ServiceNow CSM.
Příklady
CS0010001CS0010045CS0010112
|
|||
|
Název aktivity
ActivityName
|
Název konkrétní události nebo úkolu, ke kterému došlo během životního cyklu servisního požadavku. | ||
|
Popis
Název aktivity popisuje krok v procesu zákaznické podpory, například „Vytvoření servisního požadavku“, „Přiřazení požadavku pracovníkovi“ nebo „Návrh řešení“. Tyto aktivity se získávají ze systémových protokolů nebo aktualizací tabulek a vytvářejí chronologickou posloupnost událostí pro každý servisní požadavek. Tento atribut je důležitý pro vizualizaci mapy procesu, hledání úzkých míst a pochopení toku práce. Analýza pořadí a četnosti aktivit pomáhá odhalit obvyklé cesty procesem, odchylky i opakovanou nebo neefektivní práci. Podrobnost definovaných aktivit přímo ovlivňuje, jaké poznatky lze z modelu procesu získat.
Proč je to důležité
Tento atribut tvoří základ mapy procesu. Určuje konkrétní kroky a úkoly, jejichž pořadí a dobu trvání analyzujete.
Kde data získat
Jde o koncepční atribut odvozený ze systémových tabulek auditu, například „sys_audit“, nebo ze sledování změn stavů a důležitých polí v tabulce „sn_customerservice_case“.
Příklady
Požadavek na službu vytvořenPožadavek přidělen agentoviVyžádání informací od zákazníkaVyřešení servisního požadavku
|
|||
|
Došlo k porušení SLA
IsSlaBreached
|
Logická hodnota, která určuje, zda požadavek na službu překročil stanovený cíl smlouvy o úrovni služeb (SLA). | ||
|
Popis
Tento vypočítaný atribut určuje, zda byl požadavek na službu vyřešen v dohodnutém termínu. Obvykle má hodnotu „True“, pokud doba řešení překročila cíl SLA, a „False“, pokud jej nepřekročila. U každého případu tak jasně ukazuje, zda byla SLA splněna. Atribut je důležitý pro dashboard „Trendy plnění a porušování SLA“ a KPI „Míra plnění SLA“. Analýzu zjednodušuje přímým filtrováním a počítáním případů s porušenou SLA. Snadno tak zjistíte, které typy požadavků, priority nebo týmy s porušováním SLA nejčastěji souvisejí.
Proč je to důležité
Jednoznačně ukazuje, zda byl termín případu dodržen. To je základ pro měření a vykazování plnění SLA.
Kde data získat
Vypočítává se z pole
Příklady
truefalse
|
|||
|
Kategorie
Category
|
Hlavní klasifikace servisního požadavku, například „Fakturace“ nebo „Technický problém“. | ||
|
Popis
Kategorie sdružuje servisní požadavky podle povahy dotazu nebo problému zákazníka. Obvykle se určuje při vytvoření požadavku a pomáhá předat jej správné skupině přiřazení. Tento atribut je důležitý pro rozdělení analýzy procesu. Filtrováním podle kategorie mohou analytici porovnávat průběh různých typů požadavků. Řešení problému s fakturací se například může výrazně lišit od řešení technického problému. Jde o důležitý atribut pro filtrování dat ve většině dashboardů.
Proč je to důležité
Umožňuje rozdělit analýzu podle typu požadavku a zjistit, zda u některých kategorií častěji dochází k prodlevám, eskalacím nebo nesplnění SLA.
Kde data získat
Odpovídá poli „category“ v tabulce „sn_customerservice_case“.
Příklady
Dotaz / pomocObjednávkyProblémy s produktemFakturace
|
|||
|
Priorita
Priority
|
Úroveň priority servisního požadavku, která určuje jeho naléhavost. | ||
|
Popis
Priorita vyjadřuje důležitost a naléhavost servisního požadavku. Obvykle se určuje podle dopadu požadavku na zákazníka a jeho naléhavosti. Běžné hodnoty sahají od kritické po nízkou. V process mining slouží priorita jako užitečné kritérium pro filtrování a porovnávání. Analytici mohou ověřit, zda se požadavky s vysokou prioritou skutečně zpracovávají rychleji než požadavky s nízkou prioritou, a zjistit, zda se SLA častěji nesplní u některých úrovní priority. Tento atribut je důležitý pro dashboard „Celková doba průchodu servisního požadavku“.
Proč je to důležité
Umožňuje rozdělit servisní požadavky podle naléhavosti a ověřit, zda se kritické problémy řeší rychleji než ostatní.
Kde data získat
Odpovídá poli „priority“ v tabulce „sn_customerservice_case“.
Příklady
1 - Kritická2 - Vysoká3 - Střední4 - Nízká
|
|||
|
Přiřazený pracovník
AssignedAgent
|
Pracovník zákaznické podpory, který má aktuálně na starosti servisní požadavek. | ||
|
Popis
Tento atribut určuje uživatele odpovědného za servisní požadavek v daném okamžiku. Během životního cyklu případu se často mění, když se požadavek předává mezi pracovníky nebo specialisty. Analýza přiřazených pracovníků pomáhá pochopit rozložení pracovní zátěže, výkonnost pracovníků a předávání případů. Odpovídá například na otázky, kdo řeší nejsložitější případy, jak často se případy přeřazují a zda jsou někteří pracovníci spojeni s delší dobou řešení nebo vyšší spokojeností zákazníků. Tento atribut je důležitý pro dashboard „Předávání a přeřazování případů mezi pracovníky“.
Proč je to důležité
Sleduje odpovědnost pracovníků a umožňuje analyzovat pracovní zátěž, výkonnost i četnost přeřazování, které často ukazuje na problémy v procesu.
Kde data získat
Odpovídá poli „assigned_to“ v tabulce „sn_customerservice_case“.
Příklady
Beth AnglinDavid LooAbel Tuter
|
|||
|
Skupina přiřazení
AssignmentGroup
|
Tým nebo oddělení odpovědné za servisní požadavek. | ||
|
Popis
Skupina přiřazení označuje frontu nebo tým, kterému je servisní požadavek přidělen. Podle povahy problému se požadavky často předávají mezi různými skupinami, například podporou první úrovně, specializovaným technickým týmem nebo fakturačním oddělením. Tento atribut je důležitý pro analýzu předávání práce mezi odděleními a hledání úzkých míst na úrovni týmů. Ukazuje, jak práce prochází různými oblastmi, a může odhalit přetížené týmy nebo potřebu dalšího školení. Využívají ho dashboardy „Předávání a přeřazování případů mezi pracovníky“ a „Tok procesu“.
Proč je to důležité
Určuje tým odpovědný za práci. Je důležitý pro analýzu výkonnosti a pracovní zátěže týmů i předávání práce mezi odděleními.
Kde data získat
Odpovídá poli „assignment_group“ v tabulce „sn_customerservice_case“.
Příklady
Servisní podporaDotazy k fakturaciTechnická podpora, druhá úroveň
|
|||
|
Stav
State
|
Aktuální stav servisního požadavku v průběhu jeho životního cyklu. | ||
|
Popis
Atribut Stav popisuje aktuální stav servisního požadavku, například „New“, „In Progress“, „Awaiting Info“, „Resolved“ nebo „Closed“. Změny tohoto pole se často používají k určení aktivit v modelu procesu. Analýza stavu poskytuje přehled o tom, v jaké fázi procesu se případy nacházejí. Pomáhá zjistit, jak dlouho případy setrvávají v určitých stavech, například „Awaiting Info“, který může být významným zdrojem prodlev. Pomáhá také určit začátek a konec důležitých KPI, například „Doba od vyřešení do uzavření“.
Proč je to důležité
Ukazuje stav požadavku v kterémkoli okamžiku a pomáhá zjistit dobu strávenou v neproduktivních stavech, například „On Hold“ nebo „Awaiting Information“.
Kde data získat
Odpovídá poli „state“ v tabulce „sn_customerservice_case“.
Příklady
NovýProbíháČeká se na informace od uživateleVyřešenoUzavřeno
|
|||
|
Došlo k opakovanému zpracování
IsRework
|
Logická hodnota, která určuje, zda došlo k významnému opakovanému zpracování, například k opětovnému otevření případu nebo opakovanému šetření. | ||
|
Popis
Tento vypočítaný atribut označuje případy, u kterých se opakuje neefektivní postup. Může se nastavit například při události „Požadavek na službu znovu otevřen“ nebo pokud se v jednom případu několikrát opakuje důležitá posloupnost činností, například „Pracovník zahájí šetření“ a poté „Navrženo řešení“. Díky tomuto příznaku rychle najdete problematické případy a změříte rozsah opakovaného zpracování v procesu. Podporuje dashboard „Místa s opakovaným zpracováním“ a KPI „Míra opakovaného zpracování“. Analytici se tak mohou zaměřit na příčiny neefektivity, aniž by museli opakující se vzorce hledat ručně.
Proč je to důležité
Pomáhá měřit neefektivitu procesu tím, že označuje případy s opakovanými cykly nebo opětovným otevřením. Opakované zpracování tak lze snadno vyhodnotit a řešit.
Kde data získat
Jde o vypočítaný atribut. Vzniká při transformaci dat na základě obchodní logiky, která rozpoznává opakované zpracování, například nenulovou hodnotu
Příklady
truefalse
|
|||
|
Kód vyřešení
ResolutionCode
|
Kód označující konečný výsledek nebo způsob vyřešení servisního požadavku. | ||
|
Popis
Kód vyřešení je strukturovaná hodnota, kterou pracovník vybere při vyřešení případu. Upřesňuje způsob řešení, například „Vyřešeno uživatelem“, „Známá chyba“, „Duplicitní“ nebo „Není třeba nic dělat“. Tento atribut pomáhá při analýze hlavních příčin. Analýza četnosti jednotlivých kódů vyřešení může odhalit opakující se problémy, nedostatky ve znalostech nebo potíže s produktem. Na základě těchto informací lze zavést zlepšení a snížit počet některých typů servisních požadavků.
Proč je to důležité
Poskytuje přehled o výsledcích servisních požadavků a pomáhá při analýze hlavních příčin i hledání opakujících se problémů.
Kde data získat
Odpovídá poli „close_code“ nebo vlastnímu poli kódu vyřešení v tabulce „sn_customerservice_case“.
Příklady
Vyřešeno (náhradním řešením)Vyřešeno (trvale)Nevyřešeno (zákazník nereaguje)Uzavřeno/vyřešeno volajícím
|
|||
|
Komunikační kanál
Channel
|
Komunikační kanál, kterým byl servisní požadavek podán. | ||
|
Popis
Komunikační kanál označuje způsob, kterým zákazník podal požadavek, například e-mailem, telefonicky, přes webový portál nebo chat. Jednotlivé kanály se mohou výrazně lišit průběhem i očekáváními zákazníků. Analýza procesu podle kanálu pomáhá vyhodnotit účinnost jednotlivých způsobů komunikace. Může například ukázat, zda se požadavky podané telefonicky častěji vyřeší při prvním kontaktu nebo zda e-mailové požadavky mívají delší dobu průchodu. Tento atribut využívá dashboard „Účinnost komunikačních kanálů“.
Proč je to důležité
Pomáhá porovnat efektivitu a výsledky různých kanálů komunikace se zákazníky, například telefonu, e-mailu nebo webového portálu.
Kde data získat
Obvykle odpovídá poli „contact_type“ v tabulce „sn_customerservice_case“.
Příklady
TelefonE-mailSamoobsluhaChat
|
|||
|
Počet opětovných otevření
ReopenCount
|
Počet případů, kdy zákazník znovu otevřel vyřešený servisní požadavek. | ||
|
Popis
Tento čítač sleduje, kolikrát se případ změnil ze stavu „Resolved“ nebo „Closed“ zpět na „In Progress“ nebo „Open“. Opětovné otevření případu může znamenat, že původní řešení nebylo účinné nebo úplné. Tento atribut výrazně vypovídá o opakované práci a kvalitě vyřešení napoprvé. Vysoký počet opětovných otevření ukazuje na problémy při řešení, například na předčasné uzavírání tiketů nebo nedostatečné řešení skutečného problému zákazníka. Jde o důležitý ukazatel účinnosti navržených řešení.
Proč je to důležité
Ukazuje na neúspěšná řešení a opakovanou práci. Vysoký počet opětovných otevření signalizuje nízkou kvalitu řešení a vede k nespokojenosti zákazníků.
Kde data získat
Tento údaj se často ukládá do pole
Příklady
012
|
|||
|
Počet přeřazení
ReassignmentCount
|
Celkový počet případů, kdy byl servisní požadavek přeřazen jinému pracovníkovi nebo skupině. | ||
|
Popis
Tento atribut je čítač, který se zvýší při každé změně pole „assigned_to“ nebo „assignment_group“. Jednoduše měří, kolikrát byl případ interně předán. Počet přeřazení přímo ukazuje na problémy v procesu. Je důležitým vstupem pro dashboard „Předávání a přeřazování případů mezi pracovníky“ a KPI „Průměrný počet předání na požadavek“. Vysoký počet přeřazení často ukazuje na problémy s prvotním směrováním, nedostatečné dovednosti pracovníků nebo obtížnou klasifikaci případů. To vše prodlužuje dobu řešení.
Proč je to důležité
Měří neefektivitu procesu podle počtu předání. Vysoký počet často souvisí s delší dobou řešení a nespokojeností zákazníků.
Kde data získat
Jde o standardní pole metriky „reassignment_count“ v tabulce „task“, kterou rozšiřuje tabulka „sn_customerservice_case“.
Příklady
0135
|
|||
|
Poslední aktualizace dat
LastDataUpdate
|
Časové razítko označující, kdy byla data naposledy získána ze zdrojového systému nebo obnovena. | ||
|
Popis
Tento atribut zaznamenává datum a čas posledního načtení dat. Informuje o aktuálnosti analyzovaných dat, takže uživatelé vědí, zda pracují s informacemi téměř v reálném čase, nebo s historickým snímkem. Při analýze jde o důležitá metadata, která pomáhají určit časové období datové sady. Uživatelé díky nim správně interpretují dashboardy a KPI, například s vědomím, že data zachycují stav k poslední hodině nebo předchozímu dni.
Proč je to důležité
Ukazuje aktuálnost dat, která je důležitá pro relevanci a včasnost poznatků z process mining.
Kde data získat
Toto časové razítko se vytváří a přidává při procesu extrakce, transformace a načítání dat (ETL).
Příklady
2023-11-20T08:00:00Z
|
|||
|
Vyřešeno při prvním kontaktu
IsFirstContactResolution
|
Logická hodnota, která určuje, zda požadavek vyřešil první přidělený pracovník bez předání nebo eskalace. | ||
|
Popis
Tento vypočítaný atribut označuje požadavky na službu vyřešené při prvním kontaktu nebo prvním pracovníkem, který případ řešil. Logika obvykle kontroluje, zda nedošlo k přeřazení ( Atribut přímo měří důležitou metriku zákaznického servisu a podporuje dashboard i KPI „Míra vyřešení při prvním kontaktu“. Umožňuje snadno vyhodnotit FCR a analyzovat faktory, například kanál nebo kategorii požadavku, které pomáhají nebo brání vyřešení při prvním kontaktu.
Proč je to důležité
Přímo měří efektivitu první reakce. Vysoká míra FCR úzce souvisí s efektivitou provozu i spokojeností zákazníků.
Kde data získat
Jde o vypočítaný atribut. Vzniká při transformaci dat podle pravidel, například když je
Příklady
truefalse
|
|||
|
Zákazník
Customer
|
Jméno nebo identifikátor zákazníka či společnosti, která podala servisní požadavek. | ||
|
Popis
Tento atribut určuje externího účastníka, jednotlivce nebo organizaci, pro kterého je servisní požadavek určen. Poskytuje kontext zákazníka pro každý případ. Při analýze umožňuje atribut Zákazník sledovat proces z pohledu zákazníků. Lze zjistit, zda se u některých zákazníků častěji objevují problémy nebo delší prodlevy, a propojit údaje s dalšími informacemi o zákaznících, například o jejich segmentu nebo hodnotě, a určit priority zlepšování procesů. Můžete například ověřit, zda zákazníci s vysokou hodnotou dostávají rychlejší podporu.
Proč je to důležité
Propojuje proces s konkrétními zákazníky a umožňuje analyzovat úroveň služeb a četnost problémů u důležitých zákazníků nebo zákaznických segmentů.
Kde data získat
Může jít o pole „caller_id“, „opened_for“ nebo „account“ v tabulce „sn_customerservice_case“, která odkazují na tabulky uživatelů nebo společností.
Příklady
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
Zdrojový systém
SourceSystem
|
Systém, ze kterého byla data získána. | ||
|
Popis
Tento atribut určuje původ dat, což je důležité zejména v prostředích, kde se informace shromažďují z více systémů. V tomto pohledu na proces bude jeho hodnota vždy „ServiceNow CSM“. Při analýze pomáhá se správou dat a řešením problémů. Pokud se používá více zdrojových systémů, umožňuje filtrovat proces podle konkrétního systému nebo porovnávat jeho průběh v různých systémech.
Proč je to důležité
Uvádí původ dat, zajišťuje přehlednost v prostředí s více systémy a pomáhá se správou dat.
Kde data získat
Jde o statickou hodnotu, která se přidává při transformaci dat a označuje jejich původ.
Příklady
ServiceNow CSM
|
|||
Činnosti zákaznického servisu
| Aktivita | Popis | ||
|---|---|---|---|
|
Požadavek na službu vytvořen
|
Tato činnost označuje začátek procesu zákaznické podpory, kdy se v systému formálně zaznamená nový případ. Událost se zachytí při vložení nového záznamu do tabulky sn_customerservice_case. | ||
|
Proč je to důležité
Jako výchozí bod každého případu je tato činnost nezbytná pro výpočet celkové doby průchodu procesem a analýzu objemu přijatých požadavků. Spouští všechny navazující procesy i měření SLA.
Kde data získat
Tato událost odpovídá vytvoření záznamu v tabulce sn_customerservice_case. Časové razítko se přebírá z pole sys_created_on.
Zachycení
Časové razítko vytvoření záznamu (sys_created_on) v tabulce sn_customerservice_case.
Typ události
explicit
|
|||
|
Požadavek přidělen agentovi
|
K této činnosti dochází, když je požadavek na službu přidělen konkrétnímu agentovi k prověření a vyřešení. Událost se odvozuje ze změny pole assigned_to v záznamu případu. | ||
|
Proč je to důležité
Jde o důležitý milník při měření doby do první reakce a rozložení pracovní zátěže agentů. Sledování opakovaných změn tohoto pole odhalí neefektivitu procesu a možná úzká místa v dostupnosti agentů.
Kde data získat
Odvozuje se z historie auditu (sys_audit) tabulky sn_customerservice_case. Sleduje se vyplnění nebo změna pole assigned_to.
Zachycení
V auditním záznamu případu zachyťte změnu hodnoty pole „assigned_to“.
Typ události
inferred
|
|||
|
Uzavření servisního požadavku
|
Jde o závěrečnou aktivitu, která označuje formální uzavření záznamu servisního požadavku, často až po uplynutí doby na potvrzení po vyřešení. Zaznamená se při změně stavu případu na „Closed“ a vyplnění časového razítka closed_at. | ||
|
Proč je to důležité
Jako definitivní konec procesu je tato aktivita nezbytná pro výpočet celkové doby životního cyklu případu. Analýza doby mezi stavy „Resolved“ a „Closed“ odhalí administrativní zátěž nebo prodlevy.
Kde data získat
Událost lze odvodit z historie změn, když se pole state v tabulce sn_customerservice_case nastaví na „Closed“. Pole closed_at se vyplní ve stejnou dobu.
Zachycení
Zaznamenejte změnu pole „state“ na „Closed“ a použijte odpovídající časové razítko.
Typ události
inferred
|
|||
|
Vyřešení servisního požadavku
|
Tento důležitý milník označuje dokončení práce pracovníka podpory a vyřešení problému. Zaznamená se při změně stavu případu na „Resolved“ a vyplnění časového razítka resolved_at. | ||
|
Proč je to důležité
Tato aktivita ukončuje aktivní řešení případu. Je důležitá pro výpočet doby řešení a plnění SLA a slouží jako hlavní koncový bod řady KPI zaměřených na efektivitu.
Kde data získat
Událost lze odvodit z historie změn, když se pole state v tabulce sn_customerservice_case nastaví na „Resolved“. Pole resolved_at se obvykle vyplní ve stejnou dobu.
Zachycení
Zaznamenejte změnu pole „state“ na „Resolved“ a použijte odpovídající časové razítko.
Typ události
inferred
|
|||
|
Zahájení interní eskalace
|
Označuje formální předání servisního požadavku k vyřešení na vyšší úroveň podpory nebo vedení. Událost lze odvodit ze změny skupiny přiřazení na tým vyšší úrovně nebo z nastavení příznaku eskalace. | ||
|
Proč je to důležité
Sledování eskalací pomáhá odhalit slabá místa procesu, nedostatky ve znalostech podpory první úrovně a složité typy případů. Jde o ukazatel problémů v procesu a nespokojenosti zákazníků.
Kde data získat
Událost lze odvodit z protokolu změn. Sledujte změnu pole „assignment_group“ na známý eskalační tým nebo změnu pole „escalation“ v záznamu případu.
Zachycení
Zaznamenejte změnu pole „escalation“ nebo přeřazení do skupiny „assignment_group“ vyšší úrovně.
Typ události
inferred
|
|||
|
Návrh řešení
|
Tato aktivita označuje okamžik, kdy pracovník najde řešení a sdělí ho zákazníkovi k potvrzení. Lze ji odvodit ze změny stavu na hodnotu jako „Awaiting Acceptance“ nebo z konkrétní poznámky k práci. | ||
|
Proč je to důležité
Tento milník odděluje fázi šetření od fáze potvrzení a vyřešení. Analýza doby čekání na potvrzení zákazníka může odhalit možnosti, jak zkrátit závěrečné kroky případu.
Kde data získat
Událost lze odvodit z protokolu změn tabulky sn_customerservice_case, když se stav změní na hodnotu označující navržené řešení, například „Proposed Solution“. Konkrétní hodnota se může lišit podle nasazení.
Zachycení
Zaznamenejte změnu pole „state“ na hodnotu jako „Proposed Solution“ nebo „Awaiting Acceptance“.
Typ události
inferred
|
|||
|
Nesplnění SLA
|
Označuje okamžik, kdy servisní požadavek nesplní stanovenou dohodu o úrovni služeb, například lhůtu pro vyřešení. Jde o vypočítanou událost, která vznikne porovnáním doby řešení s plánovaným koncem SLA. | ||
|
Proč je to důležité
Odhalování případů, kdy nebylo splněno SLA, je důležité pro sledování shody a řízení výkonnosti. Tato událost pomáhá určit, které fáze procesu nebo typy případů nejvíce přispívají k porušení SLA.
Kde data získat
Událost se vypočítá záznamy v tabulce task_sla souvisejícími s případem. K nesplnění SLA dojde, pokud je pole has_breached nastaveno na true nebo pokud actual_elapsed_time překročí planned_duration.
Zachycení
Zkontrolujte příznak „has_breached“ v propojeném záznamu task_sla.
Typ události
calculated
|
|||
|
Odeslání zákaznického průzkumu
|
Označuje odeslání průzkumu spokojenosti zákazníka po vyřešení případu. Událost se obvykle zaznamená při vytvoření záznamu průzkumu a jeho propojení s případem. | ||
|
Proč je to důležité
Tato aktivita pomáhá porovnat průběh procesu se zpětnou vazbou od zákazníků. Informace o tom, zda a kdy se průzkumy odesílají, jsou důležité pro vyhodnocení účinnosti zpětné vazby.
Kde data získat
Jde o výslovně zaznamenanou událost ve specializované tabulce průzkumů, například asmt_assessment_instance, která obsahuje odkaz na zdrojový záznam případu.
Zachycení
Vytvoření záznamu v tabulce „asmt_assessment_instance“ propojeného s případem.
Typ události
explicit
|
|||
|
Opětovné otevření servisního požadavku
|
K této události dochází, když se dříve vyřešený servisní požadavek vrátí do aktivního stavu, protože se problém opakoval nebo řešení nebylo účinné. Událost lze odvodit ze změny stavu z „Resolved“ zpět na „Work in Progress“. | ||
|
Proč je to důležité
Opětovně otevřené případy přímo vypovídají o kvalitě řešení a jsou hlavním zdrojem opakované práce. Jejich analýza je důležitá pro zvýšení podílu vyřešení při prvním kontaktu i spokojenosti zákazníků.
Kde data získat
Událost lze odvodit z historie změn tabulky sn_customerservice_case. Hledejte posloupnost, ve které se pole state změní z „Resolved“ na aktivní stav.
Zachycení
Zaznamenejte změnu pole „state“ z „Resolved“ na aktivní hodnotu, například „Work in Progress“.
Typ události
inferred
|
|||
|
Požadavek zařazen do kategorie a určena priorita
|
Označuje úvodní třídění, při kterém se požadavek zařadí do kategorie a určí se jeho priorita, naléhavost a způsob směrování. Událost se odvozuje ze změn polí kategorie, podkategorie nebo priority v auditním záznamu případu. | ||
|
Proč je to důležité
Analýza této činnosti pomáhá odhalit zdržení při třídění případů a ověřit, zda se požadavky směrují správně a řeší podle naléhavosti. Ovlivňuje dobu do prvního přidělení i celkovou efektivitu řešení.
Kde data získat
Odvozuje se z historie auditu (sys_audit) tabulky sn_customerservice_case. Sleduje se zejména první vyplnění nebo změna polí kategorie a priority.
Zachycení
Zachyťte první nastavení hodnoty nebo její změnu v polích „category“ či „priority“.
Typ události
inferred
|
|||
|
Pracovník zahájí šetření
|
Tato aktivita označuje okamžik, kdy pracovník začne aktivně řešit servisní požadavek. Obvykle ji lze odvodit ze změny stavu případu z hodnoty jako „New“ nebo „Assigned“ na „Work in Progress“. | ||
|
Proč je to důležité
Tato událost odděluje dobu čekání ve frontě od aktivní práce. Analýza doby mezi přiřazením případu a zahájením šetření odhalí prodlevy, než se pracovníci začnou novým případům věnovat.
Kde data získat
Událost lze odvodit ze změny pole stavu případu na hodnotu označující aktivní práci, například „Work in Progress“. Konkrétní hodnoty stavů lze nastavit a je třeba je ověřit.
Zachycení
Zaznamenejte změnu pole „state“ z čekající hodnoty na aktivní, například z „New“ na „Work in Progress“.
Typ události
inferred
|
|||
|
Přijetí informací od zákazníka
|
Tato aktivita označuje okamžik, kdy zákazník poskytne požadované informace a pracovník může pokračovat v práci. Lze ji odvodit ze změny stavu případu z „Awaiting User Info“ zpět na aktivní stav. | ||
|
Proč je to důležité
Tato událost ukončuje dobu čekání na zákazníka a umožňuje přesně měřit dobu jeho odezvy. Pomáhá zjistit, které typy případů nebo zákazníci jsou spojeni s nejdelšími prodlevami.
Kde data získat
Událost lze odvodit z historie změn tabulky sn_customerservice_case, když se pole state změní ze stavu „Awaiting Info“ zpět na aktivní hodnotu, například „Work in Progress“.
Zachycení
Zaznamenejte změnu pole „state“ z hodnoty označující čekání na zákazníka zpět na aktivní hodnotu.
Typ události
inferred
|
|||
|
Skupina pro přidělování změněna
|
Označuje předání odpovědnosti za případ z jednoho týmu do druhého. Událost se odvozuje ze sledování změn pole assignment_group v záznamu případu. | ||
|
Proč je to důležité
Sledování změn skupin pro přidělování je důležité pro analýzu předávání mezi odděleními a odhalení systémových problémů se směrováním. Časté změny mohou ukazovat na nejasnou odpovědnost nebo nedostatečně popsané procesy.
Kde data získat
Odvozuje se z historie auditu (sys_audit) tabulky sn_customerservice_case sledováním změn pole assignment_group.
Zachycení
V auditním záznamu případu zachyťte změnu hodnoty pole „assignment_group“.
Typ události
inferred
|
|||
|
Vyžádání informací od zákazníka
|
K této události dochází, když pracovník potřebuje od zákazníka další informace, aby mohl pokračovat, a nastaví případ do čekajícího stavu. Událost lze odvodit ze změny stavu na hodnotu jako „Awaiting User Info“ nebo „On Hold“. | ||
|
Proč je to důležité
Tato aktivita je důležitá pro analýzu „Doby čekání na informace od zákazníka“. Odděluje prodlevy způsobené vnějšími závislostmi od času potřebného na interní zpracování.
Kde data získat
Událost lze odvodit z historie změn tabulky sn_customerservice_case, když se pole state změní na hodnotu označující čekání na informace od zákazníka, například „Awaiting Info“.
Zachycení
Zaznamenejte změnu pole „state“ na určenou hodnotu označující čekání na zákazníka.
Typ události
inferred
|
|||
Návody k extrakci dat
Chcete začít?
Pomocí této šablony připravíte data a zjistíte, kde lze zákaznický servis zlepšit. Začněte pracovat na efektivnějším procesu, který lépe odpovídá potřebám zákazníků.
Zlepšete efektivitu zákaznického servisu
Zvyšte spokojenost zákazníků a dosáhněte 80% míry vyřešení při prvním kontaktu.
Platební kartu nepotřebujete. Začít můžete během několika minut.