Datová šablona pro zákaznický servis

ServiceNow CSM
Datová šablona pro zákaznický servis

Datová šablona pro zákaznický servis

Tato datová šablona vám pomůže připravit informace potřebné k analýze procesu zákaznického servisu. Uvádí důležité datové atributy, činnosti, které je vhodné sledovat, a postup, jak data získat ze zdrojového systému. Využijte ji k přesné a efektivní přípravě dat pro process mining.
  • Doporučené atributy ke sběru
  • Důležité činnosti ke sledování
  • Pokyny k extrakci dat
Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Atributy zákaznického servisu

Toto jsou doporučená datová pole pro záznam událostí, která umožní důkladnou analýzu zákaznického servisu.
3 Povinné 6 Doporučené 9 Volitelné
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 made_sla v tabulce task_sla nebo porovnáním skutečné doby řešení s plánovanou dobou řešení.

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 ReopenCount nebo opakované činnosti.

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 reopen_count v tabulce sn_customerservice_case nebo v související tabulce.

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í (ReassignmentCount je 0), k činnosti „Zahájena interní eskalace“ ani k žádosti o doplnění informací od zákazníka.

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 ReassignmentCount nulový a nedošlo k žádné eskalaci.

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
Povinné Doporučené Volitelné

Činnosti zákaznického servisu

Toto jsou důležité kroky a milníky procesu, které je vhodné zaznamenat do záznamu událostí pro přesné zjištění průběhu procesu.
5 Doporučené 9 Volitelné
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
Doporučené Volitelné

Návody k extrakci dat

Jak získat data ze ServiceNow CSM

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.

Začněte zkušební verzi zdarma

Platební kartu nepotřebujete. Začít můžete během několika minut.