> การปรับปรุงกระบวนการอย่างต่อเนื่อง > การจัดการเหตุการณ์ > Zendesk Support > เทมเพลตข้อมูล

เทมเพลตข้อมูลการจัดการเหตุขัดข้องของคุณ

Zendesk Support

แอตทริบิวต์การจัดการเหตุขัดข้อง(23) กิจกรรมในการจัดการเหตุขัดข้อง(13) คู่มือการดึงข้อมูล(4)

เทมเพลตข้อมูลการจัดการเหตุขัดข้องของคุณ

เทมเพลตนี้สรุปข้อมูลสำคัญที่ต้องใช้วิเคราะห์กระบวนการจัดการเหตุขัดข้อง โดยระบุแอตทริบิวต์ที่ควรเก็บ กิจกรรมหลักที่ควรติดตาม และแนวทางดึงข้อมูลจาก Zendesk Support ใช้เทมเพลตนี้เตรียมชุดข้อมูลให้พร้อมสำหรับเริ่มโครงการ process mining.

แอตทริบิวต์ที่แนะนำให้เก็บ
กิจกรรมสำคัญที่ควรติดตามเพื่อทำแผนที่กระบวนการ
แนวทางดึงข้อมูลไปใช้จริง

เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

ดาวน์โหลดเทมเพลต

แอตทริบิวต์การจัดการเหตุขัดข้อง

ฟิลด์ข้อมูลเหล่านี้เป็นรายการแนะนำสำหรับบันทึกเหตุการณ์ เพื่อให้วิเคราะห์กระบวนการจัดการเหตุขัดข้องได้อย่างละเอียด.

5 จำเป็น 7 แนะนำ 11 ไม่บังคับ

	ชื่อ	คำอธิบาย
	Incident ID TicketId	รหัสเฉพาะที่ระบบสร้างขึ้นสำหรับทิกเก็ตเหตุการณ์แต่ละรายการ.
คำอธิบาย Incident ID เป็นคีย์หลักที่ใช้ระบุเคสเหตุการณ์แต่ละรายการใน Zendesk Support โดยไม่ซ้ำกัน ใช้เป็น CaseId สำหรับ process mining เพื่อเชื่อมโยงกิจกรรม การเปลี่ยนสถานะ และการสื่อสารที่เกี่ยวข้องทั้งหมด ตั้งแต่สร้างเหตุการณ์จนถึงปิดเคส ในการวิเคราะห์ รหัสนี้จำเป็นต่อการสร้างลำดับการจัดการเหตุการณ์แต่ละรายการตั้งแต่ต้นจนจบ ช่วยรวบรวมข้อมูลเหตุการณ์เพื่อวัดตัวชี้วัด เช่น เวลาแก้ไขทั้งหมด จำนวนครั้งที่ส่งต่องาน และการทำตามข้อตกลงระดับการให้บริการของแต่ละเคส เมื่อนำเหตุการณ์มาแยกกลุ่มตามรหัสนี้ นักวิเคราะห์จะเห็นเส้นทางกระบวนการที่เกิดขึ้นบ่อยและตรวจพบจุดที่ต่างจากขั้นตอนมาตรฐานได้. เหตุผลที่สำคัญ นี่คือรหัสสำคัญที่เชื่อมโยงเหตุการณ์ทั้งหมดเข้ากับเหตุการณ์เดียว ทำให้ติดตามวงจรทั้งหมดและวิเคราะห์ผลการดำเนินงานของกระบวนการได้อย่างแม่นยำ. แหล่งข้อมูล Zendesk Tickets API (/api/v2/tickets/{id}), ฟิลด์ id. ตัวอย่าง 19428230113521941055
	เวลาที่เกิดเหตุการณ์ EventTimestamp	วันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ.
คำอธิบาย เวลานี้บันทึกช่วงเวลาที่เหตุการณ์เกิดขึ้นในวงจรการจัดการเหตุการณ์อย่างแม่นยำ เช่น เวลาที่เพิ่มความคิดเห็นหรือเปลี่ยนสถานะ และใช้เรียงลำดับกิจกรรมทั้งหมดภายในเคสตามเวลา แอตทริบิวต์นี้เป็นพื้นฐานสำคัญของการวิเคราะห์ process mining ตามเวลา ใช้คำนวณระยะเวลาระหว่างกิจกรรม ระบุเวลารอ วัดระยะเวลารวมของเคส และวิเคราะห์ผลการดำเนินงานของกระบวนการในแต่ละช่วงเวลา การบันทึกเวลาที่แม่นยำจำเป็นต่อการสร้างแผนผังกระบวนการแบบเคลื่อนไหวที่แสดงการดำเนินงานของเคสตามเวลา และสร้างแดชบอร์ดติดตาม KPI เช่น เวลาแก้ไขเฉลี่ย. เหตุผลที่สำคัญ เวลาที่เกิดเหตุการณ์ช่วยระบุลำดับของกิจกรรม ทำให้คำนวณระยะเวลา ค้นหาคอขวด และวิเคราะห์ผลการดำเนินงานของกระบวนการในแต่ละช่วงเวลาได้. แหล่งข้อมูล Zendesk Ticket Audits API (/api/v2/tickets/{ticket_id}/audits), ฟิลด์ created_at ของแต่ละเหตุการณ์ audit. ตัวอย่าง 2023-04-15T10:00:00Z2023-04-15T10:05:12Z2023-04-16T14:30:00Z
	กิจกรรม ActivityName	ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้น ณ จุดหนึ่งในวงจรการจัดการเหตุการณ์.
คำอธิบาย แอตทริบิวต์นี้อธิบายขั้นตอนหรือการดำเนินการที่เกิดขึ้นในกระบวนการจัดการเหตุการณ์ เช่น 'สร้างเหตุการณ์' 'กำหนดทิกเก็ตให้เจ้าหน้าที่' หรือ 'แก้ไขเหตุการณ์แล้ว' กิจกรรมเหล่านี้ได้มาจากบันทึกเหตุการณ์หรือข้อมูล audit trail ของ Zendesk ซึ่งบันทึกการเปลี่ยนแปลงในระบบไว้ ใน process mining ลำดับกิจกรรมเหล่านี้ประกอบกันเป็นแผนผังกระบวนการ ซึ่งเป็นพื้นฐานของการวิเคราะห์ทั้งหมด เมื่อวิเคราะห์ลำดับกิจกรรม องค์กรจะค้นพบเส้นทางที่เหตุการณ์เกิดขึ้นจริง ระบุคอขวดระหว่างขั้นตอน วัดการทำงานซ้ำ เช่น การเปิดทิกเก็ตที่แก้ไขแล้วอีกครั้ง และตรวจสอบว่ากระบวนการเป็นไปตามมาตรฐานที่กำหนดหรือไม่. เหตุผลที่สำคัญ ลำดับกิจกรรมกำหนดขั้นตอนการทำงาน ซึ่งเป็นหัวใจของการวิเคราะห์ process mining เพื่อค้นหาความไม่มีประสิทธิภาพ จุดที่เบี่ยงเบน และโอกาสในการปรับปรุง. แหล่งข้อมูล ได้จากเหตุการณ์ใน Zendesk Ticket Audits API ตัวอย่างเช่น เหตุการณ์ Change ของฟิลด์ status อาจจับคู่กับ 'เปลี่ยนสถานะแล้ว'. ตัวอย่าง สร้างเหตุการณ์กำหนดทิกเก็ตให้เจ้าหน้าที่เปลี่ยนสถานะเป็นรอดำเนินการแก้ไขเหตุการณ์แล้วปิดเหตุการณ์
	ระบบต้นทาง SourceSystem	ระบบที่ใช้ดึงข้อมูลเหตุการณ์.
คำอธิบาย แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลกระบวนการ สำหรับมุมมองนี้ ค่าจะเป็นค่าคงที่ เช่น 'Zendesk Support' เพื่อระบุว่าเหตุการณ์และแอตทริบิวต์ทั้งหมดมาจากระบบดังกล่าว ในสภาพแวดล้อมที่รวมข้อมูลจากหลายระบบ ฟิลด์นี้ช่วยแยกแหล่งข้อมูลแต่ละแห่งออกจากกัน และสนับสนุนการตรวจสอบความถูกต้องของข้อมูลกับการวิเคราะห์เฉพาะแหล่ง เช่น เปรียบเทียบกระบวนการจัดการเหตุการณ์ใน Zendesk กับเครื่องมือ ITSM อื่น. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูลและการวิเคราะห์ที่รวมข้อมูลจากหลายระบบต้นทาง. แหล่งข้อมูล กำหนดค่าแบบคงที่ระหว่างการแปลงข้อมูลเพื่อระบุแหล่งที่มา. ตัวอย่าง Zendesk SupportZendesk
	อัปเดตข้อมูลล่าสุด LastDataUpdate	เวลาที่ระบุว่ามีการรีเฟรชข้อมูลของกระบวนการนี้ครั้งล่าสุดเมื่อใด.
คำอธิบาย แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงหรืออัปเดตข้อมูลจากระบบต้นทางครั้งล่าสุด โดยทั่วไปจะใช้ค่าเดียวกับชุดข้อมูลทั้งหมดจากรอบการรีเฟรชนั้น ข้อมูลนี้สำคัญต่อการกำกับดูแลข้อมูลและผู้ใช้ผลการวิเคราะห์ process mining เพราะช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด และนักวิเคราะห์กำลังดูข้อมูลล่าสุดที่มีหรือไม่ ซึ่งสำคัญเป็นพิเศษเมื่อติดตามผลการปฏิบัติงานและตัดสินใจจากผลการวิเคราะห์ให้ทันเวลา. เหตุผลที่สำคัญ ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด และข้อมูลที่ใช้วิเคราะห์มาจากระบบต้นทางเมื่อใด. แหล่งข้อมูล เวลาที่ ETL/กระบวนการส่งข้อมูลสร้างขึ้นเมื่อรีเฟรชข้อมูลเสร็จ. ตัวอย่าง 2023-10-27T08:00:00Z2023-10-28T08:00:00Z
	กลุ่มที่ได้รับมอบหมาย AssignedGroup	ทีมสนับสนุนหรือกลุ่มที่ได้รับมอบหมายให้จัดการเหตุขัดข้องในขณะนั้น.
คำอธิบาย แอตทริบิวต์นี้ระบุว่าทีมใดรับผิดชอบเหตุขัดข้อง เหตุขัดข้องมักถูกส่งต่อระหว่างระดับการสนับสนุนหรือกลุ่มผู้เชี่ยวชาญ เช่น จาก «ฝ่ายสนับสนุนระดับ 1» ไปยัง «ทีมเครือข่าย» ข้อมูลนี้เป็นมิติสำคัญสำหรับวิเคราะห์การส่งต่องานและระบุคอขวด การติดตามเส้นทางของเหตุขัดข้องระหว่างกลุ่มช่วยให้นักวิเคราะห์วัดการพึ่งพากันระหว่างทีม คำนวณเวลารอในคิวของแต่ละทีม และปรับกฎการจัดเส้นทางงานให้เหมาะสม ข้อมูลนี้ยังใช้กับแดชบอร์ด «วิเคราะห์การส่งต่องานและการทำงานซ้ำ» โดยตรง. เหตุผลที่สำคัญ ติดตามว่าทีมใดเป็นผู้รับผิดชอบ ซึ่งจำเป็นต่อการวิเคราะห์การส่งต่องานระหว่างทีม ระบุคอขวดของแต่ละทีม และวัดเวลารอในคิว. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ group_id บันทึกการเปลี่ยนแปลงไว้ใน Ticket Audits API. ตัวอย่าง ฝ่ายสนับสนุนระดับ 1ทีมเครือข่ายระดับ 2ฝ่ายโครงสร้างพื้นฐานระดับ 3ฝ่ายเรียกเก็บเงิน
	เจ้าหน้าที่ที่ได้รับมอบหมาย Assignee	เจ้าหน้าที่ฝ่ายสนับสนุนที่ได้รับมอบหมายให้จัดการเหตุขัดข้องในขณะนั้น.
คำอธิบาย แอตทริบิวต์นี้ระบุว่าเจ้าหน้าที่คนใดรับผิดชอบเหตุขัดข้องในช่วงเวลาหนึ่ง การเปลี่ยนผู้รับผิดชอบเป็นเหตุการณ์สำคัญที่แสดงถึงการส่งต่องานจากคนหนึ่งไปยังอีกคนหนึ่ง การวิเคราะห์เจ้าหน้าที่ที่ได้รับมอบหมายช่วยให้เข้าใจการกระจายภาระงาน ผลการปฏิบัติงานของแต่ละคน และรูปแบบการทำงานร่วมกัน การติดตามการเปลี่ยนแปลงของฟิลด์นี้จำเป็นต่อการคำนวณ KPI «จำนวนการส่งต่องานเฉลี่ยต่อเหตุขัดข้อง» และระบุกรณีที่มีการส่งต่อเหตุขัดข้องหลายครั้ง ซึ่งอาจบ่งชี้ถึงช่องว่างด้านความรู้หรือการจัดเส้นทางงานที่ไม่มีประสิทธิภาพ. เหตุผลที่สำคัญ ระบุเจ้าหน้าที่ผู้รับผิดชอบ เพื่อวิเคราะห์ภาระงานและติดตามการส่งต่องาน ซึ่งช่วยระบุจุดที่กระบวนการไม่มีประสิทธิภาพ. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ assignee_id บันทึกการเปลี่ยนแปลงไว้ใน Ticket Audits API. ตัวอย่าง John SmithJane Doeระบบอัตโนมัติของฝ่ายบริการ
	ช่องทางที่แจ้งเหตุ Channel	ช่องทางที่ใช้แจ้งเหตุขัดข้องในครั้งแรก เช่น «อีเมล» «เว็บ» หรือ «API».
คำอธิบาย แอตทริบิวต์นี้บันทึกวิธีที่ผู้ใช้ปลายทางหรือระบบใช้สร้าง Ticket เหตุขัดข้อง การเข้าใจช่องทางที่ใช้แจ้งเหตุช่วยให้วิเคราะห์แหล่งที่มาของเหตุขัดข้องและปรับกระบวนการสนับสนุนให้เหมาะสมได้ การวิเคราะห์เหตุขัดข้องแยกตามช่องทางช่วยให้เห็นรูปแบบที่แตกต่างกัน เช่น เหตุขัดข้องที่แจ้งทางโทรศัพท์อาจใช้เวลาแก้ไขน้อยกว่าที่แจ้งทางอีเมล ข้อมูลนี้ใช้กับแดชบอร์ด «ปริมาณเหตุขัดข้องที่ดำเนินการ» และช่วยวางแผนทรัพยากรกับปรับปรุงช่องทางให้เหมาะสม. เหตุผลที่สำคัญ ช่วยวิเคราะห์ปริมาณเหตุขัดข้องและผลการดำเนินงานของกระบวนการตามแหล่งที่มา เพื่อปรับปรุงกระบวนการและจัดสรรทรัพยากรให้เหมาะกับแต่ละช่องทาง. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ via.channel. ตัวอย่าง เว็บอีเมลAPIโทรศัพท์
	ระดับความสำคัญ TicketPriority	ระดับความสำคัญที่กำหนดให้เหตุขัดข้อง เช่น «ต่ำ» «ปกติ» «สูง» หรือ «เร่งด่วน».
คำอธิบาย ระดับความสำคัญของเหตุขัดข้องเป็นตัวกำหนดความเร่งด่วนในการตอบสนองและแก้ไข อีกทั้งยังเป็นปัจจัยสำคัญในการจัดลำดับงานและจัดสรรทรัพยากรภายในทีมสนับสนุน การวิเคราะห์กระบวนการใช้ระดับความสำคัญเพื่อแบ่งกลุ่มเหตุขัดข้อง แล้วเปรียบเทียบเส้นทางและผลการดำเนินงานของแต่ละกลุ่ม ตัวอย่างเช่น นักวิเคราะห์ตรวจสอบได้ว่าเหตุขัดข้องระดับ «เร่งด่วน» ได้รับการแก้ไขเร็วกว่าระดับ «ต่ำ» จริงหรือไม่ นอกจากนี้ยังใช้ติดตามการปฏิบัติตาม SLA เนื่องจากมักกำหนด SLA ตามระดับความสำคัญ ส่วน KPI «อัตราการเปลี่ยนระดับความสำคัญ» อาศัยการติดตามการเปลี่ยนแปลงของฟิลด์นี้. เหตุผลที่สำคัญ แอตทริบิวต์นี้จำเป็นต่อการแบ่งกลุ่มข้อมูลเพื่อวิเคราะห์ ประเมินประสิทธิผลของการจัดลำดับความสำคัญ และติดตามการปฏิบัติตาม SLA ในแต่ละระดับความเร่งด่วน. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ priority บันทึกการเปลี่ยนแปลงไว้ใน Ticket Audits API. ตัวอย่าง ต่ำปกติสูงเร่งด่วน
	เวลาสิ้นสุดเหตุการณ์ EventEndTime	เวลาที่ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด.
คำอธิบาย เวลาสิ้นสุดเหตุการณ์ระบุว่ากิจกรรมสิ้นสุดเมื่อใด ในข้อมูลบันทึกเหตุการณ์ มักอนุมานเวลาสิ้นสุดของกิจกรรมหนึ่งจากเวลาเริ่มต้นของกิจกรรมถัดไปในลำดับเดียวกัน สำหรับกิจกรรมสุดท้ายของกรณีหนึ่ง เวลาสิ้นสุดอาจตรงกับเวลาเริ่มต้น แอตทริบิวต์นี้จำเป็นต่อการคำนวณระยะเวลาของแต่ละกิจกรรม (ProcessingTime) และเวลารอระหว่างกิจกรรม ข้อมูลนี้เป็นพื้นฐานสำหรับวิเคราะห์คอขวดอย่างละเอียด ช่วยให้นักวิเคราะห์เห็นทั้งระยะเวลาที่ใช้ในแต่ละขั้นตอนและเวลาที่กรณีงานหยุดรอก่อนเริ่มขั้นตอนนั้น. เหตุผลที่สำคัญ ใช้คำนวณระยะเวลากิจกรรมและเวลารอ ซึ่งเป็นข้อมูลพื้นฐานสำหรับวิเคราะห์คอขวดอย่างละเอียดและระบุความล่าช้าในกระบวนการ. แหล่งข้อมูล คำนวณจากเวลาเริ่มต้นของเหตุการณ์ถัดไปในกรณีเดียวกัน เวลาสิ้นสุดของเหตุการณ์สุดท้ายอาจตรงกับเวลาเริ่มต้นหรือเวลาปิดกรณี. ตัวอย่าง 2023-04-15T10:05:12Z2023-04-16T14:30:00Z2023-04-16T18:00:00Z
	สถานะ SLA SlaStatus	สถานะปัจจุบันของข้อตกลงระดับการให้บริการ (SLA) สำหรับเหตุขัดข้อง.
คำอธิบาย แอตทริบิวต์นี้ระบุว่าเหตุขัดข้องยังมีแนวโน้มเป็นไปตามเป้าหมาย SLA ที่กำหนดหรือไม่ เกินกำหนดแล้วหรือไม่ หรือหยุดจับเวลา SLA ไว้ Zendesk ติดตามตัวชี้วัด SLA โดยอัตโนมัติตามนโยบายที่ตั้งค่าไว้ แอตทริบิวต์นี้สำคัญต่อแดชบอร์ด «ติดตามการปฏิบัติตาม SLA» เพราะใช้วัดผลการดำเนินงานเทียบกับข้อผูกพันด้านบริการโดยตรง การวิเคราะห์ว่า SLA เกินกำหนดเมื่อใดและเพราะเหตุใดช่วยให้องค์กรระบุจุดอ่อนของกระบวนการและปรับปรุงความน่าเชื่อถือของบริการได้ อีกทั้งยังใช้กับ KPI «อัตราการปฏิบัติตาม SLA สำหรับเหตุขัดข้อง» โดยตรง. เหตุผลที่สำคัญ วัดผลการดำเนินงานเทียบกับข้อผูกพันด้านบริการโดยตรง ช่วยวิเคราะห์กรณีที่ SLA เกินกำหนดและติดตามสถานะเชิงรุกเพื่อปรับปรุงการปฏิบัติตามข้อกำหนด. แหล่งข้อมูล Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json) ซึ่งคำนวณจากฟิลด์ต่างๆ เช่น sla_policy และ breached_at เป็นต้น. ตัวอย่าง กำลังดำเนินการหยุดชั่วคราวเกินกำหนดดำเนินการครบถ้วน
	สถานะทิกเก็ต TicketStatus	สถานะของทิกเก็ตเหตุการณ์ ณ เวลาที่เกิดเหตุการณ์ เช่น 'เปิด' 'รอดำเนินการ' หรือ 'แก้ไขแล้ว'.
คำอธิบาย แอตทริบิวต์นี้แสดงสถานะของทิกเก็ตเหตุการณ์ในแต่ละช่วงของวงจร สถานะมาตรฐานของ Zendesk ได้แก่ new, open, pending, on-hold, solved และ closed การติดตามการเปลี่ยนแปลงของฟิลด์นี้เป็นวิธีหลักในการสร้างกิจกรรมสำหรับ process mining การวิเคราะห์สถานะทิกเก็ตเป็นพื้นฐานสำคัญในการทำความเข้าใจกระบวนการ ช่วยให้เห็นว่าเหตุการณ์ใช้เวลาอยู่ในแต่ละสถานะนานเท่าใด เช่น สถานะ 'Pending' ซึ่งมักหมายถึงกำลังรอคำตอบจากลูกค้า และยังใช้กำหนดว่าเคสเสร็จสิ้นเมื่อใด รวมถึงคำนวณเวลาแก้ไขด้วย. เหตุผลที่สำคัญ การติดตามการเปลี่ยนสถานะช่วยให้เห็นความคืบหน้าของกระบวนการ ระบุเวลารอ และกำหนดจุดเริ่มต้นกับจุดสิ้นสุดของวงจรการจัดการเหตุขัดข้อง. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ status บันทึกการเปลี่ยนแปลงไว้ใน Ticket Audits API. ตัวอย่าง ใหม่เปิดรอดำเนินการแก้ไขแล้วปิดแล้ว
	แก้ไขได้ตั้งแต่การติดต่อครั้งแรกหรือไม่ IsFirstContactResolution	ค่าบูลีนที่เป็นจริงเมื่อเจ้าหน้าที่หรือกลุ่มที่ได้รับมอบหมายในครั้งแรกแก้ไขเหตุขัดข้องได้โดยไม่มีการส่งต่องาน.
คำอธิบาย การแก้ไขได้ตั้งแต่การติดต่อครั้งแรก (FCR) เป็นตัวชี้วัดสำคัญของประสิทธิภาพศูนย์สนับสนุนและความพึงพอใจของลูกค้า แอตทริบิวต์ที่คำนวณนี้ระบุเหตุขัดข้องที่แก้ไขได้โดยไม่ต้องมอบหมายต่อให้เจ้าหน้าที่หรือทีมอื่น โดยทั่วไปจะตรวจสอบว่า Ticket มีสถานะ «แก้ไขแล้ว» ขณะที่ยังอยู่กับเจ้าหน้าที่และกลุ่มเดิมที่ได้รับมอบหมายในครั้งแรกหรือไม่ ใน process mining ข้อมูลนี้ใช้คำนวณอัตรา FCR โดยตรง และเปรียบเทียบเส้นทางของเหตุขัดข้องที่แก้ไขได้ตั้งแต่ครั้งแรกกับกรณีที่ต้องยกระดับการจัดการ เพื่อหาโอกาสเพิ่มขีดความสามารถให้ทีมสนับสนุนด่านหน้า. เหตุผลที่สำคัญ วัดประสิทธิภาพของจุดให้บริการสนับสนุนครั้งแรกโดยตรง และช่วยระบุโอกาสในการแก้ไขปัญหาให้ได้เร็วขึ้นในกระบวนการ. แหล่งข้อมูล ค่าบูลีนที่คำนวณขึ้น เป็นจริงเมื่อสถานะ Ticket เป็น «แก้ไขแล้ว» หรือ «ปิดแล้ว» และมีผู้รับผิดชอบหรือกลุ่มที่ได้รับมอบหมายเพียงรายเดียวตลอดวงจรเหตุขัดข้อง. ตัวอย่าง truefalse
	คะแนนความพึงพอใจ SatisfactionRating	คะแนนความพึงพอใจที่ผู้ใช้ปลายทางให้หลังจากแก้ไขเหตุขัดข้องแล้ว.
คำอธิบาย แอตทริบิวต์นี้บันทึกความคิดเห็นของลูกค้าต่อประสบการณ์การรับบริการสนับสนุน โดยทั่วไปจะเก็บผ่านแบบสำรวจหลังจากแก้ไข Ticket แล้ว คะแนนที่ใช้กันใน Zendesk ได้แก่ «ดี» หรือ «ไม่ดี» แม้คะแนนความพึงพอใจจะไม่ได้วัดประสิทธิภาพของกระบวนการโดยตรง แต่เป็นตัวชี้วัดผลลัพธ์ที่สำคัญ ใน process mining สามารถนำคะแนนนี้ไปเปรียบเทียบกับรูปแบบกระบวนการ เพื่อดูว่าเส้นทางการแก้ไขแบบใดทำให้ลูกค้าพึงพอใจมากกว่า ตัวอย่างเช่น เหตุขัดข้องที่มีการส่งต่องานหลายครั้งได้คะแนนต่ำกว่าหรือไม่? เหตุผลที่สำคัญ เป็นตัวชี้วัดผลลัพธ์สำคัญที่นำไปเปรียบเทียบกับลักษณะของกระบวนการ เพื่อทำความเข้าใจว่าผลการดำเนินงานส่งผลต่อความพึงพอใจของผู้ใช้อย่างไร. แหล่งข้อมูล Zendesk Ticket Metrics API (/api/v2/ticket_metrics.json) ฟิลด์ satisfaction_rating.score. ตัวอย่าง ดีไม่ดีมีการเสนอแบบสำรวจไม่มีการเสนอแบบสำรวจ
	จำนวนครั้งที่ส่งต่องาน HandoffCount	จำนวนครั้งทั้งหมดที่มีการมอบหมายเหตุขัดข้องให้เจ้าหน้าที่หรือกลุ่มอื่น.
คำอธิบาย ตัวชี้วัดที่คำนวณนี้นับจำนวนครั้งที่มีการโอนความรับผิดชอบต่อเหตุขัดข้อง การเปลี่ยนแปลงแต่ละครั้งในฟิลด์ Assignee หรือ AssignedGroup จะเพิ่มจำนวนครั้งของกรณีนั้น การส่งต่องานเป็นสาเหตุที่พบบ่อยของความไม่มีประสิทธิภาพและความล่าช้าในการจัดการเหตุขัดข้อง หากมีการส่งต่องานหลายครั้ง อาจหมายถึงกฎการจัดเส้นทางงานไม่ชัดเจน ทีมสนับสนุนมีช่องว่างด้านความรู้ หรือกระบวนการซับซ้อนเกินไป ตัวชี้วัดนี้เป็นพื้นฐานของ KPI «จำนวนการส่งต่องานเฉลี่ยต่อเหตุขัดข้อง» และจำเป็นต่อแดชบอร์ด «วิเคราะห์การส่งต่องานและการทำงานซ้ำ». เหตุผลที่สำคัญ วัดความติดขัดของกระบวนการที่เกิดจากการส่งต่องาน ช่วยระบุปัญหาในการจัดเส้นทางงานและช่องว่างด้านความรู้ที่ทำให้การแก้ไขล่าช้า. แหล่งข้อมูล คำนวณโดยนับจำนวนครั้งที่ฟิลด์ AssignedGroup หรือ Assignee เปลี่ยนแปลงสำหรับเหตุขัดข้องหนึ่งรายการ. ตัวอย่าง 0135
	แท็ก Tags	รายการแท็กที่กำหนดให้เหตุขัดข้องเพื่อใช้จัดหมวดหมู่และให้บริบทเพิ่มเติม.
คำอธิบาย แท็กเป็นป้ายกำกับที่ปรับเปลี่ยนได้ตามต้องการ สามารถเพิ่มลงใน Ticket เพื่อให้บริบทเพิ่มเติม ช่วยจัดหมวดหมู่ หรือกำหนดเส้นทางงาน เจ้าหน้าที่อาจเพิ่มแท็กเอง หรือระบบเพิ่มให้อัตโนมัติผ่าน triggers และ automations แท็กเป็นแหล่งข้อมูลที่มีประโยชน์สำหรับการวิเคราะห์ process mining คุณใช้แท็กแบ่งกลุ่มข้อมูลอย่างละเอียดได้ เช่น กรองเหตุขัดข้องที่เกี่ยวกับการเปิดตัวผลิตภัณฑ์ («launch_q4») หรือเหตุขัดข้องที่ทราบอยู่แล้ว («outage_20231027») ความยืดหยุ่นนี้ช่วยให้ตรวจสอบข้อมูลเชิงลึกได้มากกว่าการใช้ฟิลด์ Ticket มาตรฐานเพียงอย่างเดียว. เหตุผลที่สำคัญ ช่วยจัดหมวดหมู่และกรองเหตุขัดข้องได้อย่างยืดหยุ่น ทำให้วิเคราะห์ตามบริบทได้ละเอียดขึ้น ซึ่งอาจทำไม่ได้หากใช้เฉพาะฟิลด์มาตรฐาน. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ tags. ตัวอย่าง ผู้ใช้ VIPปัญหาเครือข่ายoutage_20231027เกี่ยวกับการเรียกเก็บเงิน
	ประเภท Ticket TicketType	ประเภทของ Ticket เช่น «เหตุขัดข้อง» «ปัญหา» «คำถาม» หรือ «งาน».
คำอธิบาย ฟิลด์นี้ใช้จัดประเภท Ticket ตามลักษณะของคำขอ กระบวนการจัดการเหตุขัดข้องจะเน้น Ticket ที่มีประเภทเป็น «เหตุขัดข้อง» ซึ่งหมายถึงบริการ IT หยุดชะงักหรือคุณภาพลดลงโดยไม่ได้วางแผนไว้ ในการวิเคราะห์ แอตทริบิวต์นี้ใช้เป็นตัวกรองเพื่อให้มุมมองกระบวนการแสดงเฉพาะเหตุขัดข้อง นอกจากนี้ยังใช้วิเคราะห์ ITSM ในภาพรวม เพื่อเปรียบเทียบกระบวนการจัดการเหตุขัดข้อง ปัญหา หรือคำขอรับบริการได้. เหตุผลที่สำคัญ ใช้กรองข้อมูลให้แสดงเฉพาะเหตุขัดข้อง เพื่อให้การวิเคราะห์กระบวนการตรงกับวงจรการจัดการเหตุขัดข้อง. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ type. ตัวอย่าง เหตุขัดข้องปัญหาคำถามงาน
	เป็นระบบอัตโนมัติหรือไม่ IsAutomated	ค่าบูลีนที่ระบุว่ากิจกรรมดำเนินการโดยระบบอัตโนมัติหรือเจ้าหน้าที่.
คำอธิบาย แอตทริบิวต์ที่คำนวณขึ้นนี้ช่วยแยกเหตุการณ์ที่ผู้ใช้ดำเนินการออกจากเหตุการณ์ที่เกิดจากระบบอัตโนมัติ triggers หรือการเชื่อมต่อ API โดยทั่วไปจะตรวจสอบว่าผู้เขียนเหตุการณ์เป็นผู้ใช้ระบบที่รู้จักหรือไม่ การเข้าใจระดับการทำงานอัตโนมัติเป็นสิ่งสำคัญต่อการวิเคราะห์กระบวนการในปัจจุบัน ช่วยประเมินประสิทธิผลของกฎอัตโนมัติ ระบุงานที่ทำด้วยมือซึ่งอาจทำให้เป็นอัตโนมัติได้ และวัดผลของระบบอัตโนมัติต่อประสิทธิภาพกับเวลาแก้ไข คุณยังใช้แอตทริบิวต์นี้เปรียบเทียบเส้นทางกระบวนการของกิจกรรมอัตโนมัติกับกิจกรรมที่ทำด้วยมือได้. เหตุผลที่สำคัญ แยกการดำเนินการของคนออกจากระบบ ซึ่งจำเป็นต่อการวิเคราะห์ผลของระบบอัตโนมัติต่อประสิทธิภาพกระบวนการและระบุโอกาสในการทำงานอัตโนมัติเพิ่มเติม. แหล่งข้อมูล คำนวณโดยตรวจสอบว่าผู้เขียนเหตุการณ์ (author_id ใน Ticket Audits API) เป็นผู้ใช้ระบบหรือผู้ใช้ระบบอัตโนมัติที่รู้จักหรือไม่. ตัวอย่าง truefalse
	ผู้แจ้ง Ticket Submitter	ผู้ใช้ปลายทางหรือระบบที่แจ้งเหตุขัดข้องในครั้งแรก.
คำอธิบาย แอตทริบิวต์นี้ระบุบุคคลหรือหน่วยงานที่สร้าง Ticket ซึ่งต่างจากผู้ร้องขอ เพราะเจ้าหน้าที่อาจสร้าง Ticket ในนามของบุคคลอื่น การวิเคราะห์ข้อมูลผู้แจ้ง Ticket ช่วยให้เข้าใจว่าใครเป็นผู้รายงานปัญหา เมื่อนำไปประกอบกับข้อมูลองค์กร จะช่วยระบุได้ว่าลูกค้าหรือกลุ่มผู้ใช้ใดพบเหตุขัดข้องจำนวนมาก ข้อมูลนี้ใช้วางแผนการสนับสนุนเชิงรุกหรือการฝึกอบรมได้. เหตุผลที่สำคัญ ระบุแหล่งที่มาของรายงานเหตุขัดข้อง ซึ่งนำไปวิเคราะห์หารูปแบบที่เกี่ยวข้องกับผู้ใช้ แผนก หรือระบบอัตโนมัติเฉพาะได้. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ submitter_id. ตัวอย่าง alice.jones@example.combob.williams@example.comระบบตรวจสอบระบบ
	ระดับความรุนแรง Severity	ระดับผลกระทบที่เหตุขัดข้องมีต่อธุรกิจ.
คำอธิบาย ระดับความรุนแรงใช้ระบุผลกระทบของเหตุขัดข้องต่อธุรกิจ โดยมักพิจารณาร่วมกับระดับความสำคัญเพื่อกำหนดความเร่งด่วนโดยรวม โดยทั่วไปจะตั้งค่าเป็นฟิลด์แบบกำหนดเองใน Zendesk การวิเคราะห์ระดับความรุนแรงช่วยให้เข้าใจความสำคัญของเหตุขัดข้องที่กำลังจัดการ ข้อมูลนี้เป็นมิติสำคัญสำหรับแบ่งกลุ่มข้อมูลในแดชบอร์ด เช่น «ติดตามการปฏิบัติตาม SLA» และ «ตัวชี้วัดประสิทธิผลของการจัดลำดับความสำคัญ» การเปรียบเทียบเส้นทางกระบวนการในแต่ละระดับความรุนแรงช่วยให้เห็นว่าเหตุขัดข้องที่รุนแรงได้รับการจัดการด้วยความรวดเร็วและทรัพยากรที่เหมาะสมหรือไม่. เหตุผลที่สำคัญ ระบุผลกระทบของเหตุขัดข้องต่อธุรกิจ ช่วยให้วิเคราะห์ปัญหาที่สำคัญที่สุดและตรวจสอบว่าได้รับการแก้ไขอย่างมีประสิทธิภาพ. แหล่งข้อมูล โดยทั่วไปฟิลด์นี้กำหนดเองได้ ตรวจสอบการตั้งค่า Ticket Fields ใน Zendesk Admin Center. ตัวอย่าง 1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
	ระยะเวลาของกรณีงาน CaseDuration	เวลารวมตั้งแต่สร้างเหตุขัดข้องจนปิดกรณีในที่สุด.
คำอธิบาย ตัวชี้วัดที่คำนวณนี้แสดงเวลาตั้งแต่ต้นจนจบของเหตุขัดข้องหนึ่งกรณี โดยหาผลต่างระหว่างเวลาของเหตุการณ์แรกสุด (เช่น «สร้างเหตุขัดข้อง») กับเหตุการณ์สุดท้าย (เช่น «ปิดเหตุขัดข้อง») ระยะเวลาของกรณีงานเป็น KPI หลักที่ใช้วัดประสิทธิภาพโดยรวมของกระบวนการ แดชบอร์ดมักใช้ตัวชี้วัดนี้แสดงเวลาเฉลี่ยตั้งแต่ต้นจนจบ ระบุกรณีที่ใช้เวลานาน และวิเคราะห์แนวโน้มตามช่วงเวลา นอกจากนี้ยังช่วยวัดภาพรวมว่ากระบวนการจัดการและแก้ไขเหตุขัดข้องได้รวดเร็วเพียงใด. เหตุผลที่สำคัญ KPI นี้สำคัญต่อการวัดความรวดเร็วโดยรวมของกระบวนการ และระบุปัจจัยที่ทำให้ใช้เวลาแก้ไขนาน. แหล่งข้อมูล คำนวณจากผลต่างระหว่างเวลาของเหตุการณ์สุดท้ายกับเหตุการณ์แรกของ Incident ID แต่ละรายการ. ตัวอย่าง 25920060480086400
	หมวดหมู่สาเหตุที่แท้จริง RootCauseCategory	หมวดหมู่ระดับสูงของสาเหตุที่แท้จริงของเหตุขัดข้อง.
คำอธิบาย แอตทริบิวต์นี้ใช้จัดประเภทสาเหตุพื้นฐานของเหตุขัดข้อง โดยทั่วไปจะบันทึกไว้ในช่วงท้ายของวงจรเหตุขัดข้อง มักเป็นส่วนหนึ่งของการทบทวนหลังเหตุการณ์หรือกระบวนการจัดการปัญหา และจัดเก็บไว้ในฟิลด์แบบกำหนดเอง ข้อมูลนี้จำเป็นต่อแดชบอร์ด «ความแม่นยำในการระบุสาเหตุที่แท้จริง» และ KPI «ความครอบคลุมของการวิเคราะห์สาเหตุที่แท้จริง (RCA)» การวิเคราะห์เหตุขัดข้องตามสาเหตุช่วยให้ระบุปัญหาที่เกิดซ้ำและวางแผนแก้ไขอย่างถาวรเพื่อลดเหตุขัดข้องในอนาคต ทำให้ทีมเปลี่ยนจากการแก้ปัญหาเฉพาะหน้าไปสู่การป้องกันปัญหาเชิงรุก. เหตุผลที่สำคัญ ช่วยจัดการปัญหาเชิงรุกด้วยการจัดหมวดหมู่สาเหตุของเหตุขัดข้อง เพื่อระบุแนวโน้มและป้องกันไม่ให้เกิดซ้ำ. แหล่งข้อมูล โดยทั่วไปฟิลด์นี้เป็นฟิลด์ Ticket ที่กำหนดเอง ตรวจสอบการตั้งค่า Ticket Fields ใน Zendesk Admin Center. ตัวอย่าง ข้อบกพร่องของซอฟต์แวร์ฮาร์ดแวร์ขัดข้องผู้ใช้ดำเนินการผิดพลาดเครือข่ายขัดข้อง
	องค์กรของลูกค้า Organization	องค์กรหรือบริษัทที่ผู้ร้องขอให้จัดการเหตุขัดข้องสังกัดอยู่.
คำอธิบาย แอตทริบิวต์นี้เชื่อมโยงเหตุขัดข้องกับองค์กรของลูกค้า จึงจำเป็นสำหรับการสนับสนุนแบบ B2B ที่ระดับบริการและกระบวนการสนับสนุนอาจแตกต่างกันไปในแต่ละลูกค้า การวิเคราะห์เหตุขัดข้องแยกตามองค์กรช่วยให้ทีมสนับสนุนติดตามสถานะของลูกค้า ระบุปัญหาที่เกิดซ้ำกับลูกค้าบางราย และตรวจสอบการปฏิบัติตามข้อผูกพันตามสัญญา ข้อมูลนี้เป็นมิติสำคัญสำหรับกรองแดชบอร์ดและรายงาน เพื่อให้เห็นผลการดำเนินงานในมุมมองของลูกค้า. เหตุผลที่สำคัญ ช่วยวิเคราะห์ข้อมูลแยกตามลูกค้า ติดตามระดับบริการ ระบุแนวโน้มของลูกค้ารายสำคัญ และบริหารความสัมพันธ์กับลูกค้าได้อย่างมีประสิทธิภาพ. แหล่งข้อมูล Zendesk Tickets API ฟิลด์ organization_id. ตัวอย่าง Global Tech Inc.Innovate SolutionsData Corp

จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการจัดการเหตุขัดข้อง

ขั้นตอนและจุดสำคัญของกระบวนการที่ควรบันทึกไว้ในบันทึกเหตุการณ์ เพื่อให้ค้นพบและวิเคราะห์กระบวนการได้อย่างแม่นยำ.

6 แนะนำ 7 ไม่บังคับ

	กิจกรรม	คำอธิบาย
	กำหนดทิกเก็ตให้เจ้าหน้าที่	กิจกรรมนี้เกิดขึ้นเมื่อกำหนดทิกเก็ตให้เจ้าหน้าที่คนใดคนหนึ่งเป็นผู้ดูแล โดยบันทึกไว้อย่างชัดเจนในประวัติ audit ของทิกเก็ต และแสดงว่ามีผู้รับผิดชอบงานแล้ว.
เหตุผลที่สำคัญ เหตุการณ์สำคัญนี้ใช้วัดเวลาจนถึงการมอบหมายงานครั้งแรก และเป็นพื้นฐานในการวิเคราะห์การส่งต่องาน การทำงานซ้ำ และอัตราการแก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรก (FCR). แหล่งข้อมูล ดึงข้อมูลจาก audit log ของทิกเก็ตเมื่อมีการกรอกหรือเปลี่ยนฟิลด์ 'assignee_id' การมอบหมายครั้งแรกเป็นเหตุการณ์สำคัญในการคำนวณ KPI. บันทึก ระบุจากเหตุการณ์ 'Change' ของฟิลด์ 'assignee_id' ใน audit log ของทิกเก็ต. ประเภทเหตุการณ์ explicit
	แก้ไขเหตุการณ์แล้ว	เหตุการณ์สำคัญนี้เกิดขึ้นเมื่อเจ้าหน้าที่ดำเนินการแก้ไขและเปลี่ยนสถานะทิกเก็ตเป็น 'solved' โดยบันทึกเป็นการเปลี่ยนสถานะใน audit log ของทิกเก็ต.
เหตุผลที่สำคัญ นี่คือกิจกรรมหลักที่แสดงว่าแก้ไขเหตุการณ์แล้ว และเป็นจุดสำคัญในการวัดเวลาแก้ไข ช่วงเวลาระหว่างเหตุการณ์นี้กับ 'ปิดเหตุการณ์' คือช่วงรอการยืนยันจากผู้ใช้หรือรอระบบปิดทิกเก็ตโดยอัตโนมัติ. แหล่งข้อมูล ดึงข้อมูลจาก audit log ของทิกเก็ตผ่านเหตุการณ์ 'Change' ที่ค่าใหม่ของฟิลด์ 'status' เป็น 'solved'. บันทึก ระบุจากเหตุการณ์ 'Change' ของฟิลด์ 'status' เป็น 'solved'. ประเภทเหตุการณ์ explicit
	ปิดเหตุการณ์	เป็นจุดสิ้นสุดของวงจรเหตุการณ์เมื่อปิดทิกเก็ตอย่างถาวร ใน Zendesk มักเกิดขึ้นโดยอัตโนมัติหลังจากเปลี่ยนสถานะเป็นแก้ไขแล้วตามระยะเวลาที่กำหนด และบันทึกเป็นการเปลี่ยนสถานะครั้งสุดท้าย.
เหตุผลที่สำคัญ นี่คือกิจกรรมสุดท้ายของกระบวนการ ระยะเวลารวมคำนวณตั้งแต่ 'สร้างเหตุการณ์' จนถึงเหตุการณ์นี้ เพื่อให้เห็นเวลาตั้งแต่ต้นจนจบ. แหล่งข้อมูล ดึงข้อมูลจาก audit log ของทิกเก็ตผ่านเหตุการณ์ 'Change' ที่ค่าใหม่ของฟิลด์ 'status' เป็น 'closed'. บันทึก ระบุจากเหตุการณ์ 'Change' ของฟิลด์ 'status' เป็น 'closed'. ประเภทเหตุการณ์ explicit
	เปลี่ยนสถานะเป็นเปิด	แสดงว่าเจ้าหน้าที่เริ่มดำเนินการกับเหตุการณ์แล้ว โดยทั่วไปอนุมานจากการเปลี่ยนฟิลด์ 'status' ของทิกเก็ตจาก 'new' เป็น 'open' ซึ่งหมายถึงเริ่มตรวจสอบและวินิจฉัยปัญหา.
เหตุผลที่สำคัญ เหตุการณ์นี้แสดงการเปลี่ยนจากการรอคิวไปสู่การลงมือทำ เวลาที่ทิกเก็ตอยู่ในสถานะ 'new' ก่อนเปลี่ยนเป็น 'open' เป็นตัวชี้วัดสำคัญของเวลาตอบกลับครั้งแรก. แหล่งข้อมูล อนุมานจาก audit log ของทิกเก็ต โดยตรวจหาเหตุการณ์ 'Change' ที่ค่าใหม่ของฟิลด์ 'status' เป็น 'open' และค่าก่อนหน้าเป็น 'new'. บันทึก อนุมานจากการเปลี่ยนฟิลด์สถานะจาก 'new' เป็น 'open'. ประเภทเหตุการณ์ inferred
	มอบหมายทิกเก็ตใหม่	เกิดขึ้นเมื่อมีการโอนความรับผิดชอบของทิกเก็ตจากเจ้าหน้าที่หรือกลุ่มหนึ่งไปยังอีกคนหรืออีกกลุ่ม หลังจากมอบหมายครั้งแรกแล้ว ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนในประวัติ audit ของทิกเก็ต.
เหตุผลที่สำคัญ การมอบหมายใหม่เป็นข้อมูลสำคัญสำหรับวิเคราะห์การส่งต่องานและการทำงานซ้ำ หากเกิดบ่อยครั้ง มักบ่งชี้ว่าการส่งต่อครั้งแรกไม่ถูกต้อง ปัญหาซับซ้อน หรือกระบวนการมีคอขวด. แหล่งข้อมูล ดึงข้อมูลจาก audit log ของทิกเก็ต โดยตรวจหาเหตุการณ์ 'Change' ของฟิลด์ 'assignee_id' หรือ 'group_id' หลังจากมีการกำหนดค่าในฟิลด์นั้นครั้งแรก. บันทึก ระบุจากเหตุการณ์ 'Change' ครั้งถัดไปของฟิลด์ 'assignee_id' หรือ 'group_id'. ประเภทเหตุการณ์ explicit
	สร้างเหตุการณ์	เป็นจุดเริ่มต้นของวงจรเหตุการณ์ เมื่อมีการสร้างทิกเก็ตใหม่ใน Zendesk ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนใน audit log การสร้างทิกเก็ตของ Zendesk และใช้เป็นจุดเริ่มต้นของแต่ละเคส.
เหตุผลที่สำคัญ นี่คือกิจกรรมเริ่มต้นหลัก การวิเคราะห์เวลาตั้งแต่เหตุการณ์นี้ไปจนถึงเหตุการณ์อื่นมีความสำคัญต่อการวัดระยะเวลาตั้งแต่ต้นจนจบของทิกเก็ตและเวลาตอบกลับครั้งแรก. แหล่งข้อมูล เหตุการณ์นี้บันทึกไว้อย่างชัดเจนใน audit log ของทิกเก็ต Zendesk ทิกเก็ตใหม่แต่ละรายการจะสร้างเหตุการณ์ 'Create' พร้อมเวลาที่เกิดเหตุการณ์. บันทึก ดึงข้อมูลโดยตรงจากเหตุการณ์สร้างทิกเก็ตใน audit log. ประเภทเหตุการณ์ explicit
	กำหนดทิกเก็ตให้กลุ่ม	หมายถึงการส่งต่อหรือคัดแยกเหตุการณ์เบื้องต้นไปยังกลุ่มสนับสนุนที่ระบุ โดยทั่วไปเป็นขั้นตอนแรกในการกำหนดผู้รับผิดชอบ และบันทึกเป็นเหตุการณ์การเปลี่ยนแปลงในประวัติ audit ของทิกเก็ต.
เหตุผลที่สำคัญ การติดตามการกำหนดกลุ่มช่วยวิเคราะห์ประสิทธิภาพของการคัดแยกเบื้องต้น และค้นหาความล่าช้าก่อนส่งทิกเก็ตไปยังทีมที่ถูกต้อง. แหล่งข้อมูล ดึงข้อมูลจาก audit log ของทิกเก็ตเมื่อมีการกำหนดหรือเปลี่ยนฟิลด์ 'group_id' การเปลี่ยนแปลงครั้งแรกหลังสร้างทิกเก็ตถือเป็นการกำหนดกลุ่มครั้งแรก. บันทึก ระบุจากเหตุการณ์ 'Change' ของฟิลด์ 'group_id' ใน audit log ของทิกเก็ต. ประเภทเหตุการณ์ explicit
	กำหนดระดับความสำคัญ	กำหนดระดับความสำคัญของเหตุการณ์ เช่น ต่ำ ปกติ สูง หรือเร่งด่วน โดยบันทึกเป็นเหตุการณ์การเปลี่ยนแปลงอย่างชัดเจน และใช้กำหนดความเร่งด่วนกับเวลาตอบสนองที่ต้องการสำหรับทิกเก็ต.
เหตุผลที่สำคัญ การติดตามเวลาและวิธีการกำหนดระดับความสำคัญมีความสำคัญต่อแดชบอร์ด 'ตัวชี้วัดประสิทธิผลการจัดลำดับความสำคัญ' เพื่อให้จัดการปัญหาสำคัญได้ทันท่วงที. แหล่งข้อมูล ดึงข้อมูลจากเหตุการณ์ 'Change' ของฟิลด์ 'priority' ใน audit log ของทิกเก็ต นอกจากนี้ยังติดตามการเปลี่ยนแปลงครั้งต่อ ๆ ไปเพื่อวัด KPI อัตราการเปลี่ยนระดับความสำคัญได้. บันทึก ระบุจากเหตุการณ์ 'Change' ของฟิลด์ 'priority' ใน audit log ของทิกเก็ต. ประเภทเหตุการณ์ explicit
	เปลี่ยนสถานะเป็นรอดำเนินการ	แสดงว่ากระบวนการหยุดรอคำตอบจากผู้แจ้ง โดยอนุมานจากการเปลี่ยนฟิลด์ 'status' ของทิกเก็ตเป็น 'pending'.
เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการคำนวณเวลารอการยืนยันจากผู้ใช้ หากอยู่ในสถานะนี้นาน จะทำให้เวลาแก้ไขโดยรวมเพิ่มขึ้นอย่างมาก และอาจบ่งชี้ถึงความล่าช้าในการสื่อสาร. แหล่งข้อมูล อนุมานจาก audit log ของทิกเก็ต โดยตรวจหาเหตุการณ์ 'Change' ที่ค่าใหม่ของฟิลด์ 'status' เป็น 'pending'. บันทึก อนุมานจากการเปลี่ยนฟิลด์สถานะเป็น 'pending'. ประเภทเหตุการณ์ inferred
	เพิ่มบันทึกภายใน	กิจกรรมนี้แสดงการทำงานร่วมกันภายในทีม เมื่อเจ้าหน้าที่เพิ่มบันทึกส่วนตัวในทิกเก็ตเพื่อให้สมาชิกคนอื่นเห็น ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนเมื่อความคิดเห็นถูกกำหนดให้ไม่เป็นสาธารณะ.
เหตุผลที่สำคัญ การวิเคราะห์บันทึกภายในช่วยให้เข้าใจปัญหาซับซ้อนที่ต้องอาศัยความร่วมมือ แต่หากมีจำนวนมากเกินไป อาจบ่งชี้ถึงช่องว่างด้านความรู้หรือความไม่มีประสิทธิภาพของกระบวนการ. แหล่งข้อมูล ดึงข้อมูลจากความคิดเห็นของทิกเก็ต โดยถือว่าเป็นบันทึกภายในเมื่อแอตทริบิวต์ 'public' มีค่าเป็น false. บันทึก ระบบบันทึกเหตุการณ์เมื่อมีการเพิ่มความคิดเห็นใหม่ที่มีค่า 'public: false' ในทิกเก็ต. ประเภทเหตุการณ์ explicit
	ละเมิดเป้าหมาย SLA	ระบุเวลาที่ทิกเก็ตไม่เป็นไปตามข้อตกลงระดับการให้บริการที่กำหนดไว้ เช่น เวลาตอบกลับครั้งแรกหรือเวลาแก้ไข ระบบคำนวณเหตุการณ์นี้จากนิยามนโยบาย SLA และเวลาที่อัปเดตทิกเก็ต.
เหตุผลที่สำคัญ เหตุการณ์นี้ช่วยติดตามการปฏิบัติตาม SLA การระบุว่าเกิดการละเมิดเมื่อใดและเพราะเหตุใดเป็นพื้นฐานสำคัญในการเพิ่มความน่าเชื่อถือของบริการและความไว้วางใจจากลูกค้า. แหล่งข้อมูล เหตุการณ์นี้ได้จากการคำนวณ โดยวิเคราะห์ข้อมูล 'sla_policy_metrics' ที่เชื่อมโยงกับทิกเก็ต และใช้เวลา 'breached_at' ของเป้าหมาย SLA แต่ละรายการ. บันทึก คำนวณจากเวลา 'breached_at' ในข้อมูลตัวชี้วัด SLA ของทิกเก็ต. ประเภทเหตุการณ์ calculated
	ส่งข้อความตอบกลับสาธารณะ	หมายถึงข้อความที่เจ้าหน้าที่ฝ่ายสนับสนุนส่งถึงผู้ใช้ปลายทาง Zendesk บันทึกเหตุการณ์นี้ไว้อย่างชัดเจนทุกครั้งที่มีการเพิ่มความคิดเห็นสาธารณะในทิกเก็ต.
เหตุผลที่สำคัญ การติดตามข้อความตอบกลับสาธารณะช่วยให้เข้าใจความถี่ในการสื่อสาร และใช้ดูช่วงเวลาที่ผู้ใช้ยืนยันข้อมูลล่าช้าได้. แหล่งข้อมูล ดึงข้อมูลจากความคิดเห็นของทิกเก็ต โดยถือว่าความคิดเห็นเป็นสาธารณะเมื่อแอตทริบิวต์ 'public' มีค่าเป็น true. บันทึก ระบบบันทึกเหตุการณ์เมื่อมีการเพิ่มความคิดเห็นใหม่ที่มีค่า 'public: true' ในทิกเก็ต. ประเภทเหตุการณ์ explicit
	ให้คะแนนความพึงพอใจ	หมายถึงเวลาที่ผู้ใช้ปลายทางให้คะแนนความพึงพอใจต่อบริการสนับสนุนที่ได้รับ Zendesk บันทึกเหตุการณ์นี้ไว้อย่างชัดเจนหลังจากแก้ไขทิกเก็ตแล้ว.
เหตุผลที่สำคัญ การวิเคราะห์คะแนนความพึงพอใจช่วยให้เห็นผลการทำงานของเจ้าหน้าที่และประสิทธิผลของกระบวนการ พร้อมเชื่อมโยงตัวชี้วัดกระบวนการกับผลลัพธ์ที่ลูกค้าได้รับ. แหล่งข้อมูล ดึงข้อมูลจากคะแนนความพึงพอใจที่เชื่อมโยงกับทิกเก็ต โดยทั่วไปประกอบด้วยคะแนน ('good' หรือ 'bad') และความคิดเห็นเพิ่มเติมที่ไม่บังคับ. บันทึก ระบบบันทึกเหตุการณ์เมื่อมีการส่งคะแนนความพึงพอใจสำหรับทิกเก็ต. ประเภทเหตุการณ์ explicit

แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก Zendesk Support

ขั้นตอน

เข้าใช้ Zendesk Explore: ลงชื่อเข้าใช้ Zendesk Support ด้วยบัญชีผู้ใช้ที่มีสิทธิ์สร้างและจัดการรายงานใน Zendesk Explore.
สร้างรายงานใหม่: ไปที่โมดูล Explore คลิกไอคอน 'Reports' ในแถบนำทางด้านซ้าย แล้วคลิกปุ่ม 'New report'.
เลือกชุดข้อมูล: ในหน้าต่าง 'Choose a dataset' ให้เลือกชุดข้อมูล Support: Ticket updates [default] ซึ่งมีประวัติการตรวจสอบการเปลี่ยนแปลงของ Ticket ทุกครั้ง และจำเป็นต่อการสร้างบันทึกเหตุการณ์.
เพิ่มแอตทริบิวต์เริ่มต้น (คอลัมน์): ในเครื่องมือสร้างรายงาน ไปที่ส่วน 'Rows' คลิก 'Add' แล้วเลือกแอตทริบิวต์ต่อไปนี้เพื่อใช้เป็นคอลัมน์ในบันทึกเหตุการณ์: Ticket ID, Update - Timestamp, Ticket status, Assignee name, Ticket group, Ticket priority, Ticket channel, Changes - Field name, Changes - Previous value, Changes - New value, Comment public.
สร้างแอตทริบิวต์คำนวณ: ขั้นตอนนี้สำคัญที่สุด ไปที่เมนู 'Calculations' (ไอคอนรูปบีกเกอร์) แล้วเลือก 'Standard calculated attribute' สร้างแอตทริบิวต์ 3 รายการตามที่ระบุในส่วน 'Query' ด้านล่าง ได้แก่ ActivityName, SourceSystem และ LastDataUpdate โดยคัดลอกสูตรที่ให้ไว้ให้ตรงทุกประการ.
ปรับคอลัมน์รายงาน: เพิ่มแอตทริบิวต์คำนวณที่สร้างใหม่ (ActivityName, SourceSystem, LastDataUpdate) ในส่วน 'Rows' จากนั้นนำฟิลด์ดิบที่ใช้สร้าง ActivityName ออกได้ ได้แก่ Changes - Field name, Changes - Previous value, Changes - New value และ Comment public เพื่อให้รายงานอ่านง่ายขึ้น.
เพิ่มตัวกรองรายงาน: ไปที่ส่วน 'Filters' แล้วคลิก 'Add' เพิ่มตัวกรอง Update - Date และเลือกช่วงวันที่ที่ต้องการ เช่น 3 เดือนล่าสุด จากนั้นเพิ่มตัวกรอง ActivityName ซึ่งเป็นแอตทริบิวต์คำนวณ แล้วตัดค่าว่างออก เพื่อไม่ให้มีการอัปเดต Ticket ที่ไม่ตรงกับกิจกรรมที่ต้องการ.
เรียกใช้และตรวจสอบรายงาน: Zendesk Explore จะอัปเดตรายงานโดยอัตโนมัติเมื่อคุณเพิ่มแอตทริบิวต์และตัวกรอง ตรวจสอบตารางข้อมูลว่ามีแถวและคอลัมน์ตามที่ต้องการ โดยรายงานควรมีหนึ่งแถวต่อหนึ่งเหตุการณ์.
ส่งออกข้อมูลเป็น CSV: เมื่อจัดทำรายงานเสร็จแล้ว คลิกปุ่ม 'Export' ที่มุมขวาบน แล้วเลือก 'CSV' Zendesk จะสร้างและดาวน์โหลดไฟล์ CSV.
เตรียมไฟล์สำหรับอัปโหลด: เปิดไฟล์ CSV ที่ส่งออก แล้วเปลี่ยนชื่อหัวคอลัมน์ให้ตรงกับชื่อแอตทริบิวต์ที่เครื่องมือ process mining ต้องใช้ เช่น เปลี่ยน 'Ticket ID' เป็น TicketId และ 'Update - Timestamp' เป็น EventTimestamp ตรวจสอบว่ารูปแบบวันที่และเวลาตรงตาม ISO 8601 จากนั้นไฟล์ก็พร้อมอัปโหลด.

การกำหนดค่า

ชุดข้อมูล Zendesk: ต้องสร้างรายงานจากชุดข้อมูล Support: Ticket updates [default] ซึ่งเป็นชุดข้อมูลมาตรฐานชุดเดียวที่มีประวัติการตรวจสอบโดยละเอียดสำหรับสร้างลำดับเหตุการณ์ของกระบวนการ.
กรองช่วงวันที่: ควรกรองวันที่เพื่อจำกัดปริมาณข้อมูล โดยใช้แอตทริบิวต์ Update - Date เป็นตัวกรองหลัก สำหรับการวิเคราะห์เบื้องต้น แนะนำให้ใช้ข้อมูลย้อนหลัง 3-6 เดือน.
ตัวกรองกิจกรรม: หลังสร้างแอตทริบิวต์คำนวณ ActivityName แล้ว ให้กรองรายงานเพื่อตัดแถวที่มีค่าว่างออก วิธีนี้จะนำการเปลี่ยนแปลง Ticket ที่ไม่เกี่ยวข้อง เช่น การอัปเดตจากระบบหรือการเปลี่ยนแท็ก ออกจากบันทึกเหตุการณ์.
แอตทริบิวต์คำนวณ: การดึงข้อมูลนี้อาศัยแอตทริบิวต์คำนวณมาตรฐานเป็นหลัก เพื่อแปลงการเปลี่ยนแปลงฟิลด์ Ticket ดิบให้เป็นชื่อกิจกรรมที่อ่านเข้าใจได้ สูตรจึงต้องถูกต้องแม่นยำ.
ข้อกำหนดเบื้องต้น: ผู้เรียกใช้รายงานต้องมีบทบาท 'Viewer' ใน Zendesk Explore เป็นอย่างน้อย หากต้องการสร้างและบันทึกรายงาน ต้องมีสิทธิ์ 'Editor' หรือ 'Admin'.

ตัวอย่างคำค้น config

This extraction is configured using the Zendesk Explore UI. The core logic is contained within a standard calculated attribute. 

**1. Dataset Selection:**
* `Support: Ticket updates [default]`

**2. Report Columns (Add to 'Rows' panel):**
* `Ticket ID`
* `ActivityName` (Calculated Attribute)
* `EventTimestamp` (Use the `Update - Timestamp` attribute)
* `SourceSystem` (Calculated Attribute)
* `LastDataUpdate` (Calculated Attribute)
* `Ticket status`
* `Assignee name`
* `Ticket group`
* `Ticket priority`
* `Ticket channel`
* `SLA metric status`
* `EventEndTime` (Use the `Update - Timestamp` attribute again)

**3. Standard Calculated Attribute Formulas:**

**Attribute Name:** `ActivityName`
**Formula:**
```
IF ([Changes - Field name] = "status" AND [Changes - Previous value] = NULL AND [Changes - New value] = "new") THEN "Incident Created"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "open") THEN "Status Changed to Open"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "pending") THEN "Status Changed to Pending"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "solved") THEN "Incident Resolved"
ELIF ([Changes - Field name] = "status" AND [Changes - New value] = "closed") THEN "Incident Closed"
ELIF ([Changes - Field name] = "group_id") THEN "Ticket Assigned to Group"
ELIF ([Changes - Field name] = "assignee_id") THEN "Ticket Assigned to Agent"
ELIF ([Changes - Field name] = "priority") THEN "Priority Set"
ELIF ([Changes - Field name] = "satisfaction_score") THEN "User Satisfaction Rated"
ELIF ([Changes - Field name] = "SLA metric breach") THEN "SLA Target Breached"
ELIF ([Comment public] = TRUE) THEN "Public Reply Sent"
ELIF ([Comment public] = FALSE) THEN "Internal Note Added"
ELSE NULL
ENDIF
```

**Attribute Name:** `SourceSystem`
**Formula:**
```
"Zendesk Support"
```

**Attribute Name:** `LastDataUpdate`
**Formula:**
```
NOW()
```

ขั้นตอน

ข้อกำหนดเบื้องต้น: ติดตั้ง Python 3.6 ขึ้นไป พร้อมไลบรารี requests และ pandas โดยติดตั้งผ่าน pip ได้ด้วยคำสั่ง: pip install requests pandas.
สร้าง Zendesk API Token: ลงชื่อเข้าใช้ Zendesk Support ในฐานะผู้ดูแลระบบ ไปที่ Admin Center > Apps and integrations > APIs > Zendesk APIs ในส่วน "API Tokens" ให้เพิ่ม API token ที่เปิดใช้งานใหม่ แล้วบันทึกสตริง token ที่สร้างขึ้นไว้ในที่ปลอดภัย.
ตั้งค่าสคริปต์ Python: สร้างไฟล์ Python ใหม่ เช่น extract_zendesk_logs.py แล้วคัดลอกสคริปต์ที่ให้ไว้ลงในไฟล์ แก้ค่าตัวแปรตัวอย่างด้านบนของสคริปต์ ได้แก่ ZENDESK_SUBDOMAIN, ZENDESK_EMAIL และ ZENDESK_API_TOKEN ให้เป็นข้อมูลรับรองของคุณ กำหนด START_TIMESTAMP เพื่อระบุจุดเริ่มต้นของช่วงเวลาที่ต้องการดึงข้อมูล โดยใช้ Unix epoch timestamp.
ทำความเข้าใจ API endpoints: สคริปต์ใช้ Zendesk API endpoints หลัก 2 รายการ โดย incremental/tickets/cursor.json ใช้ดึง Ticket ทั้งหมดที่อัปเดตหลัง START_TIMESTAMP อย่างมีประสิทธิภาพ จากนั้นสคริปต์จะเรียก tickets/{ticket_id}/audits.json สำหรับแต่ละ Ticket เพื่อดึงประวัติการเปลี่ยนแปลงและเหตุการณ์โดยละเอียด.
เรียกใช้สคริปต์: เรียกใช้สคริปต์จากเทอร์มินัลด้วยคำสั่ง python extract_zendesk_logs.py สคริปต์จะเริ่มดึงข้อมูลจาก Zendesk API.
ติดตามความคืบหน้าของสคริปต์: สคริปต์จะแสดงจำนวน Ticket ที่ประมวลผลแล้วในคอนโซล คุณจึงติดตามความคืบหน้าได้ ระยะเวลาที่ใช้ขึ้นอยู่กับช่วงวันที่และจำนวน Ticket ซึ่งอาจใช้เวลานาน.
ดึงข้อมูลและแบ่งหน้า: สคริปต์จัดการการแบ่งหน้าของ API โดยอัตโนมัติ เริ่มจาก URL สำหรับส่งออก Ticket แล้วเรียกใช้ after_url ที่ได้รับจากการตอบกลับของ API แต่ละครั้ง จนกว่าจะดึง Ticket ในช่วงเวลานั้นครบทั้งหมด.
แปลงเหตุการณ์: สคริปต์จะไล่ดูประวัติการตรวจสอบของ Ticket แต่ละรายการ แยกวิเคราะห์เหตุการณ์ แล้วแปลงประเภทเหตุการณ์ภายในของ Zendesk เช่น Create, Change และ Comment ให้เป็นกิจกรรมทางธุรกิจที่ต้องการ เช่น Incident Created, Status Changed to Open และ Public Reply Sent.
จัดการข้อมูล SLA: สคริปต์มีฟังก์ชันเฉพาะชื่อ get_sla_breach_events เพื่อดึงตัวชี้วัด SLA ของ Ticket ที่แก้ไขแล้ว เนื่องจากการละเมิด SLA ไม่ใช่เหตุการณ์มาตรฐานในบันทึกการตรวจสอบ ฟังก์ชันนี้จะเรียก API เพิ่มเติมเพื่อดึงรายละเอียดการใช้ SLA policy.
สร้างบันทึกเหตุการณ์: เมื่อประมวลผล Ticket ทั้งหมดแล้ว สคริปต์จะรวบรวมเหตุการณ์ที่ดึงมาไว้ใน pandas DataFrame และบันทึกบันทึกเหตุการณ์ฉบับสุดท้ายเป็นไฟล์ CSV ชื่อ zendesk_incident_event_log.csv ในไดเรกทอรีเดียวกับที่เรียกใช้สคริปต์.
เตรียมไฟล์สำหรับอัปโหลด: ตรวจสอบความถูกต้องของไฟล์ CSV ที่สร้างขึ้น ไฟล์นี้อยู่ในรูปแบบที่พร้อมอัปโหลดเข้า ProcessMind เพื่อวิเคราะห์.

การกำหนดค่า

ข้อมูลรับรอง Zendesk API: ต้องระบุ subdomain ของ Zendesk อีเมลที่เชื่อมโยงกับบัญชีผู้ดูแลระบบหรือเจ้าหน้าที่ และ API token ที่ใช้งานได้ เก็บข้อมูลเหล่านี้อย่างปลอดภัย และอย่าฝังไว้ในสคริปต์ที่ควบคุมเวอร์ชันเมื่อนำไปใช้จริง.
เวลาเริ่มต้น (START_TIMESTAMP): ค่าจำนวนเต็มนี้กำหนดจุดเริ่มต้นของการดึงข้อมูล และต้องเป็น Unix epoch timestamp แนะนำให้เริ่มย้อนหลัง 3-6 เดือน เพื่อให้ได้ข้อมูลเพียงพอโดยไม่ทำให้ระบบรับภาระมากเกินไป คุณใช้เครื่องมือแปลงเวลาออนไลน์เพื่อหาค่า timestamp ที่ถูกต้องของวันที่ต้องการได้.
การจำกัดอัตราการเรียก API: สคริปต์เรียก API หลายครั้ง Zendesk กำหนดขีดจำกัดการเรียกใช้ซึ่งแตกต่างกันตามแพ็กเกจ แม้สคริปต์จะใช้ได้กับข้อมูลปริมาณปานกลาง แต่หากมีข้อมูลจำนวนมาก อาจต้องเพิ่มคำสั่ง time.sleep() ในลูป เพื่อไม่ให้เกินขีดจำกัดและได้รับข้อผิดพลาด 429.
ไลบรารี Python ที่ต้องใช้: สคริปต์ใช้ไลบรารี requests สำหรับเรียก API และ pandas สำหรับจัดการข้อมูลและส่งออก CSV ตรวจสอบว่าติดตั้งไลบรารีเหล่านี้ในสภาพแวดล้อม Python แล้ว.
สิทธิ์ผู้ใช้: บัญชีผู้ใช้ที่เชื่อมโยงกับ API token ต้องมีสิทธิ์เพียงพอในการอ่านข้อมูล Ticket รวมถึงประวัติการตรวจสอบและตัวชี้วัดของ Ticket.

ตัวอย่างคำค้น python

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

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Zendesk details
ZENDESK_SUBDOMAIN = class="hl-string">"[your_subdomain]"
ZENDESK_EMAIL = class="hl-string">"[your_login_email@example.com]"
ZENDESK_API_TOKEN = class="hl-string">"[your_zendesk_api_token]"

class=class="hl-string">"hl-comment"># Set the start time for the incremental export (Unix epoch timestamp)
class=class="hl-string">"hl-comment"># Example: 1672531200 is for January 1, 2023 00:00:00 UTC
class=class="hl-string">"hl-comment"># It's recommended to extract the last 3-6 months of data.
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", ZENDESK_API_TOKEN)
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_sla_breach_events(ticket_id, session):
    class="hl-string">"""Fetches SLA metrics for a ticket and creates breach events."""
    sla_events = []
    try:
        metrics_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/metrics.json"
        response = session.get(metrics_url)
        response.raise_for_status()
        metrics = response.json().get(class="hl-string">'ticket_metric', {})
        
        if metrics and metrics.get(class="hl-string">'sla_policy'):
            for sla in metrics.get(class="hl-string">'sla_policy').get(class="hl-string">'policy_metrics', []):
                if sla.get(class="hl-string">'breach_at'):
                    breach_timestamp = sla[class="hl-string">'breach_at']
                    sla_events.append({
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Target Breached',
                        class="hl-string">'EventTimestamp': breach_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': class="hl-string">'breached',
                        class="hl-string">'Assignee': metrics.get(class="hl-string">'assignee_updated_at'), 
                        class="hl-string">'AssignedGroup': metrics.get(class="hl-string">'group_stations'),
                        class="hl-string">'TicketPriority': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'Channel': None, class=class="hl-string">"hl-comment"># Not directly available in metrics
                        class="hl-string">'SlaStatus': fclass="hl-string">"{sla.get('metric')} Breached",
                        class="hl-string">'EventEndTime': breach_timestamp
                    })
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not fetch SLA metrics for ticket {ticket_id}: {e}")
    return sla_events

def process_ticket(ticket, session):
    class="hl-string">"""Processes a single ticket's audits to extract all relevant events."""
    all_events = []
    ticket_id = ticket[class="hl-string">'id']
    ticket_created_at = ticket[class="hl-string">'created_at']
    
    class=class="hl-string">"hl-comment"># 1. Incident Created event
    all_events.append({
        class="hl-string">'TicketId': ticket_id,
        class="hl-string">'ActivityName': class="hl-string">'Incident Created',
        class="hl-string">'EventTimestamp': ticket_created_at,
        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
        class="hl-string">'TicketStatus': class="hl-string">'new',
        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
        class="hl-string">'SlaStatus': None,
        class="hl-string">'EventEndTime': ticket_created_at
    })
    
    class=class="hl-string">"hl-comment"># Process audits for other events
    audits_url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    try:
        response = session.get(audits_url)
        response.raise_for_status()
        audits = response.json().get(class="hl-string">'audits', [])
        
        is_first_group_assignment = True
        is_first_agent_assignment = True

        for audit in audits:
            event_timestamp = audit[class="hl-string">'created_at']
            for event in audit.get(class="hl-string">'events', []):
                activity = {}
                event_type = event.get(class="hl-string">'type')

                if event_type == class="hl-string">'Change':
                    field_name = event.get(class="hl-string">'field_name')
                    value = event.get(class="hl-string">'value')
                    
                    if field_name == class="hl-string">'group_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Group' if is_first_group_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_group_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'AssignedGroup': value}

                    elif field_name == class="hl-string">'assignee_id' and value is not None:
                        activity_name = class="hl-string">'Ticket Assigned to Agent' if is_first_agent_assignment else class="hl-string">'Ticket Reassigned'
                        is_first_agent_assignment = False
                        activity = {class="hl-string">'ActivityName': activity_name, class="hl-string">'Assignee': value}
                        
                    elif field_name == class="hl-string">'priority':
                        activity = {class="hl-string">'ActivityName': class="hl-string">'Priority Set', class="hl-string">'TicketPriority': value}
                        
                    elif field_name == class="hl-string">'status':
                        if value == class="hl-string">'open': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Open', class="hl-string">'TicketStatus': class="hl-string">'open'}
                        elif value == class="hl-string">'pending': activity = {class="hl-string">'ActivityName': class="hl-string">'Status Changed to Pending', class="hl-string">'TicketStatus': class="hl-string">'pending'}
                        elif value == class="hl-string">'solved': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'TicketStatus': class="hl-string">'solved'}
                        elif value == class="hl-string">'closed': activity = {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'TicketStatus': class="hl-string">'closed'}
                        
                elif event_type == class="hl-string">'Comment':
                    is_public = event.get(class="hl-string">'public', False)
                    activity_name = class="hl-string">'Public Reply Sent' if is_public else class="hl-string">'Internal Note Added'
                    activity = {class="hl-string">'ActivityName': activity_name}

                elif event_type == class="hl-string">'SatisfactionRating':
                    activity = {class="hl-string">'ActivityName': class="hl-string">'User Satisfaction Rated'}

                if activity:
                    base_event = {
                        class="hl-string">'TicketId': ticket_id,
                        class="hl-string">'EventTimestamp': event_timestamp,
                        class="hl-string">'SourceSystem': SOURCE_SYSTEM,
                        class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
                        class="hl-string">'TicketStatus': ticket.get(class="hl-string">'status'),
                        class="hl-string">'Assignee': ticket.get(class="hl-string">'assignee_id'),
                        class="hl-string">'AssignedGroup': ticket.get(class="hl-string">'group_id'),
                        class="hl-string">'TicketPriority': ticket.get(class="hl-string">'priority'),
                        class="hl-string">'Channel': ticket.get(class="hl-string">'via', {}).get(class="hl-string">'channel'),
                        class="hl-string">'SlaStatus': None,
                        class="hl-string">'EventEndTime': event_timestamp
                    }
                    base_event.update(activity)
                    all_events.append(base_event)
    
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Could not process audits for ticket {ticket_id}: {e}")

    class=class="hl-string">"hl-comment"># Get SLA Breach events if ticket is solved
    if ticket.get(class="hl-string">'status') in [class="hl-string">'solved', class="hl-string">'closed']:
        all_events.extend(get_sla_breach_events(ticket_id, session))

    return all_events

def main():
    class="hl-string">"""Main function to fetch tickets and generate the event log."""
    all_ticket_events = []
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json?start_time={START_TIMESTAMP}"
    
    with requests.Session() as session:
        session.auth = AUTH
        
        ticket_count = 0
        while url:
            try:
                response = session.get(url)
                response.raise_for_status()
                data = response.json()
                tickets = data.get(class="hl-string">'tickets', [])
                
                for ticket in tickets:
                    ticket_count += 1
                    all_ticket_events.extend(process_ticket(ticket, session))
                    if ticket_count % 100 == 0:
                        print(fclass="hl-string">"Processed {ticket_count} tickets...")

                if data.get(class="hl-string">'end_of_stream', True):
                    print(class="hl-string">"Reached the end of the ticket stream.")
                    break
                
                url = data.get(class="hl-string">'after_url')
                class=class="hl-string">"hl-comment"># Respect rate limits
                time.sleep(1) 

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"An API error occurred: {e}")
                if hasattr(e, class="hl-string">'response') and e.response.status_code == 429:
                    retry_after = int(e.response.headers.get(class="hl-string">'Retry-After', 60))
                    print(fclass="hl-string">"Rate limit exceeded. Retrying after {retry_after} seconds...")
                    time.sleep(retry_after)
                else:
                    break

    if not all_ticket_events:
        print(class="hl-string">"No events were extracted. Check configuration and API access.")
        return

    print(fclass="hl-string">"\nTotal events extracted: {len(all_ticket_events)}")
    df = pd.DataFrame(all_ticket_events)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    cols = [
        class="hl-string">'TicketId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventEndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'TicketStatus', class="hl-string">'Assignee', class="hl-string">'AssignedGroup', class="hl-string">'TicketPriority', class="hl-string">'Channel', class="hl-string">'SlaStatus'
    ]
    df = df[cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    output_file = class="hl-string">'zendesk_incident_event_log.csv'
    df.to_csv(output_file, index=False)
    print(fclass="hl-string">"Event log successfully saved to {output_file}")

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

ขั้นตอน

สร้างไคลเอนต์ Zendesk API ที่มีสิทธิ์อ่านทิกเก็ต ประวัติการตรวจสอบทิกเก็ต ผู้ใช้ กลุ่ม คะแนนความพึงพอใจ และการส่งออกข้อมูลแบบเพิ่ม ใช้ API token หรือข้อมูลรับรอง OAuth ที่กำหนดค่าสำหรับ Zendesk Support ของคุณ จัดเก็บโดเมนย่อย ข้อมูลรับรอง และจุดบันทึกความคืบหน้าการดึงข้อมูลเป็นค่าการกำหนดค่าที่ปลอดภัย
ใช้ Zendesk Incremental Ticket Export API เพื่อดึงทิกเก็ตที่มีการอัปเดตหลังจุดบันทึกความคืบหน้าครั้งล่าสุดที่สำเร็จ สคริปต์ด้านล่างใช้รูปแบบจุดเชื่อมต่อที่ระบุไว้ในเอกสาร https://[Your Zendesk subdomain].zendesk.com/api/v2/incremental/tickets/cursor.json และดึงข้อมูลต่อเนื่องตามเคอร์เซอร์จนกว่า API จะแจ้งว่าดึงข้อมูลครบแล้ว
สำหรับทิกเก็ตแต่ละรายการที่ได้รับ ให้เรียกดูประวัติการตรวจสอบจากจุดเชื่อมต่อ ticket audits ต้องใช้ระเบียนการตรวจสอบ เพราะ ProcessMind อ่านบันทึกเหตุการณ์ตามข้อมูลที่มี และไม่ได้อนุมานกิจกรรมจากสถานะสุดท้ายของทิกเก็ต เก็บเวลาประทับ ผู้ดำเนินการ รหัสทิกเก็ต และเหตุการณ์จากการตรวจสอบไว้
แปลงเหตุการณ์จากการตรวจสอบให้เป็นแถวเหตุการณ์อย่างชัดเจน ดึงข้อมูลการสร้างทิกเก็ต การกำหนดกลุ่ม การมอบหมายเจ้าหน้าที่ การเปลี่ยนระดับความสำคัญ การเปลี่ยนสถานะเป็นเปิด การตอบกลับสาธารณะ บันทึกภายใน การมอบหมายใหม่ การเปลี่ยนสถานะเป็นรอดำเนินการ สถานะแก้ไขแล้ว และสถานะปิด ดึงคะแนนความพึงพอใจเป็นแถวแยกเมื่อมีข้อมูล คำนวณการผิด SLA เฉพาะเมื่อมีเป้าหมาย SLA และเวลาประทับเหตุการณ์ที่จำเป็น พร้อมบันทึกข้อมูลที่ใช้คำนวณ
เก็บเวลาหรือเคอร์เซอร์ของการอัปเดตล่าสุดที่ประมวลผลสำเร็จ อย่าเลื่อนจุดบันทึกความคืบหน้าจนกว่าจะเขียนข้อมูลครบทุกหน้า ประวัติการตรวจสอบทิกเก็ต และข้อมูลความพึงพอใจที่เลือกใช้เรียบร้อยแล้ว สำหรับการดึงข้อมูลครั้งแรก ให้กำหนดเวลาเริ่มต้นที่มีขอบเขต เช่น [วันที่เริ่มต้นในรูปแบบ ISO 8601] โดยทั่วไปครอบคลุมข้อมูลย้อนหลัง 3 ถึง 6 เดือน
ระบุคอลัมน์ที่จำเป็น TicketId, ActivityName, EventTimestamp, SourceSystem และ LastDataUpdate ระบุคอลัมน์ที่แนะนำ ได้แก่ TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus และ EventEndTime เมื่อข้อมูลต้นทางรองรับ เว้นค่าไว้เฉพาะเมื่อ Zendesk ไม่มีแอตทริบิวต์นั้นสำหรับเหตุการณ์
ลบข้อมูลซ้ำโดยใช้ TicketId, ActivityName, EventTimestamp และรหัสเหตุการณ์ต้นทางที่คงที่เมื่อมี เก็บเหตุการณ์เดียวกันที่เกิดขึ้นหลายครั้งตามจริงไว้ เช่น การตอบกลับสาธารณะ บันทึกภายใน การมอบหมาย หรือการเปลี่ยนสถานะหลายครั้ง
บันทึกแถวผลลัพธ์เป็น CSV หรือรูปแบบบันทึกเหตุการณ์อื่นที่ ProcessMind รองรับ ตรวจสอบให้เวลาประทับเป็น ISO 8601 พร้อมระบุ UTC offset ให้ TicketId ใช้ชนิดข้อมูลเดียวกัน ค่า ActivityName ตรงกับชื่อกิจกรรมที่กำหนดไว้ทุกประการ และ LastDataUpdate มีค่าเดียวกันในทุกแถวของชุดข้อมูลที่ดึงมาในรอบเดียวกัน
อัปโหลดบันทึกเหตุการณ์ไปยัง ProcessMind และกำหนด Incident ID เป็นรหัสเคส Activity เป็นคอลัมน์กิจกรรม และ Event Timestamp เป็นคอลัมน์เวลาเหตุการณ์ ตรวจสอบว่ามีกิจกรรมที่จำเป็นครบในรูปแบบแถวข้อมูลที่ระบุชัดเจน ไม่ใช่กิจกรรมที่สร้างขึ้นระหว่างการแสดงผล

การกำหนดค่า

วิธีเรียก API: ใช้ Zendesk Incremental Ticket Export API พร้อมการแบ่งหน้าด้วย cursor ใช้ endpoint ของ ticket audit เพื่อดึงข้อมูลระดับเหตุการณ์ และใช้ endpoint คะแนนความพึงพอใจเมื่อเปิดใช้คะแนนดังกล่าวและมีสิทธิ์เข้าถึง.
การตั้งค่าที่ต้องใช้: subdomain ของ Zendesk, การยืนยันตัวตน API, วันที่เริ่มต้น, จุดบันทึกความคืบหน้าการดึงข้อมูล, request timeout, นโยบายการลองใหม่ และตำแหน่งจัดเก็บผลลัพธ์ แทนที่ [Your Zendesk subdomain], [Your API email] และ [Your API token] ด้วยค่าที่ปลอดภัยสำหรับระบบใช้งานจริง.
ช่วงวันที่: สำหรับการโหลดครั้งแรก ให้ใช้ข้อมูลย้อนหลัง 3-6 เดือน เว้นแต่ต้องใช้ประวัตินานกว่านั้น สำหรับการโหลดครั้งถัดไป ให้ดึงข้อมูลหลังจุดบันทึกความคืบหน้าครั้งล่าสุดที่สำเร็จ และเผื่อช่วงเวลาซ้อนทับเล็กน้อยเพื่อรองรับข้อมูลที่มาถึงล่าช้า จากนั้นจึงลบข้อมูลซ้ำ.
ตัวกรอง: กรองบริษัท แบรนด์ กลุ่ม องค์กร แบบฟอร์ม Ticket ช่องทาง หรือฟิลด์กำหนดเอง เฉพาะเมื่อขอบเขตกระบวนการกำหนดไว้อย่างชัดเจน Zendesk Support ไม่มีตัวกรอง Company Code หรือ Document Type แบบ SAP เว้นแต่จะตั้งค่าฟิลด์ที่ใช้แทนแนวคิดเหล่านี้ไว้ใน Zendesk.
ความหมายของเหตุการณ์: ให้ถือว่าเหตุการณ์จากการตรวจสอบเป็นข้อมูลอ้างอิงสำหรับการเปลี่ยนแปลงที่เกิดขึ้นจริง อย่าสร้างเหตุการณ์เปลี่ยนสถานะเพียงเพราะ Ticket มีสถานะปัจจุบัน ต้องสร้างเหตุการณ์สถานะจากเหตุการณ์ในประวัติการตรวจสอบหรือแหล่งเหตุการณ์อื่นที่มีเอกสารอ้างอิง.
การตั้งค่า SLA: การระบุว่าเกินเป้าหมาย SLA ต้องเข้าถึง SLA policy ที่เกี่ยวข้อง ระยะเวลาเป้าหมาย ปฏิทินเวลาทำการ และ timestamp ที่ใช้ประเมินเป้าหมาย หาก Zendesk แสดงเหตุการณ์หรือเมตริกการละเมิด ให้ใช้ข้อมูลนั้น มิฉะนั้นให้คำนวณเฉพาะเมื่อมีข้อมูล policy ที่ระบุไว้ชัดเจน และเก็บหลักเกณฑ์การคำนวณไว้.
การตั้งค่าความพึงพอใจ: กิจกรรม User Satisfaction Rated ต้องเปิดใช้คะแนนความพึงพอใจและเข้าถึงข้อมูลคะแนนผ่าน API ได้ Ticket ที่แก้ไขแล้วแต่ไม่มีคะแนนต้องไม่สร้างเหตุการณ์คะแนนขึ้นมาเอง.
ประสิทธิภาพ: ใช้การแบ่งหน้าด้วย cursor จำกัดจำนวนคำขอประวัติการตรวจสอบ Ticket ที่ทำพร้อมกัน ใช้การเชื่อมต่อซ้ำ ใช้ exponential backoff เมื่อถูกจำกัดอัตราเรียก และบันทึกจุดตรวจหลังประมวลผลแต่ละชุดสำเร็จ อย่าดึงประวัติการตรวจสอบของ Ticket ทั้งหมดซ้ำทุกครั้งที่เรียกใช้.
ความครบถ้วน: Incremental exports อาจมี Ticket ที่อัปเดตหลังเวลาที่ร้องขอ แต่ต้องจัดการการดึงประวัติการตรวจสอบและข้อมูลที่มาถึงล่าช้าแยกต่างหาก ใช้ช่วงเวลาซ้อนทับและคีย์สำหรับลบข้อมูลซ้ำที่คงที่.
ข้อกำหนดเบื้องต้น: ต้องเข้าถึง API และมีสิทธิ์อ่าน Ticket กับประวัติการตรวจสอบ รวมถึงเข้าถึงผู้ใช้และกลุ่มเพื่อแสดงชื่อ หากต้องใช้ข้อมูลความพึงพอใจหรือคำนวณการละเมิด SLA ก็ต้องเข้าถึงข้อมูลเหล่านั้นด้วย ประเภทเหตุการณ์ในประวัติการตรวจสอบที่มีให้ใช้อาจแตกต่างกันตามการตั้งค่าและแพ็กเกจ Zendesk.

ตัวอย่างคำค้น python

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

import requests

ZENDESK_SUBDOMAIN = os.getenv(class="hl-string">"ZENDESK_SUBDOMAIN", class="hl-string">"[Your Zendesk subdomain]")
API_EMAIL = os.getenv(class="hl-string">"ZENDESK_API_EMAIL", class="hl-string">"[Your API email]")
API_TOKEN = os.getenv(class="hl-string">"ZENDESK_API_TOKEN", class="hl-string">"[Your API token]")
START_DATE = os.getenv(class="hl-string">"START_DATE", class="hl-string">"[Start date in ISO 8601 format]")
OUTPUT_FILE = os.getenv(class="hl-string">"OUTPUT_FILE", class="hl-string">"incident_event_log.csv")
SOURCE_SYSTEM = class="hl-string">"Zendesk Support"
LAST_DATA_UPDATE = datetime.now(timezone.utc).isoformat()

if class="hl-string">"[" in ZENDESK_SUBDOMAIN or class="hl-string">"[" in API_EMAIL or class="hl-string">"[" in API_TOKEN or class="hl-string">"[" in START_DATE:
    raise ValueError(class="hl-string">"Set ZENDESK_SUBDOMAIN, ZENDESK_API_EMAIL, ZENDESK_API_TOKEN, and START_DATE before running")

BASE_URL = fclass="hl-string">"https://{ZENDESK_SUBDOMAIN}.zendesk.com/api/v2"
SESSION = requests.Session()
SESSION.auth = (fclass="hl-string">"{API_EMAIL}/token", API_TOKEN)
SESSION.headers.update({class="hl-string">"Accept": class="hl-string">"application/json"})

FIELDS = [
    class="hl-string">"TicketId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"SourceSystem", class="hl-string">"LastDataUpdate",
    class="hl-string">"TicketStatus", class="hl-string">"Assignee", class="hl-string">"AssignedGroup", class="hl-string">"TicketPriority", class="hl-string">"Channel",
    class="hl-string">"SlaStatus", class="hl-string">"EventEndTime"
]


def parse_time(value: Optional[str]) -> Optional[datetime]:
    if not value:
        return None
    return datetime.fromisoformat(value.replace(class="hl-string">"Z", class="hl-string">"+00:00"))


def iso(value: Any) -> str:
    if isinstance(value, datetime):
        return value.astimezone(timezone.utc).isoformat()
    if value is None:
        return class="hl-string">""
    return str(value)


def get_json(url: str, params: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
    for attempt in range(6):
        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, 2 ** attempt))
            continue
        response.raise_for_status()
        return response.json()
    raise RuntimeError(fclass="hl-string">"Request failed after retries: {url}")


def incremental_tickets(start_time: str) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/incremental/tickets/cursor.json"
    params: Optional[Dict[str, Any]] = {class="hl-string">"start_time": int(parse_time(start_time).timestamp())}
    while url:
        payload = get_json(url, params)
        for ticket in payload.get(class="hl-string">"tickets", []):
            yield ticket
        if payload.get(class="hl-string">"end_of_stream"):
            break
        url = payload.get(class="hl-string">"after_url")
        params = None


def ticket_audits(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/audits.json"
    while url:
        payload = get_json(url)
        for audit in payload.get(class="hl-string">"audits", []):
            yield audit
        url = payload.get(class="hl-string">"next_page")


def satisfaction_for_ticket(ticket_id: int) -> Iterable[Dict[str, Any]]:
    url = fclass="hl-string">"{BASE_URL}/tickets/{ticket_id}/satisfaction_ratings.json"
    try:
        payload = get_json(url)
    except requests.HTTPError as error:
        if error.response is not None and error.response.status_code in (403, 404):
            return
        raise
    for rating in payload.get(class="hl-string">"satisfaction_ratings", []):
        yield rating


def user_name(user_id: Any, cache: Dict[str, str]) -> str:
    if not user_id:
        return class="hl-string">""
    key = str(user_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/users/{user_id}.json")
        user = payload.get(class="hl-string">"user", {})
        cache[key] = user.get(class="hl-string">"name") or user.get(class="hl-string">"email") or key
    return cache[key]


def group_name(group_id: Any, cache: Dict[str, str]) -> str:
    if not group_id:
        return class="hl-string">""
    key = str(group_id)
    if key not in cache:
        payload = get_json(fclass="hl-string">"{BASE_URL}/groups/{group_id}.json")
        cache[key] = payload.get(class="hl-string">"group", {}).get(class="hl-string">"name") or key
    return cache[key]


def ticket_context(ticket: Dict[str, Any], users: Dict[str, str], groups: Dict[str, str]) -> Dict[str, str]:
    assignee = user_name(ticket.get(class="hl-string">"assignee_id"), users)
    group = group_name(ticket.get(class="hl-string">"group_id"), groups)
    return {
        class="hl-string">"TicketStatus": str(ticket.get(class="hl-string">"status") or class="hl-string">""),
        class="hl-string">"Assignee": assignee,
        class="hl-string">"AssignedGroup": group,
        class="hl-string">"TicketPriority": str(ticket.get(class="hl-string">"priority") or class="hl-string">""),
        class="hl-string">"Channel": str((ticket.get(class="hl-string">"via") or {}).get(class="hl-string">"channel") or class="hl-string">""),
        class="hl-string">"SlaStatus": class="hl-string">"",
    }


def make_row(ticket_id: Any, activity: str, event_time: Any, context: Dict[str, str], end_time: Any = class="hl-string">"") -> Dict[str, str]:
    row = {
        class="hl-string">"TicketId": str(ticket_id),
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": iso(event_time),
        class="hl-string">"SourceSystem": SOURCE_SYSTEM,
        class="hl-string">"LastDataUpdate": LAST_DATA_UPDATE,
        class="hl-string">"TicketStatus": context.get(class="hl-string">"TicketStatus", class="hl-string">""),
        class="hl-string">"Assignee": context.get(class="hl-string">"Assignee", class="hl-string">""),
        class="hl-string">"AssignedGroup": context.get(class="hl-string">"AssignedGroup", class="hl-string">""),
        class="hl-string">"TicketPriority": context.get(class="hl-string">"TicketPriority", class="hl-string">""),
        class="hl-string">"Channel": context.get(class="hl-string">"Channel", class="hl-string">""),
        class="hl-string">"SlaStatus": context.get(class="hl-string">"SlaStatus", class="hl-string">""),
        class="hl-string">"EventEndTime": iso(end_time),
    }
    return row


def audit_value(audit_event: Dict[str, Any], field: str) -> Any:
    for change in audit_event.get(class="hl-string">"changes", []):
        if change.get(class="hl-string">"field") == field:
            return change
    return None


def append_audit_rows(ticket: Dict[str, Any], audit: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    ticket_id = ticket.get(class="hl-string">"id")
    event_time = audit.get(class="hl-string">"created_at")
    context = ticket_context(ticket, users, groups)
    author = user_name(audit.get(class="hl-string">"author_id"), users)
    for change in audit.get(class="hl-string">"events", []):
        event_type = change.get(class="hl-string">"type")
        field = change.get(class="hl-string">"field")
        value = change.get(class="hl-string">"value")
        previous = change.get(class="hl-string">"previous_value")
        if event_type == class="hl-string">"Create" or field == class="hl-string">"created_at":
            rows.append(make_row(ticket_id, class="hl-string">"Incident Created", event_time, context))
        if field == class="hl-string">"group_id" and value is not None:
            context[class="hl-string">"AssignedGroup"] = group_name(value, groups)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Group", event_time, context))
        if field == class="hl-string">"assignee_id" and value is not None:
            context[class="hl-string">"Assignee"] = user_name(value, users)
            if previous not in (None, class="hl-string">"", value):
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Reassigned", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Ticket Assigned to Agent", event_time, context))
        if field == class="hl-string">"priority" and value is not None:
            context[class="hl-string">"TicketPriority"] = str(value)
            rows.append(make_row(ticket_id, class="hl-string">"Priority Set", event_time, context))
        if field == class="hl-string">"status":
            context[class="hl-string">"TicketStatus"] = str(value or class="hl-string">"")
            if value == class="hl-string">"open":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Open", event_time, context))
            if value == class="hl-string">"pending":
                rows.append(make_row(ticket_id, class="hl-string">"Status Changed to Pending", event_time, context))
            if value == class="hl-string">"solved":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Resolved", event_time, context))
            if value == class="hl-string">"closed":
                rows.append(make_row(ticket_id, class="hl-string">"Incident Closed", event_time, context))
        if event_type == class="hl-string">"Comment":
            if bool(change.get(class="hl-string">"public")):
                rows.append(make_row(ticket_id, class="hl-string">"Public Reply Sent", event_time, context))
            else:
                rows.append(make_row(ticket_id, class="hl-string">"Internal Note Added", event_time, context))


def append_satisfaction_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    for rating in satisfaction_for_ticket(ticket.get(class="hl-string">"id")):
        rated_at = rating.get(class="hl-string">"created_at") or rating.get(class="hl-string">"updated_at")
        if rated_at:
            rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"User Satisfaction Rated", rated_at, context))


def append_sla_breach_rows(ticket: Dict[str, Any], rows: List[Dict[str, str]], users: Dict[str, str], groups: Dict[str, str]) -> None:
    context = ticket_context(ticket, users, groups)
    sla_breach_time = ticket.get(class="hl-string">"sla_breach_at")
    if sla_breach_time:
        context[class="hl-string">"SlaStatus"] = class="hl-string">"Breached"
        rows.append(make_row(ticket.get(class="hl-string">"id"), class="hl-string">"SLA Target Breached", sla_breach_time, context))


def extract() -> List[Dict[str, str]]:
    rows: List[Dict[str, str]] = []
    users: Dict[str, str] = {}
    groups: Dict[str, str] = {}
    seen = set()
    for ticket in incremental_tickets(START_DATE):
        for audit in ticket_audits(ticket.get(class="hl-string">"id")):
            append_audit_rows(ticket, audit, rows, users, groups)
        append_satisfaction_rows(ticket, rows, users, groups)
        append_sla_breach_rows(ticket, rows, users, groups)
    unique_rows: List[Dict[str, str]] = []
    for row in rows:
        key = (row[class="hl-string">"TicketId"], row[class="hl-string">"ActivityName"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"Assignee"], row[class="hl-string">"AssignedGroup"])
        if key not in seen:
            seen.add(key)
            unique_rows.append(row)
    unique_rows.sort(key=lambda item: (item[class="hl-string">"TicketId"], item[class="hl-string">"EventTimestamp"], item[class="hl-string">"ActivityName"]))
    return unique_rows


if __name__ == class="hl-string">"__main__":
    event_rows = extract()
    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=FIELDS)
        writer.writeheader()
        writer.writerows(event_rows)
    print(json.dumps({class="hl-string">"output_file": OUTPUT_FILE, class="hl-string">"rows": len(event_rows), class="hl-string">"last_data_update": LAST_DATA_UPDATE}))

ขั้นตอน

เลือกเครื่องมือ ETL หรือเครื่องมือผสานข้อมูลเชิงพาณิชย์ที่มี Zendesk Support connector ที่ผ่านการตรวจสอบ รองรับประวัติการตรวจสอบ Ticket และการดึงความคิดเห็น และเขียนข้อมูลไปยังคลังข้อมูลหรือระบบไฟล์เป้าหมายได้ ตรวจสอบว่า connector รองรับการดึงข้อมูลแบบ incremental การแบ่งหน้า การจัดการข้อจำกัดอัตราการเรียก และการเก็บ timestamp ต้นทาง.
สร้างการเชื่อมต่อ Zendesk ในเครื่องมือที่เลือก ระบุ subdomain ของ Zendesk วิธีการยืนยันตัวตน ข้อมูลรับรองหรือ token และการตั้งค่าการเชื่อมต่อที่จำเป็นผ่านหน้าตั้งค่าของเครื่องมือ ให้สิทธิ์เข้าถึง Ticket ประวัติการตรวจสอบ ความคิดเห็น ผู้ใช้ กลุ่ม คะแนนความพึงพอใจ และข้อมูล SLA เมื่อ Zendesk plan และ connector รองรับข้อมูลเหล่านี้.
ตั้งค่าช่วงเวลาดึงข้อมูล สำหรับการโหลดครั้งแรก ให้ใช้ช่วงย้อนหลัง 3-6 เดือน จากนั้นตั้งค่าการโหลดแบบ incremental โดยอิง timestamp การอัปเดตหรือ timestamp การตรวจสอบที่ connector รองรับ จัดเก็บจุดบันทึกความคืบหน้าของการดึงข้อมูลครั้งล่าสุดที่สำเร็จไว้นอกบันทึกเหตุการณ์ เพื่อไม่ให้การเรียกครั้งถัดไปทำให้ข้อมูลซ้ำหรือตกหล่น.
ดึงข้อมูลระดับ Ticket ที่จำเป็นต่อบริบทของเคส ได้แก่ ตัวระบุ Ticket สถานะปัจจุบันหรือสถานะขณะเกิดเหตุการณ์ ผู้รับผิดชอบ กลุ่ม ลำดับความสำคัญ ช่องทางที่รายงาน สถานะ SLA และ timestamp การอัปเดตที่เกี่ยวข้อง ดึงประวัติการตรวจสอบ Ticket ด้วย เพราะการเปลี่ยนผู้รับผิดชอบ ลำดับความสำคัญ สถานะ และฟิลด์อื่นต้องแสดงเป็นแถวเหตุการณ์อย่างชัดเจน.
ดึงความคิดเห็นของ Ticket และแยกความคิดเห็นสาธารณะออกจากบันทึกภายในโดยใช้ตัวบ่งชี้ public หรือ visibility ของ connector ดึง timestamp ความคิดเห็น ตัวระบุ Ticket ตัวระบุผู้เขียน และเวลาสิ้นสุดหรือเวลาที่เสร็จสิ้น หากมี สร้างแถว Public Reply Sent สำหรับความคิดเห็นสาธารณะ และ Internal Note Added สำหรับบันทึกส่วนตัว.
ดึงข้อมูลคะแนนความพึงพอใจและการละเมิด SLA เมื่อ connector แสดงข้อมูลเหล่านี้ หาก connector ไม่แสดงเหตุการณ์การละเมิด SLA โดยตรง ให้ตั้งค่าเครื่องมือ ETL คำนวณจากเป้าหมาย SLA, policy, เวลาทำการ และ timestamp ของเหตุการณ์ที่มี อย่าสร้างแถวการละเมิด เว้นแต่ข้อมูลต้นทางหรือการคำนวณที่ตั้งค่าไว้ยืนยันว่าเกินเป้าหมาย.
ปรับข้อมูลต้นทางให้อยู่ในรูปแบบบันทึกเหตุการณ์มาตรฐาน โดยสร้างหนึ่งแถวต่อกิจกรรมที่เกิดขึ้นจริง แปลงการสร้าง Ticket เป็น Incident Created, การเปลี่ยนกลุ่มเป็น Ticket Assigned to Group หรือ Ticket Reassigned, การเปลี่ยนเจ้าหน้าที่เป็น Ticket Assigned to Agent หรือ Ticket Reassigned, การเปลี่ยนลำดับความสำคัญเป็น Priority Set, การเปลี่ยนสถานะเป็นกิจกรรมสถานะที่ตรงกัน, ความคิดเห็นเป็น Public Reply Sent หรือ Internal Note Added, สถานะ solved เป็น Incident Resolved, คะแนนความพึงพอใจเป็น User Satisfaction Rated และสถานะ closed เป็น Incident Closed.
ใช้กฎจัดประเภทเหตุการณ์ตามลำดับที่กำหนดแน่นอน โดยอ้างอิงค่าเดิมและค่าใหม่จากประวัติการตรวจสอบเมื่อมี จัดประเภทการมอบหมายครั้งแรกให้กลุ่มเป็น Ticket Assigned to Group และการมอบหมายครั้งแรกให้เจ้าหน้าที่เป็น Ticket Assigned to Agent ส่วนการเปลี่ยนเจ้าของงานครั้งต่อไปให้เป็น Ticket Reassigned สร้างแถวสำหรับการเปลี่ยนแปลงที่เข้าเกณฑ์ทุกครั้ง ไม่ใช่เฉพาะสถานะล่าสุดของ Ticket.
กรอกคอลัมน์ที่ต้องใช้ ได้แก่ TicketId, ActivityName, EventTimestamp, SourceSystem และ LastDataUpdate กรอกคอลัมน์แนะนำ ได้แก่ TicketStatus, Assignee, AssignedGroup, TicketPriority, Channel, SlaStatus และ EventEndTime โดยอิงบริบทของเหตุการณ์หรือข้อมูลต้นทางที่ถูกต้องที่สุด เก็บ timestamp ต้นทางในเขตเวลาเดียวกัน โดยแนะนำให้ใช้ UTC และรักษาความละเอียดเดิมที่ connector รองรับ.
ตรวจสอบผลลัพธ์ที่แปลงแล้ว โดยเช็กว่า TicketId ทุกรายการมีแถว Incident Created, timestamp ของเหตุการณ์อยู่ในช่วงเวลาที่ดึงข้อมูลเมื่อเกี่ยวข้อง, มีชื่อกิจกรรมที่ต้องใช้ทั้ง 13 รายการเมื่อมีข้อมูลต้นทาง และจัดการคีย์เหตุการณ์ซ้ำตามตัวระบุการตรวจสอบต้นทางหรือคีย์ผสมที่มีเอกสารกำกับ.
เขียนบันทึกเหตุการณ์ลงตารางคลังข้อมูลหรือไฟล์เป้าหมายในรูปแบบตารางที่ ProcessMind รองรับ เช่น CSV หรือรูปแบบ connector ของคลังข้อมูลที่รองรับ ใช้แถวหัวตารางหนึ่งแถว ชื่อคอลัมน์คงที่ การเข้ารหัส UTF-8, timestamp รูปแบบ ISO 8601 และไม่มี JSON ซ้อนในคอลัมน์เหตุการณ์สุดท้าย อัปโหลดหรือเชื่อมต่อบันทึกเหตุการณ์กับ ProcessMind โดยไม่พึ่งการอนุมานกิจกรรม เพราะ ProcessMind อ่านแถวข้อมูลตามที่ได้รับ.

การกำหนดค่า

Connector และไลเซนส์: ใช้เครื่องมือ ETL หรือผสานข้อมูลเชิงพาณิชย์ที่มี Zendesk Support connector ซึ่งดึง Ticket, ประวัติการตรวจสอบ Ticket, ความคิดเห็น, ผู้ใช้, กลุ่ม, คะแนนความพึงพอใจ และข้อมูล SLA ได้ตามที่ Zendesk plan และ connector version รองรับ.
การยืนยันตัวตนและการกำหนดสิทธิ์: ตั้งค่า subdomain ของ Zendesk และวิธีการยืนยันตัวตนที่ได้รับอนุมัติ ให้สิทธิ์เท่าที่จำเป็นสำหรับการดึง Ticket ประวัติการตรวจสอบ ความคิดเห็น ผู้ใช้ กลุ่ม คะแนนความพึงพอใจ และ SLA ตรวจสอบว่าบัญชีที่ใช้เชื่อมต่ออ่านข้อมูลย้อนหลังได้.
ช่วงวันที่: เริ่มจากข้อมูลย้อนหลัง 3-6 เดือนเพื่อทดสอบและโหลดข้อมูลครั้งแรก ขยายช่วงเวลาเมื่อยืนยันจำนวนแถว การแบ่งหน้า และการจัดการข้อจำกัดอัตราการเรียกแล้ว ใช้จุดบันทึกความคืบหน้าแบบ incremental สำหรับการเรียกตามกำหนดเวลา.
ตัวกรองที่ต้องใช้: ใช้ตัวกรองเฉพาะบริษัทเมื่อยืนยันได้จากการตั้งค่าต้นทาง เช่น subdomain ของ Zendesk, แบรนด์, องค์กร, กลุ่ม หรือขอบเขต Ticket ที่เลือก อย่าใช้ตัวกรอง Company Code หรือ Document Type เว้นแต่ฟิลด์เหล่านี้มีอยู่ในโมเดลข้อมูล Zendesk ที่ตั้งค่าไว้.
ประวัติการตรวจสอบ: เปิดการดึงเหตุการณ์จากประวัติการตรวจสอบ Ticket และเก็บตัวระบุการตรวจสอบต้นทางไว้เมื่อมี เพื่อป้องกันเหตุการณ์ซ้ำระหว่างการโหลดแบบ incremental.
ความคิดเห็น: ดึงทั้งความคิดเห็นสาธารณะและส่วนตัว ใช้ตัวบ่งชี้ visibility จากต้นทางเพื่อจัดประเภท Public Reply Sent และ Internal Note Added อย่าอนุมานประเภทจากข้อความความคิดเห็น.
การจัดประเภทการมอบหมาย: เปรียบเทียบค่ากลุ่มหรือผู้รับผิดชอบเดิมกับค่าใหม่ แยกการมอบหมายครั้งแรกที่เข้าเกณฑ์ออกจากการเปลี่ยนแปลงครั้งถัดไป และสร้าง Ticket Reassigned เมื่อมีการเปลี่ยนเจ้าของงานในภายหลัง.
การจัดประเภทสถานะ: สร้างแถวเฉพาะเมื่อมีการเปลี่ยนสถานะอย่างชัดเจน จัดค่า new, open, pending, solved และ closed ให้ตรงกับโมเดลสถานะ Zendesk ที่ตั้งค่าไว้ หากใช้สถานะกำหนดเอง ให้บันทึกวิธีจับคู่ก่อนโหลดข้อมูล.
การจัดการ SLA: ให้ใช้เหตุการณ์การละเมิด SLA จากต้นทางก่อน หากไม่มี ให้ตั้งค่าการคำนวณที่มีเอกสารกำกับ โดยใช้เป้าหมาย SLA, policy, เวลาทำการ และ timestamp ของเหตุการณ์ที่มี บันทึกหลักเกณฑ์การคำนวณไว้ในข้อมูลกำกับ ETL อย่าสร้างฟิลด์ต้นทางขึ้นเอง.
การจัดการ timestamp: ปรับ EventTimestamp และ EventEndTime ให้อยู่ใน UTC หรือเขตเวลาอื่นที่มีเอกสารกำกับ เก็บ timestamp ต้นทางไว้ และอย่าแทนเวลาเกิดเหตุการณ์ด้วยเวลาที่ดึงข้อมูล.
LastDataUpdate: กำหนด LastDataUpdate เป็นเวลาที่ ETL รีเฟรชข้อมูลสำเร็จ และใช้ค่าเดียวกันกับทุกแถวในการโหลดครั้งนั้น.
ประสิทธิภาพ: ใช้การแบ่งหน้า การดึงข้อมูลแบบ incremental การแบ่งชุดตามเวลาอัปเดต Ticket หรือเวลาในประวัติการตรวจสอบ การประมวลผลพร้อมกันในระดับที่ควบคุมได้ การลองใหม่ และการหน่วงเวลาเมื่อถึงขีดจำกัดอัตราการเรียก อย่าดึงประวัติ Ticket ทั้งหมดซ้ำทุกครั้งตามกำหนดเวลา.
โครงสร้างข้อมูลเป้าหมาย: ตั้งค่าตารางเหตุการณ์แบบแบนหรือไฟล์ที่มีคอลัมน์ที่ต้องใช้ ได้แก่ TicketId, ActivityName, EventTimestamp, SourceSystem และ LastDataUpdate พร้อมแอตทริบิวต์แนะนำเมื่อมีข้อมูล.
การทำงานของ ProcessMind: อย่าพึ่ง ProcessMind ให้สร้างการเปลี่ยนสถานะ การมอบหมาย การตอบกลับ บันทึก การละเมิด SLA หรือจุดสำคัญของวงจรชีวิต แต่ละกิจกรรมต้องมีแถวเหตุการณ์อยู่แล้วก่อนอัปโหลด.

ตัวอย่างคำค้น config

-- Configure this transformation in the selected ETL tool using its Zendesk connector.
-- Replace bracketed connection, credential, date, and company-specific values in the tool configuration.
-- The connector source objects and field mappings must be selected from the tool's verified Zendesk schema.

WITH
source_tickets AS (
    SELECT
        ticket_id,
        created_at,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        updated_at
    FROM [Your Zendesk tickets source]
    WHERE updated_at >= [Start date parameter]
      AND updated_at < [End date parameter]
),
source_audits AS (
    SELECT
        ticket_id,
        audit_id,
        event_timestamp,
        event_type,
        previous_value,
        new_value,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket audits source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_comments AS (
    SELECT
        ticket_id,
        comment_id,
        event_timestamp,
        is_public,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk ticket comments source]
    WHERE event_timestamp >= [Start date parameter]
      AND event_timestamp < [End date parameter]
),
source_sla_breaches AS (
    SELECT
        ticket_id,
        breach_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk SLA breach source]
    WHERE breach_timestamp >= [Start date parameter]
      AND breach_timestamp < [End date parameter]
),
source_satisfaction AS (
    SELECT
        ticket_id,
        rating_timestamp,
        status,
        assignee,
        assigned_group,
        priority,
        channel,
        sla_status,
        event_end_time
    FROM [Your Zendesk satisfaction rating source]
    WHERE rating_timestamp >= [Start date parameter]
      AND rating_timestamp < [End date parameter]
),
classified_audits AS (
    SELECT
        a.*,
        ROW_NUMBER() OVER (
            PARTITION BY a.ticket_id, a.event_type
            ORDER BY a.event_timestamp, a.audit_id
        ) AS event_sequence
    FROM source_audits a
),
event_log AS (
    SELECT
        CAST(t.ticket_id AS VARCHAR(255)) AS TicketId,
        'Incident Created' AS ActivityName,
        t.created_at AS EventTimestamp,
        'Zendesk Support' AS SourceSystem,
        [ETL refresh timestamp] AS LastDataUpdate,
        t.status AS TicketStatus,
        t.assignee AS Assignee,
        t.assigned_group AS AssignedGroup,
        t.priority AS TicketPriority,
        t.channel AS Channel,
        t.sla_status AS SlaStatus,
        CAST(NULL AS TIMESTAMP) AS EventEndTime
    FROM source_tickets t

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Group',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'group_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Assigned to Agent',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'assignee_assignment'
      AND a.event_sequence = 1
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Priority Set',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.new_value,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'priority_change'
      AND a.new_value IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Open',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.previous_value = 'new'
      AND a.new_value = 'open'

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Public Reply Sent',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = TRUE

    UNION ALL

    SELECT
        CAST(c.ticket_id AS VARCHAR(255)),
        'Internal Note Added',
        c.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        c.status,
        c.assignee,
        c.assigned_group,
        c.priority,
        c.channel,
        c.sla_status,
        c.event_end_time
    FROM source_comments c
    WHERE c.is_public = FALSE

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Ticket Reassigned',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.status,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type IN ('group_assignment', 'assignee_assignment')
      AND a.event_sequence > 1
      AND COALESCE(a.previous_value, '') <> COALESCE(a.new_value, '')

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Status Changed to Pending',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'pending'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'SLA Target Breached',
        s.breach_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_sla_breaches s
    WHERE s.breach_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Resolved',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'solved'

    UNION ALL

    SELECT
        CAST(s.ticket_id AS VARCHAR(255)),
        'User Satisfaction Rated',
        s.rating_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        s.status,
        s.assignee,
        s.assigned_group,
        s.priority,
        s.channel,
        s.sla_status,
        s.event_end_time
    FROM source_satisfaction s
    WHERE s.rating_timestamp IS NOT NULL

    UNION ALL

    SELECT
        CAST(a.ticket_id AS VARCHAR(255)),
        'Incident Closed',
        a.event_timestamp,
        'Zendesk Support',
        [ETL refresh timestamp],
        a.new_value,
        a.assignee,
        a.assigned_group,
        a.priority,
        a.channel,
        a.sla_status,
        a.event_end_time
    FROM classified_audits a
    WHERE a.event_type = 'status_change'
      AND a.new_value = 'closed'
)
SELECT
    TicketId,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    TicketStatus,
    Assignee,
    AssignedGroup,
    TicketPriority,
    Channel,
    SlaStatus,
    EventEndTime
FROM event_log
WHERE TicketId IS NOT NULL
  AND ActivityName IS NOT NULL
  AND EventTimestamp IS NOT NULL
ORDER BY TicketId, EventTimestamp, ActivityName;

พร้อมเริ่มต้นหรือยัง?

ใช้เทมเพลตนี้ช่วยเตรียมข้อมูลและค้นหาข้อมูลเชิงลึกเกี่ยวกับผลการดำเนินงานด้านการจัดการเหตุขัดข้อง เริ่มปรับปรุงกระบวนการของคุณได้เลย.

กลับไปยังคู่มือการปรับปรุง

ดาวน์โหลดเทมเพลต

ปรับปรุงการจัดการเหตุขัดข้อง แก้ไขปัญหาได้เร็วขึ้น

ลด MTTR ลง 35% ลดเหตุขัดข้องที่เกิดซ้ำ และเพิ่มความพึงพอใจ.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงได้ในไม่กี่นาที

เทมเพลตข้อมูลการจัดการเหตุขัดข้องของคุณ

เทมเพลตข้อมูลการจัดการเหตุขัดข้องของคุณ

แอตทริบิวต์การจัดการเหตุขัดข้อง

กิจกรรมในการจัดการเหตุขัดข้อง

คู่มือการดึงข้อมูล

ส่งออกรายงาน Zendesk Explore UI เป็นไฟล์ CSV

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น config

สคริปต์ Python ที่ใช้ Zendesk Support REST API

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น python

Zendesk Incremental Export API สำหรับซิงค์ข้อมูลจำนวนมาก

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น python

เครื่องมือ ETL จากผู้ให้บริการภายนอกที่เชื่อมต่อกับ Zendesk API

ขั้นตอน

การกำหนดค่า

ตัวอย่างคำค้น config

พร้อมเริ่มต้นหรือยัง?

ปรับปรุงการจัดการเหตุขัดข้อง แก้ไขปัญหาได้เร็วขึ้น