เทมเพลตข้อมูลการจัดการปัญหา

Zendesk Support
เทมเพลตข้อมูลการจัดการปัญหา

เทมเพลตข้อมูลการจัดการปัญหา

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

แอตทริบิวต์การจัดการปัญหา

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

แอตทริบิวต์นี้บันทึกขั้นตอนหรือการดำเนินการที่เกิดขึ้นในวงจรของระเบียนปัญหา เช่น การเปลี่ยนสถานะจาก 'Open' เป็น 'Pending' การเปลี่ยนผู้รับผิดชอบ หรือขั้นตอนเฉพาะในเวิร์กโฟลว์ เช่น 'Workaround Published'.

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ดึงข้อมูลจาก Zendesk Ticket Audits หรือ Ticket Metrics

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

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

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

เหตุผลที่สำคัญ

ช่วยตรวจสอบที่มาของข้อมูล และรองรับการตั้งค่า process mining ที่ใช้ข้อมูลจากหลายระบบ.

แหล่งข้อมูล

กำหนดค่าไว้ตายตัวระหว่างดึงข้อมูล

ตัวอย่าง
Zendesk Support
ระเบียนปัญหา
ProblemRecordId
รหัสตัวเลขเฉพาะที่กำหนดให้กับบัตรปัญหาใน Zendesk.
คำอธิบาย

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

ในการวิเคราะห์ รหัสนี้ใช้ระบุเส้นทางการตรวจสอบปัญหาแต่ละรายการตั้งแต่สร้างจนปิดได้อย่างชัดเจน และช่วยเชื่อมโยงเหตุขัดข้องที่เกี่ยวข้อง รวมถึงติดตามวงจรของปัญหาผ่านระดับการสนับสนุนต่าง ๆ.

เหตุผลที่สำคัญ

เป็นรหัสหลักที่จำเป็นสำหรับจัดกลุ่มเหตุการณ์เป็นกรณี เพื่อใช้วิเคราะห์ด้วย process mining.

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'id' ที่มี type เป็น 'problem'

ตัวอย่าง
1045293849921
เวลาเริ่มต้น
EventTimestamp
วันที่และเวลาที่เกิดกิจกรรม.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ใช้เรียงลำดับกิจกรรมและคำนวณ KPI ที่อิงกับเวลาได้ทั้งหมด.

แหล่งข้อมูล

Zendesk Ticket Audits ฟิลด์ 'created_at'

ตัวอย่าง
2023-10-12T08:30:00Z2023-10-12T09:15:22Z
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่ระเบียนปัญหาได้รับการแก้ไขล่าสุด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ใช้ติดตามความใหม่ของข้อมูลและช่วยวางแผนการโหลดข้อมูลแบบเพิ่มเฉพาะส่วนที่เปลี่ยนแปลง.

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'updated_at'

ตัวอย่าง
2023-11-01T14:20:00Z
กลุ่มสนับสนุน
SupportGroup
ทีม หรือแผนกที่รับผิดชอบระเบียนปัญหาในขณะนั้น.
คำอธิบาย

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

ในการวิเคราะห์ ข้อมูลนี้จำเป็นสำหรับแดชบอร์ด 'Support Group Handover Analysis' ช่วยวัดผลการทำงานของแต่ละทีม ค้นหาคอขวดระหว่างการส่งต่องาน และวิเคราะห์การกระจายภาระงานของทรัพยากร.

เหตุผลที่สำคัญ

ช่วยวิเคราะห์การทำงานระหว่างหน่วยงานและค้นหาคอขวดระหว่างแผนก.

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'group_id' (แปลงเป็นชื่อกลุ่ม)

ตัวอย่าง
ฝ่ายสนับสนุนระดับ L2ทีมฐานข้อมูลฝ่ายปฏิบัติการเครือข่าย
กำหนดเวลาแก้ไขตาม SLA
SlaDueDate
วันและเวลาที่ควรแก้ไขปัญหาให้เสร็จ.
คำอธิบาย

แอตทริบิวต์นี้ระบุกำหนดเวลาแก้ไขตามการตั้งค่า Service Level Agreement โดยปกติคำนวณจากระดับความสำคัญและเวลาที่สร้างบัตร.

ในการวิเคราะห์ จะนำไปเปรียบเทียบกับเวลาแก้ไขจริงเพื่อคำนวณ 'อัตราการปฏิบัติตาม SLA ของปัญหา' และใช้ในแดชบอร์ด 'SLA Performance and Risk' เพื่อแสดงกรณีที่ใกล้ถึงกำหนดหรือเกินเวลาที่จัดสรรไว้แล้ว.

เหตุผลที่สำคัญ

จำเป็นต่อการวัดการปฏิบัติตามข้อกำหนดและผลการดำเนินงานตามสัญญา.

แหล่งข้อมูล

Zendesk Ticket Metrics หรือ SLA Policies endpoint

ตัวอย่าง
2023-12-01T17:00:00Z
จำนวนเหตุขัดข้องที่เกี่ยวข้อง
RelatedIncidentCount
จำนวนบัตรเหตุขัดข้องที่เชื่อมโยงกับระเบียนปัญหานี้.
คำอธิบาย

แอตทริบิวต์นี้นับจำนวนบัตรเหตุขัดข้องที่เชื่อมโยงกับระเบียนปัญหา ใน Zendesk การเชื่อมโยงนี้ทำผ่านฟิลด์ 'problem_id' ในบัตรเหตุขัดข้อง ซึ่งอ้างอิงกลับมายังระเบียนนี้.

ในการวิเคราะห์ นี่คือตัวชี้วัดหลักสำหรับ 'Incident Correlation and Impact' ช่วยจัดลำดับความสำคัญของปัญหาที่ส่งผลต่อผู้ใช้จำนวนมาก และใช้ประกอบการตัดสินใจว่าควรแก้ปัญหาใดก่อนเพื่อให้ลดจำนวนบัตรได้มากที่สุดเมื่อเทียบกับผลตอบแทนจากการลงทุน.

เหตุผลที่สำคัญ

แสดงขนาดของปัญหาและผลกระทบต่อผู้ใช้.

แหล่งข้อมูล

Zendesk Tickets API นับบัตรที่ type='incident' และ problem_id=ThisID

ตัวอย่าง
015342
ชื่อผู้รับผิดชอบ
AssigneeName
เจ้าหน้าที่ที่ได้รับมอบหมายให้จัดการปัญหา.
คำอธิบาย

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

ในการวิเคราะห์ ข้อมูลนี้ช่วยให้เข้าใจภาระงานและผลการทำงานของแต่ละคน แม้โดยทั่วไปจะวิเคราะห์ในระดับกลุ่ม แต่ข้อมูลระดับผู้รับผิดชอบยังช่วยค้นหาความต้องการในการฝึกอบรม หรือผู้ที่จัดการสาเหตุที่ซับซ้อนได้อย่างมีประสิทธิภาพเป็นพิเศษ.

เหตุผลที่สำคัญ

ช่วยวิเคราะห์การจัดสรรทรัพยากรในระดับบุคคล.

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'assignee_id' (แปลงเป็นชื่อ)

ตัวอย่าง
สมชาย ใจดีสมหญิง ใจงามระบบ
ระดับความสำคัญ
Priority
ระดับความเร่งด่วนที่กำหนดให้กับระเบียนปัญหา.
คำอธิบาย

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

ในการวิเคราะห์ ใช้แบ่งกลุ่มกระบวนการและเปรียบเทียบผลการดำเนินงานตามระดับความเร่งด่วน เช่น ตรวจสอบว่าปัญหาเร่งด่วนได้รับการแก้ไขเร็วกว่าปัญหาระดับต่ำตามที่กำหนดไว้ในแดชบอร์ด 'Root Cause Investigation Velocity' หรือไม่.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'priority'

ตัวอย่าง
เร่งด่วนสูงปกติต่ำ
สถานะปัญหา
ProblemStatus
สถานะปัจจุบันของระเบียนปัญหาในวงจรการดำเนินงาน.
คำอธิบาย

แอตทริบิวต์นี้แสดงสถานะปัจจุบันของปัญหา เช่น New, Open, Pending, Solved หรือ Closed ซึ่งสะท้อนความคืบหน้าของการตรวจสอบ.

ในการวิเคราะห์ ใช้กรองกรณีที่เปิดหรือปิดแล้ว และจำเป็นสำหรับแดชบอร์ด 'Stale Problem Record Monitoring' เพื่อระบุกรณีที่ยังดำเนินการอยู่แต่ไม่คืบหน้าตามวงจรสถานะที่คาดไว้.

เหตุผลที่สำคัญ

ใช้กรองกรณีตามสถานะการดำเนินการเสร็จสิ้น.

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'status'

ตัวอย่าง
ใหม่เปิดอยู่รอดำเนินการแก้ไขแล้วปิดแล้ว
หมวดหมู่ปัญหา
ProblemCategory
การจัดประเภทของปัญหา เช่น ซอฟต์แวร์ ฮาร์ดแวร์ หรือเครือข่าย.
คำอธิบาย

แอตทริบิวต์นี้ใช้จัดหมวดหมู่ปัญหาตามบริการหรือชุดเทคโนโลยีที่ได้รับผลกระทบ โดยทั่วไปจะเป็นฟิลด์แบบดรอปดาวน์ที่กำหนดเองในแบบฟอร์ม Zendesk

ในการวิเคราะห์ จะใช้แอตทริบิวต์นี้กับแดชบอร์ด 'ความแม่นยำในการจัดหมวดหมู่ปัญหา' โดยเปรียบเทียบหมวดหมู่ที่ระบุไว้ตอนแรกกับสาเหตุหลักที่พบในภายหลัง เพื่อดูว่าการคัดแยกเบื้องต้นส่งปัญหาไปยังทีมที่เหมาะสมหรือไม่.

เหตุผลที่สำคัญ

ช่วยให้แยกวิเคราะห์ตามเทคโนโลยีหรือบริการทางธุรกิจได้.

แหล่งข้อมูล

ฟิลด์ที่กำหนดเองของ Zendesk Ticket

ตัวอย่าง
ฐานข้อมูลส่วนติดต่อผู้ใช้/ประสบการณ์ผู้ใช้โครงสร้างพื้นฐานเครือข่าย
หมวดหมู่สาเหตุหลัก
RootCauseCategory
สาเหตุเบื้องหลังของปัญหาที่ระบุได้ เช่น ข้อบกพร่องของโค้ด หรือข้อผิดพลาดในการตั้งค่า.
คำอธิบาย

แอตทริบิวต์นี้บันทึกผลการวินิจฉัยขั้นสุดท้ายว่าอะไรเป็นสาเหตุของปัญหา โดยปกติจะกรอกข้อมูลระหว่างกิจกรรม 'ระบุสาเหตุหลัก'

ในการวิเคราะห์ จะใช้ข้อมูลนี้สร้างรายงาน 'ความแม่นยำในการจัดหมวดหมู่ปัญหา' และวิเคราะห์แนวโน้มความขัดข้องของระบบ ช่วยให้ผู้บริหารตัดสินใจได้ว่าควรให้ความสำคัญกับคุณภาพโค้ด ความเสถียรของโครงสร้างพื้นฐาน หรือการบริหารผู้ขาย.

เหตุผลที่สำคัญ

ช่วยวิเคราะห์รูปแบบความขัดข้องและกำหนดแนวทางปรับปรุงในระยะยาว.

แหล่งข้อมูล

ฟิลด์ที่กำหนดเองของ Zendesk Ticket

ตัวอย่าง
ข้อบกพร่องของซอฟต์แวร์การตั้งค่าผิดพลาดข้อผิดพลาดจากผู้ใช้
มี PIR
HasPostImplementationReview
ระบุว่ามีการทบทวนหลังนำไปใช้หรือไม่.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ใช้ตรวจสอบการปฏิบัติตามกระบวนการปรับปรุงอย่างต่อเนื่อง.

แหล่งข้อมูล

พิจารณาจากการมีกิจกรรม «ดำเนินการทบทวนหลังนำไปใช้»

ตัวอย่าง
truefalse
มีวิธีแก้ปัญหาชั่วคราว
WorkaroundActive
ตัวบ่งชี้ว่ามีการจัดทำหรือเผยแพร่วิธีแก้ปัญหาชั่วคราวแล้วหรือไม่.
คำอธิบาย

แอตทริบิวต์แบบค่าจริง/เท็จนี้ระบุว่ามีการบันทึกวิธีแก้ปัญหาชั่วคราวไว้หรือไม่ โดยมักพิจารณาจากการมีกิจกรรม 'เผยแพร่วิธีแก้ปัญหาชั่วคราว' หรือช่องทำเครื่องหมายเฉพาะในแบบฟอร์ม

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

เหตุผลที่สำคัญ

เป็นข้อมูลสำคัญในการวัดการบรรเทาผลกระทบต่อผู้ใช้ระหว่างการตรวจสอบ.

แหล่งข้อมูล

คำนวณจากการมีกิจกรรม «เผยแพร่วิธีแก้ปัญหาชั่วคราว» หรือฟิลด์ที่กำหนดเอง

ตัวอย่าง
truefalse
ไม่มีความเคลื่อนไหว
IsStale
ระบุว่าปัญหาไม่มีความเคลื่อนไหวเกิน 14 วัน.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ช่วยระบุงานที่สูญเปล่าในกระบวนการและรายการงานที่ถูกละเลย.

แหล่งข้อมูล

คำนวณในเครื่องมือ process mining: (Now - LastDataUpdate) > 14 วัน

ตัวอย่าง
truefalse
รหัสคำขอเปลี่ยนแปลง
ChangeRequestId
รหัสของคำขอเปลี่ยนแปลงที่เชื่อมโยงเพื่อดำเนินการแก้ไข.
คำอธิบาย

แอตทริบิวต์นี้เชื่อมโยงระเบียนปัญหากับระเบียนการจัดการการเปลี่ยนแปลง ซึ่งอาจอยู่ในระบบอื่นหรือเป็นประเภท Ticket อีกแบบหนึ่ง แสดงว่ามีการเริ่มกระบวนการเปลี่ยนแปลงอย่างเป็นทางการแล้ว

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

เหตุผลที่สำคัญ

เชื่อมโยงกระบวนการจัดการปัญหากับกระบวนการจัดการการเปลี่ยนแปลง.

แหล่งข้อมูล

ฟิลด์ที่กำหนดเองของ Zendesk Ticket หรือ Ticket ที่เชื่อมโยง

ตัวอย่าง
CR-1002CHG00394
รหัสบทความฐานความรู้
KnowledgeArticleId
รหัสของบทความฐานความรู้ที่สร้างขึ้นหรือเชื่อมโยงกับปัญหา.
คำอธิบาย

แอตทริบิวต์นี้เก็บข้อมูลอ้างอิงไปยังบทความ Zendesk Guide หรือรายการความรู้จากแหล่งภายนอก ซึ่งแสดงว่ามีการบันทึกความรู้ที่ได้จากการแก้ปัญหาไว้แล้ว

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

เหตุผลที่สำคัญ

ใช้วัดประสิทธิผลของกระบวนการจัดการความรู้.

แหล่งข้อมูล

ฟิลด์ที่กำหนดเองของ Zendesk Ticket หรือเนื้อหาที่เชื่อมโยง

ตัวอย่าง
360045889KB-2991
หัวข้อปัญหา
ProblemSubject
สรุปสั้น ๆ หรือชื่อระเบียนปัญหา.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ให้บริบทที่อ่านเข้าใจได้สำหรับแต่ละกรณี.

แหล่งข้อมูล

ออบเจ็กต์ Zendesk Ticket ฟิลด์ 'subject'

ตัวอย่าง
ไม่สามารถประมวลผลการชำระเงินในภูมิภาค EU ได้เซิร์ฟเวอร์เข้าสู่ระบบมีค่าความหน่วงพุ่งสูงผู้ดูแลระบบส่งออกข้อมูลไม่สำเร็จ
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมการจัดการปัญหา

บันทึกขั้นตอนสำคัญและการเปลี่ยนสถานะเหล่านี้ เพื่อแสดงภาพกระบวนการตั้งแต่เริ่มระบุปัญหาไปจนถึงการนำวิธีแก้ไขถาวรไปใช้.
8 แนะนำ 4 ไม่บังคับ
กิจกรรม คำอธิบาย
นำวิธีแก้ไขถาวรไปใช้แล้ว
แสดงว่ามีการนำวิธีแก้ไขทางเทคนิคไปติดตั้งในระบบแล้ว โดยปกติติดตามจากการเปลี่ยนสถานะที่กำหนดเองหรือแท็กเฉพาะ ก่อนปิดบัตรว่าแก้ไขแล้ว.
เหตุผลที่สำคัญ

จำเป็นสำหรับแดชบอร์ด Fix Implementation Efficiency เพื่อวัดเวลาตั้งแต่วินิจฉัยจนถึงนำวิธีแก้ไขไปใช้.

แหล่งข้อมูล

อนุมานจากแท็กเฉพาะ เช่น 'fix_deployed' หรือฟิลด์สถานะที่กำหนดเอง หากมี.

บันทึก

ติดตามแท็กหรือเมนูสถานะที่กำหนดเอง

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

ใช้กำหนดเวลาเริ่มต้นของรอบการแก้ปัญหาตั้งแต่ต้นจนจบ และเป็นค่าฐานสำหรับวัดระยะเวลาดำเนินการทั้งหมดหลังจากนั้น.

แหล่งข้อมูล

ดึงข้อมูลจากเวลา 'created_at' ในออบเจ็กต์บัตร หรือรายการแรกในบันทึกการตรวจสอบบัตร.

บันทึก

บันทึกเมื่อมีการดำเนินธุรกรรม Ticket Created

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

ระบุจุดสิ้นสุดของอายุระเบียนอย่างสมบูรณ์ ใช้สำหรับการเก็บรักษาข้อมูลและจัดทำรายงานย้อนหลัง.

แหล่งข้อมูล

ดึงข้อมูลจากการเปลี่ยนสถานะบัตรเป็น 'Closed'.

บันทึก

บันทึกเมื่อสถานะเปลี่ยนเป็น Closed

ประเภทเหตุการณ์ explicit
เผยแพร่วิธีแก้ปัญหาชั่วคราว
การจัดทำเอกสารและแบ่งปันวิธีแก้ปัญหาชั่วคราว ใน Zendesk มักบันทึกเหตุการณ์นี้ด้วยแท็กเฉพาะหรือช่องทำเครื่องหมายที่กำหนดเอง เพื่อระบุว่ามีวิธีแก้ชั่วคราวแล้ว.
เหตุผลที่สำคัญ

รองรับแดชบอร์ด Workaround Publication Compliance เพื่อให้ผู้ใช้ได้รับการบรรเทาปัญหาชั่วคราวระหว่างการตรวจสอบที่ใช้เวลานาน.

แหล่งข้อมูล

ติดตามการเพิ่มแท็ก 'workaround_published' หรือการเปลี่ยนค่าฟิลด์บูลีนที่กำหนดเองชื่อ 'Workaround'.

บันทึก

เปรียบเทียบค่าฟิลด์หรือแท็กที่กำหนดเอง

ประเภทเหตุการณ์ inferred
มอบหมายให้กลุ่มสนับสนุน
การส่งระเบียนปัญหาไปยังทีมหรือแผนกด้านเทคนิคที่กำหนด ระบบติดตามเหตุการณ์นี้เมื่อมีการอัปเดตฟิลด์ Group ID ในบัตร.
เหตุผลที่สำคัญ

จำเป็นสำหรับแดชบอร์ด Support Group Handover Analysis เพื่อวัดเวลารอระหว่างแผนก.

แหล่งข้อมูล

ติดตามการเปลี่ยนแปลงของฟิลด์ 'group_id' ในบันทึกการตรวจสอบบัตร.

บันทึก

บันทึกเมื่อมีการดำเนินธุรกรรม Group Assignment Change

ประเภทเหตุการณ์ explicit
ยืนยันการแก้ไขปัญหา
การกำหนดสถานะปัญหาอย่างเป็นทางการว่าแก้ไขแล้ว ใน Zendesk จะเกิดขึ้นเมื่อกำหนดสถานะมาตรฐานของระบบเป็น 'Solved' ซึ่งหมายความว่าได้ตรวจสอบวิธีแก้ไขแล้วและปิดกรณีได้.
เหตุผลที่สำคัญ

เป็นจุดสิ้นสุดหลักสำหรับคำนวณประสิทธิภาพและความเสี่ยงด้าน SLA รวมถึงอัตราการปฏิบัติตาม SLA ของปัญหา.

แหล่งข้อมูล

ดึงข้อมูลจากการเปลี่ยนสถานะบัตรเป็น 'Solved'.

บันทึก

บันทึกเมื่อสถานะเปลี่ยนเป็น Solved

ประเภทเหตุการณ์ explicit
ระบุสาเหตุที่แท้จริงแล้ว
จุดที่ระบุสาเหตุเบื้องหลังของปัญหาได้ โดยทั่วไปจะบันทึกเมื่อเจ้าหน้าที่กรอกฟิลด์ข้อความ 'Root Cause' หรือเลือกหมวดหมู่จากเมนูแบบเลื่อนลงที่กำหนดเอง.
เหตุผลที่สำคัญ

เป็นหมุดหมายสำคัญสำหรับแดชบอร์ด Root Cause Investigation Velocity และการวัดประสิทธิภาพในการวินิจฉัย.

แหล่งข้อมูล

ติดตามการเปลี่ยนแปลงของฟิลด์ที่กำหนดเองชื่อ 'Root Cause', 'RCA' หรือ 'Problem Source' เมื่อมีการกรอกค่า.

บันทึก

ตรวจสอบว่ามีการกรอกค่าฟิลด์ที่กำหนดเองหรือไม่

ประเภทเหตุการณ์ inferred
เริ่มการตรวจสอบ
แสดงการเปลี่ยนจากสถานะ 'New' ที่ยังไม่มีการดำเนินการ ไปสู่สถานะที่เริ่มทำงานแล้ว หมายความว่าเจ้าหน้าที่รับทราบปัญหาและเริ่มวินิจฉัย.
เหตุผลที่สำคัญ

ใช้คำนวณตัวชี้วัดระเบียนปัญหาที่ไม่มีความคืบหน้า และเป็นจุดเริ่มต้นในการคำนวณ KPI ระยะเวลาเฉลี่ยในการวิเคราะห์หาสาเหตุที่แท้จริง.

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะบัตรจาก 'New' เป็น 'Open' หรือ 'Pending'.

บันทึก

เปรียบเทียบฟิลด์สถานะก่อนและหลัง

ประเภทเหตุการณ์ inferred
จัดทำร่างวิธีแก้ไขที่เสนอ
การสร้างบทความในฐานความรู้จากผลการตรวจสอบปัญหา อนุมานได้จากการใช้แอป Zendesk Knowledge Capture หรือการเชื่อมโยงบทความใหม่.
เหตุผลที่สำคัญ

รองรับ KPI อัตราการเชื่อมโยงฐานความรู้ เพื่อส่งเสริมการเรียนรู้ในองค์กร.

แหล่งข้อมูล

ติดตามเหตุการณ์ที่เกี่ยวข้องกับการเชื่อมต่อ 'Knowledge Capture' หรือแท็ก เช่น 'kcs_draft'.

บันทึก

อนุมานจากแท็กระบบเฉพาะหรือเหตุการณ์การเชื่อมโยง

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

จำเป็นสำหรับ KPI ความถี่ในการทบทวนหลังนำไปใช้ เพื่อให้เป็นไปตามมาตรฐานคุณภาพ.

แหล่งข้อมูล

ติดตามการอัปเดตช่องทำเครื่องหมายที่กำหนดเอง 'PIR Completed' หรือฟิลด์วันที่ 'PIR Date'.

บันทึก

ติดตามการกรอกข้อมูลในฟิลด์ที่กำหนดเอง

ประเภทเหตุการณ์ inferred
เปิดการตรวจสอบปัญหาอีกครั้ง
เกิดขึ้นเมื่อเปลี่ยนระเบียนปัญหาที่เคยกำหนดสถานะเป็น Solved กลับเป็น Open หรือสถานะที่ยังดำเนินการอยู่ ซึ่งอาจหมายถึงวิธีแก้ไขไม่ได้ผลหรือถูกปฏิเสธ.
เหตุผลที่สำคัญ

รองรับ KPI อัตราการเปิดปัญหาซ้ำ และช่วยค้นหาปัญหาด้านคุณภาพในกระบวนการแก้ไข.

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะจาก 'Solved' กลับเป็น 'Open', 'New' หรือ 'Pending'.

บันทึก

เปรียบเทียบฟิลด์สถานะก่อนและหลัง

ประเภทเหตุการณ์ inferred
เริ่มคำขอเปลี่ยนแปลง
แสดงว่ามีการเริ่มกระบวนการจัดการการเปลี่ยนแปลงอย่างเป็นทางการเพื่อแก้ปัญหา โดยมักอนุมานจากการกรอกฟิลด์ที่กำหนดเอง 'Change Request ID' หรือการเชื่อมโยงบัตรประเภท 'Change'.
เหตุผลที่สำคัญ

ติดตามอัตราการเริ่มคำขอเปลี่ยนแปลง และเชื่อมโยงเวิร์กโฟลว์ของ Problem Management กับ Change Management.

แหล่งข้อมูล

ติดตามการอัปเดตฟิลด์ที่กำหนดเอง เช่น 'change_reference' หรือการสร้างลิงก์ประเภท 'problem_change'.

บันทึก

ติดตามการกรอกรหัสภายนอกในฟิลด์ที่กำหนดเอง

ประเภทเหตุการณ์ inferred
แนะนำ ไม่บังคับ

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

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

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

นำเทมเพลตนี้ไปใช้กับ Zendesk ของคุณ เพื่อช่วยเพิ่มเสถียรภาพให้ระบบ IT ทีมงานของเราพร้อมช่วยปรับวิธีดึงข้อมูลและเริ่มต้นใช้งาน process mining.

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

ลดระยะเวลาการแก้ไขลง 30 เปอร์เซ็นต์และแก้คอขวดในงาน IT.

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

ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.