> Folyamatos folyamatfejlesztés > Ügyfélszolgálat > Zendesk Support > Adatsablon

Ügyfélszolgálati adatsablon

Zendesk Support

← Vissza a folyamatfejlesztési útmutatóhoz

Ügyfélszolgálati attribútumok(18) Ügyfélszolgálati tevékenységek(14) Adatkinyerési útmutatók(4)

Ügyfélszolgálati adatsablon

Ez a sablon segít összegyűjteni az ügyfélszolgálati folyamat elemzéséhez szükséges adatokat. Bemutatja a rögzítendő fontos attribútumokat és tevékenységeket, valamint gyakorlati útmutatást ad az adatok kinyeréséhez. Az útmutató alapján olyan eseménynaplót állíthat össze, amelyből feltárhatja a fejlesztési lehetőségeket, és javíthatja az ügyfélszolgálat működését.

Javasolt attribútumok
Az ügyfélszolgálati folyamatban követendő fontos tevékenységek
Adatkinyerési útmutató a Zendesk Supporthoz

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

Sablon letöltése

Ügyfélszolgálati attribútumok

Ezeket az adatmezőket érdemes felvenni az eseménynaplóba az ügyfélszolgálat részletes elemzéséhez.

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

	Név	Leírás
	Kezdési idő StartTime	Az időbélyeg, amely megadja, mikor kezdődött egy tevékenység vagy esemény.
Leírás A kezdési idő, vagyis az esemény időbélyege rögzíti egy adott tevékenység pontos dátumát és időpontját. Megmutatja például, mikor érkezett ügyfélmegjegyzés, mikor rendeltek hozzá ügyintézőt, vagy mikor változott a jegy állapota „Resolved” értékre. Ez az időbélyeg alapvető a process mininghez, mert meghatározza az események időrendi sorrendjét. A tevékenységek közötti időtartamok és a teljes átfutási idők kiszámítására, az SLA-k szerinti teljesítmény mérésére, valamint az ügyfélszolgálati folyamat időbeli alakulásának megértésére használható. Miért fontos? Ez az időbélyeg elengedhetetlen az események sorrendbe állításához, az időtartamok kiszámításához és az ügyfélszolgálati folyamat időbeli alakulásának elemzéséhez. Hol szerezhető be? Zendesk Ticket Audits API, az auditnapló egyes eseményeinek `created_at` mezője. Példák 2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
	Ügyfélszolgálati kérés ServiceRequest	Az egyes ügyfélszolgálati kérések egyedi azonosítója, más néven jegy- vagy ügyazonosító.
Leírás Az ügyfélszolgálati kérés az elsődleges ügyazonosító, amely az egyetlen ügyfélkérdéshez vagy problémához kapcsolódó összes tevékenységet összeköti a létrehozástól a végleges megoldásig. Minden kapcsolatfelvétel, frissítés és belső művelet ehhez az egyedi azonosítóhoz tartozik. A process mining során az ügyfélszolgálati kérés szerint csoportosított események elemzése teljes, végpontok közötti képet ad az ügyfél ügyintézési útjáról. Ez az alapja az olyan fő mutatók kiszámításának, mint a teljes megoldási idő, a folyamateltérések feltárásának és az egyes ügyek életciklusa megértésének. Miért fontos? Ez az alapvető ügyazonosító kapcsolja össze a folyamat összes lépését, így rekonstruálható és elemezhető minden egyes ügyfél ügyintézési útja. Hol szerezhető be? Zendesk Tickets API, `id` mező. Példák 102451287415332
	Forrásrendszer SourceSystem	Az a nyilvántartó rendszer, amelyből az adatokat kinyerték.
Leírás Ez az attribútum jelöli az ügyfélszolgálati adatok forrásrendszerét, jelen esetben a Zendesk Supportot. Segíti az adatirányítást és az adatok eredetének nyomon követését, különösen akkor, ha több rendszerből származó adatokat kapcsolnak össze. Az elemzés során biztosítja, hogy az adatokat a megfelelő forráshoz rendeljék. Ez fontos az adatok sértetlenségének megőrzéséhez és a folyamat hátterének megértéséhez, különösen több rendszert használó környezetben. Miért fontos? Megmutatja az adatok eredetét, ami fontos az adatirányításhoz és a folyamatadatok megkülönböztetéséhez integrált rendszerekben. Hol szerezhető be? Ez az adatok kinyerésekor hozzáadott állandó érték, amely megjelöli az adatok forrását. Példák Zendesk Support
	Tevékenység neve ActivityName	Az ügyfélszolgálati kérés életciklusa során bekövetkezett esemény vagy elvégzett feladat neve.
Leírás A tevékenység neve az ügyfélszolgálati folyamat egyetlen lépését vagy mérföldkövét jelöli, például „Ügyfélszolgálati kérés létrehozva”, „Kérés ügyintézőhöz rendelve” vagy „Ügyfélszolgálati kérés megoldva”. Ezek az időbélyeggel ellátott események adják az egyes kérések műveleti sorrendjét. Ez az attribútum elengedhetetlen a folyamat menetének megjelenítéséhez, a folyamatváltozatok feltárásához, valamint az események gyakoriságának és sorrendjének elemzéséhez. Segítségével az elemzők megérthetik, milyen műveletek történnek, és azonosíthatják a gyakori útvonalakat, a szűk keresztmetszeteket, valamint a szokásos eljárástól való eltéréseket. Miért fontos? Ez az attribútum határozza meg a folyamat lépéseit, így megjeleníthető a folyamattérkép, és elemezhető a folyamat menete, valamint annak változatai. Hol szerezhető be? A Zendesk jegyaudit-naplóiból vagy az eseményadatfolyamokból származik, amelyek a változásokat és műveleteket rögzítik. Példák Ügyfélszolgálati kérés létrehozvaKérés ügyintézőhöz rendelveÜgyintéző első nyilvános válasza elküldveÜgyfélszolgálati kérés megoldva
	Utolsó adatfrissítés LastDataUpdate	A forrásrendszerből végzett legutóbbi adatfrissítés vagy adatkivonás időbélyege.
Leírás Ez az attribútum jelzi, mikor frissítették utoljára az adatkészletet a Zendesk Supportból. Segít megítélni, mennyire frissek az elemzett adatok. Az utolsó frissítés időpontjának ismeretében az elemzők és az üzleti felhasználók megállapíthatják, hogy a folyamat legfrissebb adatait látják-e. Segít tisztázni az adatok aktualitásával kapcsolatos elvárásokat, és fontos a jelentésekhez, valamint a nyomon követéshez. Miért fontos? Jelzi, mennyire frissek az adatok, így a felhasználók tudják, mennyire aktuális a folyamatelemzés. Hol szerezhető be? Ez az adatkivonás során létrehozott és tárolt metaadatmező rögzíti az adatkinyerési feladat időbélyegét. Példák 2023-10-27T02:00:00Z
	Hozzárendelt ügyintéző AssignedAgent	Az ügyfélszolgálati kérés kezeléséért felelős ügyintéző neve vagy azonosítója.
Leírás Ez az attribútum megmutatja, hogy egy adott időpontban melyik ügyintéző felelős a tevékenységért vagy az ügyfélszolgálati kérésért. A kérés életciklusa során ez változhat, ha másik ügyintézőhöz rendelik. A hozzárendelt ügyintéző szerinti elemzés segít megérteni az ügyintézők munkaterhelését, teljesítményét és hatékonyságát. Az „Ügyintézői munkaterhelés és hatékonyság” dashboardon összehasonlíthatók az ügyintézési idők és az ügyek száma, így felismerhetők a képzési lehetőségek, és kiegyensúlyozható a munkaterhelés. Miért fontos? Rögzíti, melyik ügyintéző végezte el a műveletet, így elemezhető az egyéni teljesítmény, a munkaterhelés eloszlása és az erőforrások felhasználása. Hol szerezhető be? Zendesk Tickets API, `assignee_id` mező. A felhasználói adatok a Users API-ból kérhetők le. Példák John SmithJane DoeSupportBot
	Kapcsolattartási csatorna CommunicationChannel	Az a csatorna, amelyen keresztül az ügyfél benyújtotta a szolgáltatási kérelmet, vagy amelyen a kommunikáció zajlott.
Leírás Ez az attribútum a kommunikáció módját jelöli, például e-mailt, webes űrlapot, chatet vagy telefonhívást. Megmutatja, hogyan lépnek kapcsolatba az ügyfelek az ügyfélszolgálattal. A csatornák használatának ismerete segíti az erőforrások tervezését és az ügyfélélmény javítását. A „Kapcsolattartási csatornák használata” dashboard megmutatja, mely csatornák a legnépszerűbbek, illetve hogy egyes csatornákhoz hosszabb megoldási idő vagy eltérő folyamatút társul-e. Az adatok alapján eldöntheti, mely csatornák fejlesztésébe vagy automatizálásába érdemes befektetni. Miért fontos? Megmutatja, hogyan kommunikálnak az ügyfelek és az ügyintézők, így elemezhető a csatornák hatékonysága, valamint a folyamatra és az ügyfélélményre gyakorolt hatásuk. Hol szerezhető be? Zendesk Tickets API, `via.channel` mező. Példák webe-mailapichat
	Prioritás Priority	Az ügyfélszolgálati kéréshez rendelt prioritási szint, például „Alacsony”, „Normál”, „Magas” vagy „Sürgős”.
Leírás A prioritás jelzi, mennyire sürgős az ügyfélszolgálati kérés, és gyakran meghatározza a sorban elfoglalt helyét, valamint a célként kitűzött megoldási időt. Segít az ügyintézőknek először a legsürgősebb problémákra összpontosítani. Ez az attribútum elengedhetetlen a teljesítmény és az SLA-k elemzéséhez. Az „Ügyfélszolgálati kérések megoldási idejének elemzése” dashboard a prioritás szerint bontja az adatokat, így látható, hogy a magas prioritású kéréseket gyorsabban kezelik-e az alacsonyabb prioritásúaknál, és az erőforrásokat az üzleti igényeknek megfelelően osztják-e el. Miért fontos? A kérelem sürgősségét jelzi. Ez az SLA-megfelelés elemzéséhez és a sürgős ügyek gyors kezeléséhez is fontos. Hol szerezhető be? Zendesk Tickets API, `priority` mező. Példák AlacsonyNormálMagasSürgős
	SLA szerinti megoldási határidő SlaTargetResolutionTime	Az SLA-szabályzat alapján meghatározott időtartam, amelyen belül a szolgáltatási kérelmet meg kell oldani.
Leírás Ez az attribútum határozza meg a jegy megoldására vonatkozó szolgáltatási szint megállapodás (SLA) célértékét. Ez az érték gyakran változó, és függhet például a kérelem prioritásától, típusától vagy az ügyfél szolgáltatási csomagjától. Ez az attribútum az „SLA-megfelelési teljesítmény” dashboard alapja. Viszonyítási alapként szolgál a tényleges megoldási idő méréséhez. A célértékhez viszonyított teljesítmény elemzésével számszerűsíthető a szolgáltatás minősége, és ellenőrizhető, hogy teljesülnek-e az ügyfelekkel szemben vállalt szerződéses kötelezettségek. Miért fontos? Rögzíti az ügyfélnek tett szolgáltatási vállalást, és viszonyítási alapot ad a határidőre történő teljesítés és az SLA-megfelelés méréséhez. Hol szerezhető be? A jegyre alkalmazott SLA-szabályzatokból származik. Az adat a Zendesk Ticket Metrics API-n keresztül érhető el. Példák 144002880086400
	SLA-túllépés történt IsSlaBreached	Logikai érték, amely jelzi, hogy a szolgáltatási kérelem megoldási ideje túllépte-e az SLA-célértéket.
Leírás Ez a számított attribútum egyszerű igaz vagy hamis értékkel jelzi, hogy a szolgáltatási kérelem megoldása megfelelt-e a meghatározott szolgáltatási szint megállapodásnak. Az érték a tényleges megoldási idő és az SLA-célérték összehasonlításából adódik. Ez a jelző egyszerűbbé teszi az SLA-megfelelés elemzését. Az „SLA-megfelelési teljesítmény” dashboard és az „SLA-megfelelési arány” KPI alapadata. Segítségével gyorsan összesíthető és megjeleníthető, hány kérelem teljesíti a szolgáltatási célértékeket, és hány nem. Miért fontos? Egyértelmű, kétértékű eredményt ad az egyes ügyek SLA-teljesítéséről, így egyszerűbbé teszi a megfelelés nyomon követését és jelentését. Hol szerezhető be? Az adatátalakítás során számítjuk ki a teljes megoldási idő és a SlaTargetResolutionTime összehasonlításával. Példák truefalse
	Ügyfélszolgálati kérés típusa ServiceRequestType	Az ügyfélszolgálati kérés besorolása, például „Kérdés”, „Incidens”, „Probléma” vagy „Feladat”.
Leírás Ez az attribútum a kérés jellege alapján kategorizálja az ügyfélszolgálati kérést. A besorolást általában a kérés létrehozásakor vagy kezdeti feldolgozásakor állítják be, és segít meghatározni a megfelelő munkafolyamatot és prioritást. Az elemzésben alapvető a kéréstípus szerinti bontás. Lehetővé teszi a különböző problématípusok megoldási idejének, eszkalációs arányának és folyamatmenetének összehasonlítását, például az „Ügyfélszolgálati kérések megoldási idejének elemzése” és a „Belső eszkalációk aránya és okai” dashboardon. Így kiderülhet, hogy bizonyos kéréstípusok kezelése problémásabb vagy kevésbé hatékony-e. Miért fontos? A kérések kategorizálásával összehasonlítható és elemezhető a teljesítmény a különböző problématípusok között, ami célzott folyamatfejlesztést tesz lehetővé. Hol szerezhető be? Zendesk Tickets API, `type` mező. Példák KérdésIncidensProblémaFeladat
	Befejezési idő EndTime	Az időbélyeg, amely megadja, mikor fejeződött be egy tevékenység vagy esemény.
Leírás A befejezési idő a tevékenység lezárásának időpontját jelöli. Sok eseménynaplóban a következő tevékenység kezdési ideje adja meg az aktuális tevékenység befejezési idejét. Az olyan állapotalapú tevékenységeknél, mint az „Ügyintéző kivizsgálja a problémát”, azt mutatja, mikor ért véget az adott állapot. Ez az attribútum elengedhetetlen a tevékenységek pontos időtartamának kiszámításához, ami a teljesítményelemzés egyik alapja. Segít azonosítani a legtöbb időt igénylő lépéseket, és alapot ad a szűk keresztmetszetek részletes elemzéséhez, valamint az erőforrások hatékonyságának méréséhez. Miért fontos? Lehetővé teszi a tevékenységek időtartamának kiszámítását, ami elengedhetetlen a szűk keresztmetszetek feltárásához és a teljesítmény méréséhez. Hol szerezhető be? Ezt gyakran úgy határozzák meg, hogy az adott ügyfélszolgálati kérés következő eseményének StartTime értékét veszik alapul. Példák 2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
	Elégedettségi értékelés SatisfactionRating	Az ügyfél által a szolgáltatási kérelem megoldása után adott elégedettségi pontszám.
Leírás Ez az attribútum az ügyfél szolgáltatással kapcsolatos visszajelzését rögzíti, amelyet általában a jegy megoldása után, kérdőívben gyűjtenek be. Az értékelés lehet például „Jó”, „Rossz” vagy egy számszerű pontszám. Ez közvetlenül méri az ügyfél elégedettségét, és fontos eredménymutató. Ebből számítható ki az „Ügyfél-elégedettségi pontszám” KPI. Ha az elégedettségi értékeléseket a folyamatadatokkal, például a megoldási idővel vagy az ügyintézői kapcsolatfelvételek számával együtt elemzi, kiderülhet, mely folyamatlépések vezetnek jobb ügyféleredményekhez. Miért fontos? Közvetlenül méri az ügyfél visszajelzését a kapott szolgáltatásról, és összekapcsolja a folyamat teljesítményét az ügyfél eredményeivel. Hol szerezhető be? Zendesk Tickets API, `satisfaction_rating.score` mező. Példák jórosszfelajánlva
	Információkérések száma InformationRequestCount	Az ügyféltől egyetlen szolgáltatási kérelem kapcsán kért információk összesített száma.
Leírás Ez a számított mutató szolgáltatási kérelmenként összesíti az „Információkérés az ügyféltől” tevékenység előfordulásait. A magas érték arra utalhat, hogy az ügyintézők nem gyűjtik be előre az összes szükséges információt. Ez az attribútum az „Ismételt információkérések elemzése” dashboardon használható. A kérések számának követése segít feltárni a folyamat hiányosságait és az ügyintézők képzési igényeit. Ha kevesebbszer kell információt kérni, jelentősen csökkenhet a megoldási idő, és javulhat az ügyfélélmény. Miért fontos? Számszerűsíti az ügyféllel folytatott oda-vissza kommunikációt, és rávilágít azokra a hiányosságokra, amelyek meghosszabbítják a megoldási időt és rontják az ügyfélélményt. Hol szerezhető be? A szolgáltatási kérelemhez tartozó események közül megszámolja azokat, amelyeknél az ActivityName értéke „Information Requested From Customer”. Példák 013
	Megoldási kód ResolutionCode	A kérelem végleges megoldásának vagy lezárásának okát jelölő kód vagy kategória.
Leírás A megoldási kód részletesen rögzíti, mi történt a szolgáltatási kérelemmel. Ilyen érték lehet például: „Ügyintéző megoldotta”, „Duplikált”, „Nincs további teendő” vagy „Ismert hiba”. Több információt ad, mint az egyszerű „Lezárva” állapot. Ez az attribútum különösen hasznos a kiváltó okok elemzéséhez. Az „Újranyitott szolgáltatási kérelmek alakulása” dashboardon a megoldási kód szerinti újranyitási arány megmutathatja, ha bizonyos megoldások kevésbé hatékonyak, és emiatt az ügyfeleknek ismét kapcsolatba kell lépniük az ügyfélszolgálattal. Miért fontos? Megmutatja, mi lett a szolgáltatási kérelem eredménye. Ez segít feltárni a kiváltó okokat és megérteni, miért nyitják meg újra a kérelmeket. Hol szerezhető be? Ez általában egy egyéni jegymező a Zendeskben. A pontos mezőnév a Zendesk adott konfigurációjától függ. Példák Megoldás az első kapcsolatfelvételkorTovábbítva a 2. szintű ügyfélszolgálathozÜgyfél válaszára várTermékhiba
	Termék- vagy szolgáltatáskategória ProductServiceCategory	Az a konkrét termék, szolgáltatás vagy funkció, amelyre az ügyfél kérelme vonatkozik.
Leírás Ez az attribútum termék vagy szolgáltatási terület szerint kategorizálja a kérelmet, így részletesebb kontextust ad. A kategóriát gyakran az ügyintéző állítja be, de a kérelem tartalma alapján automatikusan is meghatározható. Ez a besorolás fontos a „Kérelmek kategorizálásának pontossága” és a „Vizsgálati ciklusidő részletezése” dashboardokhoz. Segítségével részletesen elemezhető, mely termékekkel kapcsolatban érkezik a legtöbb kérelem, melyek megoldása a legösszetettebb, és hogy az eredeti kategorizálás megfelel-e a végső megoldásnak. Az eredmények alapján javítható a kérelmek irányítása és az ügyintézők képzése. Miért fontos? A kérelmeket konkrét üzleti területekhez, termékekhez vagy szolgáltatásokhoz kapcsolja, így célzottan elemezhetők a problémás területek és azok folyamatra gyakorolt hatásai. Hol szerezhető be? Ez általában egy egyéni jegymező a Zendeskben. A pontos mezőnév a Zendesk adott konfigurációjától függ. Példák MobilalkalmazásElőfizetés-kezelésAPI-integrációHardver
	Ügyintézői csoport AgentGroup	Az a támogatási csoport vagy csapat, amelyhez a szolgáltatási kérelmet hozzárendelték.
Leírás Ez az attribútum a szolgáltatási kérelemért felelős ügyintézői csapatot jelöli. A kérelmeket gyakran szaktudás, termékterület vagy nyelv alapján irányítják egy-egy csoporthoz. Az ügyintézői csoportok szerinti elemzés segít megérteni a csapatok teljesítményét, a munkaterhelés eloszlását és a csoportok közötti továbbításokat. Az egyes ügyintézők vizsgálatánál átfogóbb képet ad, és segíthet feltárni az egyes részlegek vagy területek működésében jelentkező rendszerszintű problémákat. Miért fontos? Rögzíti, melyik csapat felelős az ügyért, így elemezhető a csoportok teljesítménye, a csapatok közötti átadás és az erőforrások elosztása a különböző támogatási szintek és szakterületek között. Hol szerezhető be? Zendesk Tickets API, `group_id` mező. A csoportok adatai a Groups API-n keresztül kérhetők le. Példák 1. szintű ügyfélszolgálatMűszaki támogatásSzámlázás
	Újranyitották IsReopened	Logikai érték, amely jelzi, hogy a szolgáltatási kérelmet a megoldottnak jelölése után újranyitották-e.
Leírás Ez az attribútum akkor kap igaz értéket, ha a szolgáltatási kérelem a megoldott vagy lezárt állapotból ismét nyitott állapotba kerül. Ez azt jelzi, hogy az eredeti megoldás nem volt elegendő. A jelző segít nyomon követni az ismételt munkát és az első kapcsolatfelvételkor elmaradt megoldásokat. Közvetlenül támogatja az „Újranyitott szolgáltatási kérelmek alakulása” dashboardot és a „Szolgáltatási kérelmek újranyitási aránya” KPI-t. Egyszerűen összesíthetők és elemezhetők vele azok az ügyek, amelyek további figyelmet igényelnek, és amelyek gyakran mélyebb problémákra utalnak. Miért fontos? Azonosítja az ismételt munkát és a sikertelen megoldásokat, így mérhetővé teszi a nyújtott megoldások minőségét és hatékonyságát. Hol szerezhető be? Az adatátalakítás során számítjuk ki annak ellenőrzésével, hogy a jegy állapota „resolved” vagy „closed” értékről „open” értékre változott-e. Példák truefalse

Kötelező Javasolt Nem kötelező

Ügyfélszolgálati tevékenységek

Ezeket a fontos folyamatlépéseket és mérföldköveket érdemes rögzíteni az eseménynaplóban az ügyfélszolgálati folyamat pontos feltérképezéséhez.

6 Javasolt 8 Nem kötelező

	Tevékenység	Leírás
	Kérés ügyintézőhöz rendelve	Ez az esemény azt jelzi, hogy az ügyfélszolgálati kérést egy adott ügyintézőhöz rendelték. A hozzárendelés történhet automatikusan, irányítási szabályok alapján, vagy kézzel, csoportvezető vagy ügyintéző által.
Miért fontos? A hozzárendelés fontos mérföldkő az elszámoltathatóság és a munkaterhelés kezelése szempontjából. A hozzárendelésig eltelt idő és az újraosztások mintázatának elemzése feltárja a kezdeti besorolás és az elosztás szűk keresztmetszeteit. Hol szerezhető be? Ez a Zendesk Ticket Audits API-ban rögzített, kifejezett „Change” esemény, amely akkor keletkezik, amikor az „assignee_id” mezőt kitöltik vagy módosítják. Rögzítés Kövesse nyomon az „assignee_id” mező változásait a Ticket Audits naplóban. Eseménytípus explicit
	További információ kérése az ügyféltől	Akkor történik, amikor az ügyintézőnek további információra van szüksége a továbblépéshez, ezért a jegy állapotát „pending” értékre állítja. Ez az állapotváltozás egyértelműen jelzi, hogy a folyamat külső félre vár.
Miért fontos? Ez a tevékenység jelzi az ügyféltől való függést, és szünetelteti a belső SLA-időmérést. Ha egy jegynél gyakran vagy többször fordul elő, az hiányos kezdeti információgyűjtésre utalhat, és meghosszabbíthatja a megoldási időt. Hol szerezhető be? Ez a Zendesk Ticket Audits API-ban rögzített, kifejezett állapotváltozási esemény. Akkor kerül rögzítésre, amikor a „status” mező értéke „pending” lesz. Rögzítés Keresse meg a Ticket Audits „Change” eseményei között azokat, amelyeknél a jegy állapota „pending” értékre változik. Eseménytípus explicit
	Ügyfélszolgálati kérés létrehozva	Ez a tevékenység jelöli az ügyfélszolgálati folyamat kezdetét: új jegy jön létre a Zendeskben, például e-mailből, webes űrlapról vagy csevegésből. A rendszer a létrehozáskor egyedi jegyazonosítóval és időbélyeggel rögzíti az eseményt.
Miért fontos? Ez a folyamat első eseménye, ezért alapvető az ügy teljes időtartamának kiszámításához és a beérkező kérések időbeli alakulásának elemzéséhez. Kiindulópontként szolgál olyan KPI-k méréséhez, mint az első válaszig eltelt idő és a teljes megoldási idő. Hol szerezhető be? Ez a Zendesk Ticket Audits API-ban rögzített, kifejezett esemény. A jegy „Create” eseményének felel meg, és megadja a létrehozás időpontját. Rögzítés A Ticket Audits napló jegylétrehozási eseményéből származik. Eseménytípus explicit
	Ügyfélszolgálati kérés lezárva	Ez az utolsó tevékenység, amely végleg lezárja az ügyfélszolgálati kérést. Ez általában automatikusan történik, miután a jegy „solved” állapotba került, és egy meghatározott ideig nem érkezett új ügyfélválasz.
Miért fontos? Ez a végleges lezárást jelző esemény zárja le a jegy életciklusát. A „solved” és a „closed” állapot közötti időszakban még újranyitható a jegy, a „closed” esemény pedig megerősíti, hogy a megoldást elfogadták. Hol szerezhető be? Ez a Zendesk Ticket Audits API-ban rögzített, kifejezett állapotváltozás, amely akkor történik, amikor a „status” mező értéke „closed” lesz. Rögzítés Keresse meg a Ticket Audits „Change” eseményei között azokat, amelyeknél a jegy állapota „closed” értékre változik. Eseménytípus explicit
	Ügyfélszolgálati kérés megoldva	Az ügyintéző „solved” állapotúra állítja az ügyfélszolgálati kérést, miután megoldást adott az ügyfélnek. Ez még nem végleges állapot, mert az ügyfél válasza a jegy végleges lezárása előtt újranyithatja azt.
Miért fontos? Ez a megoldási idő és az ügyintézői hatékonyság mérésének fő mérföldköve. Azt jelzi, hogy az ügyintéző befejezettnek tekinti a munkát, és alapot ad az utómunka elemzéséhez, ha a jegyet újranyitják. Hol szerezhető be? Ez a Zendesk Ticket Audits API-ban rögzített, kifejezett állapotváltozás, amely akkor történik, amikor a „status” mező értéke „solved” lesz. Rögzítés Keresse meg a Ticket Audits „Change” eseményei között azokat, amelyeknél a jegy állapota „solved” értékre változik. Eseménytípus explicit
	Ügyfélszolgálati kérés újranyitva	Ez a tevékenység akkor történik, ha az ügyfél „solved” állapotú jegyre válaszol. A Zendesk automatikusan „open” értékre állítja vissza az állapotot, jelezve, hogy a probléma nem oldódott meg teljesen.
Miért fontos? Az újranyitás az első kapcsolatfelvételkor történő megoldás sikertelenségének és a megoldás gyenge minőségének fontos jelzője. Az újranyitott jegyek gyakoriságának és okainak elemzése segít meghatározni, hogyan javítható az ügyintézők képzése és a megoldási folyamat. Hol szerezhető be? Ez a Ticket Audits API-ban rögzített, kifejezett állapotváltozás, amely akkor keletkezik, amikor a „status” értéke „solved” állapotról „open” állapotra változik. Rögzítés Kövesse nyomon a „solved” értékről „open” értékre történő „Change” állapotváltozásokat. Eseménytípus explicit
	Az ügyfél válaszolt	Ez az esemény akkor következik be, amikor az ügyfél válaszol egy jegyre, amelynek állapota általában „pending”. A Zendesk automatikusan „pending” értékről „open” értékre állítja a jegy állapotát, jelezve, hogy az ügyintéző folytathatja a munkát.
Miért fontos? Ez a tevékenység jelzi a várakozási idő végét, és a folyamat folytatásának kiváltó eseménye. Az ügyfél válaszidejének elemzése segíthet megítélni, mennyire egyértelműek az ügyintéző kérései. Hol szerezhető be? Ez az esemény a végfelhasználó új nyilvános megjegyzésének felel meg, amely a Ticket Audits API-ban kifejezett állapotváltozást indít el „pending” értékről „open” értékre. Rögzítés Kövesse nyomon a „pending” értékről „open” értékre történő „Change” állapotváltozásokat, vagy keresse meg a végfelhasználó új nyilvános megjegyzéseit. Eseménytípus explicit
	Belső eszkaláció indult	Az ügyfélszolgálati kérés átadása egy másik belső csapatnak vagy magasabb támogatási szintnek. Erre általában abból lehet következtetni, hogy megváltozik a jegyhez rendelt csoport.
Miért fontos? Az eszkalációk nyomon követése segít feltárni a folyamat gyenge pontjait, az első vonalbeli támogatás tudáshiányait és az összetett kéréstípusokat. A magas eszkalációs arány jobb képzés vagy részletesebb folyamatdokumentáció szükségességére utalhat. Hol szerezhető be? A Ticket Audits API „Change” eseményéből következtethető ki, ha módosul a „group_id” mező. A csoportváltás a csapatok közötti átadást jelzi. Rögzítés Kövesse nyomon a „group_id” mező változásait a Ticket Audits naplóban. Eseménytípus inferred
	Elégedettségi értékelés beérkezett	Ez az esemény akkor történik, amikor az ügyfél elküldi válaszát az elégedettségi felmérésre, például „Good” vagy „Bad” értékelést ad. Az értékelést és a hozzá tartozó megjegyzést a rendszer a jegyhez rögzíti.
Miért fontos? Az ügyfelektől közvetlenül érkező visszajelzés felbecsülhetetlen értékű a szolgáltatás minőségének és az ügyfelek véleményének méréséhez. Ha az értékeléseket a folyamat menetével együtt elemzi, feltárhatja, hogyan függnek össze az egyes tevékenységek vagy ügyintézők az eredményekkel. Hol szerezhető be? A Ticket Audits API „Change” eseményként rögzíti, amikor az ügyfél pontszámával és megjegyzésével kitöltik a „satisfaction_rating” mezőt. Rögzítés Szűrje a Ticket Audit naplókat a „satisfaction_rating” mező változásaira. Eseménytípus explicit
	Elégedettségi felmérés elküldve	Azt az időpontot jelöli, amikor automatikusan elégedettségi (CSAT) felmérés érkezik az ügyfélhez. Ez általában röviddel azután történik, hogy a jegy „solved” állapotba kerül.
Miért fontos? Ez a tevékenység indítja el az ügyfél-visszajelzési folyamatot. A felmérések küldési idejének és tényének ismerete segít az elégedettségi pontszámok értelmezésében és a visszajelzési program hatékonyságának mérésében. Hol szerezhető be? Az esemény automatizmusnaplóból vagy a jegyhez hozzáadott címke alapján következtethető ki. A Ticket Audits API „satisfaction_rating” szakasza azt is rögzíti, mikor ajánlották fel a felmérést. Rögzítés Keressen olyan címkéket, mint a „csat_sent”, vagy használja azt az időbélyeget, amikor az elégedettségi értékelést felajánlották. Eseménytípus inferred
	Első visszaigazolás elküldve	Az ügyfélnek küldött automatikus első válasz, amely megerősíti a kérés beérkezését. Ezt általában egy Zendesk trigger kezeli, amely a jegy létrehozása után azonnal sablonos e-mail-értesítést küld.
Miért fontos? Ennek a tevékenységnek a nyomon követése fontos az első válasz gyorsaságának méréséhez és az ügyfélelvárások kezeléséhez. A kérés létrehozása és a visszaigazolás közötti idő az ügyfél-elégedettség egyik fontos mutatója. Hol szerezhető be? A jegyhez fűzött első nyilvános megjegyzés alapján következtethető ki, ha azt automatizált felhasználó írta, vagy a jegy létrehozása után néhány másodpercen belül született. A Ticket Comments adatfolyam elemzésével azonosítható. Rögzítés Keresse meg a jegy létrehozását közvetlenül követő első nyilvános megjegyzést, amelyet automatizmus vagy trigger hozott létre. Eseménytípus inferred
	Kérés kategorizálva és rangsorolva	Ez a tevékenység akkor történik, amikor egy ügyintéző vagy automatizmus beállítja vagy módosítja a jegy mezőit, például a típust, a kategóriát vagy a prioritást. A lépés változásként jelenik meg a jegy előzményeiben.
Miért fontos? A megfelelő kategorizálás és rangsorolás elengedhetetlen a hatékony irányításhoz és az erőforrások elosztásához. A tevékenység elemzésével megállapítható, mennyire pontos az első besorolás, és hogyan hat a megoldási időre. Hol szerezhető be? A Zendesk Ticket Audits API „Change” eseményeiből nyerhető ki. Az első olyan módosítást kell keresni, amely a „priority”, a „type” vagy a kategorizáláshoz kapcsolódó egyéni mezőket érinti. Rögzítés Szűrje a Ticket Audit naplókat a létrehozás utáni első „Change” eseményre a fő kategorizálási mezőkben. Eseménytípus explicit
	SLA-sértés történt	Ez a tevékenység azt az időpontot jelöli, amikor az ügyfélszolgálati kérés nem teljesíti az előre meghatározott szolgáltatási szintre vonatkozó megállapodást, például az első válaszidőre vagy a megoldási időre vonatkozó célt. Az esemény a jegytevékenységek időbélyegeinek és az SLA-szabályoknak az összevetésével számítható ki.
Miért fontos? Az SLA-sértések közvetlenül hatnak az ügyfél-elégedettségre és a szerződéses vállalások teljesítésére. A bekövetkezésük időpontjának és okainak elemzése segít feltárni a rendszerszintű késéseket, az erőforráshiányt vagy a nem reális teljesítménycélokat. Hol szerezhető be? Az adat a Zendesk Ticket Metrics API-ból származhat, amely az SLA-sértések időbélyegét („breached_at”) tárolja. Másik lehetőségként a jegyesemények időbélyegei az SLA-szabályokkal összevetve is kiszámíthatók. Rögzítés Használja a Ticket Metrics API „breached_at” időbélyegét, vagy számítsa ki az értéket a megoldási idő és az SLA-szabályban meghatározott idő összevetésével. Eseménytípus calculated
	Ügyintéző első nyilvános válasza elküldve	Ez a tevékenység jelöli, amikor egy ügyintéző először küld nyilvános megjegyzést az ügyfélnek, nem pedig automatikus visszaigazolás érkezik. Fontos jelzője annak, mikor kezd az ügyintéző érdemben foglalkozni az ügyfél problémájával.
Miért fontos? Ez fontos mérföldkő az első válaszidőre vonatkozó SLA mérésében, amely az ügyfélszolgálat gyorsaságának egyik fő mutatója. Elkülöníti az automatikus üzeneteket az aktív, emberi ügyintézés kezdetétől. Hol szerezhető be? A Ticket Comments adatfolyam első olyan nyilvános megjegyzése alapján azonosítható, amelyet emberi ügyintéző írt, nem pedig automatizált rendszerfelhasználó. Rögzítés Vizsgálja át a jegyhez fűzött megjegyzéseket, szűrje ki az ügyintézők nyilvános megjegyzéseit, majd válassza ki a legkorábbi időbélyegűt. Eseménytípus inferred

Javasolt Nem kötelező

Adatkinyerési útmutatók

Így nyerheti ki az adatokat a Zendesk Supportból

Lépések

Nyissa meg a Zendesk Explore-t: Jelentkezzen be a Zendesk-példányába, majd a felső sáv termékindító ikonjára kattintva válassza ki az Explore-t.
Hozzon létre új lekérdezést: Az Explore-ban kattintson a bal oldali sáv Lekérdezések ikonjára, majd a jobb felső sarokban az „Új lekérdezés” gombra.
Válassza ki az adatkészletet: A „Válasszon adatkészletet” ablakban jelölje ki a Support: Tickets adatkészletet. Ez tartalmazza az elsődleges jegyattribútumokat és a fontos események időbélyegeit.
Adjon hozzá mérőszámokat: A lekérdezéskészítő „Mérőszámok” paneljén kattintson a „Hozzáadás” gombra, majd válassza ki a COUNT(Tickets) mérőszámot. Ezzel ellenőrizheti az adatok mennyiségét.
Adjon attribútumokat a sorokhoz: Lépjen a „Sorok” panelre, kattintson a „Hozzáadás” gombra, és adja hozzá a következő attribútumokat. Ezek lesznek a széles formátumú export alapvető oszlopai.
- Jegyazonosító (ez az esetazonosító, ServiceRequest)
- Felelős neve (AssignedAgent)
- Jegy típusa (ServiceRequestType)
- Jegy prioritása (Priority)
- Jegy csatornája (CommunicationChannel)
- SLA-megoldási idő (SlaTargetResolutionTime)
- SLA-sértés állapota (IsSlaBreached)
- Teljes megoldási idő (perc) (ServiceRequestResolutionTime)
Adja hozzá a tevékenységek időbélyegeit a sorokhoz: Adja hozzá a következő időbélyeg-attribútumokat a „Sorok” panelhez. Mindegyik egy lehetséges tevékenységet jelöl. Néhány tevékenységhez egyéni számított attribútumot kell létrehoznia.
- Jegy létrehozva - időbélyeg: a Szolgáltatási igény létrehozva és a Visszaigazolás elküldve tevékenységhez.
- Jegy hozzárendelve - időbélyeg: az Igény hozzárendelve ügyintézőhöz tevékenységhez.
- Első válasz ideje - időbélyeg: az Ügyintéző első nyilvános válasza elküldve tevékenységhez.
- Jegy megoldva - időbélyeg: a Szolgáltatási igény megoldva és az Elégedettségi felmérés elküldve tevékenységhez.
- Jegy újranyitva - időbélyeg: a Szolgáltatási igény újranyitva tevékenységhez.
- Elégedettségi értékelés beérkezett - időbélyeg: az Elégedettségi értékelés beérkezett tevékenységhez.
- Jegy lezárva - időbélyeg: a Szolgáltatási igény lezárva tevékenységhez.
Hozzon létre egyéni számított attribútumokat a többi tevékenységhez: Néhány tevékenység adott mezők változásán alapul, ezért az időbélyeg rögzítéséhez egyéni attribútumot kell létrehoznia. Nyissa meg a Számítások menüt (számológép ikon), majd válassza a „Szabványos számított attribútum” lehetőséget. Hozzon létre attribútumot az alábbi tevékenységekhez. A mezők és értékek pontos nevét a Zendesk-példányában kell megkeresnie.
- Név: Időbélyeg - Kategorizálva és prioritás megadva. Képlet: IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF. Létrehozás után adja hozzá az attribútumot a „Sorok” panelhez, és az összesítő függvényt állítsa MIN értékre.
- Név: Időbélyeg - További információt kértek. Képlet: IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF. Adja hozzá a „Sorok” panelhez, és az összesítő függvényt állítsa MIN értékre.
- Név: Időbélyeg - Ügyfél válaszolt. Képlet: IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF. Adja hozzá a „Sorok” panelhez, és az összesítő függvényt állítsa MIN értékre.
- Név: Időbélyeg - Eszkalálva. Képlet: IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF. Adja hozzá a „Sorok” panelhez, és az összesítő függvényt állítsa MIN értékre.
- Név: Időbélyeg - SLA-sértés. Képlet: IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF. Adja hozzá a „Sorok” panelhez, és az összesítő függvényt állítsa MIN értékre.
Szűrje az adatokat: Nyissa meg a „Szűrők” panelt, és kattintson a „Hozzáadás” gombra. Adjon meg szűrőt a Jegy létrehozva - dátum mezőre, majd válasszon megfelelő időszakot, például az elmúlt 3–6 hónapot, hogy kezelhető méretű maradjon az adatkészlet.
Futtassa és exportálja a jelentést: A lekérdezés futtatásához kattintson a „Mentés” gombra. Amikor megjelenik az adattábla, kattintson az „Exportálás” gombra, és válassza ki a kívánt formátumot, például a CSV-t vagy az Excelt.
Alakítsa át az adatokat eseménynapló-formátumra: Az exportált fájl „széles” formátumú: minden sor egy jegyet, minden oszlop pedig egy esemény időbélyegét tartalmazza. A process mining elemzéshez ezt „hosszú” formátumra kell átalakítania. Használhat például Microsoft Excelt (a Power Query oszlopok sorokká alakítása funkciójával), Pythont vagy más adat-előkészítő eszközt.
- Minden jegyhez hozzon létre új sorokat, egyet minden nem üres időbélyeg-oszlophoz.
- A végső táblázatban szerepeljenek például a ServiceRequest, ActivityName és StartTime oszlopok, valamint a többi attribútum. Az attribútumokat az adott szolgáltatási igény minden tevékenységsorában ismételje meg.

Konfiguráció

Adatkészlet: Elsődleges adatkészletként a Support: Tickets elemet használja. Egyetlen lekérdezésben hozzáférhet a legtöbb jegytulajdonsághoz és a fontos időbélyegekhez.
Jogosultságok: Lekérdezések létrehozásához és mentéséhez legalább Editor vagy Admin szerepkör szükséges a Zendesk Explore-ban.
Időszak: Feltétlenül állítson be dátumszűrőt a Ticket created - Date mezőre. Az elemzéshez általában 3–6 hónapnyi adat ajánlott, így az eredmények és a teljesítmény között megfelelő egyensúly érhető el. Több millió jegy exportálása lassú lehet, vagy akár meg is hiúsulhat.
Lekérdezésszűrők: Az elemzést egy adott szolgáltatásra vagy csapatra szűkítheti például a Ticket brand, Ticket form vagy Ticket group mező alapján.
Számított attribútumok: Ez a módszer nagyrészt olyan események időbélyegének rögzítésére szolgáló, szabványos számított attribútumokra épül, amelyekhez nincs alapértelmezett attribútum, például az állapotváltozásokra vagy az eszkalációkra. Ellenőrizze, hogy rendelkezik-e az attribútumok létrehozásához szükséges jogosultságokkal.

Példa-lekérdezés config

This extraction is configured through the Zendesk Explore graphical user interface. There is no single script to execute. The configuration below outlines the components to add in the query builder.

**Dataset**: `Support: Tickets`

**Metrics**:
1.  `COUNT(Tickets)`

**Rows (Attributes)**:
1.  `Ticket ID`
2.  `Assignee name`
3.  `Ticket type`
4.  `Ticket priority`
5.  `Ticket channel`
6.  `SLA resolution time`
7.  `SLA breach status`
8.  `Full resolution time (min)`
9.  `MIN(Ticket created - Timestamp)`
10. `MIN(Ticket assigned - Timestamp)`
11. `MIN(First reply time - Timestamp)`
12. `MIN(Ticket solved - Timestamp)`
13. `MIN(Ticket reopened - Timestamp)`
14. `MIN(Satisfaction rating received - Timestamp)`
15. `MIN(Ticket closed - Timestamp)`
16. `MIN(Timestamp - Categorized and Prioritized)` (Custom calculated attribute)
17. `MIN(Timestamp - Info Requested)` (Custom calculated attribute)
18. `MIN(Timestamp - Customer Responded)` (Custom calculated attribute)
19. `MIN(Timestamp - Escalated)` (Custom calculated attribute)
20. `MIN(Timestamp - SLA Breach)` (Custom calculated attribute)

**Filters**:
1.  `Ticket created - Date`: Select a date range (e.g., last 180 days)

**Standard Calculated Attribute Formulas**:
*   `Timestamp - Categorized and Prioritized`: `IF ([Changes - Field name] = "priority" OR [Changes - Field name] = "type") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Info Requested`: `IF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Customer Responded`: `IF ([Changes - Field name] = "status" AND [Changes - Previous value] = "pending" AND [Changes - New value] = "open") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - Escalated`: `IF ([Changes - Field name] = "group") THEN [Update - Timestamp] ENDIF`
*   `Timestamp - SLA Breach`: `IF ([SLA breach status]=TRUE) THEN [SLA update - Timestamp] ENDIF`

Lépések

Készítse elő a Zendesk API-hozzáférést: Jelentkezzen be rendszergazdaként a Zendeskbe. Nyissa meg az Admin Centert, majd lépjen az Apps and integrations > APIs > Zendesk API menüpontra. A Settings lapon ellenőrizze, hogy a Token Access engedélyezve van-e. Új token létrehozásához kattintson az „Add API token” gombra. Másolja ki biztonságosan a létrehozott tokent, mert később nem jelenik meg újra.
Állítsa be a Python-környezetet: Telepítse a Python 3.6-os vagy újabb verzióját. Telepítse a requests könyvtárat is, amelyre a Zendesk API felé indított HTTP-kérésekhez van szükség. A parancssorban ezzel telepítheti: pip install requests.
Állítsa be a Python-szkriptet: Mentse a megadott Python-szkriptet egy fájlba, például extract_zendesk_log.py néven. Nyissa meg egy szövegszerkesztőben, és cserélje le a fájl elején található helyőrző változókat: ZENDESK_SUBDOMAIN, ZENDESK_EMAIL és API_TOKEN. Adja meg a saját Zendesk-példányának adatait és a hozzáférési adatokat.
Adja meg a kinyerési időszakot: Keresse meg a szkriptben a START_TIMESTAMP változót. Ez határozza meg az adatok kinyerésének kezdő időpontját. Unix epoch időbélyeget kell megadnia. Első elemzéshez az elmúlt 3–6 hónapnak megfelelő érték ajánlott.
Futtassa a szkriptet: Nyisson meg egy terminált vagy parancssort, lépjen abba a könyvtárba, ahová a szkriptet mentette, majd futtassa a következő paranccsal: python extract_zendesk_log.py.
Kövesse a futást: A szkript a konzolon jelzi a folyamat állapotát és a feldolgozott jegyek számát. A futás időtartama a kinyerendő adatok mennyiségétől és a Zendesk által alkalmazott API-korlátozásoktól függ. A szkript alapvető logikát tartalmaz a korlátozást jelző válaszok kezelésére.
Töltse le az eseménynaplót: Sikeres futás után a szkript a zendesk_event_log.csv nevű fájlt hozza létre ugyanabban a könyvtárban. A fájl elemzésre kész, strukturált eseménynaplót tartalmaz.
Készítse elő a feltöltést: Nyissa meg a zendesk_event_log.csv fájlt, és ellenőrizze, hogy megfelelően jött-e létre. Nézze meg, hogy az oszlopok megfelelnek-e a szükséges attribútumoknak: ServiceRequest, ActivityName, StartTime, SourceSystem és LastDataUpdate. A fájl készen áll a process mining eszközbe való feltöltésre.

Konfiguráció

API-hitelesítési adatok: A szkript futtatásához szükség van egy érvényes Zendesk-aldomainre, egy ügyintéző vagy rendszergazda e-mail-címére, valamint egy aktív API-tokenre. A hitelesítési adatokhoz tartozó felhasználónak jogosultsággal kell rendelkeznie a jegyek, a jegyellenőrzések, a felhasználók és a jegymutatók olvasásához.
Időszak: A kinyerés kezdő dátumát a szkript START_TIMESTAMP változója határozza meg, amelynek Unix epoch időbélyegnek kell lennie. Először érdemes rövidebb időszakkal, például 3 hónappal próbálkozni. Így ellenőrizheti a szkript eredményét és teljesítményét, mielőtt nagyobb előzményállományt kér le.
Incremental Export API: A megoldás a Zendesk Incremental Export API-t használja. Nagy mennyiségű jegy lekérésére ez a leghatékonyabb és ajánlott módszer, mert tömeges adatexportra készült, és elkerüli a lapozás gyakori buktatóit.
Teljesítmény és lekérési korlátozások: A Zendesk-előfizetési csomagtól függő API-korlátozásokat alkalmaz. Ha a korlátozás életbe lép, a szkript az API által visszaadott Retry-After fejléc alapján szünetelteti a futást. Nagy Zendesk-példányok esetén a kinyerés több órát is igénybe vehet.
Előfeltételek: A módszerhez működő Python 3.6-os vagy újabb környezet és a külső requests könyvtár szükséges. A szükséges API-token létrehozásához rendszergazdai hozzáférés kell a célként használt Zendesk-példányhoz.

Példa-lekérdezés python

import requests
import json
import time
import datetime
import csv

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">'[your_zendesk_subdomain]'
ZENDESK_EMAIL = class="hl-string">'[your_zendesk_login_email]'
API_TOKEN = class="hl-string">'[your_zendesk_api_token]'

class=class="hl-string">"hl-comment"># Set the start time for the export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is Jan 1, 2023 00:00:00 GMT
START_TIMESTAMP = 1672531200

class=class="hl-string">"hl-comment"># --- Script --- 

BASE_URL = fclass="hl-string">'https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2'
AUTH = (fclass="hl-string">'{ZENDESK_EMAIL}/token', API_TOKEN)
SOURCE_SYSTEM = class="hl-string">'Zendesk Support'
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

CSV_FILENAME = class="hl-string">'zendesk_event_log.csv'
CSV_HEADERS = [
    class="hl-string">'ServiceRequest', class="hl-string">'ActivityName', class="hl-string">'StartTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
    class="hl-string">'AssignedAgent', class="hl-string">'ServiceRequestType', class="hl-string">'Priority', class="hl-string">'CommunicationChannel',
    class="hl-string">'SlaTargetResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'ServiceRequestResolutionTime'
]

def get_user_name(user_id, users_cache, session):
    if user_id in users_cache:
        return users_cache[user_id]
    if user_id is None:
        return None
    try:
        response = session.get(fclass="hl-string">'{BASE_URL}/users/{user_id}.json')
        response.raise_for_status()
        user_name = response.json().get(class="hl-string">'user', {}).get(class="hl-string">'name')
        users_cache[user_id] = user_name
        return user_name
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">'Warning: Could not fetch user {user_id}. Error: {e}')
        users_cache[user_id] = str(user_id)
        return str(user_id)

def format_duration(seconds):
    if seconds is None:
        return None
    return str(datetime.timedelta(seconds=seconds))

def main():
    session = requests.Session()
    session.auth = AUTH
    users_cache = {}
    event_log = []

    class=class="hl-string">"hl-comment"># Fetch tickets using the incremental export API
    url = fclass="hl-string">'{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}'
    ticket_count = 0

    while url:
        print(fclass="hl-string">'Fetching tickets from: {url}')
        try:
            response = session.get(url)

            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">'Retry-After', 60))
                print(fclass="hl-string">'Rate limit hit. Retrying after {retry_after} seconds.')
                time.sleep(retry_after)
                continue

            response.raise_for_status()
            data = response.json()
            tickets = data.get(class="hl-string">'tickets', [])

            for ticket in tickets:
                ticket_count += 1
                ticket_id = ticket[class="hl-string">'id']
                print(fclass="hl-string">'Processing ticket {ticket_id} ({ticket_count} total)...')

                class=class="hl-string">"hl-comment"># Fetch ticket metrics for SLA and resolution time
                metrics_response = session.get(fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/metrics.json')
                ticket_metrics = metrics_response.json().get(class="hl-string">'ticket_metric', {}) if metrics_response.ok else {}

                resolution_time_seconds = ticket_metrics.get(class="hl-string">'full_resolution_time_in_minutes', {}).get(class="hl-string">'business')
                if resolution_time_seconds:
                    resolution_time_seconds *= 60

                class=class="hl-string">"hl-comment"># Fetch ticket audits for events
                audits_url = fclass="hl-string">'{BASE_URL}/tickets/{ticket_id}/audits.json'
                audits_response = session.get(audits_url)
                audits = audits_response.json().get(class="hl-string">'audits', []) if audits_response.ok else []

                first_agent_reply_sent = False

                for audit in audits:
                    audit_created_at = audit[class="hl-string">'created_at']
                    base_event = {
                        class="hl-string">'ServiceRequest': ticket_id,
                        class="hl-string">'StartTime': audit_created_at,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'AssignedAgent': get_user_name(ticket.get(class="hl-string">'assignee_id'), users_cache, session),
                        class="hl-string">'ServiceRequestType': ticket.get(class="hl-string">'type'),
                        class="hl-string">'Priority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'CommunicationChannel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaTargetResolutionTime': None, class=class="hl-string">"hl-comment"># Requires parsing SLA policies, complex
                        class="hl-string">'IsSlaBreached': ticket_metrics.get(class="hl-string">'sla_breach_at') is not None,
                        class="hl-string">'ServiceRequestResolutionTime': format_duration(resolution_time_seconds)
                    }

                    for event in audit.get(class="hl-string">'events', []):
                        event_type = event.get(class="hl-string">'type')
                        class=class="hl-string">"hl-comment"># Service Request Created
                        if event_type == class="hl-string">'Create' and event.get(class="hl-string">'field_name') == class="hl-string">'id':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Created'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Initial Acknowledgment Sent (Proxy by Notification event)
                        if event_type == class="hl-string">'Notification':
                            new_event = base_event.copy()
                            new_event[class="hl-string">'ActivityName'] = class="hl-string">'Initial Acknowledgment Sent'
                            event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># Request Categorized And Prioritized, Assigned, Status Changes
                        if event_type == class="hl-string">'Change':
                            field = event.get(class="hl-string">'field_name')
                            if field in [class="hl-string">'type', class="hl-string">'priority', class="hl-string">'custom_field_[your_category_field_id]']:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Categorized And Prioritized'
                                event_log.append(new_event)
                            
                            if field == class="hl-string">'assignee_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Request Assigned To Agent'
                                new_event[class="hl-string">'AssignedAgent'] = get_user_name(event.get(class="hl-string">'value'), users_cache, session)
                                event_log.append(new_event)

                            if field == class="hl-string">'group_id':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Internal Escalation Triggered'
                                event_log.append(new_event)

                            if field == class="hl-string">'status':
                                new_status = event.get(class="hl-string">'value')
                                if new_status == class="hl-string">'pending':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Information Requested From Customer'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'solved':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Resolved'
                                    event_log.append(new_event)
                                    class=class="hl-string">"hl-comment"># Satisfaction Survey Sent (Proxy: occurs after solve)
                                    solve_time = datetime.datetime.fromisoformat(audit_created_at.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                                    survey_time = solve_time + datetime.timedelta(hours=1)
                                    survey_event = new_event.copy()
                                    survey_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Survey Sent'
                                    survey_event[class="hl-string">'StartTime'] = survey_time.isoformat().replace(class="hl-string">'+00:00', class="hl-string">'Z')
                                    event_log.append(survey_event)
                                elif new_status == class="hl-string">'closed':
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'Service Request Closed'
                                    event_log.append(new_event)
                                elif new_status == class="hl-string">'open' and event.get(class="hl-string">'previous_value') in [class="hl-string">'solved', class="hl-string">'pending']:
                                    activity = class="hl-string">'Service Request Reopened' if event.get(class="hl-string">'previous_value') == class="hl-string">'solved' else class="hl-string">'Customer Responded'
                                    new_event = base_event.copy()
                                    new_event[class="hl-string">'ActivityName'] = activity
                                    event_log.append(new_event)
                            
                            if field == class="hl-string">'satisfaction_score':
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'Satisfaction Rating Received'
                                event_log.append(new_event)

                        class=class="hl-string">"hl-comment"># First Agent Public Reply Sent & Customer Responded
                        if event_type == class="hl-string">'Comment':
                            author_id = event.get(class="hl-string">'author_id')
                            author_details_response = session.get(fclass="hl-string">'{BASE_URL}/users/{author_id}.json')
                            author_role = author_details_response.json().get(class="hl-string">'user',{}).get(class="hl-string">'role', class="hl-string">'end-user') if author_details_response.ok else class="hl-string">'end-user'

                            if author_role in [class="hl-string">'agent', class="hl-string">'admin'] and event.get(class="hl-string">'public') and not first_agent_reply_sent:
                                new_event = base_event.copy()
                                new_event[class="hl-string">'ActivityName'] = class="hl-string">'First Agent Public Reply Sent'
                                event_log.append(new_event)
                                first_agent_reply_sent = True

                class=class="hl-string">"hl-comment"># SLA Breach Occurred
                if ticket_metrics.get(class="hl-string">'sla_breach_at'):
                    sla_breach_time = ticket_metrics.get(class="hl-string">'sla_breach_at')
                    new_event = base_event.copy()
                    new_event[class="hl-string">'ActivityName'] = class="hl-string">'SLA Breach Occurred'
                    new_event[class="hl-string">'StartTime'] = sla_breach_time
                    event_log.append(new_event)

            url = data.get(class="hl-string">'after_url')
            if not data.get(class="hl-string">'end_of_stream', False):
                time.sleep(1) class=class="hl-string">"hl-comment"># Be a good API citizen
            else:
                url = None

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">'An error occurred: {e}')
            break

    class=class="hl-string">"hl-comment"># Write to CSV
    print(fclass="hl-string">'Writing {len(event_log)} events to {CSV_FILENAME}...')
    with open(CSV_FILENAME, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
        writer = csv.DictWriter(csvfile, fieldnames=CSV_HEADERS)
        writer.writeheader()
        class=class="hl-string">"hl-comment"># Sort events by ticket and then by time for chronological order
        sorted_log = sorted(event_log, key=lambda x: (x[class="hl-string">'ServiceRequest'], x[class="hl-string">'StartTime']))
        for row in sorted_log:
            writer.writerow(row)
    print(class="hl-string">'Extraction complete.')

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

Lépések

Ellenőrizze, hogy a Zendesk Support-fiókja hozzáférést biztosít-e az Incremental Exports API-hoz, és hogy az integrációs felhasználó jogosult-e a jegyek, jegyesemények, felhasználók, csoportok, megjegyzések, elégedettségi értékelések és SLA-adatok olvasására, amennyiben ezek a funkciók engedélyezve vannak. A szervezet által jóváhagyott beállítások alapján ellenőrizze a fiók aldomainjét és a hitelesítési módot.
Válassza ki az elemzéshez szükséges időszak kezdőpontját. A jegyek inkrementális exportja Unix időbélyeget használ, és az ettől az időponttól kezdve létrehozott vagy módosított rekordokat adja vissza. A teljes előzményállomány első betöltéséhez használja a [Configure based on your system] értéket kezdő időpontként, majd a következő inkrementális futásokhoz mentse el a visszaadott záró időpontot. Rendszeres elemzéshez általában 3–6 hónap elegendő, ha ez lefedi a működési előzményeket.
Futtassa a Python-adatkinyerő szkriptet a Zendesk-aldomain, a hitelesítési adatok, a kezdő időbélyeg és az esetleges vállalatspecifikus szűrők megadásával. A szkript lekéri az inkrementális jegyadatokat, végiglép az oldalakon, majd az átalakítás előtt elmenti a nyers jegyrekordokat és az elérhető eseményadatokat.
Ha az inkrementális jegyválasz nem tartalmaz elegendő információt a mezőváltozásokról, hozzárendelésekről, megjegyzésekről vagy állapotokról, kérje le az egyes jegyek ellenőrzési vagy eseménytörténetét is. Csak a Zendesk-fiókjában engedélyezett és jóváhagyott API-erőforrásokat használja. Őrizze meg a forrásjegy azonosítóját, az ellenőrzés azonosítóját, a megjegyzés azonosítóját, az esemény időbélyegét, a végrehajtót, a mező nevét, az előző értéket és az új értéket, ha ezek rendelkezésre állnak.
Egységesítse az időbélyegeket UTC szerint, és alakítsa át a Unix időbélyegeket vagy az ISO 8601 értékeket egységes dátum-idő formátumra. Rendezze a forrásrekordokat a ServiceRequest, az esemény időbélyege és a forrásesemény-azonosító szerint. A rekordokat a rendelkezésre álló legpontosabb, stabil forrásazonosítóval, például ellenőrzés- vagy megjegyzésazonosítóval szűrje ki az ismétlődések közül.
Hozzon létre külön eseménynapló-sort mind a 14 szükséges tevékenységhez. Ne várja el a ProcessMindtől, hogy az állapotváltozásokból vagy mezőértékekből következtessen a tevékenységekre. Rögzítse a Service Request Created eseményt a jegy létrehozásakor; az Initial Acknowledgment Sent eseményt ellenőrzött, automatikus első válasznál; a Request Categorized And Prioritized eseményt kategória-, típus- vagy prioritásváltozáskor; a Request Assigned To Agent eseményt ügyintéző-hozzárendeléskor; a First Agent Public Reply Sent eseményt az első, feltételeknek megfelelő nyilvános ügyintézői megjegyzésnél; az Information Requested From Customer eseményt információkéréshez kapcsolódó függő állapotba lépéskor; a Customer Responded eseményt megfelelő ügyfélválasznál; az Internal Escalation Triggered eseményt csoportváltáskor; az SLA Breach Occurred eseményt ellenőrzött SLA-sértési időbélyeg vagy kifejezetten kiszámított SLA-sértés esetén; a Service Request Resolved eseményt megoldott állapotba lépéskor; a Service Request Reopened eseményt ügyfélválasz miatt megoldott állapotból nyitott állapotba váltáskor; a Satisfaction Survey Sent eseményt ellenőrzött kérdőívküldéskor; a Satisfaction Rating Received eseményt értékelés beküldésekor; a Service Request Closed eseményt lezárt állapotba lépéskor vagy ellenőrzött végleges lezáráskor.
Töltse ki a kötelező oszlopokat: ServiceRequest, ActivityName, StartTime, SourceSystem és LastDataUpdate. Ha a forrás megbízható értékeket biztosít, töltse ki az ajánlott oszlopokat is: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime és IsSlaBreached. A nem elérhető, nem kötelező attribútumokhoz használjon null értéket, ne találjon ki adatot.
Alkalmazza a jóváhagyott vállalatspecifikus szűrőket a kinyerés után, de exportálás előtt. A belső előkészítő példányban őrizze meg a nyers forrásazonosítókat és időbélyegeket, hogy az események besorolása ellenőrizhető és újrafuttatható legyen.
Ellenőrizze a sorok számát, a tevékenységek lefedettségét, az időbélyegek sorrendjét, az ismétlődések kezelését és az attribútumok kitöltöttségét. Minden létrehozott sornak tartalmaznia kell a ServiceRequest, ActivityName, StartTime, SourceSystem és LastDataUpdate értékét.
Exportálja az átalakított eseménynaplót UTF-8 kódolású CSV-fájlként vagy más, ProcessMind által támogatott táblázatos formátumban. Az oszlopnevek pontosan egyezzenek a szükséges attribútumnevekkel, minden tevékenység-előfordulás külön sorban szerepeljen, majd töltse fel a fájlt a beállított ProcessMind-importfolyamaton keresztül.

Konfiguráció

Adatkinyerési módszer: Nagy mennyiségű jegy kinyeréséhez használja a Zendesk Incremental Exports API-t. A szkript egy elmentett Unix kezdő időbélyegtől kérje le az adatokat, járja végig az oldalakat, tartsa be a lekérési korlátozásokat, és mentse el a visszaadott záró időbélyeget a következő futáshoz.
Hitelesítés: A szervezet biztonsági szabályainak megfelelően állítsa be a jóváhagyott Zendesk-hitelesítési módot, a fiók aldomainjét, a hitelesítési adatokat és az API-jogosultságokat. Ne tárolja a hitelesítési adatokat közvetlenül a forráskódban.
Időszak: Rendszeres folyamatelemzéshez használjon 3–6 hónapnyi adatot. Első betöltéskor olyan kezdő időpontot válasszon, amely megelőzi a vizsgált folyamat időszakát, mert a korábban létrehozott jegyekhez tartozó tevékenységek az elemzési időszakban is történhetnek. Inkrementális betöltéskor használja az előző sikeres kinyerés időpontját, és adjon hozzá egy rövid átfedő időszakot a késve érkező módosítások miatt. Ezután szűrje ki az ismétlődéseket a forrásazonosítók alapján.
Szűrők: Csak a Zendesk-fiókjában elérhető erőforrások által támogatott szűrőket használja, például jóváhagyott szervezetre, csoportra, márkára, jegytípusra, állapotra vagy egyéni mezőre vonatkozókat. A vállalatspecifikus szűrőket a saját rendszerének megfelelően kell beállítani. Ne feltételezze, hogy a Zendeskben létezik Company Code vagy Document Type mező.
Kötelező kimeneti oszlopok: ServiceRequest, ActivityName, StartTime, SourceSystem és LastDataUpdate.
Ajánlott kimeneti oszlopok: AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime és IsSlaBreached.
Eseményadatok: Az inkrementális jegyrekordok önmagukban nem feltétlenül tartalmazzák az összes korábbi állapotváltozást. Szükség esetén kérje le a jogosultsággal elérhető jegyellenőrzéseket, megjegyzéseket, elégedettségi adatokat és SLA-eseményeket is. Minden szükséges tevékenységet külön sorban rögzítsen.
SLA-beállítások: Ha elérhetők, használja a fiók tényleges SLA-szabályzatát és a visszaadott SLA-sértési időbélyegeket. Ha a rendszer számítja ki a sértést, dokumentálja az alkalmazott szabályzatot, munkaidőt, szüneteket és időzónát. Ha munkaidőre vonatkozó szabályok érvényesek, ne kizárólag a naptári idő alapján számítsa ki a sértést.
Teljesítmény: Fokozatosan dolgozza fel az oldalakat, streamelje vagy kötegelje a rekordokat, gyorsítótárazza a jegyadatokat, korlátozza a párhuzamos kérések számát, tartsa be a Zendesk lekérési korlátozásait, és minden sikeresen feldolgozott oldal után mentse a folyamat állapotát. Ne kérje le ismételten a teljes előzményt.
Adatmegőrzés: Az egyeztetés és az újrafuttatás érdekében őrizze meg a nyers API-válaszokat, a kinyerési időpontokat, a kérések metaadatait és az átalakítási naplókat.
Előfeltételek: Zendesk API-hozzáférés; jogosultság a szükséges jegy- és eseményadatok olvasásához; a jegyellenőrzés és a megjegyzések engedélyezése, ha szükséges; hozzáférés az elégedettségi adatokhoz, ha a CSAT-tevékenységeket is vizsgálni kell; valamint hozzáférés az SLA-adatokhoz, ha az SLA-sértési tevékenységekre is szükség van. A funkciók elérhetősége a Zendesk-csomagtól és a fiók beállításaitól függ.

Példa-lekérdezés python

import csv
import json
import os
import sys
import time
from datetime import datetime, timezone
from typing import Any, Dict, Iterable, List, Optional, Tuple

import requests

ZENDESK_SUBDOMAIN = os.environ.get(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Configure based on your system]")
ZENDESK_EMAIL = os.environ.get(class="hl-string">"ZENDESK_EMAIL", class="hl-string">"[Configure based on your system]")
ZENDESK_API_TOKEN = os.environ.get(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Configure based on your system]")
START_TIME = os.environ.get(class="hl-string">"START_TIME", class="hl-string">"[Configure based on your system]")
OUTPUT_FILE = os.environ.get(class="hl-string">"OUTPUT_FILE", class="hl-string">"zendesk_processmind_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"

REQUIRED_COLUMNS = [
    class="hl-string">"ServiceRequest",
    class="hl-string">"ActivityName",
    class="hl-string">"StartTime",
    class="hl-string">"SourceSystem",
    class="hl-string">"LastDataUpdate",
]
RECOMMENDED_COLUMNS = [
    class="hl-string">"AssignedAgent",
    class="hl-string">"ServiceRequestType",
    class="hl-string">"Priority",
    class="hl-string">"CommunicationChannel",
    class="hl-string">"SlaTargetResolutionTime",
    class="hl-string">"IsSlaBreached",
]
ALL_COLUMNS = REQUIRED_COLUMNS + RECOMMENDED_COLUMNS


def fail(message: str) -> None:
    raise RuntimeError(message)


def parse_start_time(value: str) -> int:
    if value.isdigit():
        return int(value)
    try:
        return int(datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00")).timestamp())
    except ValueError as exc:
        raise RuntimeError(class="hl-string">"START_TIME must be a Unix timestamp or ISO 8601 timestamp") from exc


def iso_timestamp(value: Any) -> Optional[str]:
    if value is None or value == class="hl-string">"":
        return None
    if isinstance(value, (int, float)):
        return datetime.fromtimestamp(value, tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    text = str(value)
    if text.isdigit():
        return datetime.fromtimestamp(int(text), tz=timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")
    return text


def now_utc() -> str:
    return datetime.now(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z")


def api_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    url = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    while True:
        response = session.get(url, params=params, timeout=60)
        if response.status_code == 429:
            retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
            time.sleep(max(retry_after, 1))
            continue
        response.raise_for_status()
        return response.json()


def paged_get(session: requests.Session, path: str, params: Optional[Dict[str, Any]] = None) -> Iterable[Dict[str, Any]]:
    next_url: Optional[str] = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com{path}"
    next_params = params
    while next_url:
        while True:
            response = session.get(next_url, params=next_params, timeout=60)
            if response.status_code == 429:
                retry_after = int(response.headers.get(class="hl-string">"Retry-After", class="hl-string">"5"))
                time.sleep(max(retry_after, 1))
                continue
            response.raise_for_status()
            payload = response.json()
            break
        for item in payload.get(class="hl-string">"tickets", payload.get(class="hl-string">"audits", payload.get(class="hl-string">"comments", payload.get(class="hl-string">"results", [])))):
            yield item
        next_url = payload.get(class="hl-string">"next_page")
        next_params = None


def get_user_name(session: requests.Session, user_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not user_id:
        return None
    key = str(user_id)
    if key in cache:
        return cache[key]
    try:
        user = api_get(session, fclass="hl-string">"/api/v2/users/{key}.json").get(class="hl-string">"user", {})
        name = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def get_group_name(session: requests.Session, group_id: Any, cache: Dict[str, str]) -> Optional[str]:
    if not group_id:
        return None
    key = str(group_id)
    if key in cache:
        return cache[key]
    try:
        group = api_get(session, fclass="hl-string">"/api/v2/groups/{key}.json").get(class="hl-string">"group", {})
        name = group.get(class="hl-string">"name") or key
        cache[key] = str(name)
        return cache[key]
    except requests.HTTPError:
        cache[key] = key
        return key


def ticket_field(ticket: Dict[str, Any], names: List[str]) -> Any:
    for name in names:
        if ticket.get(name) is not None:
            return ticket.get(name)
    return None


def base_row(ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str]) -> Dict[str, Any]:
    return {
        class="hl-string">"ServiceRequest": str(ticket.get(class="hl-string">"id")),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"StartTime": iso_timestamp(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": last_update,
        class="hl-string">"AssignedAgent": get_user_name(session, ticket.get(class="hl-string">"assignee_id"), user_cache),
        class="hl-string">"ServiceRequestType": ticket.get(class="hl-string">"type"),
        class="hl-string">"Priority": ticket.get(class="hl-string">"priority"),
        class="hl-string">"CommunicationChannel": ticket.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(ticket.get(class="hl-string">"via"), dict) else ticket.get(class="hl-string">"via"),
        class="hl-string">"SlaTargetResolutionTime": ticket.get(class="hl-string">"sla_target_resolution_time"),
        class="hl-string">"IsSlaBreached": ticket.get(class="hl-string">"is_sla_breached"),
    }


def add_event(events: List[Dict[str, Any]], seen: set, ticket: Dict[str, Any], activity: str, event_time: Any, last_update: str, user_cache: Dict[str, str], source_key: str) -> None:
    if event_time is None:
        return
    key = (str(ticket.get(class="hl-string">"id")), activity, source_key, str(event_time))
    if key in seen:
        return
    seen.add(key)
    events.append(base_row(ticket, activity, event_time, last_update, user_cache))


def audit_events(session: requests.Session, ticket_id: Any) -> List[Dict[str, Any]]:
    return list(paged_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/audits.json"))


def audit_events_for_field(audit: Dict[str, Any], field_names: List[str]) -> List[Tuple[str, Any, Any]]:
    output: List[Tuple[str, Any, Any]] = []
    for event in audit.get(class="hl-string">"events", []):
        if event.get(class="hl-string">"type") != class="hl-string">"Change":
            continue
        field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
        if field in field_names:
            output.append((field, event.get(class="hl-string">"previous_value"), event.get(class="hl-string">"value")))
    return output


def is_customer_actor(audit: Dict[str, Any], ticket: Dict[str, Any]) -> bool:
    author_id = audit.get(class="hl-string">"author_id")
    requester_id = ticket.get(class="hl-string">"requester_id")
    return author_id is not None and requester_id is not None and str(author_id) == str(requester_id)


def is_public_comment(event: Dict[str, Any]) -> bool:
    return event.get(class="hl-string">"type") in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and event.get(class="hl-string">"public") is not False


def is_automated_acknowledgment(event: Dict[str, Any]) -> bool:
    body = str(event.get(class="hl-string">"body") or event.get(class="hl-string">"html_body") or class="hl-string">"").lower()
    marker = str(event.get(class="hl-string">"via", {}).get(class="hl-string">"channel") if isinstance(event.get(class="hl-string">"via"), dict) else event.get(class="hl-string">"via") or class="hl-string">"").lower()
    return class="hl-string">"acknowledg" in body or class="hl-string">"received your request" in body or marker in {class="hl-string">"trigger", class="hl-string">"automation", class="hl-string">"system"}


def extract_ticket_events(session: requests.Session, ticket: Dict[str, Any], last_update: str, user_cache: Dict[str, str], group_cache: Dict[str, str], seen: set) -> List[Dict[str, Any]]:
    events: List[Dict[str, Any]] = []
    ticket_id = ticket.get(class="hl-string">"id")
    audits = audit_events(session, ticket_id)
    audits.sort(key=lambda item: (str(item.get(class="hl-string">"created_at") or class="hl-string">""), str(item.get(class="hl-string">"id") or class="hl-string">"")))
    add_event(events, seen, ticket, class="hl-string">"Service Request Created", ticket.get(class="hl-string">"created_at"), last_update, user_cache, class="hl-string">"ticket_created")
    first_public_agent_reply = False
    first_ack = False
    for audit in audits:
        audit_time = audit.get(class="hl-string">"created_at")
        audit_id = str(audit.get(class="hl-string">"id") or audit_time)
        for event in audit.get(class="hl-string">"events", []):
            event_type = event.get(class="hl-string">"type")
            if event_type in {class="hl-string">"Comment", class="hl-string">"VoiceComment"} and is_public_comment(event):
                if not first_ack and is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"Initial Acknowledgment Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":ack")
                    first_ack = True
                if not is_customer_actor(audit, ticket) and not first_public_agent_reply and not is_automated_acknowledgment(event):
                    add_event(events, seen, ticket, class="hl-string">"First Agent Public Reply Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":first_agent_reply")
                    first_public_agent_reply = True
                if is_customer_actor(audit, ticket):
                    add_event(events, seen, ticket, class="hl-string">"Customer Responded", audit_time, last_update, user_cache, audit_id + class="hl-string">":customer_reply")
            if event_type == class="hl-string">"Change":
                field = str(event.get(class="hl-string">"field_name") or event.get(class="hl-string">"field") or class="hl-string">"")
                previous = event.get(class="hl-string">"previous_value")
                value = event.get(class="hl-string">"value")
                if field in {class="hl-string">"type", class="hl-string">"priority", class="hl-string">"custom_fields"}:
                    add_event(events, seen, ticket, class="hl-string">"Request Categorized And Prioritized", audit_time, last_update, user_cache, audit_id + class="hl-string">":category_priority:" + field)
                if field in {class="hl-string">"assignee_id", class="hl-string">"assignee"} and value not in (None, class="hl-string">"", 0, class="hl-string">"0"):
                    add_event(events, seen, ticket, class="hl-string">"Request Assigned To Agent", audit_time, last_update, user_cache, audit_id + class="hl-string">":assignee")
                if field in {class="hl-string">"group_id", class="hl-string">"group"} and previous not in (None, class="hl-string">"", 0, class="hl-string">"0") and value not in (None, class="hl-string">"", 0, class="hl-string">"0") and str(previous) != str(value):
                    get_group_name(session, value, group_cache)
                    add_event(events, seen, ticket, class="hl-string">"Internal Escalation Triggered", audit_time, last_update, user_cache, audit_id + class="hl-string">":group")
                if field == class="hl-string">"status":
                    old_status = str(previous or class="hl-string">"").lower()
                    new_status = str(value or class="hl-string">"").lower()
                    if new_status == class="hl-string">"pending":
                        add_event(events, seen, ticket, class="hl-string">"Information Requested From Customer", audit_time, last_update, user_cache, audit_id + class="hl-string">":pending")
                    if new_status == class="hl-string">"solved":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Resolved", audit_time, last_update, user_cache, audit_id + class="hl-string">":solved")
                    if old_status == class="hl-string">"solved" and new_status == class="hl-string">"open":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Reopened", audit_time, last_update, user_cache, audit_id + class="hl-string">":reopened")
                    if new_status == class="hl-string">"closed":
                        add_event(events, seen, ticket, class="hl-string">"Service Request Closed", audit_time, last_update, user_cache, audit_id + class="hl-string">":closed")
                if field in {class="hl-string">"satisfaction_survey_sent", class="hl-string">"csat_survey_sent"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes", class="hl-string">"sent"}:
                    add_event(events, seen, ticket, class="hl-string">"Satisfaction Survey Sent", audit_time, last_update, user_cache, audit_id + class="hl-string">":survey_sent")
                if field in {class="hl-string">"sla_breached", class="hl-string">"is_sla_breached"} and str(value).lower() in {class="hl-string">"true", class="hl-string">"1", class="hl-string">"yes"}:
                    row = base_row(ticket, class="hl-string">"SLA Breach Occurred", audit_time, last_update, user_cache)
                    row[class="hl-string">"IsSlaBreached"] = True
                    key = (str(ticket_id), class="hl-string">"SLA Breach Occurred", audit_id, str(audit_time))
                    if key not in seen:
                        seen.add(key)
                        events.append(row)
    try:
        satisfaction = api_get(session, fclass="hl-string">"/api/v2/tickets/{ticket_id}/satisfaction_rating.json").get(class="hl-string">"satisfaction_rating")
    except requests.HTTPError:
        satisfaction = None
    if satisfaction:
        add_event(events, seen, ticket, class="hl-string">"Satisfaction Rating Received", satisfaction.get(class="hl-string">"created_at") or satisfaction.get(class="hl-string">"updated_at"), last_update, user_cache, str(satisfaction.get(class="hl-string">"id") or class="hl-string">"rating"))
    return events


def validate_rows(rows: List[Dict[str, Any]]) -> None:
    activities = {
        class="hl-string">"Service Request Created",
        class="hl-string">"Initial Acknowledgment Sent",
        class="hl-string">"Request Categorized And Prioritized",
        class="hl-string">"Request Assigned To Agent",
        class="hl-string">"First Agent Public Reply Sent",
        class="hl-string">"Information Requested From Customer",
        class="hl-string">"Customer Responded",
        class="hl-string">"Internal Escalation Triggered",
        class="hl-string">"SLA Breach Occurred",
        class="hl-string">"Service Request Resolved",
        class="hl-string">"Service Request Reopened",
        class="hl-string">"Satisfaction Survey Sent",
        class="hl-string">"Satisfaction Rating Received",
        class="hl-string">"Service Request Closed",
    }
    missing_columns = [column for column in ALL_COLUMNS if column not in rows[0]] if rows else ALL_COLUMNS
    if missing_columns:
        fail(class="hl-string">"Missing output columns: " + class="hl-string">", ".join(missing_columns))
    invalid = [row for row in rows if not row.get(class="hl-string">"ServiceRequest") or not row.get(class="hl-string">"ActivityName") or not row.get(class="hl-string">"StartTime") or not row.get(class="hl-string">"SourceSystem") or not row.get(class="hl-string">"LastDataUpdate")]
    if invalid:
        fail(fclass="hl-string">"{len(invalid)} rows are missing required values")
    unexpected = sorted({row[class="hl-string">"ActivityName"] for row in rows} - activities)
    if unexpected:
        fail(class="hl-string">"Unexpected activity names: " + class="hl-string">", ".join(unexpected))


def main() -> None:
    global session
    if ZENDESK_SUBDOMAIN.startswith(class="hl-string">"[") or ZENDESK_EMAIL.startswith(class="hl-string">"[") or ZENDESK_API_TOKEN.startswith(class="hl-string">"[") or START_TIME.startswith(class="hl-string">"["):
        fail(class="hl-string">"Configure ZENDESK_SUBDOMAIN, ZENDESK_EMAIL, ZENDESK_API_TOKEN, and START_TIME")
    start_time = parse_start_time(START_TIME)
    session = requests.Session()
    session.auth = (fclass="hl-string">"{ZENDESK_EMAIL}/token", ZENDESK_API_TOKEN)
    session.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})
    last_update = now_utc()
    user_cache: Dict[str, str] = {}
    group_cache: Dict[str, str] = {}
    seen = set()
    rows: List[Dict[str, Any]] = []
    tickets = paged_get(session, class="hl-string">"/api/v2/incremental/tickets/cursor.json", {class="hl-string">"start_time": start_time})
    for ticket in tickets:
        rows.extend(extract_ticket_events(session, ticket, last_update, user_cache, group_cache, seen))
    rows.sort(key=lambda row: (row[class="hl-string">"ServiceRequest"], row[class="hl-string">"StartTime"], row[class="hl-string">"ActivityName"]))
    validate_rows(rows)
    with open(OUTPUT_FILE, class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as output:
        writer = csv.DictWriter(output, fieldnames=ALL_COLUMNS, extrasaction=class="hl-string">"ignore")
        writer.writeheader()
        writer.writerows(rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(rows), class="hl-string">"last_data_update": last_update}))


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

Lépések

Válasszon olyan kereskedelmi ETL- vagy ELT-platformot, amely támogatott Zendesk Support-összekötőt kínál. Ellenőrizze, hogy az összekötő át tudja-e másolni a Zendesk-fiókjában elérhető jegyeket, jegyeseményeket vagy ellenőrzéseket, megjegyzéseket, felhasználókat, csoportokat, elégedettségi értékeléseket, SLA-adatokat, valamint az aktiválási szabályok vagy automatizálások eredményeit.
Hozzon létre Zendesk API-integrációt a szervezet és a kiválasztott összekötő által támogatott hitelesítési móddal. Csak a jegyek, ellenőrzések, megjegyzések, felhasználók, csoportok, elégedettségi adatok és SLA-adatok olvasásához szükséges jogosultságokat adja meg. A kapcsolati karakterláncot és a hitelesítési adatokat az eszköz biztonságos hitelesítőadat-tárolójában helyezze el.
Állítsa be az összekötőt, hogy a szükséges Zendesk-objektumokat a céladattárba másolja. Ne feltételezzen rögzített táblázat- vagy oszlopneveket, hanem az összekötő által létrehozott forrásobjektumokat használja. A projekt dokumentációjában rögzítse a tényleges objektum- és mezőleképezéseket [Your table name] és [Your column name] formában, ha az összekötő fiókspecifikus neveket használ.
Állítsa be az inkrementális adatkinyerést a forrásrendszer által támogatott módosítási időbélyeg, kurzor vagy változáskövetési mechanizmus használatával. Töltse be a kiválasztott elemzési időszak előzményeit, általában három–hat hónapot, és őrizze meg a forrásesemény vagy -ellenőrzés azonosítóját az ismételt módosítások kiszűréséhez.
Hozzon létre normalizált előkészítő modellt, amely egyesíti a jegyrekordokat a jegyelőzményekkel, az ellenőrzési vagy eseményrekordokkal, a megjegyzésekkel, a felhasználókkal, a csoportokkal, az elégedettségi értékelésekkel, az SLA-rekordokkal, valamint az összekötőhöz tartozó aktiválási vagy automatizálási rekordokkal. Ha rendelkezésre állnak, őrizze meg az eredeti forrás-időbélyeget, a forrásrekord azonosítóját, a jegyazonosítót, a végrehajtó azonosítóját, az eseménytípust, a mező nevét, az előző értéket és az új értéket.
Alakítsa át az adatokat úgy, hogy minden egyértelműen megfigyelt tevékenységhez külön sor jöjjön létre. A jegy létrehozását képezze le Service Request Created eseményre; a feltételeknek megfelelő automatikus első választ Initial Acknowledgment Sent eseményre; a típus-, kategória- vagy prioritásváltozásokat Request Categorized And Prioritized eseményre; az ügyintéző-hozzárendelés változását Request Assigned To Agent eseményre; az első, feltételeknek megfelelő nyilvános ügyintézői választ First Agent Public Reply Sent eseményre; az információkéréshez kapcsolódó függő állapotba lépést Information Requested From Customer eseményre; az ügyfélválaszt Customer Responded eseményre; a csoportváltást Internal Escalation Triggered eseményre; a megfigyelt SLA-sértési rekordot vagy eseményt SLA Breach Occurred eseményre; a megoldott állapotba lépést Service Request Resolved eseményre; az ügyfélválasz miatt megoldott állapotból nyitott állapotba váltást Service Request Reopened eseményre; a megfigyelt kérdőívküldést Satisfaction Survey Sent eseményre; a beküldött értékelést Satisfaction Rating Received eseményre; a végleges lezárást pedig Service Request Closed eseményre.
Ne hozzon létre következtetésen alapuló sorokat kizárólag a jegy aktuális állapota vagy az eltelt idő alapján. Ha a forrás nem rögzíti egyértelműen a kérdőív kiküldését, az SLA-sértést, az automatikus visszaigazolást vagy a végleges lezárást, hagyja ki az adott tevékenységet, vagy használjon külön dokumentált, azt kifejezetten rögzítő adatforrást. A ProcessMind a kapott eseménynaplót dolgozza fel, a hiányzó eseményeket nem állítja elő.
Ha rendelkezésre áll, a forrásesemény vagy -ellenőrzés azonosítója alapján szűrje ki az ismétlődéseket. Ha nincs stabil azonosító, használjon dokumentált összetett kulcsot, amely tartalmazza a ServiceRequest, ActivityName, StartTime, a végrehajtó és a forrásrekord azonosítóját. Őrizze meg az olyan tevékenységek minden valós előfordulását, mint a Customer Responded, az Information Requested From Customer, az Internal Escalation Triggered és a Service Request Reopened.
Töltse ki a kötelező kimeneti oszlopokat: ServiceRequest, ActivityName, StartTime, SourceSystem és LastDataUpdate. Ha a forrás biztosítja ezeket, adja hozzá az AssignedAgent, ServiceRequestType, Priority, CommunicationChannel, SlaTargetResolutionTime és IsSlaBreached oszlopokat is. Használjon egységes UTC-időbélyegeket, és őrizze meg a forrás időzónájának átalakítási szabályát.
Exportálja a végleges eseménynaplót ProcessMind-kompatibilis CSV-fájlként, vagy töltse be a beállított ProcessMind-adatbetöltési helyre. Minden tevékenység-előfordulás külön sorban szerepeljen, a ServiceRequest legyen az ügyazonosító, az ActivityName mezőben a pontos tevékenységnevek szerepeljenek, a StartTime érvényes időbélyeg legyen, és minden technikailag elérhető sor tartalmazza a kötelező attribútumokat.

Konfiguráció

Összekötő és forrásadatok köre: Állítsa be a kiválasztott kereskedelmi ETL- vagy ELT-eszközt a Zendesk Supporthoz, majd válassza ki azokat a forrásobjektumokat, amelyek a jegyeket, a jegyellenőrzéseket vagy -eseményeket, a megjegyzéseket, a felhasználókat, a csoportokat, az elégedettségi értékeléseket, az SLA-adatokat, valamint az automatizálások vagy aktiválási szabályok eredményeit tartalmazzák. Az objektumnevek összekötőnként és fiókonként eltérhetnek, ezért a feltételezett táblanevek helyett az összekötő tényleges katalógusát használja.
Hitelesítés és jogosultságok: A szervezet által jóváhagyott Zendesk-hitelesítési módot használja. Adjon olvasási jogosultságot minden kiválasztott forrásobjektumhoz, beleértve a korábbi jegyeseményeket és az ügyfél-elégedettségi adatokat is. Ellenőrizze, hogy az API-hozzáférés, a szükséges Zendesk-csomagfunkciók és az összekötő licence engedélyezve van-e.
Időszak: Kezdje három–hat hónapnyi előzménnyel. Csak az API-kvóták, az adattár kapacitása, az események mennyisége, valamint az előzményadatok, az SLA-adatok és az elégedettségi rekordok elérhetőségének ellenőrzése után bővítse az időszakot.
Inkrementális betöltés: Elsősorban az összekötő beépített kurzorát, változáskövetését vagy a forrás módosítási időbélyegét használja. Ütemezzen egy kezdeti előzménybetöltést, majd rendszeres inkrementális betöltéseket. Hagyjon visszatekintési időszakot a késve érkező megjegyzések, értékelések, SLA-eredmények és jegymódosítások kezelésére.
Tevékenységszűrők: A forrásrekordokat a kiválasztott elemzési időszakra és a megfelelő Zendesk Support-példányra szűrje. Ne csak az aktuális jegyállapot alapján szűrjön, mert a korábbi tevékenységek olyan jegyekhez is tartozhatnak, amelyek állapota azóta megváltozott.
Vállalati vagy fiókszintű szűrők: Ha az összekötő több Zendesk-példányt, márkát, szervezetet vagy üzleti egységet is elér, a jóváhagyott vállalati vagy fiókszűrőt az összekötő tényleges mezőjével állítsa be. Ne feltételezze, hogy létezik Company Code mező.
Eseményleképezés: Tartson fenn egyértelmű leképezési táblát, amely a forrásesemény típusát, a mező nevét, az állapotátmenetet, a végrehajtó típusát és az automatizálási jelzőt a 14 szükséges ActivityName értékhez rendeli. Minden létrehozott sorhoz követeljen meg egyértelmű forrásadatot.
Visszaigazolás azonosítása: Az Initial Acknowledgment Sent eseményt csak akkor rendelje hozzá, ha a forrás automatikus első választ vagy azzal egyenértékű, aktiválási szabály által küldött értesítést azonosít. Forrásadat nélkül ne sorolja be az ügyintézői választ automatikus visszaigazolásként.
SLA-kezelés: Használjon kifejezett SLA-sértési rekordokat vagy az összekötő által elérhető SLA-eredményeket. A célidőt a SlaTargetResolutionTime, a sértés eredményét pedig az IsSlaBreached mezőben tárolja. Ne számítsa ki a sértést pusztán az eltelt idő alapján, kivéve, ha rendelkezésre áll az SLA-naptár, a szabályzat, a munkaidő és a célérték, és a számítás dokumentált.
Teljesítmény: A kezdeti betöltést dátum alapján korlátozza, csak a szükséges oszlopokat kérje le, használjon inkrementális replikációt, és ahol támogatott, particionálja vagy klaszterezze az adattárat a ServiceRequest és a StartTime mező szerint. A nyers adatok betöltése után hozza létre a normalizált eseménymodellt. Ne vizsgálja át újra és újra az összes jegyelőzményt.
Adatminőség: Őrizze meg a forrásazonosítókat és időbélyegeket, egységesítse az időbélyegeket UTC szerint, szabványosítsa a logikai értékeket, és hagyja meg null értékként azokat az attribútumokat, amelyeket a forrás nem biztosít. Ne pótolja kitalált értékekkel a hiányzó ügyintéző-, kategória-, prioritás-, SLA- vagy csatornaadatokat.
Frissítési időbélyeg: A LastDataUpdate mezőbe a sikeresen befejezett adatkinyerési vagy átalakítási futás időpontját írja, az eseménynapló egészében egységes időzónát és formátumot használva.

Példa-lekérdezés config

WITH source_data AS (
    SELECT
        [Your ticket identifier column] AS service_request,
        [Your source event identifier column] AS source_event_id,
        [Your event type column] AS source_event_type,
        [Your field name column] AS source_field_name,
        [Your previous value column] AS previous_value,
        [Your new value column] AS new_value,
        [Your event timestamp column] AS event_time,
        [Your actor type column] AS actor_type,
        [Your actor identifier column] AS actor_id,
        [Your assigned agent column] AS assigned_agent,
        [Your request type column] AS service_request_type,
        [Your priority column] AS priority,
        [Your communication channel column] AS communication_channel,
        [Your SLA target resolution time column] AS sla_target_resolution_time,
        [Your SLA breached flag column] AS is_sla_breached,
        [Your automated response flag column] AS is_automated_response,
        [Your public comment flag column] AS is_public_comment,
        [Your customer reply flag column] AS is_customer_reply,
        [Your survey sent flag column] AS is_survey_sent,
        [Your satisfaction rating column] AS satisfaction_rating,
        [Your source system value] AS source_system,
        [Your extraction timestamp column] AS last_data_update
    FROM [Your normalized Zendesk event source]
    WHERE [Your event timestamp column] >= [Your start date parameter]
      AND [Your event timestamp column] < [Your end date parameter]
),
activity_events AS (
    SELECT service_request, 'Service Request Created' AS activity_name, event_time AS start_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_created'
    UNION ALL
    SELECT service_request, 'Initial Acknowledgment Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_automated_response = TRUE AND is_public_comment = TRUE
    UNION ALL
    SELECT service_request, 'Request Categorized And Prioritized', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('type', 'category', 'priority')
    UNION ALL
    SELECT service_request, 'Request Assigned To Agent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('assignee', 'assigned_agent')
    UNION ALL
    SELECT service_request, 'First Agent Public Reply Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND actor_type = 'agent' AND is_automated_response = FALSE
    UNION ALL
    SELECT service_request, 'Information Requested From Customer', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'pending'
    UNION ALL
    SELECT service_request, 'Customer Responded', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'comment_added' AND is_public_comment = TRUE AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Internal Escalation Triggered', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_field_changed' AND source_field_name IN ('group', 'assigned_group')
    UNION ALL
    SELECT service_request, 'SLA Breach Occurred', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, TRUE, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('sla_breach', 'sla_breached') OR is_sla_breached = TRUE
    UNION ALL
    SELECT service_request, 'Service Request Resolved', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'solved'
    UNION ALL
    SELECT service_request, 'Service Request Reopened', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND previous_value = 'solved' AND new_value = 'open' AND is_customer_reply = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Survey Sent', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_survey_sent', 'csat_survey_sent') OR is_survey_sent = TRUE
    UNION ALL
    SELECT service_request, 'Satisfaction Rating Received', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type IN ('satisfaction_rating_received', 'csat_rating_received') OR satisfaction_rating IS NOT NULL
    UNION ALL
    SELECT service_request, 'Service Request Closed', event_time, source_event_id, assigned_agent, service_request_type, priority, communication_channel, sla_target_resolution_time, is_sla_breached, source_system, last_data_update
    FROM source_data
    WHERE source_event_type = 'ticket_status_changed' AND new_value = 'closed'
),
deduplicated_events AS (
    SELECT
        service_request,
        activity_name,
        start_time,
        assigned_agent,
        service_request_type,
        priority,
        communication_channel,
        sla_target_resolution_time,
        is_sla_breached,
        source_system,
        last_data_update,
        ROW_NUMBER() OVER (PARTITION BY service_request, activity_name, source_event_id ORDER BY start_time) AS event_rank
    FROM activity_events
)
SELECT
    service_request AS ServiceRequest,
    activity_name AS ActivityName,
    start_time AS StartTime,
    source_system AS SourceSystem,
    last_data_update AS LastDataUpdate,
    assigned_agent AS AssignedAgent,
    service_request_type AS ServiceRequestType,
    priority AS Priority,
    communication_channel AS CommunicationChannel,
    sla_target_resolution_time AS SlaTargetResolutionTime,
    is_sla_breached AS IsSlaBreached
FROM deduplicated_events
WHERE event_rank = 1
ORDER BY service_request, start_time, activity_name;

Kezdhetjük?

Kezdje el még ma fejleszteni az ügyfélszolgálati folyamatot: készítse elő adatait ezzel a sablonnal. Tárja fel a Zendesk Support működésében rejlő lehetőségeket, és növelje a hatékonyságot.

Vissza a folyamatfejlesztési útmutatóhoz

Sablon letöltése

Szüntesse meg az ügyfélszolgálati szűk keresztmetszeteket, növelje a CSAT-értéket

Csökkentse az ismételt megkereséseket. Érjen el 80%-os FCR-t, és növelje az ügyfél-elégedettséget.

Kezdje el a próbaverziót

Nincs szükség bankkártyára

Ügyfélszolgálati adatsablon

Ügyfélszolgálati adatsablon

Ügyfélszolgálati attribútumok

Ügyfélszolgálati tevékenységek

Adatkinyerési útmutatók

Jelentések és adatok exportálása a Zendesk Explore felületéről

Lépések

Konfiguráció

Példa-lekérdezés config

Python-szkript a Zendesk Support REST API használatával

Lépések

Konfiguráció

Példa-lekérdezés python

Zendesk Incremental Exports API tömeges adatkinyeréshez

Lépések

Konfiguráció

Példa-lekérdezés python

Külső ETL-eszköz Zendesk-összekötője

Lépések

Konfiguráció

Példa-lekérdezés config

Kezdhetjük?

Szüntesse meg az ügyfélszolgálati szűk keresztmetszeteket, növelje a CSAT-értéket