Ügyfélszolgálati adatsablon
Ügyfélszolgálati adatsablon
- Javasolt attribútumok
- Követendő fontos tevékenységek
- Útmutató az adatok kinyeréséhez
Ügyfélszolgálati attribútumok
| Név | Leírás | ||
|---|---|---|---|
|
Esemény időpontja
EventTime
|
Az adott tevékenység vagy esemény bekövetkezésének pontos időbélyege. | ||
|
Leírás
Az esemény időpontja rögzíti a tevékenység végrehajtásának dátumát és idejét. Ez az időbélyeg alapvető az események időrendi sorba rendezéséhez és a folyamatlépések közötti időtartamok kiszámításához. A process mining elemzésben ebből az attribútumból számítjuk az összes időalapú mutatót, többek között az átfutási, a várakozási és a feldolgozási időt. Segítségével az elemzők azonosíthatják a szűk keresztmetszeteket, például a tevékenységeket megelőző hosszú késések alapján, és mérhetik a szolgáltatási szintre vonatkozó megállapodások (SLA-k) teljesülését. A megbízható elemzéshez pontos és következetes időbélyegekre van szükség.
Miért fontos?
Ez az időbélyeg elengedhetetlen az események helyes sorrendbe állításához és a teljesítménymutatók, például az átfutási idők és a szűk keresztmetszetek kiszámításához.
Hol szerezhető be?
Ez általában a ServiceNow audit- és előzménytábláinak (például „sys_audit”) „sys_created_on” mezőjének felel meg.
Példák
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
Szolgáltatási kérés
ServiceRequest
|
Az egyes ügyfélszolgálati kérések, ügyek vagy jegyek egyedi azonosítója. | ||
|
Leírás
A szolgáltatási kérés az elsődleges ügyazonosító, amely az egyetlen ügyfélproblémához tartozó összes tevékenységet és eseményt összekapcsolja a létrehozástól a lezárásig. Ez biztosítja az ügyfélkapcsolat teljes folyamatának nyomon követéséhez szükséges közös hivatkozást. A process mining során ez az attribútum alapvető a folyamat rekonstruálásához. Minden egyedi szolgáltatásikérés-érték egy folyamatpéldányt jelöl, így ügyenként elemezhetők az átfutási idők, az útvonalak és az eltérések. Segítségével a kezdeti kapcsolatfelvételtől a végső megoldásig és lezárásig minden lépés ugyanahhoz az ügyfélkéréshez rendelhető.
Miért fontos?
Ez az ügyazonosító kapcsolja össze a folyamat összes lépését, így elemezhető az egyes ügyfélkapcsolatok teljes életciklusa.
Hol szerezhető be?
Ez általában a ServiceNow CSM „sn_customerservice_case” táblájának „number” mezője.
Példák
CS0010001CS0010045CS0010112
|
|||
|
Tevékenység neve
ActivityName
|
A szolgáltatási kérés életciklusa során bekövetkezett esemény vagy végrehajtott feladat neve. | ||
|
Leírás
A tevékenység neve az ügyfélszolgálati folyamat egy lépését jelöli, például „Szolgáltatási kérés létrehozva”, „Kérés kiosztva az ügyintézőnek” vagy „Megoldási javaslat”. Ezeket a tevékenységeket a rendszer naplóiból vagy a táblák frissítéseiből nyerjük ki, hogy minden szolgáltatási kéréshez időrendi eseménysort állítsunk össze. Ez az attribútum alapvető a folyamattérkép megjelenítéséhez, a szűk keresztmetszetek azonosításához és a munka menetének megértéséhez. A tevékenységek sorrendjének és gyakoriságának elemzésével feltárhatók a gyakori folyamatútvonalak, az eltérések, valamint az ismételt munkavégzés vagy a hatékonyság hiányának területei. A tevékenységek részletessége közvetlenül meghatározza, milyen mélységű elemzések végezhetők a folyamatmodell alapján.
Miért fontos?
Ez az attribútum adja a folyamattérkép alapját: meghatározza azokat a lépéseket és feladatokat, amelyek sorrendjét és időtartamát elemezzük.
Hol szerezhető be?
Ez egy fogalmi attribútum, amelyet a rendszer auditálási tábláiból (például „sys_audit”) vagy az „sn_customerservice_case” tábla állapotváltozásainak és fontos mezőfrissítéseinek nyomon követésével állítunk elő.
Példák
Ügyfélszolgálati kérés létrehozvaKérés hozzárendelve az ügyintézőhözInformációkérés az ügyféltőlSzolgáltatási kérés megoldva
|
|||
|
Állapot
State
|
A szolgáltatási kérés aktuális állapota az életciklusa során. | ||
|
Leírás
Az állapot attribútum a szolgáltatási kérés aktuális helyzetét írja le, például „Új”, „Folyamatban”, „Információra vár”, „Megoldva” vagy „Lezárva”. A mező változásai gyakran a folyamatmodell tevékenységeinek meghatározására szolgálnak. Az állapot elemzésével áttekinthető, hol tartanak az ügyek a folyamatban. Megmutatja, mennyi időt töltenek az ügyek bizonyos állapotokban, például „Információra vár” állapotban, amely jelentős késések forrása lehet. Emellett segít meghatározni az olyan fontos KPI-k kezdő- és végpontját, mint a „Megoldástól a lezárásig eltelt idő”.
Miért fontos?
Bármely időpontban megmutatja a kérés állapotát, így azonosítható, mennyi időt tölt nem produktív állapotban, például „Felfüggesztve” vagy „Információra vár” helyzetben.
Hol szerezhető be?
Ez az „sn_customerservice_case” tábla „state” mezőjének felel meg.
Példák
ÚjFolyamatbanÜgyféladatokra várakozásMegoldvaLezárva
|
|||
|
Felelős csoport
AssignmentGroup
|
A szolgáltatási kérésért felelős csapat vagy részleg. | ||
|
Leírás
A felelős csoport azt a várólistát vagy csapatot jelöli, amelyhez a szolgáltatási kérést kiosztották. A kérés jellegétől függően gyakran különböző csoportokhoz irányítják, például első szintű ügyfélszolgálathoz, műszaki szakértői csapathoz vagy számlázási részleghez. Ez az attribútum elengedhetetlen a részlegek közötti átadások elemzéséhez és a csapatszintű szűk keresztmetszetek azonosításához. Megmutatja, hogyan halad a munka a különböző területek között, és rávilágíthat a túlterhelt vagy további képzést igénylő csoportokra. Közvetlenül támogatja az „Ügyintézők közötti átadások és újrakiosztások”, valamint a „Folyamatmenet” dashboardot.
Miért fontos?
Megmutatja, melyik csapat felel a munkáért. Ez elengedhetetlen a csapatok teljesítményének, munkaterhelésének és a részlegek közötti átadásoknak az elemzéséhez.
Hol szerezhető be?
Ez az „sn_customerservice_case” tábla „assignment_group” mezőjének felel meg.
Példák
ÜgyfélszolgálatSzámlázási kérdések2. szintű műszaki támogatás
|
|||
|
Kategória
Category
|
A szolgáltatási kérés fő besorolása, például „Számlázás” vagy „Műszaki probléma”. | ||
|
Leírás
A kategória a szolgáltatási kéréseket az ügyfél kérdése vagy problémája alapján csoportosítja. A besorolás általában a kérés létrehozásakor történik, és segít a megfelelő felelős csoporthoz irányítani azt. Ez az attribútum elengedhetetlen a folyamat elemzésének szegmentálásához. A kategória szerinti szűréssel összehasonlíthatók a különböző kéréstípusok folyamatai. A „Számlázás” kategóriájú ügyek megoldása például jelentősen eltérhet a „Műszaki probléma” kategóriájú ügyekétől. Ez az attribútum szinte minden dashboardon használható az adatok szűrésére.
Miért fontos?
Lehetővé teszi az elemzés kéréstípus szerinti bontását, így láthatóvá válik, hogy bizonyos kategóriákban gyakoribbak-e a késések, az eszkalációk vagy az SLA-sértések.
Hol szerezhető be?
Ez az „sn_customerservice_case” tábla „category” mezőjének felel meg.
Példák
Érdeklődés / segítségkérésRendelésekTermékproblémákSzámlázás
|
|||
|
Kijelölt ügyintéző
AssignedAgent
|
A szolgáltatási kérés kezelésére jelenleg kijelölt ügyintéző. | ||
|
Leírás
Ez az attribútum azonosítja, hogy egy adott időpontban ki felel a szolgáltatási kérésért. Az ügy életciklusa során gyakran változik, ahogy a kérést különböző ügyintézők vagy szakértők veszik át. A kijelölt ügyintéző elemzése segít megérteni a munkaterhelés eloszlását, az ügyintézők teljesítményét és az átadásokat. Választ adhat például arra, hogy kik kezelik a legösszetettebb ügyeket, milyen gyakran osztják ki újra az ügyeket, illetve kapcsolódik-e egyes ügyintézőkhöz hosszabb megoldási idő vagy magasabb ügyfélelégedettség. Ez az attribútum elengedhetetlen az „Ügyintézők közötti átadások és újrakiosztások” dashboardhoz.
Miért fontos?
Nyomon követi, ki felel az ügyért, így elemezhető a munkaterhelés, a teljesítmény és az újrakiosztások gyakorisága. Az újrakiosztás gyakran a folyamatban jelentkező súrlódásra utal.
Hol szerezhető be?
Ez az „sn_customerservice_case” tábla „assigned_to” mezőjének felel meg.
Példák
Beth AnglinDavid LooAbel Tuter
|
|||
|
Prioritás
Priority
|
A szolgáltatási kérés prioritási szintje, amely meghatározza a sürgősségét. | ||
|
Leírás
A prioritás a szolgáltatási kérés fontosságát és a kezeléséhez szükséges sürgősséget jelzi. Meghatározásakor gyakran az ügyfélre gyakorolt hatást és a sürgősséget veszik figyelembe. A gyakori értékek a „Kritikus” és az „Alacsony” közötti skálán mozognak. A process mining során a prioritás hasznos szűrési és összehasonlítási szempont. Segítségével ellenőrizhető, hogy a magas prioritású kéréseket valóban gyorsabban dolgozzák-e fel az alacsony prioritásúaknál, és hogy bizonyos prioritási szinteknél gyakoribbak-e az SLA-sértések. Ez alapvető a „Szolgáltatási kérések teljes átfutási ideje” dashboardhoz.
Miért fontos?
Lehetővé teszi a szolgáltatási kérések sürgősség szerinti csoportosítását, így ellenőrizhető, hogy a kritikus ügyeket gyorsabban kezelik-e, mint a nem kritikusakat.
Hol szerezhető be?
Ez az „sn_customerservice_case” tábla „priority” mezőjének felel meg.
Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
|
|||
|
SLA-sértés történt
IsSlaBreached
|
Logikai érték, amely jelzi, hogy a szolgáltatási kérelem túllépte-e a meghatározott szolgáltatási szintre vonatkozó megállapodás (SLA) célértékét. | ||
|
Leírás
Ez a számított attribútum jelzi, hogy a szolgáltatási kérelmet a megállapodás szerinti határidőn belül oldották-e meg. Értéke általában „True”, ha a megoldás ideje túllépte az SLA célértékét, egyébként „False”. Így minden esetnél egyértelműen megállapítható, hogy teljesült-e az SLA. Ez az attribútum szükséges az „SLA-teljesítés és -sértések trendjei” dashboardhoz és az „SLA-teljesítési arány” KPI-hoz. Egyszerűbbé teszi az elemzést, mert közvetlenül szűrhetők és megszámolhatók az SLA-sértéssel érintett esetek. Így könnyen azonosítható, hogy mely kérelemtípusok, prioritások vagy csapatok esetében fordul elő leggyakrabban SLA-sértés.
Miért fontos?
Egyértelmű igen vagy nem választ ad arra, hogy az eset határidőre lezárult-e. Ez alapvető az SLA-megfelelés méréséhez és jelentéséhez.
Hol szerezhető be?
A „task_sla” tábla „made_sla” mezője alapján számítható ki, vagy a tényleges megoldási idő és a tervezett megoldási idő összehasonlításával vezethető le.
Példák
truefalse
|
|||
|
Első kapcsolatfelvételkor megoldódott-e
IsFirstContactResolution
|
Logikai érték, amely jelzi, hogy az elsőként kijelölt ügyintéző megoldotta-e a kérelmet átadás vagy eszkaláció nélkül. | ||
|
Leírás
Ez a számított attribútum azokat a szolgáltatási kérelmeket azonosítja, amelyeket hatékonyan, az első kapcsolatfelvétel során vagy az esetet elsőként kezelő ügyintéző oldott meg. A számítás általában olyan feltételeket ellenőriz, mint az újrakiosztások hiánya („ReassignmentCount” értéke 0), a „Belső eszkaláció indult” tevékenység hiánya, valamint az, hogy nem kértek-e további információt az ügyféltől. Ez az attribútum közvetlenül mér egy fontos ügyfélszolgálati mutatót, és támogatja az „Első kapcsolatfelvételkor történő megoldás aránya” dashboardot és KPI-t. Segítségével egyszerűen mérhető az első kapcsolatfelvételkor történő megoldás (FCR) aránya, és elemezhetők azok a tényezők, például a csatorna vagy a kérelem kategóriája, amelyek segítik vagy akadályozzák ezt.
Miért fontos?
Közvetlenül méri az első válasz hatékonyságát. A magas FCR-arány szorosan összefügg a működés hatékonyságával és az ügyfelek elégedettségével.
Hol szerezhető be?
Ez egy számított attribútum. Az adatátalakítás során olyan szabályok alapján jön létre, mint például a nulla „ReassignmentCount” érték és az eszkalációs tevékenységek hiánya.
Példák
truefalse
|
|||
|
Forrásrendszer
SourceSystem
|
A rendszer, amelyből az adatokat kinyertük. | ||
|
Leírás
Ez az attribútum azonosítja az adatok forrását. Különösen fontos, ha több rendszerből gyűjtjük össze az információkat. Ennél a folyamatnézetnél az érték minden esetben „ServiceNow CSM”. Az elemzés során ez az attribútum az adatirányítást és a hibakeresést is segíti. Több forrásrendszer esetén szűrhető vele a folyamat, így megvizsgálható a működése egy adott rendszerben, vagy összehasonlíthatók a különböző rendszerek folyamatai.
Miért fontos?
Megmutatja az adatok eredetét, így több rendszer használatakor is egyértelművé teszi a forrást, és segíti az adatirányítást.
Hol szerezhető be?
Ez egy statikus érték, amelyet az adatátalakítás során adunk hozzá az adatkészlet forrásának megjelölésére.
Példák
ServiceNow CSM
|
|||
|
Kapcsolatfelvételi csatorna
Channel
|
Az a kommunikációs csatorna, amelyen keresztül a szolgáltatási kérést benyújtották. | ||
|
Leírás
A kapcsolatfelvételi csatorna azt mutatja meg, hogyan nyújtotta be az ügyfél a kérését, például e-mailben, telefonon, webes portálon vagy chaten. A különböző csatornák folyamatai és az ügyfelek elvárásai jelentősen eltérhetnek. A folyamat csatorna szerinti elemzésével értékelhető az egyes kommunikációs módok hatékonysága. Kiderülhet például, hogy telefonon nagyobb-e az első kapcsolatfelvételkor történő megoldási arány, vagy az e-mailben érkező kérések átfutási ideje hosszabb-e. Ez közvetlenül támogatja a „Kommunikációs csatornák hatékonysága” dashboardot.
Miért fontos?
Segít felmérni a különböző ügyfélkapcsolati csatornák, például a telefon, az e-mail vagy a webes portál hatékonyságát és eredményeit.
Hol szerezhető be?
Ez általában az „sn_customerservice_case” tábla „contact_type” mezőjének felel meg.
Példák
TelefonE-mailÖnkiszolgálásChat
|
|||
|
Megoldási kód
ResolutionCode
|
A szolgáltatási kérés végeredményét vagy megoldásának módját jelölő kód. | ||
|
Leírás
A megoldási kód egy strukturált érték, amelyet az ügyintéző az ügy megoldásakor választ ki. Részletezi a megoldást, például „Felhasználó megoldotta”, „Ismert hiba”, „Duplikátum” vagy „Nincs szükség intézkedésre”. Ez az attribútum hasznos a kiváltó okok elemzéséhez. A különböző megoldási kódok gyakoriságából a szervezetek felismerhetik a visszatérő problémákat, a tudáshiányokat vagy a termékhibákat. Az így nyert információk alapján olyan fejlesztések indíthatók, amelyek csökkentik bizonyos típusú szolgáltatási kérések számát.
Miért fontos?
Megmutatja a szolgáltatási kérések eredményét, ami elengedhetetlen a kiváltó okok elemzéséhez és a visszatérő problémák azonosításához.
Hol szerezhető be?
Ez az „sn_customerservice_case” tábla „close_code” mezőjének vagy egy egyedi megoldásikód-mezőnek felel meg.
Példák
Megoldva (kerülő megoldással)Megoldva (véglegesen)Nem oldódott meg (az ügyfél nem válaszolt)A bejelentő lezárta / megoldotta
|
|||
|
Történt-e utómunka
IsRework
|
Logikai érték, amely jelzi, hogy történt-e jelentős utómunka, például újranyitották-e az esetet, vagy ismételt vizsgálatra volt-e szükség. | ||
|
Leírás
Ez a számított attribútum megjelöli azokat az eseteket, amelyeknél hatékonysági problémára vagy ismétlődésre utaló mintázat látható. A jelölést kiválthatják például a „Szolgáltatási kérelem újranyitva” események, vagy ha ugyanazon az eseten belül többször is előfordul egy fontos tevékenységsorozat, például az „Ügyintéző megkezdi a vizsgálatot”, majd a „Megoldási javaslat” lépés. Ez a jelölés segít gyorsan azonosítani a problémás eseteket és felmérni a folyamatban végzett utómunka mértékét. Közvetlenül támogatja az „Utómunka és ismétlődés gócpontjai” dashboardot és az „Utómunka aránya” KPI-t. Az elemzők így az ismétlődő minták kézi keresése helyett azonnal a hatékonysági problémák okaira összpontosíthatnak.
Miért fontos?
Az ismétlődő lépések vagy újranyitások megjelölésével mérhetővé teszi a folyamat hatékonysági problémáit, így az utómunka könnyen felmérhető és célzottan csökkenthető.
Hol szerezhető be?
Ez egy számított attribútum. Az adatátalakítás során olyan üzleti szabályok alkalmazásával jön létre, amelyek felismerik az utómunkára utaló mintákat, például a nem nulla „ReopenCount” értéket vagy az ismétlődő tevékenységeket.
Példák
truefalse
|
|||
|
Ügyfél
Customer
|
A szolgáltatási kérést benyújtó ügyfél vagy vállalat neve, illetve azonosítója. | ||
|
Leírás
Ez az attribútum azonosítja azt a külső érintettet, magánszemélyt vagy szervezetet, akinek a szolgáltatási kérés szól. Megadja az egyes ügyekhez tartozó ügyféladatokat. Az ügyfél attribútum segítségével az ügyfél szempontjából vizsgálható a szolgáltatási folyamat. Kiderülhet, hogy bizonyos ügyfeleknél gyakoribbak-e a problémák vagy hosszabbak-e a késések. Az attribútum más ügyféladatokkal, például a szegmenssel vagy az ügyfélértékkel is összekapcsolható, így rangsorolhatók a folyamatfejlesztési feladatok. Megvizsgálható például, hogy a kiemelt értékű ügyfelek gyorsabb kiszolgálásban részesülnek-e.
Miért fontos?
Az ügyfelekhez kapcsolja a folyamatot, így elemezhető a kiemelt ügyfelek vagy ügyfélszegmensek kiszolgálási szintje és problémáinak gyakorisága.
Hol szerezhető be?
Ez lehet az „sn_customerservice_case” tábla „caller_id”, „opened_for” vagy „account” mezője, amely a felhasználói vagy vállalati táblákra hivatkozik.
Példák
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
Újrakiosztások száma
ReassignmentCount
|
Hányszor osztották ki újra a szolgáltatási kérést egy másik ügyintézőnek vagy csoportnak. | ||
|
Leírás
Ez a számláló minden alkalommal növekszik, amikor megváltozik az „assigned_to” vagy az „assignment_group” mező. Egyszerű mutatója annak, hányszor adták át az ügyet a szervezeten belül. Az újrakiosztások száma közvetlenül jelzi a folyamatban jelentkező súrlódást. Fontos adat az „Ügyintézők közötti átadások és újrakiosztások” dashboardhoz és az „Átlagos ügyintézői átadások száma kérésenként” KPI-hoz. A sok újrakiosztás gyakran a kezdeti irányítás problémájára, az ügyintézők készséghiányára vagy nehezen besorolható ügyekre utal. Ezek mind hosszabb megoldási időhöz vezethetnek.
Miért fontos?
Az átadások számolásával közvetlenül méri a folyamat hatékonyságának hiányát. A magas érték gyakran hosszabb megoldási idővel és alacsonyabb ügyfélelégedettséggel jár együtt.
Hol szerezhető be?
Ez a „task” tábla szabványos „reassignment_count” mezője, amelyet az „sn_customerservice_case” tábla kiterjeszt.
Példák
0135
|
|||
|
Újranyitások száma
ReopenCount
|
Hányszor nyitotta újra az ügyfél a megoldott szolgáltatási kérést. | ||
|
Leírás
Ez a számláló azt követi, hányszor váltott az ügy „Resolved” vagy „Closed” állapotról „In Progress” vagy „Open” állapotra. Az újranyitott ügy arra utal, hogy az eredeti megoldás nem volt hatásos vagy teljes. Ez az attribútum jól jelzi az ismételt munkavégzést és az elsőre történő megoldás minőségét. A magas újranyitási szám a megoldási folyamat problémáira utalhat, például arra, hogy az ügyintézők túl korán zárják le a jegyeket, vagy nem kezelik teljesen az ügyfél alapvető problémáját. Fontos mutató a javasolt megoldások hatékonyságának megértéséhez.
Miért fontos?
A sikertelen megoldásokat és az ismételt munkavégzést jelzi. A gyakori újranyitás a megoldási folyamat gyenge minőségére és az ügyfelek elégedetlenségére utal.
Hol szerezhető be?
Ezt gyakran a „reopen_count” nevű mezőben tárolják az „sn_customerservice_case” táblában vagy egy kapcsolódó táblában.
Példák
012
|
|||
|
Utolsó adatfrissítés
LastDataUpdate
|
Az időbélyeg azt mutatja, mikor nyertük ki vagy frissítettük utoljára az adatokat a forrásrendszerből. | ||
|
Leírás
Ez az attribútum rögzíti a legutóbbi adatlekérés dátumát és időpontját. Megmutatja, mennyire frissek az elemzett adatok, így a felhasználók tudják, hogy közel valós idejű információt vagy korábbi állapotot látnak. Az elemzés során ez fontos metaadat az adatkészlet időszakának megértéséhez. Segít helyesen értelmezni a dashboardokat és a KPI-kat. Például láthatóvá teszi, hogy az adatok az elmúlt órára vagy az előző napra vonatkoznak-e.
Miért fontos?
Az adatok frissességét jelzi, ami meghatározza, mennyire relevánsak és időszerűek a process mining elemzés eredményei.
Hol szerezhető be?
Ez az időbélyeg az adatok kinyerése, átalakítása és betöltése (ETL) során jön létre és kerül az adatokhoz.
Példák
2023-11-20T08:00:00Z
|
|||
Ügyfélszolgálati tevékenységek
| Tevékenység | Leírás | ||
|---|---|---|---|
|
Belső eszkaláció indult
|
A szolgáltatási kérés hivatalos továbbítását jelenti magasabb szintű támogatási csoporthoz vagy vezetőhöz, hogy megoldják az ügyet. Erre az assignment group magasabb szintű csapatra váltásából vagy egy jelző beállításából következtethetünk. | ||
|
Miért fontos?
Az eszkalációk nyomon követése segít feltárni a folyamat gyenge pontjait, az első vonalbeli támogatás tudáshiányait és az összetett ügytípusokat. Az eszkaláció a folyamatban jelentkező súrlódás és az ügyfelek elégedetlenségének fontos jelzője.
Hol szerezhető be?
Az auditnapló alapján észlelhető, ha az „assignment_group” mező egy ismert eszkalációs csapatra változik, vagy módosul az ügyrekord „escalation” mezője.
Rögzítés
Az „escalation” mező változásának vagy az „assignment_group” magasabb szintű csoportra váltásának észlelése.
Eseménytípus
inferred
|
|||
|
Kérés hozzárendelve az ügyintézőhöz
|
Ez a tevékenység akkor történik, amikor egy szolgáltatási kérést egy adott ügyintézőhöz rendelnek kivizsgálásra és megoldásra. A case rekord assigned_to mezőjének változásából következtethető ki. | ||
|
Miért fontos?
Ez fontos mérföldkő az első válasz idejének és az ügyintézők munkaterhelésének méréséhez. A mező ismételt módosításainak követése feltárja a folyamat hatékonysági problémáit és az ügyintézők elérhetőségével kapcsolatos szűk keresztmetszeteket.
Hol szerezhető be?
Az sn_customerservice_case tábla auditelőzményeiből (sys_audit) következtethető ki annak követésével, hogy az assigned_to mezőt mikor töltik ki vagy módosítják.
Rögzítés
Az „assigned_to” mező értékváltozásának észlelése az ügy auditnaplójában.
Eseménytípus
inferred
|
|||
|
Szolgáltatási kérés lezárva
|
Ez az utolsó tevékenység, amely a szolgáltatási kérés rekordjának hivatalos lezárását jelöli, gyakran a megoldás utáni jóváhagyási időszakot követően. Akkor rögzül, amikor az ügy állapota „Closed” értékre változik, és beállítják a closed_at időbélyeget. | ||
|
Miért fontos?
A folyamat végpontjaként ez a tevékenység elengedhetetlen az ügy teljes életciklusának méréséhez. A „Resolved” és „Closed” közötti idő elemzése feltárja az adminisztrációs többletmunkát és a késéseket.
Hol szerezhető be?
Az auditelőzményekből következtethetünk rá, amikor az sn_customerservice_case tábla state mezője „Closed” értékre változik. A closed_at mező ekkor töltődik ki.
Rögzítés
A „state” mező „Closed” értékre váltásának észlelése, majd a hozzá tartozó időbélyeg használata.
Eseménytípus
inferred
|
|||
|
Szolgáltatási kérés megoldva
|
Ez fontos mérföldkő: azt jelzi, hogy az ügyintéző befejezte a munkát, és a probléma megoldottnak tekinthető. Akkor rögzül, amikor az ügy állapota „Resolved” értékre változik, és kitöltődik a resolved_at időbélyeg. | ||
|
Miért fontos?
Ez a tevékenység jelöli az aktív megoldási folyamat végét, és elengedhetetlen a megoldási átfutási idő és az SLA betartásának méréséhez. Számos hatékonysági KPI számításának végpontja.
Hol szerezhető be?
Az auditelőzményekből következtethetünk rá, amikor az sn_customerservice_case tábla state mezője „Resolved” értékre változik. A resolved_at mező általában ekkor töltődik ki.
Rögzítés
A „state” mező „Resolved” értékre váltásának észlelése, majd a hozzá tartozó időbélyeg használata.
Eseménytípus
inferred
|
|||
|
Ügyfélszolgálati kérés létrehozva
|
Ez a tevékenység jelzi az ügyfélszolgálati folyamat kezdetét, amikor a rendszerben hivatalosan rögzítenek egy új ügyet. Az esemény rögzítése egy új rekord beszúrásakor történik az sn_customerservice_case táblába. | ||
|
Miért fontos?
Mivel ez a tevékenység minden ügy kiindulópontja, elengedhetetlen a teljes ciklusidő kiszámításához és a beérkező kérések mennyiségének elemzéséhez. Elindítja a további folyamatokat és az SLA-időmérést.
Hol szerezhető be?
Ez az esemény az sn_customerservice_case táblában létrehozott rekordnak felel meg. Az időbélyeg forrása a sys_created_on mező.
Rögzítés
A rekord létrehozásának időbélyege (sys_created_on) az sn_customerservice_case táblában.
Eseménytípus
explicit
|
|||
|
Hozzárendelési csoport módosítva
|
Azt jelzi, hogy az ügy felelőssége egyik csapatról egy másikra került át. Az esemény a case rekord assignment_group mezőjének változásából következtethető ki. | ||
|
Miért fontos?
A hozzárendelési csoportok változásainak követése elengedhetetlen a részlegek közötti átadások elemzéséhez és az ismétlődő irányítási problémák feltárásához. Ha ez a tevékenység gyakran fordul elő, az a felelősségi körök vagy a folyamatleírások tisztázatlanságára utalhat.
Hol szerezhető be?
Az sn_customerservice_case tábla auditelőzményeiből (sys_audit) következtethető ki az assignment_group mező változásainak követésével.
Rögzítés
Az „assignment_group” mező értékváltozásának észlelése az ügy auditnaplójában.
Eseménytípus
inferred
|
|||
|
Információ érkezik az ügyféltől
|
Ez a tevékenység azt jelöli, amikor az ügyfél megadja a kért információt, így az ügyintéző folytathatja a munkát. Erre abból következtethetünk, hogy az ügy állapota „Awaiting User Info” értékről ismét aktív állapotra vált. | ||
|
Miért fontos?
Ez az esemény lezárja az ügyfélre várakozás időszakát, így pontosan mérhető az ügyfél válaszideje. Segít azonosítani, mely ügytípusokhoz vagy ügyfelekhez kapcsolódnak a leghosszabb késések.
Hol szerezhető be?
Az sn_customerservice_case tábla auditelőzményeiből következtethetünk rá, amikor a state mező „Awaiting Info” állapotról aktív értékre, például „Work in Progress” értékre vált.
Rögzítés
A „state” mező változásának észlelése ügyfélre várakozást jelző értékről ismét aktív értékre.
Eseménytípus
inferred
|
|||
|
Információkérés az ügyféltől
|
Akkor történik, amikor az ügyintézőnek további információra van szüksége az ügyféltől a munka folytatásához, ezért függő állapotba helyezi az ügyet. Erre az állapot például „Awaiting User Info” vagy „On Hold” értékre váltásából következtethetünk. | ||
|
Miért fontos?
Ez a tevékenység elengedhetetlen az „Ügyféltől kapott információra várakozás” elemzéséhez. Elkülöníti a külső függőségek okozta folyamatkéséseket a belső feldolgozási időtől.
Hol szerezhető be?
Az sn_customerservice_case tábla auditelőzményeiből következtethetünk rá, amikor a state mező olyan értékre változik, amely az ügyféltől várt információt jelzi (például „Awaiting Info”).
Rögzítés
A „state” mező változásának észlelése egy kijelölt, ügyfélre várakozást jelző értékre.
Eseménytípus
inferred
|
|||
|
Kérés kategorizálva és rangsorolva
|
A kezdeti ügybesorolás során meghatározzák a szolgáltatási kérés kategóriáját és prioritását, hogy megállapítsák a sürgősségét és a megfelelő irányítási útvonalat. Ez a case rekord auditnaplójában szereplő kategória-, alkategória- vagy prioritásmező-változásokból következtethető ki. | ||
|
Miért fontos?
Ennek a tevékenységnek az elemzése segít feltárni az ügybesorolás késedelmeit, és biztosítani, hogy a kérések a megfelelő helyre kerüljenek, illetve sürgősségüknek megfelelően kezeljék őket. Hatással van az első ügyintézőhöz rendelés idejére és a teljes megoldási folyamat hatékonyságára.
Hol szerezhető be?
Az sn_customerservice_case tábla auditelőzményeiből (sys_audit) következtethető ki. A kategória- és prioritásmezők első kitöltését, illetve módosításait kell követni.
Rögzítés
A „category” vagy „priority” mező első értékének beállítása vagy értékváltozása.
Eseménytípus
inferred
|
|||
|
Megoldási javaslat
|
Ez a tevékenység azt jelöli, amikor az ügyintéző megtalálta a megoldást, és elküldte az ügyfélnek jóváhagyásra. Erre gyakran az állapot „Awaiting Acceptance” értékre váltásából vagy egy konkrét munkanapló-bejegyzésből következtethetünk. | ||
|
Miért fontos?
Ez a mérföldkő választja el a kivizsgálást a jóváhagyás és a megoldás szakaszától. Az ügyfél jóváhagyására várakozással töltött idő elemzése megmutathatja, hogyan gyorsíthatók fel az ügy lezárásának utolsó lépései.
Hol szerezhető be?
Az sn_customerservice_case tábla auditnaplójából következtethetünk rá, amikor az állapot megoldási javaslatot jelző értékre változik (például „Proposed Solution”). Ez a beállítástól függően eltérhet.
Rögzítés
A „state” mező változásának észlelése például „Proposed Solution” vagy „Awaiting Acceptance” értékre.
Eseménytípus
inferred
|
|||
|
SLA megsértése
|
Azt az időpontot jelöli, amikor a szolgáltatási kérés nem teljesíti a meghatározott szolgáltatási szintre vonatkozó megállapodást, például a megoldási határidőt. Ez számított esemény: a megoldás idejét az SLA tervezett lejárati idejével kell összevetni. | ||
|
Miért fontos?
Az SLA-sértések azonosítása alapvető a megfelelés nyomon követéséhez és a teljesítmény kezeléséhez. Ez az esemény segít megállapítani, hogy a folyamat mely szakaszai vagy ügytípusai járulnak hozzá leginkább az SLA megsértéséhez.
Hol szerezhető be?
Az ügyhöz kapcsolódó task_sla tábla rekordjainak elemzésével számítható ki. Akkor történt SLA-sértés, ha a has_breached mező értéke true, vagy az actual_elapsed_time meghaladja a planned_duration értékét.
Rögzítés
Ellenőrizze a kapcsolódó task_sla rekord „has_breached” jelzőjét.
Eseménytípus
calculated
|
|||
|
Ügyfélelégedettségi kérdőív elküldve
|
Az ügy megoldása után elküldött ügyfélelégedettségi kérdőívet jelöli. Ez az esemény általában akkor rögzül, amikor létrejön az ügyhöz kapcsolódó kérdőívrekord. | ||
|
Miért fontos?
Ez a tevékenység segít összekapcsolni a folyamat lefutását az ügyfél visszajelzésével. A visszajelzési folyamat hatékonyságának elemzéséhez fontos tudni, hogy mikor és küldtek-e kérdőívet.
Hol szerezhető be?
Ez kifejezetten rögzített esemény egy kérdőívekhez használt táblában, például az asmt_assessment_instance táblában, amely hivatkozást tartalmaz a forrásként szolgáló ügyrekordra.
Rögzítés
Az ügyhöz kapcsolódó rekord létrehozása az „asmt_assessment_instance” táblában.
Eseménytípus
explicit
|
|||
|
Ügyintéző megkezdi a kivizsgálást
|
Ez a tevékenység azt jelzi, hogy az ügyintéző ténylegesen elkezdett dolgozni a szolgáltatási kérésen. Általában abból következtethetünk rá, hogy az ügy állapota például „Új” vagy „Kiosztva” értékről „Folyamatban” értékre változik. | ||
|
Miért fontos?
Ez az esemény különválasztja a várakozási időt az aktív munkavégzés idejétől. A kiosztás és a kivizsgálás megkezdése közötti idő elemzésével feltárhatók azok a késések, amelyek abból adódnak, hogy az ügyintézők későn veszik fel az új ügyeket.
Hol szerezhető be?
Az ügy állapotmezőjének aktív munkavégzést jelző értékre, például „Folyamatban” értékre váltásából következtethetünk rá. A konkrét állapotértékek beállíthatók, ezért ellenőrizni kell őket.
Rögzítés
A „state” mező változásának észlelése függő állapotból aktív értékre (például „New” értékről „Work in Progress” értékre).
Eseménytípus
inferred
|
|||
|
Újranyitott szolgáltatási kérés
|
Akkor történik, amikor egy korábban megoldott szolgáltatási kérés ismét aktív állapotba kerül, mert a probléma visszatért, vagy a megoldás nem volt hatásos. Ez a „Resolved” állapotról „Work in Progress” állapotra váltás észlelésével állapítható meg. | ||
|
Miért fontos?
Az újranyitott ügyek közvetlenül jelzik a megoldás minőségét, és az ismételt munkavégzés egyik fő okai. Elemzésük elengedhetetlen az első kapcsolatfelvételkor történő megoldási arány és az ügyfélelégedettség javításához.
Hol szerezhető be?
Az sn_customerservice_case tábla auditelőzményeiből azonosítható, ha a state mező „Resolved” értékről aktív állapotra vált.
Rögzítés
A „state” mező „Resolved” értékről aktív értékre, például „Work in Progress” értékre váltásának észlelése.
Eseménytípus
inferred
|
|||
Útmutatók az adatok kinyeréséhez
Kezdheti?
Használja ezt a sablont az adatok hatékony előkészítéséhez, hogy feltárhassa a folyamat működését és fejleszthesse ügyfélszolgálatát. Tegye meg az első lépést egy hatékonyabb, ügyfélközpontúbb folyamat felé.
Növelje ügyfélszolgálata hatékonyságát
Növelje az ügyfelek elégedettségét, és érje el, hogy a kérelmek 80%-a már az első kapcsolatfelvételkor megoldódjon.
Nincs szükség bankkártyára. Néhány perc alatt elkezdheti.