Incidenskezelési adatmintája

Zendesk Support
Incidenskezelési adatmintája

Incidenskezelési adatmintája

Ez a minta rendszerezetten bemutatja, milyen adatokra van szükség az incidenskezelési folyamat elemzéséhez. Felsorolja a gyűjtendő fő attribútumokat és a követendő fontos tevékenységeket, valamint gyakorlati útmutatót ad az adatok Zendesk Supportból történő kinyeréséhez. Segítségével biztosíthatja, hogy process mining projektje megfelelő és teljes adatkészlettel induljon.
  • Javasolt attribútumok
  • A folyamattérképezéshez követendő fő tevékenységek
  • Gyakorlati útmutató az adatok kinyeréséhez
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Az incidenskezelés attribútumai

Az alábbi adatmezőket érdemes felvenni az eseménynaplóba az incidenskezelési folyamat részletes elemzéséhez.
5 Kötelező 7 Javasolt 11 Nem kötelező
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
Kötelező Javasolt Nem kötelező

Az incidenskezelés tevékenységei

Az alábbi fontos folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban a pontos feltáráshoz és elemzéshez.
6 Javasolt 7 Nem kötelező
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
Javasolt Nem kötelező

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a Zendesk Supportból

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.

Próbálja ki ingyen

Nincs szükség bankkártyára, percek alatt elkezdheti a fejlesztést