> Folyamatos folyamatfejlesztés > Problémakezelés > Zendesk Support > Adatsablon

Problémakezelési adatsablon

Zendesk Support

← Vissza a folyamatfejlesztési útmutatóhoz

Problémakezelési attribútumok(19) Problémakezelési tevékenységek(12) Adatkinyerési útmutatók(3)

Problémakezelési adatsablon

Ez a sablon keretet ad a Zendesk Support problémakezelési életciklusának feltérképezéséhez. Bemutatja azokat az alapvető attribútumokat, folyamatmérföldköveket és adatkinyerési szabályokat, amelyekkel azonosíthatók a kiváltó okok elemzésének szűk keresztmetszetei. A sablon alapján jó minőségű eseménynaplót készíthet, és részletesebben elemezheti a folyamatot.

Részletes elemzéshez javasolt attribútumok
Fontos folyamati tevékenységek és állapotváltások
Útmutató a Zendesk Support adatainak kinyeréséhez

Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Sablon letöltése

Problémakezelési attribútumok

Ezek az ajánlott adatmezők biztosítják a szükséges kontextust a jegykategóriák, prioritási szintek és felelősségi körök elemzéséhez a problémamegoldás teljes életciklusa során.

5 Kötelező 8 Javasolt 6 Nem kötelező

	Név	Leírás
	Forrásrendszer SourceSystem	Annak a rendszernek a neve, ahonnan az adatok származnak.
Leírás Ez az attribútum azonosítja azt a szoftverplatformot, amelyből a folyamatadatokat kinyerték. Ebben az esetben az értéke mindig „Zendesk Support”. Több rendszer adatainak, például a Zendesk és a Jira adatainak egyesítésekor az elemzők ezzel a mezővel szűrhetnek vagy csoportosíthatnak az adatok forrása szerint. Több rendszert érintő folyamatelemzésnél segít nyomon követni az adatok eredetét. Miért fontos? Nyomon követhetővé teszi az adatok eredetét, és támogatja a több rendszert használó process mining beállításokat. Hol szerezhető be? Az adatkinyerés során rögzített érték Példák Zendesk Support
	Kezdési idő EventTimestamp	Az a pontos dátum és időpont, amikor egy tevékenység történt.
Leírás Ez az attribútum rögzíti, hogy a Zendesk rendszerben pontosan mikor történt egy tevékenység. Segítségével az események helyes sorrendbe rendezhetők, és kiszámítható az egyes lépések közötti időtartam. Az elemzésben nélkülözhetetlen a ciklusidők kiszámításához, a késések feltárásához, az SLA-követelmények betartásának ellenőrzéséhez és a folyamat időbeli alakulásának megjelenítéséhez. Pontos időbélyegek nélkül nem állapítható meg, milyen gyorsan halad a problémamegoldás. Miért fontos? Lehetővé teszi a tevékenységek időrendi rendezését és az időalapú KPI-k kiszámítását. Hol szerezhető be? Zendesk Ticket Audits, „created_at” mező Példák 2023-10-12T08:30:00Z2023-10-12T09:15:22Z
	Problémarekord ProblemRecordId	A Zendeskben a problémát jelző jegyhez rendelt egyedi numerikus azonosító.
Leírás Ez az attribútum a Zendesk Support rendszerben tárolt problémarekord egyedi kulcsa. A process miningben ez szolgál központi esetazonosítóként: segítségével az összes további esemény, frissítés és interakció egyetlen folyamatpéldányba rendezhető. Az elemzés során ez az azonosító különbözteti meg egymástól az egyes problémavizsgálatokat a létrehozástól a lezárásig. Lehetővé teszi a kapcsolódó incidensek összekapcsolását, és a probléma életciklusának nyomon követését a különböző támogatási szinteken. Miért fontos? Ez az alapvető, kötelező azonosító, amelyre az események esetekbe rendezéséhez minden process mining elemzésben szükség van. Hol szerezhető be? Zendesk Ticket objektum, „id” mező, ahol a típus „problem” Példák 1045293849921
	Tevékenység ActivityName	A problémarekordon végrehajtott esemény vagy művelet neve.
Leírás Ez az attribútum rögzíti a problémarekord életciklusa során végrehajtott konkrét lépést vagy műveletet. Ilyen például az állapotváltás „Open” értékről „Pending” értékre, a hozzárendelés módosítása vagy egy adott munkafolyamat-lépés, például az átmeneti megoldás közzététele. Az elemzésben ezek alkotják a folyamattérkép csomópontjait. A tevékenységek sorrendje megmutatja a munka menetét, segít feltárni a szűk keresztmetszeteket, és mérni az egyes folyamatlépések közötti időt. Miért fontos? Megmutatja, hogy „mi” történik a folyamatban, így ábrázolható a folyamat menete és elemezhetők a folyamatváltozatok. Hol szerezhető be? A Zendesk Ticket Audits vagy Ticket Metrics adataiból származik. Példák Probléma rögzítveA vizsgálat megkezdődöttÁtmeneti megoldás közzétéve
	Utolsó adatfrissítés LastDataUpdate	Az időbélyeg, amely megmutatja, mikor módosították utoljára a problémarekordot.
Leírás Ez az attribútum azt mutatja, mikor frissítették legutóbb a problémarekord adatait a forrásrendszerben. Nem azonos az esemény időbélyegével, mert nem egy tevékenység, hanem a teljes rekord frissítési idejét jelzi. Az elemzésben segít megállapítani, mennyire frissek az adatok. Megmutatja, hogy az adatkészlet naprakész-e, illetve van-e szinkronizálási késés a forrásrendszer és a process mining környezet között. Miért fontos? Nyomon követi az adatok frissességét, és segíti a fokozatos adatbetöltési megoldások kialakítását. Hol szerezhető be? Zendesk Ticket objektum, „updated_at” mező Példák 2023-11-01T14:20:00Z
	Felelős ügyintéző neve AssigneeName	A problémával foglalkozó kijelölt ügyintéző.
Leírás Ez az attribútum annak a felhasználónak a nevét tartalmazza, aki jelenleg a problémarekordért felel. Részletesen megmutatja, ki hajtotta végre az egyes műveleteket. Az elemzésben segít megérteni az egyéni munkaterhelést és teljesítményt. A csoportszintű elemzés mellett az ügyintézőnkénti adatok képzési igényeket tárhatnak fel, illetve megmutathatják, kik oldják meg különösen hatékonyan az összetett, gyökérokokkal kapcsolatos problémákat. Miért fontos? Lehetővé teszi az erőforrások egyéni szintű elemzését. Hol szerezhető be? Zendesk Ticket objektum, „assignee_id” mező (névhez rendelve) Példák Kovács JánosKiss JúliaRendszer
	Kapcsolódó incidensek száma RelatedIncidentCount	A problémarekordhoz kapcsolt incidensjegyek száma.
Leírás Ez az attribútum megszámolja, hány incidensjegy kapcsolódik az adott problémarekordhoz. A Zendeskben az incidensjegyek „problem_id” mezője hivatkozik erre a rekordra. Az elemzésben ez az Incident Correlation and Impact elsődleges mutatója. Segít előre sorolni azokat a problémákat, amelyek a legtöbb felhasználót érintik, és megalapozni, mely javítások csökkenthetik a legnagyobb mértékben a jegyek számát. Miért fontos? Megmutatja a probléma súlyosságát és a felhasználókra gyakorolt hatását. Hol szerezhető be? Zendesk Tickets API, azon jegyek száma, amelyeknél a type='incident' és a problem_id=ThisID Példák 015342
	Kiváltóok-kategória RootCauseCategory	A probléma azonosított kiváltó oka (például kódhiba, konfigurációs hiba).
Leírás Ez az attribútum rögzíti a probléma végső diagnózisát, vagyis azt, hogy mi okozta a problémát. Általában a „Kiváltó ok azonosítása” tevékenység során töltik ki. Az elemzésben a „Problémák besorolásának pontossága” jelentés készítésére és a rendszerhibák tendenciáinak vizsgálatára használható. Segít a vezetőknek eldönteni, hogy a kódminőségre, az infrastruktúra stabilitására vagy a beszállítók kezelésére érdemes-e összpontosítani. Miért fontos? Segít feltárni a hibamintákat, és irányt ad a hosszú távú fejlesztéseknek. Hol szerezhető be? Zendesk-jegyek egyéni mezői Példák SzoftverhibaKonfigurációs hibaFelhasználói hiba
	Prioritás Priority	A problémarekordhoz rendelt sürgősségi szint.
Leírás Ez az attribútum a probléma relatív fontosságát jelzi. Értéke általában alacsony, normál, magas vagy sürgős. A prioritás határozza meg az elvárt szolgáltatási szintet (SLA) és az erőforrások elosztását. Az elemzésben a folyamat prioritás szerinti bontására és a különböző sürgősségi szintek teljesítményének összehasonlítására használható. Például ellenőrizhető, hogy a sürgős problémákat valóban gyorsabban oldják-e meg, mint az alacsony prioritásúakat, ahogyan azt a Root Cause Investigation Velocity dashboard elvárja. Miért fontos? Az esetek csoportosításával elemezhető az SLA-követelmények betartása és az erőforrások prioritás szerinti elosztása. Hol szerezhető be? Zendesk Ticket objektum, „priority” mező Példák SürgősMagasNormálAlacsony
	Probléma állapota ProblemStatus	A problémarekord aktuális állapota az életciklusban.
Leírás Ez az attribútum a probléma aktuális állapotát mutatja, például „New”, „Open”, „Pending”, „Solved” vagy „Closed”. Az állapot jelzi a vizsgálat előrehaladását. Az elemzésben a nyitott és lezárt esetek szűrésére használható. A Stale Problem Record Monitoring dashboard ezen a mezőn keresztül azonosítja azokat az aktív eseteket, amelyek nem a várt állapotok szerint haladnak. Miért fontos? Lehetővé teszi az esetek szűrését a lezártságuk szerint. Hol szerezhető be? Zendesk Ticket objektum, „status” mező Példák ÚjNyitottFüggőbenMegoldvaLezárva
	Problémakategória ProblemCategory	A probléma besorolása (például szoftver, hardver, hálózat).
Leírás Ez az attribútum az érintett szolgáltatás vagy technológiai környezet alapján kategorizálja a problémát. A Zendesk űrlapjain általában egyéni legördülő mezőként szerepel. Az elemzésben a „Problémák besorolásának pontossága” dashboard használja. A kezdeti kategória és a végső kiváltó ok összevetésével megállapítható, hogy az első vizsgálat megfelelő csapathoz irányítja-e a problémákat. Miért fontos? Lehetővé teszi az elemzést technológia vagy üzleti szolgáltatás szerint. Hol szerezhető be? Zendesk-jegyek egyéni mezői Példák AdatbázisFelhasználói felület és felhasználói élményHálózati infrastruktúra
	SLA-határidő SlaDueDate	Az a célként megadott dátum és időpont, ameddig a problémát meg kell oldani.
Leírás Ez az attribútum a szolgáltatási szintre vonatkozó megállapodás beállításai alapján meghatározott megoldási határidőt jelöli. Általában a jegy prioritása és létrehozásának időpontja alapján számítják ki. Az elemzésben a tényleges megoldási idővel összevetve kiszámítható a problémák SLA-követési aránya. Az SLA Performance and Risk dashboard kiemeli a határidőhöz közeledő vagy azt túllépő eseteket. Miért fontos? A megfelelés és a szerződéses teljesítmény méréséhez szükséges. Hol szerezhető be? Zendesk Ticket Metrics vagy SLA Policies végpont Példák 2023-12-01T17:00:00Z
	Támogatási csoport SupportGroup	A problémarekordért jelenleg felelős csapat vagy részleg.
Leírás Ez az attribútum azonosítja, hogy egy adott időpontban melyik ügyintézői csoport felel a problémáért. Az értéke akkor változik, amikor a jegyet átadják egy másik csapatnak. Az elemzésben a Support Group Handover Analysis dashboard használja. Segítségével mérhető az egyes csapatok teljesítménye, feltárhatók az átadások szűk keresztmetszetei, és elemezhető az erőforrások terhelésének megoszlása. Miért fontos? Lehetővé teszi a szervezeti szintű elemzést és a részlegek közötti szűk keresztmetszetek feltárását. Hol szerezhető be? Zendesk Ticket objektum, „group_id” mező (névhez rendelve) Példák Második szintű támogatásAdatbáziscsapatHálózati üzemeltetés
	Elavult IsStale	Jelzi, ha több mint 14 napja nem történt tevékenység a problémával kapcsolatban.
Leírás Ez a számított attribútum azokat a rekordokat azonosítja, amelyeket nem frissítettek mostanában. Összeveti az aktuális dátumot (vagy az elemzés dátumát) az utolsó tevékenység időbélyegével. Az elemzésben az „Elavult problémarekordok figyelése” dashboard alapjául szolgál. Segít a vezetőknek gyorsan megtalálni az elhanyagolt eseteket, amelyek feleslegesen növelik a hátralékot, és amelyeket esetleg adminisztratív úton le kell zárni vagy másik munkatárshoz kell rendelni. Miért fontos? Segít feltárni a folyamatveszteséget és az elhanyagolt feladatokat. Hol szerezhető be? A process mining eszköz számítja ki: (Most - LastDataUpdate) > 14 nap Példák truefalse
	Kerülő megoldás aktív WorkaroundActive	Jelzi, hogy rendelkezésre bocsátottak vagy közzétettek-e kerülő megoldást.
Leírás Ez a logikai attribútum azt jelzi, hogy dokumentáltak-e ideiglenes javítást a problémához. Értéke gyakran a „Kerülő megoldás közzétéve” tevékenység vagy az űrlap egy adott jelölőnégyzete alapján állapítható meg. Az elemzésben a „Kerülő megoldások közzétételének megfelelősége” dashboard használja. Azt méri, milyen gyakran nyújt az ügyfélszolgálati csapat azonnali segítséget a felhasználóknak, miközben a hosszú távú kivizsgálás folytatódik. Miért fontos? Segít mérni, mennyire sikerül mérsékelni a felhasználókra gyakorolt hatást a kivizsgálás alatt. Hol szerezhető be? A „Kerülő megoldás közzétéve” tevékenység vagy egyéni mező megléte alapján meghatározva Példák truefalse
	Módosítási kérelem azonosítója ChangeRequestId	A javítás bevezetéséhez kapcsolódó módosítási kérelem azonosítója.
Leírás Ez az attribútum összekapcsolja a problémarekordot egy módosításkezelési rekorddal, amely akár másik rendszerben vagy más jegytípusban is szerepelhet. Azt jelzi, hogy hivatalos módosítási folyamat indult. Az elemzésben a „Módosítási kérelmek indítási aránya” dashboard alapjául szolgál. Segít nyomon követni az utat a diagnózistól a bevezetésig, és ellenőrizni, hogy az azonosított kiváltó okokból hivatalos módosítási intézkedések születtek-e. Miért fontos? Összekapcsolja a problémakezelési folyamatot a módosításkezelési folyamattal. Hol szerezhető be? Zendesk-jegyek egyéni mezői vagy kapcsolt jegyek Példák CR-1002CHG00394
	Probléma tárgya ProblemSubject	A problémarekord rövid összefoglalója vagy címe.
Leírás Ez az attribútum a probléma létrehozásakor megadott szöveges összefoglalót tartalmazza. Általában a vizsgált tünetet vagy hibát írja le. Az elemzés során kontextust ad az elemzőnek, amikor egy adott eset részleteit vizsgálja. Szövegelemzéssel hasonló problémák csoportosíthatók, illetve olyan visszatérő témák azonosíthatók, amelyeket a strukturált kategóriamezők nem rögzítenek. Miért fontos? Közérthető kontextust ad az egyes esetekhez. Hol szerezhető be? Zendesk Ticket objektum, „subject” mező Példák Nem sikerül fizetést feldolgozni az EU régióbanMegugrik a késleltetés a bejelentkezési kiszolgálónAz adminisztrátori felhasználók adatexportja sikertelen
	Történt PIR HasPostImplementationReview	Jelzi, hogy tartottak-e bevezetés utáni felülvizsgálatot.
Leírás Ez az attribútum azt jelzi, hogy a probléma megoldási folyamata tartalmazott-e felülvizsgálati szakaszt. Értékét az eset előzményeiben szereplő „Bevezetés utáni felülvizsgálat elvégezve” tevékenység alapján határozza meg a rendszer. Az elemzésben a „Bevezetés utáni felülvizsgálatok lefedettsége” dashboard alapjául szolgál. Megfelelési mutatóként azt ellenőrzi, hogy a szervezet tanul-e a jelentős problémákból. Miért fontos? Ellenőrzi a folyamatos fejlesztési folyamatoknak való megfelelést. Hol szerezhető be? A „Bevezetés utáni felülvizsgálat elvégezve” tevékenység megléte alapján meghatározva Példák truefalse
	Tudásbáziscikk azonosítója KnowledgeArticleId	A problémához létrehozott vagy ahhoz kapcsolt tudásbáziscikk azonosítója.
Leírás Ez az attribútum egy Zendesk Guide-cikkre vagy külső tudásanyagra mutató hivatkozást tárol. Jelzi, hogy a probléma során szerzett ismereteket dokumentálták. Az elemzésben a mező megléte alapján számítható ki a „Tudásbázis-integráció aránya”. Ezzel ellenőrizhető, hogy a szervezet dokumentálja-e a megoldásokat, hogy később is felhasználhatók legyenek. Miért fontos? A tudásmenedzsment-folyamatok hatékonyságát méri. Hol szerezhető be? Zendesk-jegyek egyéni mezői vagy kapcsolt tartalmak Példák 360045889KB-2991

Kötelező Javasolt Nem kötelező

Problémakezelési tevékenységek

Rögzítse ezeket a fontos folyamatlépéseket és állapotváltozásokat, hogy megjeleníthesse a teljes folyamatot a probléma első azonosításától a végleges megoldás bevezetéséig.

8 Javasolt 4 Nem kötelező

	Tevékenység	Leírás
	A gyökérok azonosítva	Az a pont, amikor meghatározzák a probléma alapjául szolgáló okot. Ezt általában az jelzi, hogy az ügyintéző kitölt egy egyéni „Root Cause” szöveges mezőt vagy legördülő kategóriát.
Miért fontos? Fontos mérföldkő a Root Cause Investigation Velocity dashboardon és a diagnosztika hatékonyságának mérésében. Hol szerezhető be? Kövesse a „Root Cause”, „RCA” vagy „Problem Source” címkéjű egyéni mezők módosítását, és keresse a nem üres értékeket. Rögzítés Ellenőrizze, hogy az egyéni mezők ki vannak-e töltve. Eseménytípus inferred
	A megoldás ellenőrizve	A probléma hivatalos megjelölése megoldottként. A Zendeskben ez akkor történik, amikor a rendszer állapota „Solved” értékre változik, ami azt jelzi, hogy a javítást ellenőrizték, és az ügy lezárult.
Miért fontos? Az SLA-teljesítmény és -kockázat, valamint a problémák SLA-követési arányának számításához ez a fő végpont. Hol szerezhető be? A jegy állapotának „Solved” értékre változásából származik. Rögzítés Akkor kerül naplózásra, amikor az állapot „Solved” értékre változik. Eseménytípus explicit
	A vizsgálat megkezdődött	A passzív „New” állapotból aktív munkavégzési állapotba való átmenetet jelzi. Ez azt mutatja, hogy egy ügyintéző tudomásul vette a problémát, és megkezdte a diagnosztikát.
Miért fontos? A Stale Problem Record mutatók kiszámításához használható, és az átlagos gyökérok-elemzési idő KPI kiindulópontja. Hol szerezhető be? Akkor következtethető ki, amikor a jegy állapota „New” értékről „Open” vagy „Pending” értékre változik. Rögzítés Hasonlítsa össze az állapotmező értékét a változás előtt és után. Eseménytípus inferred
	Átmeneti megoldás közzétéve	A probléma átmeneti megoldásának dokumentálása és megosztása. A Zendeskben ezt gyakran egy külön címke vagy egy egyéni jelölőnégyzet rögzíti, amely jelzi, hogy rendelkezésre áll átmeneti megoldás.
Miért fontos? A Workaround Publication Compliance dashboard adatait biztosítja, és segít abban, hogy a felhasználók hosszabb vizsgálat alatt is átmeneti megoldást kapjanak. Hol szerezhető be? Kövesse a „workaround_published” címke hozzáadását vagy a „Workaround” nevű egyéni logikai mező módosítását. Rögzítés Hasonlítsa össze az egyéni mező vagy címke értékeit. Eseménytípus inferred
	Hozzárendelve egy támogatási csoporthoz	A problémarekord hozzárendelése egy adott műszaki csapathoz vagy részleghez. A rendszer a jegy Group ID mezőjének módosításakor rögzíti.
Miért fontos? A támogatási csoportok közötti várakozási idő méréséhez szükséges a Support Group Handover Analysis dashboardon. Hol szerezhető be? Kövesse a jegy auditnaplójában a „group_id” mező változásait. Rögzítés Akkor kerül naplózásra, amikor a Group Assignment Change tranzakció lefut. Eseménytípus explicit
	Probléma rögzítve	A problémát jelző jegy első létrehozása a Zendesk Support rendszerben. Ez az esemény rögzíti, mikor került be először a probléma a rendszerbe, és általában elindítja a folyamatpéldányt.
Miért fontos? Meghatározza a teljes megoldási ciklus kezdő időpontját, és alapul szolgál a további átfutásiidő-mutatókhoz. Hol szerezhető be? A jegyobjektum „created_at” időbélyegéből vagy a jegy auditnaplójának első bejegyzéséből származik. Rögzítés Akkor kerül naplózásra, amikor a Ticket Created tranzakció lefut. Eseménytípus explicit
	Problémarekord lezárva	A folyamat utolsó eseménye: a jegy zárolása után már nem módosítható. A Zendeskben ez általában automatikusan, a „Solved” állapotba kerülést követő 4 nap elteltével történik.
Miért fontos? A rekord életciklusának végét jelöli, és adatmegőrzéshez, valamint korábbi időszakok jelentéseihez használható. Hol szerezhető be? A jegy állapotának „Closed” értékre változásából származik. Rögzítés Akkor kerül naplózásra, amikor az állapot „Closed” értékre változik. Eseménytípus explicit
	Végleges javítás alkalmazva	Azt jelzi, hogy a műszaki megoldást bevezették a környezetbe. Ezt általában egy egyéni állapotváltás vagy egy külön címke rögzíti, mielőtt a jegyet teljesen megoldottnak jelölik.
Miért fontos? A Fix Implementation Efficiency dashboardon a diagnózis és a bevezetés közötti idő méréséhez szükséges. Hol szerezhető be? Egy adott címkéből, például a „fix_deployed” értékből, vagy egy meglévő egyéni állapotmezőből következtethető ki. Rögzítés Kövesse a címkéket vagy az egyéni állapotválasztó mezőket. Eseménytípus inferred
	A probléma vizsgálata újraindult	Akkor történik, amikor egy korábban „Solved” állapotú problémarekord visszakerül „Open” vagy más aktív állapotba. Ez sikertelen javításra vagy elutasított megoldásra utal.
Miért fontos? A problémák újranyitási arányának KPI-ját támogatja, és segít feltárni a megoldási folyamat minőségi problémáit. Hol szerezhető be? Akkor következtethető ki, amikor az állapot „Solved” értékről visszavált „Open”, „New” vagy „Pending” értékre. Rögzítés Hasonlítsa össze az állapotmező értékét a változás előtt és után. Eseménytípus inferred
	Bevezetés utáni felülvizsgálat elvégezve	Annak megerősítése, hogy a javítás után elvégezték az utólagos felülvizsgálatot. Ezt általában egy jelölőnégyzet vagy a folyamatkoordinátor által frissített dátummező rögzíti.
Miért fontos? A bevezetés utáni felülvizsgálatok gyakoriságát mérő KPI-hoz szükséges, és segít betartani a minőségi követelményeket. Hol szerezhető be? Kövesse a „PIR Completed” egyéni jelölőnégyzet vagy a „PIR Date” dátummező módosítását. Rögzítés Kövesse az egyéni mező kitöltését. Eseménytípus inferred
	Megoldási javaslat tervezete elkészült	A probléma vizsgálata alapján tudásbáziscikk készül. Erre a Zendesk Knowledge Capture alkalmazás használatából vagy egy új cikk összekapcsolásából lehet következtetni.
Miért fontos? A Knowledge Base Integration Rate KPI mérését támogatja, és segíti a szervezeti tudás megőrzését. Hol szerezhető be? Kövesse a „Knowledge Capture” integrációhoz kapcsolódó eseményeket vagy az olyan címkéket, mint a „kcs_draft”. Rögzítés Következtessen rá a rendszer adott címkéiből vagy a hivatkozási eseményekből. Eseménytípus inferred
	Változtatási kérelem indítva	Azt jelzi, hogy a probléma megoldásához hivatalos változáskezelési folyamat indult. Ez gyakran abból következtethető ki, hogy kitöltik a „Change Request ID” egyéni mezőt, vagy összekapcsolnak egy „Change” típusú jegyet.
Miért fontos? Nyomon követi a változtatási kérelmek indítási arányát, és összekapcsolja a problémakezelési és változáskezelési munkafolyamatokat. Hol szerezhető be? Kövesse például a „change_reference” egyéni mező módosítását vagy a „problem_change” típusú hivatkozás létrehozását. Rögzítés Kövesse a külső azonosítót tartalmazó egyéni mező módosítását. Eseménytípus inferred

Javasolt Nem kötelező

Adatkinyerési útmutatók

Adatok kinyerése a Zendesk Support rendszerből

Lépések

Jelentkezzen be a Zendesk-példányba, majd a termékválasztón keresztül nyissa meg az Explore jelentéskészítő felületét.
Kattintson a Queries mappára (az újabb verziókban Reports), majd válassza a New query lehetőséget.
Az adatkészlet kiválasztásakor válassza a Support, majd az Updates History, végül a Support: Updates History [default] lehetőséget. Ez az adatkészlet a process mininghez szükséges eseménynaplókat tartalmazza, nem csupán az aktuális állapot adatait.
A Metrics panelen adja hozzá a Count (Tickets) vagy a Count (Updates) mérőszámot, hogy ellenőrizze az adatok lekérését.
A Filters panelen adjon hozzá szűrőt a Ticket > Ticket type mezőhöz, és válassza a Problem értéket, hogy csak a problémakezelési folyamat adatai szerepeljenek.
A Rows panelen az alábbi sorrendben adja hozzá az attribútumokat az eseménynapló szerkezetének meghatározásához: Ticket > Ticket ID, Time - Timestamp > Update - Timestamp, Updater > Updater name, valamint Changes > Changes - Field name.
Az Activity Name oszlop létrehozásához hozzon létre egy Standard Calculated Attribute attribútumot. Kattintson a jobb oldali sávon a Calculation ikonra, válassza a Standard calculated attribute lehetőséget, nevezze el Activity Mappernek, majd illessze be az alábbi Query részben megadott kódot.
Adja hozzá az új Activity Mapper attribútumot a Rows panelhez. Szűrje ki ebből az attribútumból a NULL értékeket, hogy eltávolítsa a nem releváns rendszernapló-bejegyzéseket.
A kontextus megadásához további attribútumokat is adjon a Rows panelhez: Ticket > Priority, Ticket > Group, Ticket > Status, valamint a kiváltó ok vagy kategória elemzéséhez szükséges egyéni mezőket, például Ticket > Ticket tags vagy konkrét Custom Fields mezőket.
A Filters panelen állítsa be az időszakot a Time - Timestamp > Update - Date mezővel, például az utolsó 6 hónapra.
Kattintson a Visualization type ikonra, majd válassza a Table lehetőséget. Ha elérhető, állítsa a táblázatot nem pivotált vagy lapos nézetre, vagy egyszerűen ellenőrizze, hogy minden attribútum a Rows szakaszban szerepel-e.
Az eredmény exportálásához kattintson az Export > CSV lehetőségre. Jelölje be a Keep attribute formatting jelölőnégyzetet, hogy megőrizze a ProcessMind számára szükséges időbélyegformátumokat.

Konfiguráció

Adatkészlet: Support: Updates History (Fontos: ne a standard Tickets adatkészletet használja, mert az csak az aktuális állapotot mutatja.)
Időszűrő: Update - Date (Ajánlott időszak: az elmúlt 90–180 nap, az adatmennyiségtől függően.)
Jegytípus: Kizárólag a Problem értékre szűrjön, hogy az incidensek és a szolgáltatáskérések ne keveredjenek az adatok közé.
Sorszámkorlát: A Zendesk Explore-exportok gyakran legfeljebb 50 000 sort tartalmazhatnak. Ha az adatkészlet ennél nagyobb, az Update - Date szűrővel exportálja kisebb, havi részekben, majd egyesítse őket külső eszközzel.
Egyéni mezők: Azonosítsa a saját Zendesk-példányában a kiváltó okhoz, a változtatási kérelemhez és a kerülő megoldáshoz tartozó mezőazonosítókat, mert ezek nem standard rendszermezők.
Rendszerengedélyek: Explore Viewer vagy Explore Professional licenc szükséges.

Példa-lekérdezés config

IF ([Changes - Field name] = "status" AND [Changes - New value] = "New") THEN "Problem Record Logged"
ELIF ([Changes - Field name] = "group_id") THEN "Assigned to Support Group"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "New" AND [Changes - New value] = "Open") THEN "Investigation Commenced"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "workaround_available")) THEN "Workaround Published"
ELIF ([Changes - Field name] = "[Your Root Cause Field Name]") THEN "Root Cause Identified"
ELIF ([Changes - Field name] = "[Your Change Request ID Field Name]") OR ([Changes - Field name] = "type" AND [Changes - New value] = "change") THEN "Change Request Initiated"
ELIF ([Changes - Field name] = "tags" AND CONTAINS([Changes - New value], "fix_deployed")) THEN "Permanent Fix Applied"
ELIF ([Changes - Field name] = "[Your Knowledge Article Linked Field]") THEN "Proposed Solution Drafted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Solved") THEN "Resolution Verified"
ELIF ([Changes - Field name] = "status" AND [Changes - Previous value] = "Solved" AND [Changes - New value] = "Open") THEN "Problem Investigation Reopened"
ELIF ([Changes - Field name] = "[Your PIR Completed Checkbox Field]") THEN "Post-Implementation Review Conducted"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "Closed") THEN "Problem Record Closed"
ELSE NULL
ENDIF

Lépések

Előfeltételek ellenőrzése: Ellenőrizze, hogy szervezeténél engedélyezve van-e a Zendesk Data Sharing kiegészítő. Győződjön meg arról, hogy rendelkezik írásvédett hozzáférési adatokkal a Zendesk replikált adatbázisához, amelyet általában Snowflake vagy Amazon Redshift üzemeltet.
Kapcsolódás az adatbázishoz: A megadott hozzáférési adatokkal csatlakozzon a Zendesk-adattárhoz az Ön által választott SQL-klienssel, például DBeaverrel, DataGrippel vagy a Snowflake/Redshift saját webes felületével.
Egyéni mezők azonosítása: A lekérdezés futtatása előtt azonosítsa a problémakezelési folyamatban használt egyéni mezők egyedi azonosítóit. A Zendesk Admin Centerben nyissa meg az Objects and rules > Tickets > Fields menüpontot. Keresse meg a „Root Cause”, „Change Request ID”, „Workaround Published”, „Permanent Fix Applied” és „Post-Implementation Review” mezőket, és jegyezze fel az azonosítóikat. Ezekkel kell majd helyettesítenie a lekérdezésben szereplő helyőrzőket.
Az SQL-lekérdezés áttekintése: A megadott lekérdezés a ProblemTickets nevű Common Table Expression (CTE) segítségével először kiválasztja és szűri a problémarekordokat. Ez javítja a teljesítményt és az olvashatóságot. A lekérdezés fő része ezután UNION ALL használatával egyesíti a 12 különálló SELECT utasítás eredményét, amelyek mindegyike egy szükséges tevékenységhez tartozik.
A lekérdezés testreszabása: Nyisson meg egy új lekérdezésszerkesztőt, és illessze be a teljes SQL-szkriptet. Módosítsa a szkriptben szereplő helyőrzőket:
- A ProblemTickets CTE-ben állítsa be a kívánt időszakot a '[YYYY-MM-DD]' érték cseréjével.
- Az egyéni mezőtől függő tevékenységeknél cserélje le a helyőrző azonosítókat, például [Your 'Root Cause Category' field_id] és `[Your 'Change Request ID' field_id] értékét a 3. lépésben azonosított tényleges azonosítókra.
A lekérdezés futtatása: Futtassa a módosított SQL-szkriptet az adatbázison. A futási idő az időszaktól és a jegyadatok mennyiségétől függ.
A „Proposed Solution Drafted” logika ellenőrzése: A lekérdezés abból indul ki, hogy a megoldás megfogalmazását egy [Your 'KB Article ID' field_id] nevű egyéni mező kitöltése jelzi. Ha az Ön folyamata ettől eltér, például egy adott címkét vagy megjegyzést használ, módosítsa ennek megfelelően a lekérdezés érintett részét.
Adatok ellenőrzése: A lekérdezés lefutása után röviden tekintse át az eredményeket. Ellenőrizze, hogy a sorok száma ésszerű-e, minden oszlop szerepel-e, és nincs-e váratlan NULL érték olyan fontos oszlopokban, mint a ProblemRecordId és az EventTimestamp.
Az eseménynapló exportálása: Exportálja a teljes eredményhalmazt az SQL-kliensből CSV-fájlba. UTF-8 kódolást használjon, és ellenőrizze, hogy az oszlopfejlécek megegyeznek-e a process mining eszköz által elvárt attribútumnevekkel.
Felkészülés a feltöltésre: Feltöltés előtt ellenőrizze a CSV-fájl formázását. Győződjön meg arról, hogy az EventTimestamp oszlop dátum- és időértékei egységes formátumúak, például YYYY-MM-DD HH24:MI:SS alakúak.

Konfiguráció

Előfeltételek: Az adatkinyeréshez szükség van a Zendesk Data Sharing kiegészítőre és közvetlen SQL-hozzáférésre a Snowflake- vagy Amazon Redshift-példányban replikált adatokhoz.
Jegytípus szerinti szűrés: A lekérdezés előre úgy van beállítva, hogy csak azokat a jegyeket elemezze, amelyek type értéke 'problem'. Ez elengedhetetlen ahhoz, hogy a problémakezelési folyamat elkülönüljön az incidensektől és más jegytípusoktól.
Időszak szerinti szűrés: A teljesítmény érdekében erősen ajánlott egy meghatározott időszakra szűrni. A lekérdezés kezdeti CTE-je tartalmazza a created_at >= '[YYYY-MM-DD]' helyőrzőt. Első elemzéshez általában 3–6 hónapnyi adat megfelelő.
Egyéni mezők beállítása: Az adatkinyerés nagyban függ az Ön Zendesk-beállításaitól. Azonosítsa és adja meg a megfelelő field_id értékeket azokhoz az egyéni mezőkhöz, amelyek például a „Root Cause Identified”, „Change Request Initiated” és „Workaround Published” tevékenységeket rögzítik. Ha nem cseréli le a helyőrző azonosítókat, a lekérdezés hibát jelezhet, vagy nem ad vissza adatot ezekhez a tevékenységekhez.
Adatkésés: A replikált adatbázis nem valós időben frissül. A Zendeskben bekövetkező esemény és az adattárban való megjelenése között általában néhány óra telik el. A közelmúlt eseményeinek elemzésekor vegye figyelembe ezt a késést.

Példa-lekérdezés sql

WITH ProblemTickets AS (
  SELECT
    t.id,
    t.created_at,
    t.updated_at,
    t.priority,
    g.name AS group_name,
    u.name AS assignee_name,
    t.status,
    (SELECT COUNT(*) FROM problem_incident_links pil WHERE pil.problem_id = t.id) AS related_incident_count,
    t.due_at AS sla_due_date,
    cf_cat.value AS problem_category,
    cf_root.value AS root_cause_category
  FROM tickets t
  LEFT JOIN users u ON t.assignee_id = u.id
  LEFT JOIN groups g ON t.group_id = g.id
  LEFT JOIN custom_field_values cf_cat ON t.id = cf_cat.ticket_id AND cf_cat.custom_field_id = [Your 'Problem Category' field_id]
  LEFT JOIN custom_field_values cf_root ON t.id = cf_root.ticket_id AND cf_root.custom_field_id = [Your 'Root Cause Category' field_id]
  WHERE t.type = 'problem'
  AND t.created_at >= '[YYYY-MM-DD]' -- Set start date for the extraction
)
-- 1. Problem Record Logged
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Logged' AS "ActivityName",
  pt.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'new' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ProblemTickets pt

UNION ALL

-- 2. Assigned to Support Group
SELECT
  pt.id AS "ProblemRecordId",
  'Assigned to Support Group' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'group'

UNION ALL

-- 3. Investigation Commenced
SELECT
  pt.id AS "ProblemRecordId",
  'Investigation Commenced' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value = 'new'

UNION ALL

-- 4. Workaround Published
SELECT
  pt.id AS "ProblemRecordId",
  'Workaround Published' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Workaround Published'' custom field name]' AND tme.value IS NOT NULL -- Example: checkbox being checked or field being filled

UNION ALL

-- 5. Root Cause Identified
SELECT
  pt.id AS "ProblemRecordId",
  'Root Cause Identified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Root Cause Category'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 6. Change Request Initiated
SELECT
  pt.id AS "ProblemRecordId",
  'Change Request Initiated' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Change Request ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 7. Permanent Fix Applied
SELECT
  pt.id AS "ProblemRecordId",
  'Permanent Fix Applied' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Permanent Fix Applied'' custom field name]' AND tme.value IS NOT NULL -- Assumes a custom field indicates this status

UNION ALL

-- 8. Proposed Solution Drafted
SELECT
  pt.id AS "ProblemRecordId",
  'Proposed Solution Drafted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''KB Article ID'' custom field name]' AND tme.value IS NOT NULL

UNION ALL

-- 9. Resolution Verified
SELECT
  pt.id AS "ProblemRecordId",
  'Resolution Verified' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'solved' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'solved'

UNION ALL

-- 10. Problem Investigation Reopened
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Investigation Reopened' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'open' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'open' AND tme.previous_value IN ('pending', 'solved')

UNION ALL

-- 11. Post-Implementation Review Conducted
SELECT
  pt.id AS "ProblemRecordId",
  'Post-Implementation Review Conducted' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  pt.status AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'custom_field' AND tme.field_name = '[Your ''Post-Implementation Review'' custom field name]' AND tme.value IS NOT NULL -- Assumes a checkbox or date field

UNION ALL

-- 12. Problem Record Closed
SELECT
  pt.id AS "ProblemRecordId",
  'Problem Record Closed' AS "ActivityName",
  tme.created_at AS "EventTimestamp",
  'Zendesk' AS "SourceSystem",
  pt.updated_at AS "LastDataUpdate",
  pt.priority AS "Priority",
  pt.group_name AS "SupportGroup",
  pt.assignee_name AS "AssigneeName",
  'closed' AS "ProblemStatus",
  pt.related_incident_count AS "RelatedIncidentCount",
  pt.sla_due_date AS "SlaDueDate",
  pt.problem_category AS "ProblemCategory",
  pt.root_cause_category AS "RootCauseCategory"
FROM ticket_metric_events tme
JOIN ProblemTickets pt ON tme.ticket_id = pt.id
WHERE tme.type = 'status' AND tme.value = 'closed' AND tme.previous_value = 'solved';

Lépések

Előfeltételek: Ellenőrizze, hogy a rendszerén telepítve van-e a Python 3.6 vagy újabb verziója. Telepítse a szükséges requests és pandas könyvtárakat a pip install requests pandas parancs futtatásával a terminálban vagy a parancssorban.
Zendesk API-token létrehozása: Rendszergazdaként jelentkezzen be a Zendesk Supportba. Nyissa meg az Admin Center > Apps and integrations > APIs > Zendesk API menüpontot. A Token Access szakaszban kattintson az „Add API token” lehetőségre új token létrehozásához. Azonnal másolja ki, és tárolja biztonságos helyen, mert később már nem jelenik meg újra.
A Python-szkript beállítása: Hozzon létre egy új Python-fájlt, például extract_zendesk_problems.py néven, és másolja bele a Query szakaszban megadott teljes szkriptet. Frissítse a szkript elején található helyőrző változókat: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN és START_TIME. Az első futtatáskor állítsa a START_TIME értékét a kívánt kezdő dátum Unix-időbélyegére.
Egyéni mezők azonosítóinak megadása: Azonosítsa a problémakezelési folyamatban használt egyéni mezők numerikus azonosítóit. Ezeket az Admin Center > Objects and rules > Tickets > Fields menüpontban, az URL vagy a mezőtulajdonságok alapján találhatja meg. Frissítse a szkript CUSTOM_FIELD_MAPPING szótárát a saját azonosítóival.
A szkript futtatása: Futtassa a szkriptet a terminálból a python extract_zendesk_problems.py paranccsal. A szkript megkezdi az adatok lekérését a Zendesk Incremental Export API-ból.
A futás nyomon követése: A szkript kiírja a folyamat állapotát, többek között a feldolgozott jegyek számát és az éppen lekért időbélyeget. Szükség esetén várakozással automatikusan kezeli az API-kérések korlátozását.
Adatok lekérése és átalakítása: A szkript először lekéri a START_TIME óta létrehozott vagy frissített problémás jegyeket. Ezután minden problémás jegyhez lekéri a teljes auditnaplót, amely az összes korábbi változást tartalmazza.
Eseménynapló létrehozása: A szkript feldolgozza az audit minden eseményét, és a mezőváltozásokat, például az állapot, a csoport vagy az egyéni mezők módosítását, a meghatározott üzleti tevékenységekhez rendeli. A felhasználók és csoportok nevét is lekéri és gyorsítótárazza, hogy kiegészítse az adatokat.
Növekményes betöltések kezelése: A kezdeti teljes betöltés után a következő futtatások előtt állítsa a START_TIME változót az előző sikeres futás végén kiírt end_time értékre. Így csak az új és frissített adatok kerülnek be, duplikáció nélkül.
Az eredmény ellenőrzése: A szkript futása után a rendszer a zendesk_problem_event_log.csv nevű fájlt hozza létre ugyanabban a könyvtárban. Ez a CSV-fájl elemzésre kész, strukturált eseménynaplót tartalmaz.
Felkészülés a feltöltésre: Nyissa meg a CSV-fájlt egy táblázatkezelőben, és ellenőrizze a tartalmát. Feltöltés előtt győződjön meg arról, hogy minden szükséges oszlop (ProblemRecordId, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate) szerepel és megfelelően ki van töltve.

Konfiguráció

Zendesk API-hozzáférési adatok: A hitelesítéshez szükség van a Zendesk aldomainjére, az API-tokenhez tartozó felhasználó e-mail-címére és magára az API-tokenre.
Kezdési időpont: A START_TIME változó egy Unix epoch időbélyeg, amely meghatározza az adatkinyerés kezdőpontját. Az első futtatáskor állítson be egy múltbeli dátumot, például 6 hónappal korábbit, hogy a korábbi adatokat is lekérje. A későbbi futtatásokhoz használja az előző futás befejezési idejét, így növekményesen kérheti le az adatokat.
Egyéni mezők hozzárendelése: A CUSTOM_FIELD_MAPPING szótár beállítása elengedhetetlen. Cserélje le a helyőrző azonosítókat a Zendesk-példányában használt tényleges egyéni mezőazonosítókra, hogy a rendszer megfelelően rögzítse például a „Workaround Published” és a „Root Cause Identified” tevékenységeket.
Jegytípus szerinti szűrés: A szkript rögzítetten csak azokat a jegyeket dolgozza fel, amelyek type értéke 'problem'. Így az incidensek, feladatok és kérdések nem kerülnek be a problémakezelési eseménynaplóba.
API-kérések korlátozása: A szkript egy egyszerű time.sleep(60) függvénnyel kezeli a 429-es, „Too Many Requests” hibákat. A várakozási időt a Zendesk-csomaghoz és a kinyerendő adatok mennyiségéhez kell igazítani.
Előfeltételek: A szkript futtatásához Python 3-környezetre, valamint a requests és pandas könyvtárakra van szükség. Az API-tokenhez olyan fióknak kell tartoznia, amely jogosult a jegyadatok olvasására.

Példa-lekérdezés python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk subdomain, email, and API token
ZENDESK_SUBDOMAIN = class="hl-string">'[your_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_email@example.com]'
ZENDESK_API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1641013200 is for Jan 1, 2022 00:00:00 GMT
START_TIME = 1641013200

class=class="hl-string">"hl-comment"># Map your custom field IDs to the corresponding activity names
class=class="hl-string">"hl-comment"># Find IDs in Admin Center > Objects and rules > Tickets > Fields
CUSTOM_FIELD_MAPPING = {
    class="hl-string">'[Your Workaround Published Field ID]': class="hl-string">'Workaround Published',
    class="hl-string">'[Your Root Cause Identified Field ID]': class="hl-string">'Root Cause Identified',
    class="hl-string">'[Your Change Request Initiated Field ID]': class="hl-string">'Change Request Initiated',
    class="hl-string">'[Your Permanent Fix Applied Field ID]': class="hl-string">'Permanent Fix Applied',
    class="hl-string">'[Your Proposed Solution Drafted Field ID]': class="hl-string">'Proposed Solution Drafted',
    class="hl-string">'[Your Post-Implementation Review Field ID]': class="hl-string">'Post-Implementation Review Conducted'
}

class=class="hl-string">"hl-comment"># --- SCRIPT --- 
BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
API_USER = fclass="hl-string">'{ZENDESK_EMAIL}/token'

class=class="hl-string">"hl-comment"># Caching for user and group lookups to reduce API calls
user_cache = {}
group_cache = {}

session = requests.Session()
session.auth = (API_USER, ZENDESK_API_TOKEN)

def get_user_name(user_id):
    if not user_id: return None
    if user_id in user_cache:
        return user_cache[user_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_cache[user_id] = response.json()[class="hl-string">'user'][class="hl-string">'name']
        return user_cache[user_id]
    except requests.exceptions.RequestException:
        return str(user_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def get_group_name(group_id):
    if not group_id: return None
    if group_id in group_cache:
        return group_cache[group_id]
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/groups/{group_id}.json')
        response.raise_for_status()
        group_cache[group_id] = response.json()[class="hl-string">'group'][class="hl-string">'name']
        return group_cache[group_id]
    except requests.exceptions.RequestException:
        return str(group_id) class=class="hl-string">"hl-comment"># Return ID if lookup fails

def fetch_tickets(start_time):
    tickets_url = fclass="hl-string">'{BASE_URL}/incremental/tickets.json'
    params = {class="hl-string">'start_time': start_time, class="hl-string">'include': class="hl-string">'metric_sets'}
    all_tickets = []
    while tickets_url:
        try:
            print(fclass="hl-string">"Fetching from: {tickets_url}")
            response = session.get(tickets_url, params=params)
            class=class="hl-string">"hl-comment"># params are only needed for the first request
            params = {}
            if response.status_code == 429:
                print(class="hl-string">"Rate limit reached. Waiting for 60 seconds.")
                time.sleep(60)
                continue
            response.raise_for_status()
            data = response.json()
            all_tickets.extend(data.get(class="hl-string">'tickets', []))
            tickets_url = data.get(class="hl-string">'next_page')
            if not data.get(class="hl-string">'end_of_stream', True):
                 class=class="hl-string">"hl-comment"># Wait a moment before the next page request to be safe
                 time.sleep(1)
            else:
                print(fclass="hl-string">"End of stream reached. Final timestamp: {data.get('end_time')}")
                tickets_url = None
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching tickets: {e}")
            break
    return all_tickets

def process_ticket_audits(ticket, event_log):
    ticket_id = ticket[class="hl-string">'id']
    audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audits for ticket {ticket_id}: {e}")
        return

    base_attributes = {
        class="hl-string">'ProblemRecordId': ticket_id,
        class="hl-string">'SourceSystem': class="hl-string">'Zendesk Support',
        class="hl-string">'LastDataUpdate': ticket[class="hl-string">'updated_at'],
        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'RelatedIncidentCount': ticket.get(class="hl-string">'metric_set', {}).get(class="hl-string">'replies', 0), class=class="hl-string">"hl-comment"># Using replies as a proxy if incident_count is not available
        class="hl-string">'SlaDueDate': ticket.get(class="hl-string">'due_at'),
        class="hl-string">'ProblemCategory': next((f[class="hl-string">'value'] for f in ticket.get(class="hl-string">'custom_fields', []) if f.get(class="hl-string">'id') == class="hl-string">'[Your Problem Category Field ID]'), None)
    }

    class=class="hl-string">"hl-comment"># 1. Problem Record Logged
    event_log.append({
        **base_attributes,
        class="hl-string">'ActivityName': class="hl-string">'Problem Record Logged',
        class="hl-string">'EventTimestamp': ticket[class="hl-string">'created_at'],
        class="hl-string">'SupportGroup': get_group_name(ticket.get(class="hl-string">'group_id')),
        class="hl-string">'AssigneeName': get_user_name(ticket.get(class="hl-string">'assignee_id')),
        class="hl-string">'ProblemStatus': class="hl-string">'new',
        class="hl-string">'RootCauseCategory': None
    })

    class=class="hl-string">"hl-comment"># Process audit trail for other activities
    for audit in audits:
        audit_ts = audit[class="hl-string">'created_at']
        for event in audit.get(class="hl-string">'events', []):
            activity_name = None
            field_name = event.get(class="hl-string">'field_name')
            value = event.get(class="hl-string">'value')
            previous_value = event.get(class="hl-string">'previous_value')

            class=class="hl-string">"hl-comment"># 2. Assigned to Support Group
            if field_name == class="hl-string">'group_id' and value is not None:
                activity_name = class="hl-string">'Assigned to Support Group'
            
            class=class="hl-string">"hl-comment"># 3. Investigation Commenced (New -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value == class="hl-string">'new':
                activity_name = class="hl-string">'Investigation Commenced'

            class=class="hl-string">"hl-comment"># 4-9. Activities from Custom Fields
            elif str(field_name) in CUSTOM_FIELD_MAPPING and value is not None and value not in [False, class="hl-string">'0', class="hl-string">'']:
                activity_name = CUSTOM_FIELD_MAPPING[str(field_name)]

            class=class="hl-string">"hl-comment"># 10. Resolution Verified (Any -> Solved)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'solved':
                activity_name = class="hl-string">'Resolution Verified'
            
            class=class="hl-string">"hl-comment"># 11. Problem Investigation Reopened (Solved/Closed -> Open)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'open' and previous_value in [class="hl-string">'solved', class="hl-string">'closed']:
                activity_name = class="hl-string">'Problem Investigation Reopened'

            class=class="hl-string">"hl-comment"># 12. Problem Record Closed (Any -> Closed)
            elif field_name == class="hl-string">'status' and value == class="hl-string">'closed':
                activity_name = class="hl-string">'Problem Record Closed'

            if activity_name:
                class=class="hl-string">"hl-comment"># Find the state of attributes at the time of the event
                temp_status = value if field_name == class="hl-string">'status' else None
                temp_group = get_group_name(value) if field_name == class="hl-string">'group_id' else None
                temp_assignee = get_user_name(value) if field_name == class="hl-string">'assignee_id' else None
                temp_root_cause = value if str(field_name) == class="hl-string">'[Your Root Cause Category Field ID]' else None

                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': audit_ts,
                    class="hl-string">'SupportGroup': temp_group,
                    class="hl-string">'AssigneeName': temp_assignee,
                    class="hl-string">'ProblemStatus': temp_status,
                    class="hl-string">'RootCauseCategory': temp_root_cause
                })

def main():
    print(class="hl-string">"Starting Zendesk Problem ticket extraction...")
    tickets = fetch_tickets(START_TIME)
    problem_tickets = [t for t in tickets if t.get(class="hl-string">'type') == class="hl-string">'problem']
    print(fclass="hl-string">"Found {len(problem_tickets)} problem tickets to process.")

    event_log_data = []
    for i, ticket in enumerate(problem_tickets):
        print(fclass="hl-string">"Processing ticket {i+1}/{len(problem_tickets)}: ID {ticket['id']}")
        process_ticket_audits(ticket, event_log_data)

    if not event_log_data:
        print(class="hl-string">"No events were generated. Exiting.")
        return

    df = pd.DataFrame(event_log_data)

    class=class="hl-string">"hl-comment"># Post-processing to fill forward null values for state attributes
    df = df.sort_values(by=[class="hl-string">'ProblemRecordId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    df[class="hl-string">'SupportGroup'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'SupportGroup'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssigneeName'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'AssigneeName'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ProblemStatus'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'ProblemStatus'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'RootCauseCategory'] = df.groupby(class="hl-string">'ProblemRecordId')[class="hl-string">'RootCauseCategory'].fillna(method=class="hl-string">'ffill')

    class=class="hl-string">"hl-comment"># Define column order
    column_order = [
        class="hl-string">'ProblemRecordId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'Priority', class="hl-string">'SupportGroup', class="hl-string">'AssigneeName', class="hl-string">'ProblemStatus', class="hl-string">'RelatedIncidentCount',
        class="hl-string">'SlaDueDate', class="hl-string">'ProblemCategory', class="hl-string">'RootCauseCategory'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'zendesk_problem_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

Készen áll a kezdésre?

Alkalmazza ezt a sablont még ma a Zendesk-környezetében, és javítsa az IT-működés stabilitását. Csapatunk segít az adatkinyerés finomhangolásában és a process mining bevezetésében.

Vissza a folyamatfejlesztési útmutatóhoz

Sablon letöltése

Fejlessze a problémakezelést, hogy gyorsabban oldja meg az IT-problémákat

Rövidítse 30 százalékkal a megoldási ciklusokat, és szüntesse meg az IT-működés szűk keresztmetszeteit.

Próbálja ki ingyen

Nincs szükség bankkártyára. Beállítás néhány perc alatt.

Problémakezelési adatsablon

Problémakezelési adatsablon

Problémakezelési attribútumok

Problémakezelési tevékenységek

Adatkinyerési útmutatók

Zendesk Explore: a frissítési előzmények exportálása

Lépések

Konfiguráció

Példa-lekérdezés config

SQL-lekérdezés Zendesk Data Sharing használatával

Lépések

Konfiguráció

Példa-lekérdezés sql

Adatkinyerés Python használatával, Incremental Export API-n keresztül

Lépések

Konfiguráció

Példa-lekérdezés python

Készen áll a kezdésre?

Fejlessze a problémakezelést, hogy gyorsabban oldja meg az IT-problémákat