Incidenskezelési adatmintája
Incidenskezelési adatmintája
- Javasolt attribútumok
- A folyamattérképezéshez követendő fő tevékenységek
- Gyakorlati útmutató az adatok kinyeréséhez
Az incidenskezelés attribútumai
| Név | Leírás | ||
|---|---|---|---|
|
Esemény időbélyege
EventTimestamp
|
A tevékenység pontos dátuma és időpontja. | ||
|
Leírás
Ez az időbélyeg rögzíti, hogy az incidens életciklusának egy eseménye pontosan mikor történt, például mikor adtak hozzá megjegyzést vagy változtatták meg az állapotot. Segítségével időrendbe állíthatók az eset összes tevékenysége. Ez az attribútum minden időalapú process mining elemzéshez nélkülözhetetlen. A tevékenységek közötti átfutási idők kiszámítására, a várakozási idők feltárására, az eset teljes időtartamának mérésére és a folyamat teljesítményének különböző időszakok szerinti elemzésére használható. A pontos időbélyegek szükségesek az esetek időbeli alakulását bemutató animált folyamattérképhez és a teljesítmény-dashboardokhoz, amelyek például az átlagos megoldási időt mérő KPI-kat követik.
Miért fontos?
Az időbélyegek időrendi összefüggésbe helyezik a tevékenységeket. Segítségükkel kiszámíthatók az időtartamok, feltárhatók a szűk keresztmetszetek, és elemezhető a folyamat teljesítményének időbeli alakulása.
Hol szerezhető be?
Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), az egyes auditbejegyzések created_at mezője.
Példák
2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
|
|||
|
Incidensazonosító
TicketId
|
A rendszer által minden incidensjegyhez létrehozott egyedi azonosító. | ||
|
Leírás
Az incidensazonosító a Zendesk Supportban minden esetet egyedileg azonosító elsődleges kulcs. A process miningben ez a CaseId, amely összekapcsolja az incidens létrehozásától a lezárásáig tartó összes kapcsolódó tevékenységet, állapotváltozást és kommunikációt. Az elemzés során ez az azonosító elengedhetetlen minden incidens teljes folyamatának rekonstruálásához. Segítségével összesíthetők az eseményadatok, és mérhetők az egyes esetek mutatói, például a teljes megoldási idő, az átadások száma és a szolgáltatási szintre vonatkozó vállalások teljesülése. Az eseményeket azonosító szerint csoportosítva az elemzők megjeleníthetik a folyamatokat, feltárhatják a gyakori útvonalakat, és észrevehetik az előírt eljárástól való eltéréseket.
Miért fontos?
Ez az azonosító kapcsolja össze az összes eseményt egyetlen incidenssel. Így nyomon követhető a teljes életciklus, és pontosan elemezhető a folyamat teljesítménye.
Hol szerezhető be?
Zendesk Tickets API (/api/v2/tickets/{id}), id mező.
Példák
19428230113521941055
|
|||
|
Adatok utolsó frissítése
LastDataUpdate
|
Az időbélyeg, amely jelzi, mikor frissítették utoljára a folyamat adatait. | ||
|
Leírás
Ez az attribútum rögzíti a forrásrendszerből történő legutóbbi adatkinyerés vagy frissítés dátumát és időpontját. Általában egyetlen érték vonatkozik az adott frissítési ciklus teljes adatkészletére. Ez az információ fontos az adatirányítás és a process mining elemzés felhasználói számára. Megmutatja, mennyire frissek az adatok, így az elemzők tudják, hogy az elérhető legújabb információkat látják-e. Ez különösen fontos a működési teljesítmény nyomon követéséhez és az elemzés alapján hozott időszerű döntésekhez.
Miért fontos?
Megmutatja, mennyire frissek az adatok, így a felhasználók tudják, mennyire aktuális az elemzés, és mikor származtak utoljára adatok a forrásrendszerből.
Hol szerezhető be?
Az ETL/adatfolyamat által az adatfrissítés befejezésekor létrehozott időbélyeg.
Példák
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Forrásrendszer
SourceSystem
|
A rendszer, amelyből az incidensadatokat kinyerték. | ||
|
Leírás
Ez az attribútum azonosítja a folyamatadatok forrását. Ebben a nézetben az értéke állandó, például „Zendesk Support”, ami azt jelzi, hogy minden esemény és attribútum ebből a rendszerből származik. Ha több rendszer adatait egyesítik, ez a mező segít megkülönböztetni az adatforrásokat. Támogatja az adatok integritásának megőrzését, és lehetővé teszi a forrásonkénti elemzést, például a Zendesk és egy másik ITSM-eszköz incidenskezelési folyamatának összehasonlítását.
Miért fontos?
Azonosítja az adatok forrását. Ez fontos az adatirányítás és a több forrásrendszer adatait egyesítő elemzések szempontjából.
Hol szerezhető be?
Az adatátalakítás során beállított állandó érték, amely azonosítja az adatok forrását.
Példák
Zendesk SupportZendesk
|
|||
|
Tevékenység
ActivityName
|
Az incidens életciklusának egy adott pontján végrehajtott üzleti tevékenység vagy bekövetkezett esemény neve. | ||
|
Leírás
Ez az attribútum az incidenskezelési folyamat egy konkrét lépését vagy műveletét írja le, például az „Incidens létrehozva”, a „Jegy ügyintézőhöz rendelve” vagy az „Incidens megoldva” tevékenységet. Ezek a Zendesk eseménynaplójából vagy auditnyomvonalából származnak, ahol a rendszer rögzíti a változásokat. A process miningben ezeknek a tevékenységeknek a sorrendje adja a folyamattérkép alapját, amelyre az elemzés épül. A tevékenységek menetét elemezve a szervezetek feltárhatják az incidensek tényleges útvonalait, azonosíthatják a lépések közötti szűk keresztmetszeteket, mérhetik az ismételt munkát, például egy megoldott jegy újbóli megnyitását, és ellenőrizhetik, hogy a folyamat megfelel-e az előírt szabványnak.
Miért fontos?
A tevékenységek sorrendje határozza meg a folyamat menetét. Ez a process mining elemzés alapja, amely segít feltárni a hatékonysági problémákat, az eltéréseket és a fejlesztési lehetőségeket.
Hol szerezhető be?
A Zendesk Ticket Audits API eseményeiből származik. Például a „status” mező „Change” eseménye „Status Changed” tevékenységként jeleníthető meg.
Példák
Incidens létrehozvaJegy ügyintézőhöz rendelveAz állapot „Pending” értékre változottIncidens megoldvaIncidens lezárva
|
|||
|
Bejelentési csatorna
Channel
|
Az a csatorna, amelyen az incidenst először bejelentették, például „E-mail”, „Web” vagy „API”. | ||
|
Leírás
Ez az attribútum rögzíti, hogy a végfelhasználó vagy a rendszer milyen módon hozta létre az incidensjegyet. A csatorna ismerete segít elemezni, honnan érkeznek az incidensek, és ennek megfelelően alakítani az ügyfélszolgálati folyamatot. A csatornánkénti elemzés eltérő mintázatokat tárhat fel. A telefonon bejelentett incidensek például gyorsabban oldódhatnak meg, mint az e-mailben érkezők. Ez az adat támogatja az „Incidensek áteresztési volumene” dashboardot, valamint az erőforrás-tervezést és a csatornák fejlesztését.
Miért fontos?
Segít a bejelentési forrás szerinti incidensmennyiség és folyamatteljesítmény elemzésében, így célzottan fejleszthetők az egyes csatornák folyamatai, és tervezhetők az erőforrások.
Hol szerezhető be?
Zendesk Tickets API, via.channel mező.
Példák
webe-mailAPItelefon
|
|||
|
Esemény befejezési ideje
EventEndTime
|
Az időbélyeg, amely jelzi, mikor fejeződött be egy tevékenység. | ||
|
Leírás
Az esemény befejezési ideje jelzi a tevékenység végét. Az eseménynaplóban egy tevékenység befejezési idejét gyakran az adott eset következő tevékenységének kezdési idejéből állapítják meg. Az eset utolsó tevékenységénél a befejezési idő megegyezhet a kezdési idővel. Ez az attribútum szükséges az egyes tevékenységek időtartamának (ProcessingTime) és a tevékenységek közötti várakozási időnek a kiszámításához. Ezek az adatok alapozzák meg a szűk keresztmetszetek elemzését: megmutatják, mennyi ideig tart egy lépés, és azt is, mennyi ideig nem történt előrelépés az esetben a lépés megkezdése előtt.
Miért fontos?
Lehetővé teszi a tevékenységek időtartamának és a várakozási időknek a kiszámítását, ami a szűk keresztmetszetek részletes elemzésének és a folyamatkésések feltárásának alapja.
Hol szerezhető be?
Az adott eset következő eseményének kezdési ideje alapján számítható ki. Az utolsó esemény befejezési ideje megegyezhet a kezdési idővel vagy az eset lezárásának időpontjával.
Példák
2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
|
|||
|
Felelős csoport
AssignedGroup
|
Az incidens kezelésére jelenleg kijelölt ügyfélszolgálati csapat vagy csoport. | ||
|
Leírás
Ez az attribútum jelzi, melyik csapat felel az incidensért. Az incidensek gyakran kerülnek át különböző támogatási szintek vagy szakterületi csoportok között, például az „L1 Support” csapattól a „Network Team” csapathoz. Ez fontos szempont a feladatátadások elemzéséhez és a szűk keresztmetszetek feltárásához. A csoportok közötti incidensáramlás követésével az elemzők mérhetik a csapatok egymásrautaltságát, kiszámíthatják az egyes csapatok várakozási idejét, és javíthatják az irányítási szabályokat. Az attribútum közvetlenül támogatja a „Feladatátadások és ismételt munka elemzése” dashboardot.
Miért fontos?
Követi, melyik csapat felel az incidensért. Ez segít elemezni a csapatok közötti átadásokat, feltárni a csapatszintű szűk keresztmetszeteket és mérni a várakozási időket.
Hol szerezhető be?
Zendesk Tickets API, group_id mező. A változásokat a Ticket Audits API naplózza.
Példák
L1 támogatásL2 hálózati csapatL3 infrastruktúraSzámlázás
|
|||
|
Felelős ügyintéző
Assignee
|
Az incidens kezelésére jelenleg kijelölt ügyfélszolgálati munkatárs. | ||
|
Leírás
Ez az attribútum azonosítja, hogy egy adott időpontban ki felel az incidensért. A felelős személyének változása fontos esemény, mert azt jelzi, hogy a munka egyik munkatárstól a másikhoz kerül. A felelős ügyintéző elemzésével feltárható a munkaterhelés megoszlása, az egyéni teljesítmény és az együttműködés mintázata. A mező változásainak követése szükséges az „Incidensenkénti átlagos átadások” KPI kiszámításához, és segít azonosítani azokat az eseteket, amikor az incidens gyakran kerül másik munkatárshoz. Ez tudáshiányra vagy nem hatékony irányításra utalhat.
Miért fontos?
Azonosítja a felelős ügyintézőt, így elemezhető a munkaterhelés és a feladatátadások száma, valamint feltárhatók a folyamat hiányosságai.
Hol szerezhető be?
Zendesk Tickets API, assignee_id mező. A változásokat a Ticket Audits API naplózza.
Példák
John SmithJane DoeÜgyfélszolgálati automatizálás
|
|||
|
Jegy állapota
TicketStatus
|
Az incidensjegy állapota az esemény időpontjában, például „Open”, „Pending” vagy „Solved”. | ||
|
Leírás
Ez az attribútum az incidensjegy állapotát mutatja az életciklus különböző pontjain. A Zendesk szabványos állapotai: new, open, pending, on-hold, solved és closed. A mező változásainak követése az egyik fő módja annak, hogy a process mininghez szükséges tevékenységeket előállítsuk. A jegy állapotának elemzése alapvető a folyamat megértéséhez. Megmutatja, mennyi időt töltenek az incidensek az egyes állapotokban. A „Pending” állapot például gyakran azt jelzi, hogy az ügyfél válaszára várnak. Az állapot a folyamat befejezésének meghatározásához és a megoldási idő kiszámításához is fontos.
Miért fontos?
Az állapotváltozások követése segít megérteni a folyamat előrehaladását, feltárni a várakozási időket, valamint meghatározni az incidens életciklusának kezdetét és végét.
Hol szerezhető be?
Zendesk Tickets API, status mező. A változásokat a Ticket Audits API naplózza.
Példák
újnyitottfüggőbenmegoldvalezárva
|
|||
|
Prioritás
TicketPriority
|
Az incidenshez rendelt prioritási szint, például „Alacsony”, „Normál”, „Magas” vagy „Sürgős”. | ||
|
Leírás
Az incidens prioritása határozza meg, milyen gyorsan kell reagálni és megoldani az esetet. A prioritás az ügyfélszolgálati csapat munkaszervezését és erőforrás-elosztását is befolyásolja. A folyamatelemzés során a prioritás alapján csoportosíthatók az incidensek, így összehasonlítható a folyamatuk és a teljesítményük. Például ellenőrizhető, hogy a „Sürgős” incidensek valóban gyorsabban oldódnak-e meg, mint az „Alacsony” prioritásúak. A prioritás az SLA-k betartásának nyomon követésére is használható, mivel az SLA-k gyakran a prioritási szinttől függnek. A „Prioritásváltozási arány” KPI kiszámításához szintén szükség van a mező változásainak követésére.
Miért fontos?
Az attribútum alapján csoportosítható az elemzés, értékelhető a prioritások meghatározása, és nyomon követhető az SLA-k betartása az egyes sürgősségi szinteken.
Hol szerezhető be?
Zendesk Tickets API, priority mező. A változásokat a Ticket Audits API naplózza.
Példák
alacsonynormálmagassürgős
|
|||
|
SLA-állapot
SlaStatus
|
Az incidenshez tartozó szolgáltatási szint megállapodás (SLA) aktuális állapota. | ||
|
Leírás
Ez az attribútum jelzi, hogy az incidens várhatóan teljesíti-e a meghatározott SLA-célokat, már túllépte-e azokat, vagy szünetel az SLA-időmérés. A Zendesk a beállított szabályzatok alapján automatikusan követi az SLA-mutatókat. Ez az attribútum közvetlenül megjelenik az „SLA-megfelelés nyomon követése” dashboardon, és megmutatja, hogyan teljesülnek a szolgáltatási vállalások. Az SLA-túllépések időpontjának és okának elemzésével feltárhatók a folyamat gyenge pontjai, és javítható a szolgáltatás megbízhatósága. Az adat az „Incidensek SLA-teljesítési aránya” KPI kiszámítását is támogatja.
Miért fontos?
Közvetlenül méri a szolgáltatási vállalások teljesítését, így elemezhetők az SLA-túllépések, és időben észlelhetők a megfelelés javításához szükséges problémák.
Hol szerezhető be?
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), az olyan mezőkből származtatva, mint a sla_policy és a breached_at.
Példák
AktívSzüneteltetveTúllépveTeljesítve
|
|||
|
Automatizált
IsAutomated
|
Logikai jelző, amely megmutatja, hogy egy tevékenységet automatizált rendszer vagy emberi ügyintéző végzett-e. | ||
|
Leírás
Ez a származtatott attribútum megkülönbözteti az emberi felhasználók által végzett eseményeket a rendszerautomatizálások, triggerek vagy API-integrációk által végrehajtottaktól. Az érték általában annak ellenőrzésével állapítható meg, hogy az esemény szerzője ismert rendszerfelhasználó-e. Az automatizálás mértékének ismerete fontos a modern folyamatelemzésben. Segít felmérni az automatizálási szabályok eredményességét, azonosítani az automatizálható kézi feladatokat, valamint mérni az automatizálás hatását a hatékonyságra és a megoldási időre. Az attribútummal összehasonlíthatók az automatizált és a kézi tevékenységek folyamatai.
Miért fontos?
Megkülönbözteti az emberi és a rendszer által végzett műveleteket, így elemezhető az automatizálás hatása a folyamat hatékonyságára, és feltárhatók az újabb automatizálási lehetőségek.
Hol szerezhető be?
Annak ellenőrzésével származtatható, hogy az esemény szerzője (author_id a Ticket Audits API-ban) ismert rendszer- vagy automatizálási felhasználó-e.
Példák
truefalse
|
|||
|
Bejelentő
Submitter
|
Az incidens eredeti bejelentője, aki lehet végfelhasználó vagy rendszer. | ||
|
Leírás
Ez az attribútum azonosítja azt a személyt vagy szervezetet, aki létrehozta a jegyet. Nem azonos a kérelmezővel, mert előfordulhat, hogy egy ügyintéző más nevében hoz létre jegyet. Az elemzésben a bejelentő adatai megmutatják, ki jelzi a problémákat. Szervezeti adatokkal együtt vizsgálva azonosíthatók azok az ügyfelek vagy felhasználói csoportok, amelyeknél sok incidens fordul elő. Ez segíthet a megelőző ügyféltámogatási és képzési intézkedések megtervezésében.
Miért fontos?
Azonosítja az incidens bejelentésének forrását, így feltárhatók az egyes felhasználókhoz, részlegekhez vagy automatizált rendszerekhez kapcsolódó mintázatok.
Hol szerezhető be?
Zendesk Tickets API, submitter_id mező.
Példák
alice.jones@example.combob.williams@example.comRendszerfigyelő
|
|||
|
Címkék
Tags
|
Az incidenshez rendelt címkék listája, amelyek besorolást és további kontextust adnak. | ||
|
Leírás
A címkék rugalmas jelölések, amelyekkel további kontextus adható a jegyekhez, illetve segíthető a besorolásuk és irányításuk. Az ügyintézők kézzel is hozzáadhatják őket, de triggerek és automatizálások is beállíthatják. A címkék sok hasznos adatot adnak a process mining elemzéshez. Részletes csoportosításra is alkalmasak, például egy adott termékbevezetéshez kapcsolódó incidensek („launch_q4”) vagy egy ismert szolgáltatáskiesés („outage_20231027”) kiszűrésére. Így a szokásos jegymezőkön túlmutató, célzott vizsgálatok is végezhetők.
Miért fontos?
Rugalmasan kategorizálhatók és szűrhetők velük az incidensek, így olyan részletes, kontextushoz kötött elemzés is végezhető, amelyre a szokásos mezők önmagukban nem adnak lehetőséget.
Hol szerezhető be?
Zendesk Tickets API, tags mező.
Példák
kiemelt_felhasználóhálózati_problémaszolgáltatáskiesés_20231027számlázással_kapcsolatos
|
|||
|
Elégedettségi értékelés
SatisfactionRating
|
A végfelhasználó által az incidens megoldása után adott elégedettségi értékelés. | ||
|
Leírás
Ez az attribútum az ügyfél visszajelzését rögzíti az ügyféltámogatási tapasztalatról. Az értékelést általában a jegy megoldása után, kérdőívben gyűjtik be. A Zendeskben gyakori értékelések a „Jó” és a „Rossz”. Az elégedettségi értékelés nem közvetlenül a folyamat hatékonyságát méri, de fontos eredménymutató. A process mining segítségével összevethető a folyamatváltozatokkal, így kiderülhet, mely megoldási útvonalak járnak nagyobb ügyfélelégedettséggel. Például alacsonyabb értékelést kapnak-e azok az incidensek, amelyeknél több feladatátadás történt?
Miért fontos?
Fontos eredménymutatót ad, amely összevethető a folyamat jellemzőivel. Így megérthető, hogyan hat a folyamatteljesítmény a felhasználói elégedettségre.
Hol szerezhető be?
Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json), satisfaction_rating.score mező.
Példák
jórosszfelajánlvanem ajánlották fel
|
|||
|
Első kapcsolatfelvételkor megoldva
IsFirstContactResolution
|
Logikai jelző, amely akkor igaz, ha az incidens az elsőként kijelölt ügyintéző vagy csoport közreműködésével, átadás nélkül oldódott meg. | ||
|
Leírás
Az első kapcsolatfelvételkor történő megoldás (FCR) az ügyfélszolgálati központ hatékonyságának és az ügyfélelégedettségnek fontos mutatója. Ez a számított attribútum jelzi azokat az incidenseket, amelyeket úgy oldottak meg, hogy nem kerültek át másik ügyintézőhöz vagy csapathoz. A számítás általában azt ellenőrzi, hogy a jegy „Megoldva” állapotba került-e úgy, hogy közben az eredeti ügyintéző és csoport maradt kijelölve. A process mining segítségével közvetlenül kiszámítható az FCR-arány, és összehasonlíthatók az FCR-esetek útvonalai azokéval, amelyek eszkalációt igényeltek. Ez segít feltárni, hogyan kaphat nagyobb döntési lehetőséget az első vonalbeli ügyfélszolgálat.
Miért fontos?
Közvetlenül méri az első ügyfélszolgálati kapcsolat hatékonyságát, és segít feltárni, hogyan lehet a folyamat korábbi szakaszában megoldani az incidenseket.
Hol szerezhető be?
Számított logikai jelző. Akkor igaz, ha a jegy állapota „megoldva” vagy „lezárva”, és az incidens teljes életciklusa alatt csak egy egyedi felelős ügyintéző vagy csoport volt kijelölve.
Példák
truefalse
|
|||
|
Eset időtartama
CaseDuration
|
Az incidens létrehozásától a végleges lezárásáig eltelt teljes idő. | ||
|
Leírás
Ez a számított mutató egyetlen incidens teljes átfutási idejét jelzi. Az első esemény (például „Incidens létrehozva”) és az utolsó esemény (például „Incidens lezárva”) időbélyege közötti különbségből számítható ki. Az eset időtartama a teljes folyamat hatékonyságának egyik fő KPI-ja. A dashboardokon az átlagos átfutási idő megjelenítésére, a hosszan elhúzódó esetek feltárására és az időbeli trendek elemzésére használják. Átfogó képet ad arról, milyen gyorsan kezeli és oldja meg a folyamat az incidenseket.
Miért fontos?
Fontos KPI a folyamat általános sebességének méréséhez és a hosszú megoldási időt okozó tényezők feltárásához.
Hol szerezhető be?
Az egyes Incident ID-k esetében az utolsó és az első esemény időbélyege közötti különbségből számítható ki.
Példák
25920060480086400
|
|||
|
Feladatátadások száma
HandoffCount
|
Az alkalmak száma, ahányszor az incidenst másik ügyintézőhöz vagy csoporthoz rendelték. | ||
|
Leírás
Ez a számított mutató azt méri, hányszor került át az incidensért viselt felelősség. Az Assignee vagy AssignedGroup mező minden változása növeli az esethez tartozó értéket. Az incidenskezelésben a feladatátadások gyakran okoznak hatékonyságvesztést és késedelmet. A magas érték arra utalhat, hogy az irányítási szabályok nem egyértelműek, hiányos a csapatok tudása, vagy túl bonyolult a folyamat. Ez a mutató az „Incidensenkénti átlagos átadások” KPI alapja, és fontos a „Feladatátadások és ismételt munka elemzése” dashboardhoz.
Miért fontos?
Méri az átadások okozta folyamatbeli súrlódást, és segít feltárni azokat az irányítási hiányosságokat és tudáshiányokat, amelyek meghosszabbítják a megoldási időt.
Hol szerezhető be?
Az incidens AssignedGroup vagy Assignee mezőjében történt változások számából számítható ki.
Példák
0135
|
|||
|
Jegytípus
TicketType
|
A jegy besorolása, például „Incidens”, „Probléma”, „Kérdés” vagy „Feladat”. | ||
|
Leírás
Ez a mező a kérés jellege alapján sorolja be a jegyet. Az incidenskezelési folyamat azokra a jegyekre összpontosít, amelyek típusa „Incidens”, vagyis egy IT-szolgáltatás nem tervezett megszakadását vagy minőségromlását jelzik. Az elemzésben ezt az attribútumot elsősorban szűrőként használjuk, hogy a folyamatnézet csak az incidenseket tartalmazza. Tágabb ITSM-elemzéshez is felhasználható, például az incidensek, problémák és szolgáltatási kérések kezelésének összehasonlítására.
Miért fontos?
Az adatok incidensekre szűrésével biztosítja, hogy a folyamatelemzés az incidenskezelés életciklusára összpontosítson.
Hol szerezhető be?
Zendesk Tickets API, type mező.
Példák
incidensproblémakérdésfeladat
|
|||
|
Kiváltó ok kategóriája
RootCauseCategory
|
Az incidens kiváltó okának fő kategóriája. | ||
|
Leírás
Ez az attribútum az incidens alapvető okának besorolására szolgál. Általában az incidens életciklusának végén rögzítik, például az utólagos elemzés vagy a problémakezelési folyamat részeként, egy egyéni mezőben. Az adat szükséges a „Kiváltó okok azonosításának pontossága” dashboardhoz és az „RCA-lefedettség” KPI-hoz. A kiváltó okok szerinti elemzés feltárja a visszatérő problémákat, és segít tartós megoldásokat bevezetni, hogy a jövőben kevesebb incidens forduljon elő. Így a reaktív hibaelhárítás helyett a problémák megelőzésére kerülhet a hangsúly.
Miért fontos?
A kiváltó okok kategorizálásával támogatja a megelőző problémakezelést, segít feltárni a trendeket és megelőzni az újabb incidenseket.
Hol szerezhető be?
Ez általában egyéni jegymező. A Zendesk Admin Centerben ellenőrizze a Ticket Fields beállításait.
Példák
SzoftverhibaHardverhibaFelhasználói hibaHálózati kimaradás
|
|||
|
Súlyosság
Severity
|
Az incidens üzleti működésre gyakorolt hatásának mértéke. | ||
|
Leírás
A súlyosság az incidens üzleti hatását jelzi. A prioritással együtt gyakran az eset sürgősségének meghatározására használják. A Zendeskben ezt általában egyéni mezőként állítják be. A súlyosság elemzésével felmérhető a kezelt incidensek jelentősége. Az „SLA-megfelelés nyomon követése” és a „Prioritáskezelés eredményességének mutatói” dashboardokon az adatok csoportosítására is használható. A különböző súlyosságú incidensek folyamatainak összehasonlítása megmutathatja, hogy a legsúlyosabb esetek kezelése megfelelő gyorsasággal és erőforrásokkal történik-e.
Miért fontos?
Jelzi az incidens üzleti hatását, így az elemzés a legsúlyosabb problémákra összpontosíthat, és ellenőrizhető, hogy azok hatékonyan oldódnak-e meg.
Hol szerezhető be?
Ez általában egyéni mező. A Zendesk Admin Centerben ellenőrizze a Ticket Fields beállításait.
Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
|
|||
|
Ügyfélszervezet
Organization
|
Az a szervezet vagy vállalat, amelyhez az incidens kérelmezője tartozik. | ||
|
Leírás
Ez az attribútum összekapcsolja az incidenst az ügyfél szervezetével. B2B ügyféltámogatásban különösen hasznos, mert a szolgáltatási szintek és a támogatási folyamatok ügyfelenként eltérhetnek. A szervezetenkénti elemzés segít nyomon követni az ügyfelek helyzetét, feltárni az egyes ügyfeleket érintő visszatérő problémákat, és ellenőrizni a szerződéses vállalások teljesítését. A dashboardok és jelentések szűrésével az ügyfél szempontjából is áttekinthetővé válik a teljesítmény.
Miért fontos?
Lehetővé teszi az ügyfelenkénti elemzést, így nyomon követhetők a szolgáltatási szintek, feltárhatók a kiemelt ügyfelekre jellemző trendek, és hatékonyabban kezelhetők az ügyfélkapcsolatok.
Hol szerezhető be?
Zendesk Tickets API, organization_id mező.
Példák
Global Tech Inc.Innovate SolutionsData Corp
|
|||
Az incidenskezelés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
|
Az állapot „Open” értékre változott
|
Azt jelzi, hogy az ügyintéző megkezdte az incidens aktív kezelését. Ez a tevékenység általában abból állapítható meg, hogy a jegy „status” mezője „new” értékről „open” értékre változik. Ezzel kezdődik a kivizsgálás és a diagnózis. | ||
|
Miért fontos?
Ez az esemény jelzi az átmenetet a várakozásból az aktív munkavégzésbe. Az első válaszidő fontos mutatója, hogy mennyi idő telik el, amíg a jegy „new” állapotból „open” állapotba kerül.
Hol szerezhető be?
A jegy auditnaplójából állapítható meg: olyan „Change” eseményt kell keresni, amelynél a „status” mező új értéke „open”, korábbi értéke pedig „new”.
Rögzítés
A „status” mező „new” értékről „open” értékre történő változásából állapítható meg.
Eseménytípus
inferred
|
|||
|
Incidens létrehozva
|
Az incidens életciklusa akkor kezdődik, amikor új jegy jön létre a Zendeskben. Ezt az eseményt a Zendesk jegylétrehozási auditnaplója rögzíti, így minden esetnél egyértelműen meghatározható a kezdőpont. | ||
|
Miért fontos?
Ez a folyamat elsődleges kezdőtevékenysége. Az esemény és a későbbi lépések közötti idő elemzésével mérhető a jegy teljes életciklusának hossza és az első válasz ideje.
Hol szerezhető be?
Ez a Zendesk jegyauditnaplóiban rögzített, egyértelmű esemény. Minden új jegyhez tartozik egy időbélyeggel ellátott „Create” esemény.
Rögzítés
Közvetlenül a jegy létrehozásakor keletkező auditnapló-bejegyzésből.
Eseménytípus
explicit
|
|||
|
Incidens lezárva
|
Az incidens életciklusa akkor ér véget, amikor a jegyet véglegesen lezárják. A Zendeskben ez gyakran a megoldás után meghatározott idő elteltével automatikusan történik, és végső állapotváltozásként jelenik meg. | ||
|
Miért fontos?
Ez a folyamat végleges zárótevékenysége. A teljes folyamat időtartama az „Incident Created” eseménytől eddig az eseményig számítható ki, így a teljes átfutási idő mérhető.
Hol szerezhető be?
A jegy auditnaplójából nyerhető ki egy „Change” esemény alapján, amelynél a „status” mező új értéke „closed”.
Rögzítés
A „status” mező „closed” értékre változását rögzítő „Change” esemény alapján azonosítható.
Eseménytípus
explicit
|
|||
|
Incidens megoldva
|
Ez a fontos mérföldkő akkor következik be, amikor az ügyintéző megoldja a problémát, és a jegyet „solved” állapotúra állítja. A művelet egyértelműen megjelenik a jegy auditnaplójában rögzített állapotváltozásként. | ||
|
Miért fontos?
Ez a folyamat elsődleges megoldási tevékenysége, és fontos mérföldkő a megoldási idő mérésében. Az esemény és az „Incident Closed” közötti idő a felhasználói visszaigazolásra vagy az automatikus lezárásra várakozást jelzi.
Hol szerezhető be?
A jegy auditnaplójából nyerhető ki egy „Change” esemény alapján, amelynél a „status” mező új értéke „solved”.
Rögzítés
A „status” mező „solved” értékre változását rögzítő „Change” esemény alapján azonosítható.
Eseménytípus
explicit
|
|||
|
Jegy ügyintézőhöz rendelve
|
Ez a tevékenység akkor történik, amikor egy jegyet egy adott ügyintézőhöz rendelnek. A jegy auditnaplójában rögzített, egyértelmű esemény jelzi, hogy egy adott személy átvette az ügyet. | ||
|
Miért fontos?
Ez a mérföldkő elengedhetetlen az első hozzárendelésig eltelt idő méréséhez, és alapot ad az átadások, az ismételt munka, valamint az első kapcsolatfelvételkor megoldott esetek arányának elemzéséhez.
Hol szerezhető be?
A jegy auditnaplójából olvasható ki, amikor az „assignee_id” mező értéket kap vagy megváltozik. Az első hozzárendelés fontos mérföldkő a KPI-k kiszámításához.
Rögzítés
A jegy auditnaplójában az „assignee_id” mezőhöz tartozó „Change” esemény alapján azonosítható.
Eseménytípus
explicit
|
|||
|
Jegy újra kiosztva
|
Akkor történik, amikor az első hozzárendelés után a jegy felelőse egy másik ügyintéző vagy csoport lesz. A jegy auditnaplója ezt egyértelmű eseményként rögzíti. | ||
|
Miért fontos?
Az újrakiosztások elemzése fontos az átadások és az ismételt munka feltárásához. Ha gyakran osztják ki újra a jegyeket, annak oka lehet a kezdeti hibás útválasztás, az ügyek összetettsége vagy a folyamat szűk keresztmetszete.
Hol szerezhető be?
A jegy auditnaplójából azonosítható, ha az „assignee_id” vagy a „group_id” mező első kitöltése után „Change” esemény történik.
Rögzítés
Az „assignee_id” vagy a „group_id” mezőhöz tartozó későbbi „Change” esemény alapján azonosítható.
Eseménytípus
explicit
|
|||
|
Az állapot „Pending” értékre változott
|
Azt jelzi, hogy a folyamat szünetel, mert a bejelentő válaszára vár. Ez az esemény abból állapítható meg, hogy a jegy „status” mezője „pending” értékre változik. | ||
|
Miért fontos?
Ez a tevékenység elengedhetetlen a felhasználói visszajelzésre várakozás idejének kiszámításához. Ha a jegy sokáig marad ebben az állapotban, jelentősen nőhet a teljes megoldási idő, ami kommunikációs késedelmekre utalhat.
Hol szerezhető be?
A jegy auditnaplójából állapítható meg: olyan „Change” eseményt kell keresni, amelynél a „status” mező új értéke „pending”.
Rögzítés
A „status” mező „pending” értékre történő változásából állapítható meg.
Eseménytípus
inferred
|
|||
|
Belső megjegyzés hozzáadva
|
Ez a tevékenység a belső együttműködést jelzi: az ügyintéző privát megjegyzést fűz a jegyhez a csapattagok számára. A rendszer egyértelműen rögzíti, ha a megjegyzés nem nyilvános. | ||
|
Miért fontos?
A belső megjegyzések elemzése megmutathatja, mely összetett ügyek igényelnek együttműködést. A túl sok megjegyzés azonban hiányos ismeretekre vagy a folyamat hatékonysági problémáira is utalhat.
Hol szerezhető be?
A jegyhez tartozó megjegyzések adataiból nyerhető ki. A megjegyzés akkor belső, ha a „public” attribútum értéke false.
Rögzítés
Akkor keletkezik esemény, amikor a jegyhez új, „public: false” értékű megjegyzést adnak.
Eseménytípus
explicit
|
|||
|
Felhasználói elégedettség értékelve
|
Azt jelzi, amikor a végfelhasználó értékeli a kapott támogatást. A Zendesk ezt egyértelmű eseményként rögzíti a jegy megoldása után. | ||
|
Miért fontos?
Az elégedettségi értékelések elemzése fontos visszajelzést ad az ügyintézők teljesítményéről és a folyamat hatékonyságáról. Így a folyamatmutatók összekapcsolhatók az ügyfelek tapasztalataival.
Hol szerezhető be?
A jegyhez tartozó elégedettségi értékelések adataiból nyerhető ki. Ezek jellemzően egy pontszámot („good” vagy „bad”) és egy opcionális megjegyzést tartalmaznak.
Rögzítés
Akkor keletkezik esemény, amikor értékelést küldenek be a jegyhez.
Eseménytípus
explicit
|
|||
|
Jegy csoporthoz rendelve
|
Az incidens kezdeti útválasztását vagy előzetes besorolását jelzi egy adott támogatási csoporthoz. Ez általában a felelősség kijelölésének első lépése, és a jegy auditnaplójában rögzített, egyértelmű változásként jelenik meg. | ||
|
Miért fontos?
A csoporthoz rendelés nyomon követésével elemezhető az első besorolás hatékonysága, és feltárhatók azok a késedelmek, amelyek még azelőtt jelentkeznek, hogy a jegy a megfelelő csapathoz kerülne.
Hol szerezhető be?
A jegy auditnaplójából olvasható ki, amikor a „group_id” mező értéket kap vagy megváltozik. A létrehozás utáni első ilyen változás jelenti a kezdeti hozzárendelést.
Rögzítés
A jegy auditnaplójában a „group_id” mezőhöz tartozó „Change” esemény alapján azonosítható.
Eseménytípus
explicit
|
|||
|
Nyilvános válasz elküldve
|
Azt jelzi, hogy egy ügyintéző üzenetet küldött a végfelhasználónak. A Zendesk ezt egyértelmű eseményként rögzíti, amikor nyilvános megjegyzés kerül a jegybe. | ||
|
Miért fontos?
A nyilvános válaszok követése segít megérteni a kommunikáció gyakoriságát, és fontos része lehet az idővonalnak, amikor a felhasználói visszajelzésre várakozás idejét elemzi.
Hol szerezhető be?
A jegyhez tartozó megjegyzések adataiból nyerhető ki. A megjegyzés akkor nyilvános, ha a „public” attribútum értéke true.
Rögzítés
Akkor keletkezik esemény, amikor a jegyhez új, „public: true” értékű megjegyzést adnak.
Eseménytípus
explicit
|
|||
|
Prioritás beállítva
|
Meghatározzák az incidens prioritását, például alacsony, normál, magas vagy sürgős értékre. A változást egyértelmű esemény rögzíti, a prioritás pedig meghatározza a jegy sürgősségét és a szükséges válaszidőt. | ||
|
Miért fontos?
A prioritás beállításának időpontja és módja fontos adat a „Prioritás meghatározásának hatékonysága” dashboardhoz. Segítségével biztosítható, hogy a kritikus problémákat időben kezeljék.
Hol szerezhető be?
A jegy auditnaplójában a „priority” mezőhöz tartozó „Change” eseményből nyerhető ki. A későbbi módosítások is követhetők a prioritásváltozási arány KPI méréséhez.
Rögzítés
A jegy auditnaplójában a „priority” mezőhöz tartozó „Change” esemény alapján azonosítható.
Eseménytípus
explicit
|
|||
|
SLA-célérték nem teljesült
|
Azt jelzi, hogy a jegy nem teljesítette a meghatározott szolgáltatási szintre vonatkozó vállalást, például az első válasz vagy a megoldás határidejét. Az esemény az SLA-szabályok és a jegyfrissítések időbélyegei alapján számítható ki. | ||
|
Miért fontos?
Ez az esemény közvetlenül támogatja az SLA-k betartásának nyomon követését. A szolgáltatás megbízhatóságának és az ügyfelek bizalmának javításához alapvető annak feltárása, hogy mikor és miért sérülnek az SLA-k.
Hol szerezhető be?
Ez számított esemény. A jegyhez tartozó „sla_policy_metrics” adatok elemzésével állapítható meg, az egyes SLA-célértékek „breached_at” időbélyegét használva.
Rögzítés
A jegy SLA-mutatóinak adatai között szereplő „breached_at” időbélyegből származik.
Eseménytípus
calculated
|
|||
Útmutatók az adatok kinyeréséhez
Készen áll a kezdésre?
Használja ezt a mintát az adatok előkészítésének egyszerűsítéséhez, és tárja fel az incidenskezelési teljesítmény javításának lehetőségeit. Kezdje el még ma a folyamat fejlesztését.
Optimalizálja az incidenskezelést, és oldja meg gyorsabban az eseteket
Csökkentse 35%-kal az MTTR-t, szüntesse meg az ismétlődő incidenseket, és növelje az elégedettséget.
Nincs szükség bankkártyára, percek alatt elkezdheti a fejlesztést