Datová šablona pro zákaznický servis
Datová šablona pro zákaznický servis
- Doporučené atributy ke sběru
- Aktivity, které je vhodné sledovat
- Návod k extrakci dat
Atributy zákaznického servisu
| Název | Popis | ||
|---|---|---|---|
|
Aktivita
Activity
|
Název konkrétní obchodní události nebo kroku, ke kterému došlo v procesu zákaznické podpory. | ||
|
Popis
Atribut Činnost označuje jednotlivou akci nebo změnu stavu v životním cyklu požadavku zákazníka. Zaznamenává důležité události, například „Vytvoření tiketu“, „Přiřazení tiketu“, „Odeslání první odpovědi“ a „Vyřešení tiketu“. Tyto činnosti tvoří uzly mapy procesu. Analýza pořadí a četnosti činností je základem process miningu. Umožňuje zobrazit průběh procesu, najít běžné i méně časté cesty a odhalit odchylky od standardního postupu. Znalost činností je důležitá pro hledání neefektivních postupů, opakované práce, například při „Opětovném otevření tiketu“, i problémů s dodržováním pravidel.
Proč je to důležité
Tento atribut určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat jeho průběh od začátku do konce.
Kde data získat
Odvozuje se z typů událostí ve Freshdesku. Může jít o kombinaci změn stavu z koncového bodu API „Tickets“ a konkrétních událostí, jako jsou poznámky nebo odpovědi z koncového bodu „Conversations“.
Příklady
Vytvoření tiketuOdeslání první odpovědiZměna stavu na čeká na zákazníkaVyřešení tiketuUzavření tiketu
|
|||
|
Čas události
EventTime
|
Časové razítko, které udává, kdy došlo ke konkrétní činnosti nebo události. | ||
|
Popis
Čas události neboli časové razítko zaznamenává přesné datum a čas, kdy k činnosti došlo. Je důležité pro chronologické seřazení událostí a výpočet doby mezi jednotlivými kroky procesu. Každá zaznamenaná činnost musí mít odpovídající časové razítko. Při analýze tento atribut slouží k sestavení časové osy každého požadavku zákazníka. Je základem pro výpočet všech časových KPI, například doby řešení, doby do první odpovědi a délky trvání úzkých míst. Přesná časová razítka jsou nezbytná pro pochopení výkonnosti procesu a odhalení prodlev.
Proč je to důležité
Toto časové razítko je nezbytné pro chronologické seřazení událostí a výpočet všech časových ukazatelů, například doby vyřízení a dodržování SLA.
Kde data získat
Odpovídá polím „created_at“ nebo „updated_at“ u událostí, odpovědí či změn stavu tiketu v API Freshdesku.
Příklady
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
Požadavek zákazníka
ServiceRequest
|
Jedinečný identifikátor jednoho dotazu nebo problému zákazníka, běžně označovaného jako tiket nebo případ. | ||
|
Popis
Požadavek zákazníka je hlavní identifikátor případu, který propojuje všechny činnosti související s jednou interakcí se zákazníkem. Každý nový dotaz, problém nebo požadavek zákazníka získá jedinečné ID požadavku. Toto ID se nemění po celou dobu životního cyklu tiketu, od vytvoření a přiřazení až po vyřešení a uzavření. V process miningu je tento atribut základem pro rekonstrukci celého průběhu každého případu. Když analytici seskupí všechny související události pod jedno ID požadavku, mohou zobrazit průběh procesu, měřit dobu vyřízení a hledat odchylky nebo úzká místa, která ovlivňují jednotlivé 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. Díky tomu získáte úplný přehled o průběhu každého případu zákaznické podpory.
Kde data získat
Jde o hlavní ID tiketu ve Freshdesku. Obvykle ho najdete v poli „id“ koncového bodu API „Tickets“.
Příklady
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
Priorita
Priority
|
Priorita přiřazená požadavku na podporu, například „Nízká“, „Střední“, „Vysoká“ nebo „Naléhavá“. | ||
|
Popis
Atribut Priorita vyjadřuje naléhavost požadavku na podporu a často určuje cílovou dobu první reakce i vyřešení. Prioritu lze nastavit automaticky podle pravidel nebo ji může pracovník podpory určit ručně při třídění požadavků. Tento atribut je důležitý pro analýzu shody se SLA a rozdělení zdrojů. Analytici mohou v mapě procesu filtrovat požadavky podle priority a ověřit, zda se požadavky s vysokou prioritou skutečně vyřizují rychleji než požadavky s nízkou prioritou. Mohou také zjistit, zda se priorita často mění, což je forma přepracování, a jaký dopad to má na proces.
Proč je to důležité
Umožňuje analyzovat SLA a ověřit, zda jsou zdroje správně rozděleny, aby se požadavky s vysokou prioritou vyřizovaly rychleji než požadavky s nízkou prioritou.
Kde data získat
Odpovídá poli „priority“ v objektu „Tickets“ ve Freshdesk.
Příklady
NízkáStředníVysokáNaléhavá
|
|||
|
Přiřazený pracovník
AssignedAgent
|
Jméno nebo ID pracovníka zákaznické podpory, který v době události odpovídal za tiket. | ||
|
Popis
Tento atribut označuje konkrétního pracovníka přiřazeného k vyřízení požadavku zákazníka. Během životního cyklu tiketu se může přiřazený pracovník změnit kvůli přeřazení nebo eskalaci. Analýza podle přiřazeného pracovníka je důležitá pro dashboardy řízení výkonnosti. Umožňuje měřit KPI jednotlivých pracovníků, například průměrnou dobu řešení, počet tiketů a míru jejich opětovného otevření. Pomáhá vám najít pracovníky s nejlepšími výsledky, určit potřeby školení a posoudit dopad předávání tiketů na celkovou dobu řešení.
Proč je to důležité
Umožňuje analyzovat výkon jednotlivých pracovníků podpory, identifikovat nejúspěšnější pracovníky, potřebu školení a dopad přeřazení požadavků.
Kde data získat
Odpovídá poli „responder_id“ v objektu „Tickets“ ve Freshdesku. Toto pole lze propojit s údaji o pracovnících.
Příklady
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
Stav
Status
|
Aktuální nebo historický stav požadavku na podporu, například „Otevřený“, „Čeká na vyřízení“, „Vyřešený“ nebo „Uzavřený“. | ||
|
Popis
Atribut Stav označuje stav požadavku na podporu v určitém okamžiku. Změny stavu často představují důležité milníky procesu. Například stav se změní z „Otevřený“ na „Čeká na vyřízení“, když čekáte na informace od zákazníka, nebo z „Čeká na vyřízení“ na „Otevřený“, když zákazník odpoví. Sledování změn stavů je základem pro pochopení životního cyklu požadavku. Ukazuje, jak dlouho požadavky zůstávají v jednotlivých stavech, a pomáhá odhalit úzká místa. Dlouhá doba ve stavu „Čeká na vyřízení“ může například znamenat, že se opožďuje získání potřebných informací od zákazníků.
Proč je to důležité
Sledování změn stavů pomáhá pochopit životní cyklus požadavku a zjistit, jak dlouho případy zůstávají v konkrétních stavech, například „Čeká na vyřízení“ nebo „Pozastaveno“.
Kde data získat
Odpovídá poli „status“ v objektu „Tickets“ ve Freshdesk. Historické stavy je třeba odvodit ze záznamů aktivit.
Příklady
OtevřenýČeká na vyřízeníVyřešenýUzavřený
|
|||
|
Typ požadavku zákazníka
ServiceRequestType
|
Klasifikace požadavku zákazníka, například „Dotaz“, „Incident“, „Problém“ nebo „Požadavek na funkci“. | ||
|
Popis
Typ požadavku zákazníka je důležitá kategorie, která určuje povahu dotazu. Obvykle se nastavuje při vytvoření tiketu nebo během úvodního třídění a pomáhá předat požadavek správnému týmu či pracovníkovi. Při analýze tento atribut umožňuje rozdělit proces podle typu požadavku a zjistit, jak se jednotlivé typy vyřizují. Pomáhá odpovědět na otázky jako „Trvá řešení incidentů déle než řešení dotazů?“ nebo „Které typy požadavků se nejčastěji znovu otevírají?“. Takové rozdělení je důležité pro hledání úzkých míst u konkrétních typů požadavků a úpravu workflow.
Proč je to důležité
Umožňuje rozdělit proces a porovnat výkonnost i workflow u různých typů problémů zákazníků, například incidentů a dotazů.
Kde data získat
Pravděpodobně jde o pole „type“ v objektu „Tickets“ ve Freshdesku.
Příklady
DotazIncidentProblémPožadavek na funkci
|
|||
|
Cílová doba vyřešení podle SLA
SlaTargetResolutionTime
|
Smluvně dohodnutá nebo cílová doba vyřešení požadavku na podporu. | ||
|
Popis
Tento atribut určuje cílovou dobu, během které má být požadavek na podporu vyřešen podle dohody o úrovni služeb (SLA). Cíl často závisí na prioritě nebo typu požadavku. Tato hodnota slouží k výpočtu plnění SLA. Porovnáním skutečné doby vyřešení s cílovou dobou zjistíte, zda bylo SLA splněno, nebo porušeno. Analýza plnění SLA podle typu požadavku, týmu nebo agenta patří k základům správy služeb.
Proč je to důležité
Poskytuje základ pro měření plnění SLA, což je důležitý ukazatel výkonnosti každého týmu zákaznické podpory.
Kde data získat
Údaj může být dostupný v poli „fr_due_by“ (první odpověď) nebo „due_by“ (vyřešení) v objektu „Tickets“ ve Freshdesk. Případně ho lze odvodit z pravidel SLA.
Příklady
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
Doba do první odpovědi
FirstResponseTime
|
Doba od vytvoření požadavku do první odpovědi agenta zákazníkovi. | ||
|
Popis
Doba do první odpovědi měří, jak rychle zákazník obdrží první odpověď od agenta podpory, která není automatická. Vypočítá se jako rozdíl mezi časem aktivity „First Response Sent“ a časem aktivity „Ticket Created“. Toto KPI ukazuje rychlost reakce podpory a výrazně ovlivňuje spokojenost zákazníků. Rychlá první odpověď zákazníkovi potvrzuje, že jste jeho požadavek přijali a řešíte ho. Analýza tohoto ukazatele pomáhá ověřit, zda dodržujete SLA pro první odpověď a reagujete na zákazníky včas.
Proč je to důležité
Měří rychlost reakce podpory, která ovlivňuje spokojenost zákazníků a umožňuje sledovat, zda jim poskytujete pomoc včas.
Kde data získat
Vypočítané pole. Jde o dobu mezi časem události „Ticket Created“ a časem události „First Response Sent“.
Příklady
3000009000001800000
|
|||
|
Došlo k porušení SLA
IsSlaBreached
|
Logická hodnota určující, zda doba vyřešení požadavku na podporu překročila cílovou dobu SLA. | ||
|
Popis
Tento vypočítaný atribut jasně označuje, zda bylo u každého požadavku na podporu splněno SLA. Vypočítá se porovnáním skutečné hodnoty „ResolutionTime“ s hodnotou „SlaTargetResolutionTime“. Pokud skutečná doba překročí cílovou, příznak má hodnotu true. Atribut usnadňuje analýzu plnění SLA i tvorbu dashboardů. Umožňuje snadno spočítat a filtrovat požadavky, u kterých došlo k porušení SLA. Analytici tak rychle zjistí rozsah problému a mohou podrobněji prozkoumat průběh těchto požadavků a hledat příčiny. Atribut přímo podporuje dashboard a KPI Přehled plnění SLA.
Proč je to důležité
Usnadňuje analýzu plnění SLA. U každého případu jasně označí, zda byl cílový čas překročen, a umožní hledat příčiny porušení SLA.
Kde data získat
Vypočítané pole. Odvozuje se porovnáním skutečného času vyřešení s hodnotou „SlaTargetResolutionTime“ nebo polem „due_by“ ve Freshdesk.
Příklady
truefalse
|
|||
|
Hodnocení spokojenosti
SatisfactionRating
|
Hodnocení spokojenosti, které zákazník udělil po vyřešení požadavku. | ||
|
Popis
Hodnocení spokojenosti je ukazatel výsledku, který se obvykle získává z dotazníku zaslaného po vyřešení požadavku. Zpravidla jde o číselné skóre nebo slovní hodnocení, například „Spokojený“, „Neutrální“ či „Nespokojený“. Tento atribut umožňuje porovnat průběh procesu s výsledky pro zákazníky. Analýzou variant procesu, které vedou k nízkému hodnocení, můžete zjistit konkrétní postupy nebo prodlevy, jež zhoršují zákaznickou zkušenost. Ukáže se tak přímá souvislost mezi efektivitou procesu a spokojeností zákazníků.
Proč je to důležité
Propojuje průběh procesu s výsledky pro zákazníky a pomáhá zjistit, které postupy vedou k vyšší nebo nižší spokojenosti.
Kde data získat
Tato data jsou součástí funkce hodnocení spokojenosti ve Freshdesk. Získat je lze prostřednictvím koncového bodu API „Surveys“ nebo „Satisfaction Ratings“.
Příklady
5314
|
|||
|
Jméno zákazníka
CustomerName
|
Jméno nebo ID zákazníka, který zadal požadavek na podporu. | ||
|
Popis
Tento atribut označuje zákazníka, kterého se požadavek na podporu týká. Umožňuje sledovat proces z pohledu zákazníka a v čase zaznamenávat všechny jeho interakce. Analýza podle zákazníka může odhalit například to, kdo zadává nejvíce požadavků nebo u koho se nejčastěji znovu otevírají vyřešené případy. Tyto poznatky pomáhají při péči o zákazníky a při identifikaci těch, kterým kvůli špatné zkušenosti hrozí odchod. Umožňují také pochopit celou zákaznickou cestu napříč více požadavky na podporu.
Proč je to důležité
Umožňuje sledovat proces z pohledu zákazníka a odhalit zákazníky, kteří se na podporu obracejí často nebo opakovaně řeší stejné potíže.
Kde data získat
Údaj je propojen přes „requester_id“ v objektu „Tickets“, který odkazuje na objekt „Contacts“ nebo „Users“ ve Freshdesk.
Příklady
Jan NovákJana SvobodováGlobal Tech Inc.
|
|||
|
Komunikační kanál
CommunicationChannel
|
Kanál, přes který byl požadavek na podporu zadán, například e-mail, telefon, chat nebo webový portál. | ||
|
Popis
Tento atribut určuje zdroj nebo kanál komunikace se zákazníkem. Jednotlivé kanály mohou mít odlišný průběh procesu i dobu vyřešení. U požadavku zadaného přes chat lze například očekávat rychlejší vyřešení než u požadavku zaslaného e-mailem. Analýza procesu podle komunikačního kanálu pomáhá lépe rozdělit zdroje a porovnat efektivitu kanálů. Ukáže, které kanály souvisejí s rychlejším vyřešením nebo vyšší spokojeností zákazníků. Na základě těchto informací se můžete rozhodnout, které kanály podpořit nebo rozvíjet.
Proč je to důležité
Pomáhá porovnat výkonnost a efektivitu procesu v různých kanálech, kterými zákazníci kontaktují podporu, například e-mailem, telefonem nebo chatem.
Kde data získat
Odpovídá poli „source“ v objektu „Tickets“ ve Freshdesk.
Příklady
E-mailTelefonWebový portálChat
|
|||
|
Počet předání mezi agenty
AgentTransferCount
|
Celkový počet případů, kdy byl požadavek na podporu přeřazen od jednoho agenta k jinému. | ||
|
Popis
Tento ukazatel na úrovni případu počítá, kolikrát se změnil přiřazený agent požadavku. Vypočítá se jako počet výskytů aktivity „Ticket Reassigned“ u každého požadavku na podporu. Časté předávání požadavku mezi agenty může způsobit výrazná zpoždění a zhoršit zákaznickou zkušenost, protože se při každém předání ztrácí část kontextu. Analýza počtu předání pomáhá odhalit problémy s prvotním směrováním, nedostatky v dovednostech agentů nebo příliš složitý proces. Cílem bývá omezit zbytečná předání a zlepšit efektivitu i spokojenost zákazníků.
Proč je to důležité
Měří četnost předávání požadavků mezi agenty. Častá předání mohou výrazně prodlužovat vyřízení a zhoršovat zkušenost zákazníků. Ukazatel pomáhá zvýšit podíl požadavků vyřešených na první úrovni podpory.
Kde data získat
Vypočítané pole. Jde o počet aktivit „Ticket Reassigned“ u každého jedinečného požadavku na podporu.
Příklady
0132
|
|||
|
Poslední aktualizace dat
LastDataUpdate
|
Časové razítko, které udává, kdy byla data naposledy aktualizována ze zdrojového systému. | ||
|
Popis
Tento atribut zaznamenává datum a čas, kdy byla data naposledy exportována z Freshdesku nebo aktualizována. Ukazuje, jak aktuální jsou analyzovaná data, což je důležité pro včasná a relevantní obchodní rozhodnutí. Analytici podle něj zjistí, jaké období data pokrývají, a ověří, zda pracují s nejaktuálnějšími dostupnými informacemi. Jde o důležitou metadata položku každého dashboardu nebo reportu process miningu, která účastníkům analýzy ukazuje, jak čerstvá data jsou.
Proč je to důležité
Ukazuje aktuálnost dat, takže analýzy a rozhodnutí vycházejí z nejnovějších dostupných informací.
Kde data získat
Toto pole metadat se vytváří při exportu dat a zaznamenává časové razítko jejich získání.
Příklady
2023-12-01T08:00:00Z
|
|||
|
Přiřazená skupina
AssignedGroup
|
Tým nebo oddělení, kterému je požadavek na podporu přiřazen. | ||
|
Popis
Přiřazená skupina označuje tým agentů odpovědný za vyřízení konkrétního požadavku na podporu. Požadavky se často směrují specializovaným skupinám podle typu nebo složitosti, například technické podpoře nebo fakturačnímu oddělení. Tento atribut pomáhá analyzovat předávání požadavků mezi odděleními a výkonnost jednotlivých týmů. Ukáže, které skupiny vyřizují nejvíce požadavků, u kterých trvá vyřešení nejdéle a jak často se požadavky mezi skupinami předávají. Tyto informace pomáhají upravit uspořádání týmů a workflow.
Proč je to důležité
Umožňuje analyzovat výkonnost týmů a oddělení, sledovat předávání požadavků a odhalovat úzká místa v jednotlivých skupinách.
Kde data získat
Odpovídá poli „group_id“ v objektu „Tickets“ ve Freshdesk.
Příklady
Podpora L1Technická podpora L2FakturacePéče o zákazníky
|
|||
|
Produkt
Product
|
Produkt nebo služba, kterých se požadavek zákazníka týká. | ||
|
Popis
Tento atribut určuje produkt nebo produktovou řadu, které se požadavek na podporu týká. Ve Freshdesk se obvykle nastavuje jako vlastní pole, které pomáhá požadavky kategorizovat pro směrování a reporting. Filtrováním procesu podle produktu můžete odhalit problémy týkající se konkrétních produktů. Zjistíte například, zda určitý produkt vyvolává neúměrně mnoho požadavků na podporu nebo zda uvedení nového produktu na trh způsobilo nárůst dotazů. Tyto poznatky mohou využít týmy vývoje a správy produktů.
Proč je to důležité
Umožňuje filtrovat proces podle oblasti produktu a zjistit, které produkty vyvolávají nejvíce požadavků na podporu nebo mají nejdelší dobu vyřešení.
Kde data získat
Obvykle jde o vlastní pole. Jeho přesné umístění závisí na nastavení Freshdesk. Pravděpodobně ho najdete v části „custom_fields“ odpovědi API pro objekt „Tickets“.
Příklady
Platforma AlphaMobilní aplikace BetaPředplatné Gamma
|
|||
|
Zdrojový systém
SourceSystem
|
Systém, ze kterého byla data exportována, v tomto případě Freshdesk. | ||
|
Popis
Tento atribut označuje zdrojovou aplikaci, ve které data procesu vznikla. V této analýze bude mít pevnou hodnotu, například „Freshdesk“, která ukazuje, že všechny události pocházejí z platformy zákaznické podpory Freshdesk. Atribut může působit jednoduše, ale je důležitý pro správu dat a pro situace, kdy se spojují data z více systémů. Uvádí jejich původ a kontext, takže analytici vědí, odkud zkoumaná data pocházejí. To je nezbytné pro zachování integrity dat a důvěry v analýzu.
Proč je to důležité
Poskytuje důležitý kontext o původu dat. To je podstatné pro jejich správu i při spojování dat z více zdrojových systémů.
Kde data získat
Jde o pevnou hodnotu „Freshdesk“, která se přidává při transformaci dat a označuje jejich zdroj.
Příklady
Freshdesk
|
|||
|
Znovu otevřený požadavek
IsReopened
|
Logická hodnota určující, zda byl vyřešený požadavek na podporu někdy znovu otevřen. | ||
|
Popis
Tento atribut na úrovni případu se nastaví na true, pokud se během životního cyklu požadavku na podporu vyskytla aktivita „Ticket Reopened“. Umožňuje snadno vyhledat a analyzovat případy, které vyžadovaly přepracování. Vysoký podíl znovu otevřených požadavků může znamenat, že první řešení nebylo účinné nebo úplné. To vede ke ztrátě času a nespokojenosti zákazníků. Filtrováním znovu otevřených požadavků můžete hledat příčiny, například nejčastější důvody opětovného otevření, týmy či agenty s vyšším podílem těchto případů a typy požadavků, u kterých se problém opakuje nejčastěji.
Proč je to důležité
Odhaluje případy, které vyžadovaly přepracování. Jde o ukazatel kvality řešení a efektivity procesu. Analýza těchto případů pomáhá zvýšit podíl požadavků vyřešených při prvním kontaktu.
Kde data získat
Vypočítané pole. U požadavku na službu nastavte hodnotu true, pokud pro daný případ existuje událost s Activity = „Ticket Reopened“.
Příklady
truefalse
|
|||
Aktivity zákaznického servisu
| Aktivita | Popis | ||
|---|---|---|---|
|
Odeslání první odpovědi
|
Označuje první veřejnou odpověď pracovníka zákazníkovi po vytvoření tiketu. Freshdesk tuto událost zaznamenává pro měření „First Response Time“ a sledování SLA. | ||
|
Proč je to důležité
Jde o důležitý milník pro měření rychlosti reakce na zákazníky a dodržování SLA. Analýza doby do této činnosti pomáhá odhalit prodlevy při prvním kontaktu se zákazníkem.
Kde data získat
Freshdesk tuto událost sleduje pro účely SLA. Odpovídá časovému razítku první veřejné poznámky přidané pracovníkem.
Zachycení
Určuje se podle první veřejné odpovědi pracovníka v historii konverzace tiketu.
Typ události
explicit
|
|||
|
Přiřazení tiketu
|
Označuje přiřazení tiketu konkrétnímu pracovníkovi nebo skupině. Událost se zaznamená do historie tiketu pokaždé, když se vyplní nebo změní pole přiřazeného pracovníka či skupiny. | ||
|
Proč je to důležité
Sledování přiřazení je důležité pro analýzu vytížení pracovníků, odhalení nedostatků v přidělování a měření KPI doby přiřazení. Ukazuje, jak se práce rozděluje a kde vznikají prodlevy ještě před jejím zahájením.
Kde data získat
Zachycuje se v záznamu „Ticket Activities“, který ukládá změny polí „Agent“ nebo „Group“ včetně časového razítka.
Zachycení
Událost se zaznamená při aktualizaci pole „Assigned to“ u pracovníka nebo skupiny.
Typ události
explicit
|
|||
|
Uzavření tiketu
|
Jde o poslední činnost, která označuje trvalé uzavření tiketu. Systém ji často provede automaticky po uplynutí stanovené doby ve stavu „Resolved“, pokud zákazník neodpoví. | ||
|
Proč je to důležité
Tato činnost označuje definitivní konec životního cyklu požadavku zákazníka. Poskytuje koncový bod pro přesný výpočet celkové doby vyřízení od začátku do konce.
Kde data získat
Zachycuje se v záznamu „Ticket Activities“, který eviduje konečnou změnu stavu na „Closed“. Často ji vyvolá automatizace systému.
Zachycení
Událost se zaznamená při změně pole „Status“ tiketu na „Closed“.
Typ události
explicit
|
|||
|
Vyřešení tiketu
|
Označuje důležitý milník, kdy pracovník poskytl řešení a změnil stav tiketu na „Resolved“. Tato změna stavu se výslovně zaznamená v historii tiketu. | ||
|
Proč je to důležité
Tato činnost označuje konec aktivní práce na tiketu a slouží jako základ pro měření doby řešení. Je důležitá pro analýzu výkonnosti pracovníků i efektivity celého procesu.
Kde data získat
Zachycuje se v záznamu „Ticket Activities“, který ukládá konkrétní změnu stavu na „Resolved“ spolu s časovým razítkem.
Zachycení
Událost se zaznamená při změně pole „Status“ tiketu na „Resolved“.
Typ události
explicit
|
|||
|
Vytvoření tiketu
|
Jde o první událost v průběhu zákaznické podpory. Označuje okamžik, kdy je požadavek zákazníka zaznamenán ve Freshdesku. Systém tuto činnost zaznamená při vytvoření nového tiketu, ať už přijde e-mailem, přes portál, telefonicky nebo prostřednictvím integrace API. | ||
|
Proč je to důležité
Tato činnost je začátkem každého případu. Je proto nezbytná pro výpočet celkové doby řešení a analýzu počtu tiketů podle kanálu nebo typu.
Kde data získat
Jde o explicitní událost v záznamu „Ticket Activities“ systému Freshdesk. Vzniká automaticky při vytvoření nového záznamu požadavku.
Zachycení
Zaznamená se přímo do historie činností tiketu při jeho vytvoření.
Typ události
explicit
|
|||
|
Odeslání průzkumu spokojenosti
|
Označuje odeslání průzkumu spokojenosti zákazníka, které obvykle spustí automatizační pravidlo po vyřešení tiketu. Událost lze zachytit, pokud se akce automatizace zaznamenává v historii tiketu. | ||
|
Proč je to důležité
Označuje začátek sběru zpětné vazby. Propojení odpovědí v průzkumu s variantami procesu může ukázat, jak výkonnost procesu ovlivňuje spokojenost zákazníků.
Kde data získat
Tuto událost obvykle spouští „Automation Rule“. Zda se zobrazí jako samostatná událost v protokolu činností tiketu, závisí na nastavení zaznamenávání automatizací ve Freshdesku.
Zachycení
Událost zaznamenaná spuštěním automatizačního pravidla po vyřešení tiketu.
Typ události
explicit
|
|||
|
Odpověď zákazníka
|
Označuje novou odpověď nebo zprávu od zákazníka. Jde o výslovně zaznamenanou událost v konverzaci tiketu, která obvykle změní stav z „Pending“ zpět na „Open“. | ||
|
Proč je to důležité
Tato činnost pomáhá pochopit průběh komunikace se zákazníkem a měřit dobu jeho odpovědi. Zároveň znovu spouští pozastavené časovače SLA, což ovlivňuje ukazatele dodržování SLA.
Kde data získat
Zaznamená se jako nová položka v konverzaci tiketu a propojí se s kontaktem zákazníka.
Zachycení
Nová veřejná poznámka přidaná do tiketu kontaktem zákazníka.
Typ události
explicit
|
|||
|
Opětovné otevření tiketu
|
K této činnosti dojde, když zákazník odpoví na tiket ve stavu „Resolved“ a systém automaticky změní jeho stav zpět na „Open“. Systém tuto událost výslovně zaznamená. | ||
|
Proč je to důležité
Vysoký podíl znovu otevřených tiketů ukazuje, že původní řešení nejsou účinná, což vede k opakované práci a nespokojenosti zákazníků. Analýza této činnosti je důležitá pro rozbor opětovně otevřených tiketů a zvýšení podílu požadavků vyřešených při prvním kontaktu.
Kde data získat
Tato událost se zachytí, když odpověď zákazníka automaticky změní stav z „Resolved“ zpět na „Open“. Změna stavu se zaznamená v „Ticket Activities“.
Zachycení
Změna stavu z „Resolved“ na „Open“ vyvolaná reakcí zákazníka.
Typ události
explicit
|
|||
|
Porušení SLA
|
Jde o vypočítanou událost, ke které dojde, když doba odpovědi nebo vyřešení tiketu překročí cílovou hodnotu stanovenou zásadami SLA. Freshdesk sleduje stav SLA a označuje tikety jako „violated“. Z těchto údajů lze tuto činnost odvodit. | ||
|
Proč je to důležité
Tato činnost přímo podporuje analýzu dodržování SLA. Přesně ukazuje, kdy a kde se nepodařilo dodržet dohodnutou úroveň služeb, a pomáhá odhalit systémové příčiny prodlev.
Kde data získat
Událost se odvozuje nebo vypočítává ze stavu „SLA“ tiketu. Činnost lze vytvořit při změně stavu SLA na „Violated“ nebo porovnáním časových razítek odpovědi či vyřešení s cíli SLA.
Zachycení
Odvoďte událost z dat tiketu, pokud hodnota „Time to Resolve“ překročí „SLA Target Resolution Time“.
Typ události
calculated
|
|||
|
Přeřazení tiketu
|
K této události dojde, když se tiket po prvním přiřazení převede od jednoho pracovníka nebo skupiny k jinému. Změna vlastníka se výslovně zaznamená v protokolu činností tiketu. | ||
|
Proč je to důležité
Časté přeřazování nebo vysoký počet předání mezi pracovníky může ukazovat na chybné počáteční přiřazení nebo sdílení znalostí v oddělených skupinách. Analýza pomáhá najít možnosti, jak zvýšit podíl požadavků vyřešených při prvním kontaktu.
Kde data získat
Sleduje se podle změn polí „Agent“ nebo „Group“ v záznamu „Ticket Activities“ po prvním přiřazení.
Zachycení
Následná aktualizace pole „Assigned to“ po prvním přiřazení.
Typ události
explicit
|
|||
|
Přidání interní poznámky
|
Pracovník přidá k tiketu soukromou poznámku určenou ke spolupráci s ostatními pracovníky. Jde o výslovně zaznamenanou událost v historii činností tiketu, kterou vidí pouze pracovníci. | ||
|
Proč je to důležité
Sledování interních poznámek pomáhá analyzovat spolupráci a odhalit případy, které vyžadují rozsáhlou interní diskusi. Časté interní poznámky před vyřešením mohou ukazovat na složitý problém nebo nedostatek potřebných znalostí.
Kde data získat
V historii konverzace tiketu se zaznamená jako „Private Note“. Od veřejných odpovědí zákazníkovi se tak odlišuje.
Zachycení
Událost se zaznamená, když pracovník přidá poznámku označenou jako „Private“.
Typ události
explicit
|
|||
|
Změna priority tiketu
|
K této události dojde, když pracovník nebo automatizační pravidlo změní prioritu tiketu, například z „Low“ na „High“. Změna se výslovně zaznamená v protokolu činností tiketu. | ||
|
Proč je to důležité
Změna priority může znamenat eskalaci nebo nové posouzení naléhavosti problému. Její analýza pomáhá pochopit příčiny eskalací a jejich vliv na dobu řešení.
Kde data získat
Zachycuje se v záznamu „Ticket Activities“, který eviduje všechny změny vlastností požadavku, včetně pole „Priority“.
Zachycení
Událost se zaznamená při změně hodnoty pole „Priority“.
Typ události
explicit
|
|||
|
Změna stavu na čeká na zákazníka
|
K této činnosti dojde, když pracovník čeká na informace od zákazníka a změní stav tiketu na „Pending“. Událost se zaznamená v historii činností jako změna stavu. | ||
|
Proč je to důležité
Označuje období, kdy je proces pozastaven a čeká se na informace zvenčí. Analýza doby strávené v tomto stavu pomáhá vyčíslit prodlevy na straně zákazníka a posoudit dodržování SLA, protože časovače SLA se v tomto stavu často pozastavují.
Kde data získat
Zachycuje se v záznamu „Ticket Activities“, který eviduje všechny změny stavu, včetně přechodu na „Pending“.
Zachycení
Událost se zaznamená při změně pole „Status“ tiketu na „Pending“.
Typ události
explicit
|
|||
Návody k extrakci dat
Chcete začít?
Získejte přehled o procesech a začněte zlepšovat provoz zákaznického servisu. Tato šablona je prvním krokem k optimalizaci založené na datech.
Optimalizujte zákaznický servis ve Freshdesk ještě dnes
Dosáhněte 80% úspěšnosti vyřešení požadavků při prvním kontaktu a zlepšete spokojenost zákazníků.
Bez platební karty, nastavení za několik minut