Šablona dat zákaznického servisu
Šablona dat zákaznického servisu
- Doporučené atributy ke shromáždění
- Hlavní aktivity ke sledování
- Pokyny k extrakci dat ze systému Microsoft Dynamics 365 Customer Service
Atributy zákaznického servisu
| Název | Popis | ||
|---|---|---|---|
|
Požadavek na službu
ServiceRequest
|
Jedinečný identifikátor požadavku zákazníka na službu, označovaného také jako případ nebo požadavek. | ||
|
Popis
Service Request slouží jako hlavní identifikátor, který propojuje všechny aktivity související s jedním zákaznickým dotazem nebo problémem. V process mining funguje jako ID případu a zajišťuje úplný a jednotný přehled o každé interakci od vytvoření po uzavření. Analýza podle Service Request umožňuje sledovat celý průběh, měřit dobu řešení a hledat vzorce napříč podobnými případy.
Proč je to důležité
Jde o hlavní ID případu, které propojuje všechny související události do jedné instance procesu a umožňuje tak analýzu od začátku do konce.
Kde data získat
Jde o primární klíč entity Case (incident) v Microsoft Dynamics 365 Customer Service.
Příklady
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Aktivita
ActivityName
|
Název konkrétní obchodní události, ke které v určitém okamžiku došlo v rámci požadavku na službu. | ||
|
Popis
Tento atribut popisuje jednotlivý krok nebo změnu stavu v procesu zákaznické podpory, například 'Případ vytvořen', 'Pracovník podpory prošetřil problém' nebo 'Případ vyřešen'. Aktivity tvoří základ procesní mapy a umožňují znázornit a analyzovat průběh procesu. Každá aktivita spolu s časovým razítkem představuje událost, která určuje pořadí kroků v procesu.
Proč je to důležité
Aktivity určují jednotlivé kroky procesu. Analýza jejich pořadí a četnosti je základem pro pochopení průběhu procesu, odhalení odchylek a nalezení úzkých míst.
Kde data získat
Obvykle se odvozuje mapováním změn stavu (statuscode) nebo konkrétních událostí ze souvisejících entit, například Tasks, Emails nebo Phone Calls, na standardizovaný název aktivity.
Příklady
Případ vytvořenPracovník podpory prošetřil problémZákazníkovi navrženo řešeníPřípad uzavřen
|
|||
|
Čas zahájení
EventTime
|
Časové razítko označující, kdy k aktivitě došlo. | ||
|
Popis
Tento atribut zaznamenává přesné datum a čas konkrétní aktivity. Je nezbytný pro správné seřazení událostí i pro veškeré časové analýzy, včetně výpočtu doby cyklu, trvání a čekání mezi aktivitami. Přesné a jednotné časové razítko je zásadní pro spolehlivou analýzu process mining.
Proč je to důležité
Časové razítko řadí události chronologicky a umožňuje výpočty dob trvání, které jsou důležité pro analýzu výkonnosti a hledání úzkých míst.
Kde data získat
Odpovídá polím, jako jsou 'createdon' nebo 'modifiedon', v entitě Case (incident) nebo souvisejících entitách aktivit, například Email, Task nebo Phone Call.
Příklady
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Poslední aktualizace dat
LastDataUpdate
|
Časové razítko poslední aktualizace nebo extrakce dat ze zdrojového systému. | ||
|
Popis
Tento atribut uvádí, kdy byla data naposledy načtena z Microsoft Dynamics 365. Pomáhá posoudit jejich aktuálnost a je důležitý pro reporting a monitorování. Uživatelé tak při interpretaci dashboardů a analýz vědí, jak stará data jsou.
Proč je to důležité
Informuje uživatele o aktuálnosti dat, která je důležitá pro včasná a přesná obchodní rozhodnutí založená na analýze procesu.
Kde data získat
Tato hodnota se vygeneruje a zapíše do datové sady při extrakci dat.
Příklady
2023-10-27T08:00:00Z
|
|||
|
Zdrojový systém
SourceSystem
|
Určuje zdrojový systém, ze kterého byla data extrahována. | ||
|
Popis
Tento atribut určuje původ dat událostí. V tomto procesu bude jako zdroj vždy označen Microsoft Dynamics 365 Customer Service. V prostředí s více systémy je toto pole důležité pro rozlišení zdrojů dat a zajištění jejich původu.
Proč je to důležité
Poskytuje přehled o původu dat, který je důležitý pro správu dat i řešení nesrovnalostí, zejména při analýze dat z více systémů.
Kde data získat
Obvykle jde o statickou hodnotu, která se přidává při extrakci a transformaci dat a označuje původ datové sady.
Příklady
Microsoft Dynamics 365 Customer Service
|
|||
|
Cílová doba řešení podle SLA
SlaTargetResolutionTime
|
Cílová doba pro vyřešení požadavku na službu sjednaná ve smlouvě. | ||
|
Popis
Tento atribut určuje cílovou dobu, během které má být požadavek na službu vyřešen podle platné dohody o úrovni služeb (SLA). Slouží jako měřítko pro porovnání skutečného výkonu. Je důležitý pro dashboard sledování dodržování SLA a výpočet KPI míry dodržování SLA. Ukazuje, kde proces neplní závazky vůči zákazníkům.
Proč je to důležité
Jde o hlavní měřítko plnění závazků v oblasti služeb. Umožňuje přímo analyzovat dodržování SLA a jeho porušení.
Kde data získat
Tato hodnota vychází z konfigurace SLA v Dynamics 365 a k případu se přiřazuje prostřednictvím instancí SLA KPI.
Příklady
2592008640014400
|
|||
|
Důvod stavu
StatusReason
|
Uvádí podrobnější důvod aktuálního stavu požadavku na službu. | ||
|
Popis
Případ může mít obecný stav, například 'Active' nebo 'Resolved'. Důvod stavu poskytuje konkrétnější informace, například 'Information Provided' nebo 'Problem Solved'. Tento atribut pomáhá pochopit, jak a proč případy postupují jednotlivými fázemi. Rozlišuje například úspěšně vyřešené případy od případů zrušených zákazníkem, což je důležité pro přesnou analýzu výsledků.
Proč je to důležité
Poskytuje podrobnější přehled o výsledku případu a důvodech změn jeho stavu. Umožňuje přesněji analyzovat způsoby řešení i příčiny problémů.
Kde data získat
Odpovídá poli 'Status Reason' (statuscode) entity Case (incident).
Příklady
ProbíháPozastavenoProblém vyřešenInformace poskytnuty
|
|||
|
Jméno pracovníka podpory
AgentName
|
Jméno pracovníka zákaznické podpory nebo uživatele odpovědného za aktivitu. | ||
|
Popis
Tento atribut určuje konkrétního pracovníka podpory nebo systémového uživatele, který provedl aktivitu, například převzal položku z fronty nebo vyřešil případ. Je důležitý pro analýzu výkonu pracovníků, rozložení pracovní zátěže a přidělování zdrojů. Sledování aktivit na úrovni jednotlivých pracovníků pomáhá odhalit nejlepší výsledky, potřeby školení i nerovnoměrné rozložení práce.
Proč je to důležité
Umožňuje analyzovat výkon jednotlivců i týmů, pomáhá vyvažovat pracovní zátěž a odhalovat příležitosti ke koučování, které mohou zlepšit kvalitu služeb.
Kde data získat
Odpovídá poli 'Owner' (ownerid) entity Case (incident), které odkazuje na entitu System User (systemuser).
Příklady
Alice SmithBob JohnsonSystém
|
|||
|
Jméno zákazníka
CustomerName
|
Jméno zákazníka nebo účtu spojeného s požadavkem na službu. | ||
|
Popis
Tento atribut určuje zákazníka, který požadavek na službu zadal. Umožňuje analyzovat proces z pohledu zákazníka a zjistit, kdo zadává nejvíce požadavků, kdo čeká na řešení nejdéle nebo kdo má nejsložitější problémy. Tyto informace jsou důležité pro správu vztahů se zákazníky a zlepšování služeb pro jednotlivé zákazníky.
Proč je to důležité
Umožňuje analýzu na úrovni zákazníků, odhalení vzorců, zlepšení služeb pro důležité účty a pochopení zákaznické cesty.
Kde data získat
Jde o vyhledávací pole 'Customer' (customerid) entity Case (incident), které může odkazovat na záznam Account nebo Contact.
Příklady
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Kanál
Channel
|
Komunikační kanál, kterým byl požadavek na službu zadán. | ||
|
Popis
Tento atribut určuje původ zákaznické interakce, například telefon, e-mail, webový portál nebo chat. Jednotlivé kanály se často liší průběhem procesu, očekáváními zákazníků i složitostí řešení. Analýza podle kanálu pomáhá upravit workflow a přidělování zdrojů pro každý kanál.
Proč je to důležité
Ukazuje, jak různé kanály kontaktu se zákazníky ovlivňují efektivitu procesu, dobu řešení a spokojenost zákazníků.
Kde data získat
Odpovídá poli 'Case Origin' (caseorigincode) entity Case (incident).
Příklady
TelefonE-mailWebChat
|
|||
|
Priorita
Priority
|
Úroveň priority přiřazená požadavku na službu, která určuje jeho naléhavost. | ||
|
Popis
Tento atribut určuje naléhavost požadavku na službu, obvykle jako nízkou, běžnou, vysokou nebo urgentní. Podle priority se stanovuje pořadí vyřizování případů a často také cíle SLA. Analýza vlivu priority na průběh procesu, přidělování zdrojů a dobu řešení pomáhá zajistit, aby se naléhavé problémy řešily včas.
Proč je to důležité
Pomáhá zjistit, zda se požadavky s vysokou prioritou vyřizují rychleji a plní stanovené cíle a jak úrovně priority ovlivňují celkovou výkonnost procesu.
Kde data získat
Odpovídá poli 'Priority' (prioritycode) entity Case (incident).
Příklady
NízkáBěžnáVysoká
|
|||
|
Typ požadavku na službu
ServiceRequestType
|
Hlavní kategorie nebo klasifikace požadavku na službu. | ||
|
Popis
Tento atribut zařazuje požadavek na službu podle jeho povahy, například jako 'Dotaz k fakturaci', 'Technická podpora' nebo 'Zpětná vazba k produktu'. Umožňuje rozdělit analýzu procesu a zjistit, jak se vyřizují různé typy požadavků. Analýza podle typu může ukázat, že některé kategorie mají delší dobu řešení, častěji se eskalují nebo procházejí jinou cestou procesem.
Proč je to důležité
Umožňuje rozdělit proces podle typu požadavku a odhalit úzká místa, potřeby zdrojů i příležitosti ke zlepšení. Pomáhá také lépe nastavit směrování a vyřizování požadavků.
Kde data získat
Tyto informace se často ukládají do pole 'Subject' (subjectid) nebo do vlastního pole kategorie entity Case (incident).
Příklady
Dotaz k fakturaciTechnická podporaZpětná vazba k produktuSpráva účtu
|
|||
|
Byla překročena SLA
IsSlaBreached
|
Vypočítaný příznak označující, zda požadavek na službu překročil cílovou hodnotu SLA. | ||
|
Popis
Tento booleovský příznak se určuje porovnáním skutečné doby vyřešení požadavku na službu s hodnotou „SLA Target Resolution Time“. Nastaví se na true, pokud skutečná doba překročí cílovou hodnotu. Atribut je základem dashboardu Sledování plnění SLA a výpočtu KPI Míra plnění SLA. U každého případu jasně ukazuje, zda byla SLA splněna.
Proč je to důležité
U každého případu jednoznačně ukazuje, zda byla SLA splněna. Usnadňuje filtrování, agregaci a analýzu příčin překročení SLA.
Kde data získat
Vypočítá se porovnáním hodnot „ServiceRequestCycleTime“ a „SlaTargetResolutionTime“.
Příklady
truefalse
|
|||
|
Hodnocení CSAT
CustomerSatisfactionScore
|
Hodnocení spokojenosti, které zákazník udělí po vyřešení případu. | ||
|
Popis
Tento atribut obsahuje číselné nebo slovní hodnocení z průzkumu spokojenosti zákazníků (CSAT), který se obvykle provádí po uzavření požadavku na službu. Přímo vyjadřuje, jak zákazník vnímá kvalitu služeb. Tyto údaje jsou důležité pro dashboard Vývoj spokojenosti zákazníků a KPI Průměrné hodnocení CSAT po vyřešení. Propojují výkonnost procesu s výsledky pro zákazníky.
Proč je to důležité
Přímo měří spokojenost zákazníků a umožňuje organizaci porovnat průběh procesu s jejich názory a podle toho provádět zlepšení.
Kde data získat
Údaje obvykle pocházejí ze související entity průzkumu, například Customer Voice, a jsou propojené s entitou Case (incident).
Příklady
5341
|
|||
|
ID článku znalostní báze
KnowledgeArticleId
|
Identifikátor článku znalostní báze propojeného s požadavkem na službu. | ||
|
Popis
Tento atribut obsahuje ID článku znalostní báze, který byl použit nebo propojen při řešení požadavku na službu. Ukazuje, jak efektivně pracovníci podpory využívají znalostní bázi při řešení zákaznických problémů. Tyto údaje jsou důležité pro dashboard Využití článků znalostní báze a související KPI. Pomáhají posoudit přínos a úplnost znalostní báze.
Proč je to důležité
Sleduje využívání znalostní báze a pomáhá zjistit, zda pracovníci podpory využívají dostupné zdroje k rychlejšímu a jednotnějšímu řešení problémů.
Kde data získat
Tyto údaje najdete ve vztahu mezi entitami Case (incident) a Knowledge Article (knowledgearticle).
Příklady
KA-01337KA-02048
|
|||
|
Je eskalován
IsEscalated
|
Příznak označující, zda byl požadavek na službu eskalován. | ||
|
Popis
Tento booleovský atribut označuje, zda byl požadavek na službu eskalován. K eskalaci dochází, když podpora první úrovně nedokáže problém vyřešit a je nutný zásah zkušenějšího týmu nebo specialisty. Sledování tohoto příznaku je důležité pro dashboard Cesty interní eskalace a KPI Míra interních eskalací. Pomáhá odhalit příčiny eskalací i slabá místa v počátečních úrovních podpory.
Proč je to důležité
Přímo měří četnost eskalací. Upozorňuje na problémy s vyřešením při prvním kontaktu a ukazuje, kde je potřeba zlepšit proces nebo dovednosti pracovníků podpory.
Kde data získat
Odpovídá poli „Is Escalated“ (isescalated) v entitě Case (incident).
Příklady
truefalse
|
|||
|
Odpovědný tým
OwnerTeam
|
Tým, který aktuálně odpovídá za požadavek na službu. | ||
|
Popis
Tento atribut určuje tým odpovědný za požadavek na službu. Požadavek může mít na starosti konkrétní pracovník podpory nebo tým (fronta). Analýza podle týmů je důležitá pro pochopení jejich výkonnosti, rozložení pracovní zátěže mezi úrovněmi podpory či specializacemi a rozdílů v postupech jednotlivých týmů.
Proč je to důležité
Umožňuje analyzovat výkonnost jednotlivých týmů, což je důležité pro efektivní řízení úrovní podpory a specializovaných skupin.
Kde data získat
Odvozuje se z pole „Owner“ (ownerid) v entitě Case (incident), pokud je vlastníkem záznam Team, nikoli System User.
Příklady
Podpora 1. úrovněFakturační odděleníTechničtí specialisté
|
|||
|
Opakované zpracování
IsRework
|
Vypočítaný příznak označující, zda případ zahrnoval opakované zpracování. | ||
|
Popis
Tento booleovský příznak označuje případy s opakovanými kroky nebo návraty v procesu, například s několika událostmi „Vyžádání informací od zákazníka“ nebo s událostí „Případ znovu otevřen“ po vyřešení. Vypočítá se analýzou pořadí aktivit, které mohou ukazovat na neefektivitu nebo na to, že problém nebyl vyřešen správně napoprvé. Atribut je důležitý pro dashboard Analýza opakovaného zpracování a opakovaných kontaktů.
Proč je to důležité
Pomáhá vyčíslit a určit neefektivní části procesu, aby se analytici mohli zaměřit na příčiny opakované práce a zbytečného úsilí.
Kde data získat
Vypočítá se pomocí process mining, který odhaluje konkrétní posloupnosti aktivit (například Vyřešeno → Znovu otevřeno) nebo opakované aktivity v rámci případu.
Příklady
truefalse
|
|||
|
Produkt, kterého se případ týká
ProductInvolved
|
Produkt spojený s požadavkem zákazníka na službu. | ||
|
Popis
Tento atribut určuje konkrétní produkt nebo službu, které se zákaznický problém týká. Umožňuje analyzovat proces podpory podle produktů a zjistit, zda některé produkty vedou k většímu počtu požadavků, složitějším problémům nebo potřebě specializovaných dovedností pracovníků podpory. Analýza pomáhá zlepšovat produkty a plánovat zdroje.
Proč je to důležité
Umožňuje analyzovat proces podle produktů, odhalovat opakující se problémy, zlepšovat dokumentaci podpory a účelně přidělovat odborné zdroje.
Kde data získat
Odpovídá vyhledávacímu poli „Product“ (productid) v entitě Case (incident).
Příklady
Tiskárna Alpha-100Software CRM ZetaDatový tarif Omega
|
|||
|
Vyřešeno při prvním kontaktu
IsFirstContactResolution
|
Příznak označující, zda byl požadavek vyřešen při prvním kontaktu. | ||
|
Popis
Tento vypočítaný atribut označuje požadavky na službu vyřešené bez dalších kontaktů se zákazníkem nebo výrazných prodlev, které by vyžadovaly předání jinému pracovníkovi podpory. Přesná logika se může lišit, obvykle však zahrnuje krátkou dobu řešení a žádné opětovné otevření případu ani následné dotazy zákazníka po prvním kontaktu. Atribut slouží jako základ pro KPI Míra vyřešení při prvním kontaktu.
Proč je to důležité
Jde o důležitý ukazatel efektivity služeb a spokojenosti zákazníků. Ukazuje, zda organizace dokáže problémy rychle a úplně vyřešit.
Kde data získat
Vypočítá se podle pořadí a časů aktivit v záznamu událostí každého případu.
Příklady
truefalse
|
|||
Aktivity zákaznického servisu
| Aktivita | Popis | ||
|---|---|---|---|
|
Případ eskalován
|
Označuje formální předání případu podpoře vyšší úrovně nebo jinému týmu. Může jít o výslovnou akci uživatele, který případ přiřadí určené eskalační frontě nebo uživateli. | ||
|
Proč je to důležité
Sledování eskalací je důležité pro KPI 'Internal Escalation Rate' i pro hledání příčin problémů, které podpora první linie nedokáže vyřešit. Odhaluje slabá místa procesu a příležitosti ke školení.
Kde data získat
Aktivitu lze odvodit ze změny pole 'ownerid' na určenou eskalační frontu nebo tým. Může ji také zaznamenat vlastní akce, která případ označí jako eskalovaný.
Zachycení
Určete změnu pole 'ownerid' na známou eskalační frontu včetně časového razítka.
Typ události
inferred
|
|||
|
Případ přiřazen
|
Tato aktivita označuje přiřazení případu konkrétní frontě nebo uživateli k vyřízení. Systém výslovně zaznamenává změny vlastníka případu, které lze sledovat v protokolech auditu. | ||
|
Proč je to důležité
Sledování přiřazení je důležité pro analýzu rozložení pracovní zátěže, odhalení zpoždění při přiřazování a posouzení efektivity směrování. Pomáhá zjistit, jak rychle se případy dostanou ke správnému týmu nebo pracovníkovi.
Kde data získat
Zaznamenává se sledováním změn pole 'ownerid' entity 'Incident'. Časové razítko změny je dostupné v protokolech historie auditu.
Zachycení
Z protokolů auditu extrahujte změny pole 'ownerid' včetně časových razítek.
Typ události
explicit
|
|||
|
Případ uzavřen
|
Jde o konečné administrativní uzavření záznamu případu, ke kterému může dojít současně s vyřešením nebo později. Aktivita se zaznamenává změnou stavu případu na 'Closed'. | ||
|
Proč je to důležité
Tato událost označuje úplný konec životního cyklu procesu v systému. Doba mezi stavy 'Resolved' a 'Closed' může ukazovat na administrativní zátěž nebo zpoždění při dokončování záznamů.
Kde data získat
Událost se zaznamenává změnou pole 'statecode' entity 'Incident' na 'Canceled' (2) nebo na vlastní stav uzavření. Časové razítko je dostupné v historii auditu.
Zachycení
Sledujte časové razítko změny 'statecode' na konečný stav (například Canceled/Closed).
Typ události
explicit
|
|||
|
Případ vyřešen
|
Tento důležitý milník označuje okamžik, kdy pracovník podpory považuje zákazníkův problém za vyřešený. Jde o výslovnou akci v Dynamics 365, při které se vytvoří aktivita 'Case Resolution' propojená s případem. | ||
|
Proč je to důležité
Jako hlavní koncová událost úspěšného vyřízení je tato aktivita nezbytná pro výpočet doby řešení a míry úspěšnosti. Patří k základním údajům téměř každého KPI zákaznické podpory.
Kde data získat
Tato událost odpovídá vytvoření aktivity 'Resolution' (Case Resolution). Časové razítko 'actualend' tohoto záznamu označuje okamžik vyřešení.
Zachycení
Použijte časové razítko 'actualend' nebo 'createdon' souvisejícího záznamu aktivity 'Resolution'.
Typ události
explicit
|
|||
|
Případ vytvořen
|
Tato aktivita označuje začátek procesu zákaznické podpory, kdy se v systému vytvoří nový záznam případu. Jde o výslovně zaznamenanou událost s časovým razítkem, které se uloží při prvním uložení záznamu entity 'Incident'. | ||
|
Proč je to důležité
Jako hlavní počáteční událost je tato aktivita nezbytná pro výpočet celkové doby životního cyklu případu a sledování vývoje počtu případů. Slouží jako výchozí bod pro veškerou další analýzu procesu.
Kde data získat
Událost se zaznamenává podle časového razítka 'createdon' u entity 'Incident' (Case) pro každý nový záznam.
Zachycení
Použijte časové razítko 'createdon' záznamu Incident.
Typ události
explicit
|
|||
|
Spuštěn časovač SLA
|
Označuje spuštění časovače dohody o úrovni služeb (SLA) pro případ. Časovač sleduje plnění stanovené metriky služby, například 'First Response By' nebo 'Resolve By'. Jde o výslovnou událost spravovanou modulem SLA v Dynamics 365. | ||
|
Proč je to důležité
Tato aktivita je zásadní pro sledování dodržování SLA a určení okamžiku, od kterého se počítá lhůta pro splnění závazku vůči zákazníkovi. Umožňuje přímo analyzovat, zda se daří plnit cíle služeb.
Kde data získat
Událost se zaznamenává v entitě 'SLA KPI Instance', která souvisí s entitou 'Incident'. Začátek označuje časové razítko 'createdon' příslušného záznamu SLA KPI Instance.
Zachycení
Použijte časové razítko vytvoření záznamu 'SLA KPI Instance' přiřazeného k případu.
Typ události
explicit
|
|||
|
Odeslán průzkum spokojenosti
|
Označuje odeslání průzkumu spokojenosti zákazníka, který se obvykle automaticky spustí po vyřešení případu. Událost se zpravidla zaznamená jako odchozí e-mail nebo aktivita průzkumu Customer Voice. | ||
|
Proč je to důležité
Tato aktivita propojuje provozní proces s výsledky zákaznické zkušenosti. Umožňuje analyzovat skóre spokojenosti v kontextu cesty, kterou případ prošel.
Kde data získat
Aktivitu lze odvodit z vytvoření odchozí aktivity 'Email' s odkazem na průzkum nebo ze záznamu aktivity 'Customer Voice survey invite' souvisejícího s případem.
Zachycení
Použijte časové razítko vytvoření aktivity související s průzkumem.
Typ události
inferred
|
|||
|
Pracovník podpory převzal položku z fronty
|
K této události dojde, když pracovník podpory aktivně převezme případ ze sdílené fronty a začne ho vyřizovat. Jde o záměrnou akci uživatele, která se liší od systémového přiřazení případu do fronty. | ||
|
Proč je to důležité
Tato aktivita pomáhá měřit, jak dlouho případ čeká ve frontě, než na něm pracovník podpory začne pracovat. Je důležitá pro odhalení úzkých míst ve frontě a posouzení aktivity pracovníků.
Kde data získat
Sleduje se, když uživatel aktualizuje pole 'workedbyid' entity 'QueueItem' přiřazené k případu nebo když se vlastník případu změní z fronty na uživatele.
Zachycení
Určete časové razítko, kdy se vyplní pole 'workedbyid' entity QueueItem.
Typ události
explicit
|
|||
|
Pracovník podpory prošetřil problém
|
Označuje, že pracovník podpory aktivně zjišťuje příčinu zákazníkova problému. Jde o odvozenou aktivitu, kterou lze často rozpoznat podle toho, že pracovník k případu připojí článek znalostní báze, což značí, že proběhlo hledání informací. | ||
|
Proč je to důležité
Sledování této aktivity pomáhá měřit využívání zdrojů znalostí a jejich vliv na dobu řešení. Ukazuje, zda pracovníci využívají dostupné nástroje k efektivnímu řešení problémů.
Kde data získat
Aktivita se odvozuje od vytvoření záznamu v entitě 'IncidentKnowledgeBaseRecord', která propojuje článek znalostní báze s případem. Použije se časové razítko vytvoření tohoto záznamu.
Zachycení
Použijte časové razítko přiřazení článku znalostní báze k Incident.
Typ události
inferred
|
|||
|
Případ znovu aktivován
|
K této události dojde, když se dříve vyřešený případ automaticky nebo ručně znovu otevře, obvykle proto, že zákazník odpověděl nebo oznámil, že problém přetrvává. Jde o standardní chování systému, při kterém se stav případu změní z 'Resolved' zpět na 'Active'. | ||
|
Proč je to důležité
Tato aktivita je důležitá pro odhalení opakované práce a analýzu KPI 'First Contact Resolution Rate'. Časté opětovné aktivace ukazují na neúplná nebo neúčinná původní řešení.
Kde data získat
Událost se zaznamenává při změně pole 'statecode' entity 'Incident' z 'Resolved' (1) zpět na 'Active' (0). Časové razítko změny je uvedeno v historii auditu.
Zachycení
V protokolech auditu sledujte časové razítko změny 'statecode' z Resolved na Active.
Typ události
explicit
|
|||
|
Vyžádány informace od zákazníka
|
Tato aktivita označuje okamžik, kdy pracovník podpory potřebuje od zákazníka další informace, aby mohl pokračovat. Lze ji často odvodit ze změny stavu případu na stav čekání nebo z odchozího e-mailu odeslaného z časové osy případu. | ||
|
Proč je to důležité
Tato aktivita je důležitá pro měření zpoždění na straně zákazníka a sledování KPI 'Customer Information Wait Time'. Pomáhá oddělit dobu procesu, po kterou se čeká na informace zvenčí.
Kde data získat
Aktivitu lze odvodit ze změny pole 'statuscode' entity 'Incident' na hodnotu, jako je 'On Hold', s důvodem 'Waiting for Customer'. Použije se časové razítko této změny stavu.
Zachycení
Sledujte časové razítko změny statuscode na určený stav 'waiting for customer'.
Typ události
inferred
|
|||
|
Zákazníkovi navrženo řešení
|
Tato aktivita označuje, že pracovník podpory připravil řešení a sdělil ho zákazníkovi. Obvykle ji lze odvodit z odchozího e-mailu odeslaného z časové osy případu nebo ze změny stavu na 'Pending Customer Confirmation'. | ||
|
Proč je to důležité
Tento milník označuje přechod od prošetřování k řešení. Analýza doby mezi návrhem a potvrzením řešení může odhalit zpoždění v odpovědi zákazníka nebo problémy s navrženým postupem.
Kde data získat
Aktivitu lze odvodit z časového razítka odchozí aktivity 'Email' související s případem nebo ze změny statuscode na stav před vyřešením.
Zachycení
Použijte časové razítko odchozí e-mailové aktivity nebo změny stavu na 'Solution Proposed'.
Typ události
inferred
|
|||
|
Změněna kategorie případu
|
K této události dojde, když pracovník podpory po vytvoření případu změní jeho kategorii nebo předmět. Systém tuto změnu výslovně zaznamenává v protokolech auditu. | ||
|
Proč je to důležité
Sledování změn kategorií je nezbytné pro KPI 'Service Request Recategorization Rate'. Časté změny ukazují na problémy s prvotním tříděním, které vedou k nesprávnému směrování a zpožděním.
Kde data získat
Událost se zaznamenává v historii auditu entity 'Incident', konkrétně sledováním změn pole 'subjectid' nebo jiných vlastních polí pro kategorizaci.
Zachycení
Z protokolů auditu extrahujte změny pole 'subjectid' včetně časových razítek.
Typ události
explicit
|
|||
Průvodce extrakcí dat
Chcete začít?
Využijte tuto datovou šablonu a pusťte se do process mining. Zjistěte, kde můžete zefektivnit provoz zákaznického servisu. Začněte zlepšovat workflow ještě dnes a zlepšete zákaznickou zkušenost.
Zlepšete zákaznický servis: zvyšte FCR a snižte náklady
Odhalte úzká místa a dosáhněte 80% vyřešení požadavků při prvním kontaktu. Zákazníci budou spokojenější.
Bez platební karty. Nastavení zabere jen několik minut.