เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
- แอตทริบิวต์ที่แนะนำสำหรับการวิเคราะห์อย่างละเอียด
- กิจกรรมสำคัญของคำขอบริการที่ควรติดตาม
- คำแนะนำในการดึงข้อมูลจาก Zendesk Support
แอตทริบิวต์สำหรับการจัดการคำขอบริการ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นกับคำขอบริการ. | ||
|
คำอธิบาย
กิจกรรมหมายถึงขั้นตอนหรือเหตุการณ์หนึ่งในวงจรของคำขอบริการ เช่น 'สร้างคำขอบริการแล้ว' 'มอบหมายคำขอให้เจ้าหน้าที่แล้ว' หรือ 'แก้ไขคำขอบริการแล้ว' กิจกรรมเหล่านี้ได้มาจากการเปลี่ยนแปลงที่บันทึกไว้ในบันทึกการตรวจสอบของทิกเก็ต Zendesk ซึ่งติดตามการแก้ไขฟิลด์ต่างๆ เช่น สถานะ ผู้รับผิดชอบ ระดับความสำคัญ และการเพิ่มความคิดเห็น. การวิเคราะห์กิจกรรมเป็นหัวใจของ process mining ช่วยให้เห็นแผนผังกระบวนการ ระบุคอขวดระหว่างขั้นตอน และวิเคราะห์วงจรการทำงานซ้ำ เมื่อเข้าใจลำดับและความถี่ของกิจกรรม องค์กรจะมองเห็นจุดไม่มีประสิทธิภาพและโอกาสในการปรับปรุงกระบวนการได้.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้กำหนดขั้นตอนในกระบวนการ ช่วยแสดงแผนผังกระบวนการและวิเคราะห์ลำดับการทำงาน ความแตกต่าง และความสอดคล้องกับกระบวนการ.
แหล่งข้อมูล
แนวคิดนี้ได้มาจากเหตุการณ์ที่บันทึกไว้ใน Zendesk Ticket Audits API ตัวอย่างเช่น การเปลี่ยนฟิลด์ 'status' จาก 'new' เป็น 'open' อาจจับคู่กับกิจกรรมอย่าง 'คัดแยกคำขอแล้ว'.
ตัวอย่าง
สร้างคำขอบริการมอบหมายเจ้าหน้าที่ใหม่แก้ไขคำขอบริการแล้ว
|
|||
|
รหัสคำขอบริการ
ServiceRequestId
|
รหัสเฉพาะของทิกเก็ตคำขอบริการแต่ละรายการใน Zendesk. | ||
|
คำอธิบาย
รหัสคำขอบริการ ซึ่งใน Zendesk มักเรียกว่า Ticket ID เป็นคีย์หลักของแต่ละเคส รหัสนี้เชื่อมโยงกิจกรรม ความคิดเห็น และการเปลี่ยนสถานะที่เกี่ยวข้องทั้งหมด ตั้งแต่สร้างคำขอจนถึงปิดเคส จึงติดตามวงจรของคำขอแต่ละรายการได้ครบถ้วนตั้งแต่ต้นจนจบ. แอตทริบิวต์นี้เป็นพื้นฐานสำคัญของการวิเคราะห์ process mining เพราะใช้ระบุเคสและสร้างลำดับกระบวนการขึ้นใหม่ ช่วยค้นหารูปแบบการดำเนินงานที่แตกต่างกัน และคำนวณตัวชี้วัดระดับเคส เช่น ระยะเวลาตั้งแต่เริ่มจนจบ ทุกเหตุการณ์ในชุดข้อมูลต้องเชื่อมโยงกับรหัสคำขอบริการ เพื่อให้เข้าใจบริบทของเหตุการณ์ในกระบวนการโดยรวม.
เหตุผลที่สำคัญ
นี่คือรหัสเคสสำคัญที่เชื่อมโยงทุกเหตุการณ์ตลอดเส้นทางของคำขอบริการ ทำให้วิเคราะห์กระบวนการตั้งแต่ต้นจนจบได้.
แหล่งข้อมูล
Zendesk Tickets API ฟิลด์ 'id'.
ตัวอย่าง
102451024610247
|
|||
|
เวลาเริ่มต้น
EventTimestamp
|
วันที่และเวลาที่แน่นอนซึ่งกิจกรรมเกิดขึ้น. | ||
|
คำอธิบาย
เวลาประทับเหตุการณ์ หรือเวลาเริ่มต้น บันทึกเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ เช่น เวลาที่มอบหมายคำขอให้เจ้าหน้าที่ เวลาที่ส่งข้อความตอบกลับสาธารณะ หรือเวลาที่เปลี่ยนสถานะทิกเก็ตเป็น 'แก้ไขแล้ว' ข้อมูลเวลานี้มาจากบันทึกการตรวจสอบของทิกเก็ต Zendesk แต่ละรายการ. แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ตามเวลา ใช้เรียงเหตุการณ์ตามลำดับเวลา คำนวณระยะห่างระหว่างกิจกรรม วัดเวลารอ และวิเคราะห์ระยะเวลาตั้งแต่เริ่มจนจบของเคส ช่วยระบุคอขวดและประเมินผลการดำเนินงานเทียบกับเป้าหมายด้านเวลา เช่น SLA.
เหตุผลที่สำคัญ
เวลาประทับนี้ใช้เรียงเหตุการณ์ตามลำดับเวลา และจำเป็นต่อการวิเคราะห์ระยะเวลา ประสิทธิภาพ และคอขวด.
แหล่งข้อมูล
Zendesk Ticket Audits API ฟิลด์ 'created_at' ของแต่ละเหตุการณ์การตรวจสอบ.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบุระบบที่ดึงข้อมูลมา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลคำขอบริการ สำหรับมุมมองกระบวนการนี้ ค่าจะเป็น 'Zendesk Support' เสมอ เพื่อระบุว่าเป็นระบบบันทึกข้อมูลหลักของกิจกรรมการจัดการบริการทั้งหมด. ในสภาพแวดล้อมที่เชื่อมต่อหลายระบบ ฟิลด์นี้สำคัญต่อการติดตามที่มาของข้อมูลและการแก้ไขปัญหา ช่วยให้กำหนดขอบเขตการวิเคราะห์กับระบบที่ต้องการได้ถูกต้อง และแยกข้อมูลเมื่อรวมข้อมูลจากหลายแหล่ง.
เหตุผลที่สำคัญ
ระบุระบบต้นทางของข้อมูล ช่วยติดตามที่มาของข้อมูลและป้องกันความสับสนเมื่อนำข้อมูลจากหลายระบบมารวมกัน.
แหล่งข้อมูล
ค่านี้เป็นค่าคงที่ ('Zendesk Support') ซึ่งเพิ่มระหว่างการดึงและแปลงข้อมูล.
ตัวอย่าง
Zendesk Support
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาประทับที่ระบุว่ามีการรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลจาก Zendesk Support ล่าสุด ช่วยให้ทราบว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด และผู้ใช้เห็นข้อมูลกระบวนการที่เป็นปัจจุบันแค่ไหน. ข้อมูลนี้สำคัญต่อการติดตามอย่างต่อเนื่องและการแสดงผลบนแดชบอร์ด ช่วยให้นักวิเคราะห์และผู้ใช้ทางธุรกิจทราบว่ากำลังดูข้อมูลที่ใกล้เคียงเวลาจริง หรือภาพข้อมูลจากช่วงก่อนหน้า ซึ่งมีผลต่อความน่าเชื่อถือของข้อสรุป.
เหตุผลที่สำคัญ
ช่วยให้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด และการวิเคราะห์อ้างอิงข้อมูลล่าสุดแค่ไหน.
แหล่งข้อมูล
ฟิลด์เมทาดาทานี้สร้างและประทับเวลาลงในชุดข้อมูลขณะดึงข้อมูล.
ตัวอย่าง
2023-10-27T08:00:00Z
|
|||
|
ช่องทางที่รับคำขอ
RequestChannel
|
ช่องทางที่ใช้ส่งคำขอบริการ เช่น อีเมล แบบฟอร์มบนเว็บไซต์ หรือโทรศัพท์. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุช่องทางที่ใช้ส่งคำขอบริการ Zendesk บันทึกวิธีสร้างทิกเก็ต เช่น ทางอีเมล พอร์ทัลเว็บไซต์ การเชื่อมต่อ API แชต หรือช่องทางอื่น ข้อมูลนี้ช่วยให้เข้าใจวิธีที่ลูกค้าติดต่อเข้ามา. ช่องทางที่รับคำขอเป็นมิติสำคัญในการวิเคราะห์ ใช้ในแดชบอร์ดประสิทธิภาพช่องทางรับคำขอ เพื่อเปรียบเทียบระยะเวลาแก้ไข คะแนนความพึงพอใจ และอัตราการทำงานซ้ำของแต่ละช่องทาง ข้อมูลนี้ช่วยให้องค์กรปรับปรุงช่องทางสนับสนุนและแนะนำให้ผู้ใช้เลือกช่องทางที่มีประสิทธิภาพกว่าได้.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพและผลลัพธ์ของช่องทางสนับสนุนลูกค้าแต่ละแบบ เพื่อให้ปรับปรุงได้ตรงจุด.
แหล่งข้อมูล
Zendesk Tickets API ออบเจ็กต์ 'via' และพร็อพเพอร์ตี 'channel'.
ตัวอย่าง
เว็บไซต์อีเมลAPIแชต
|
|||
|
ชื่อเจ้าหน้าที่
AgentName
|
ชื่อเจ้าหน้าที่ที่ได้รับมอบหมายให้ดูแลคำขอบริการในเวลาที่เกิดเหตุการณ์. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุเจ้าหน้าที่สนับสนุนที่รับผิดชอบคำขอบริการ เจ้าหน้าที่ที่ได้รับมอบหมายอาจเปลี่ยนหลายครั้งตลอดวงจรของทิกเก็ต ฟิลด์นี้จึงบันทึกว่าใครรับผิดชอบในแต่ละขั้นตอน. ชื่อเจ้าหน้าที่สำคัญต่อการวิเคราะห์ผลการดำเนินงาน ช่วยกรองและแบ่งกลุ่มข้อมูลเพื่อประเมินการกระจายภาระงาน ระยะเวลาแก้ไขปัญหาของเจ้าหน้าที่แต่ละคน และความถี่ในการมอบหมายงานใหม่ ข้อมูลนี้ช่วยสร้างแดชบอร์ดประสิทธิภาพเจ้าหน้าที่และทีม และทำความเข้าใจว่าแต่ละคนมีส่วนช่วยให้กระบวนการโดยรวมมีประสิทธิภาพอย่างไร.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ประสิทธิภาพของเจ้าหน้าที่ การกระจายภาระงาน และผลของการมอบหมายงานใหม่ต่อระยะเวลาแก้ไขปัญหา.
แหล่งข้อมูล
Zendesk Users API โดยเชื่อมข้อมูลจาก 'assignee_id' ในการตอบกลับของ Tickets API.
ตัวอย่าง
Jane DoeJohn SmithEmily Jones
|
|||
|
ทีมที่ได้รับมอบหมาย
AssignedTeam
|
ทีมสนับสนุนหรือกลุ่มที่ได้รับมอบหมายให้ดูแลคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุทีม หรือกลุ่มภายในฝ่ายสนับสนุนที่รับผิดชอบคำขอบริการ ใน Zendesk กลุ่มเหล่านี้เรียกว่า 'Groups' โดยมักมอบหมายทิกเก็ตให้กลุ่มก่อน แล้วจึงให้เจ้าหน้าที่แต่ละคนรับช่วงต่อ. การวิเคราะห์ตามทีมที่ได้รับมอบหมายช่วยให้เข้าใจผลการดำเนินงานและภาระงานของแต่ละทีม รวมถึงตอบคำถามได้ว่าทีมใดดูแลคำขอประเภทไหน ใช้เวลาแก้ไขเฉลี่ยเท่าใด และปฏิบัติตาม SLA ได้มากน้อยเพียงใด นี่เป็นมิติหลักของแดชบอร์ดประสิทธิภาพเจ้าหน้าที่และทีม.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพของทีม การกระจายภาระงาน และประสิทธิภาพการส่งต่อระหว่างกลุ่มสนับสนุน.
แหล่งข้อมูล
Zendesk Groups API โดยเชื่อมข้อมูลจาก 'group_id' ในการตอบกลับของ Tickets API.
ตัวอย่าง
ทีมสนับสนุนระดับ 1ทีมสนับสนุนด้านเทคนิคการเรียกเก็บเงิน
|
|||
|
แท็กทิกเก็ต
TicketTags
|
รายการแท็กที่ใช้จัดหมวดหมู่และส่งต่อคำขอบริการ. | ||
|
คำอธิบาย
แท็กเป็นป้ายกำกับที่ยืดหยุ่น เจ้าหน้าที่เพิ่มลงในทิกเก็ตเองได้ หรือระบบเพิ่มให้อัตโนมัติผ่านกฎทางธุรกิจ ใช้ระบุบริบทหรือหมวดหมู่เฉพาะที่ฟิลด์มาตรฐานอย่างประเภทหรือระดับความสำคัญไม่ได้บันทึกไว้. แท็กมีประโยชน์อย่างยิ่งต่อการวิเคราะห์ process mining ใช้กรองสถานการณ์เฉพาะ ติดตามเวิร์กโฟลว์ที่กำหนดเอง หรือค้นหาสาเหตุที่แท้จริงได้ ตัวอย่างเช่น ใช้แท็ก 'VIP' วิเคราะห์กระบวนการสำหรับลูกค้ารายสำคัญ หรือใช้แท็ก 'product_bug' ติดตามวงจรของรายงานข้อบกพร่อง.
เหตุผลที่สำคัญ
ช่วยแบ่งและกรองข้อมูลได้อย่างยืดหยุ่น เพื่อวิเคราะห์กระบวนการย่อยหรือคุณสมบัติของทิกเก็ตที่ไม่ได้บันทึกในฟิลด์อื่นอย่างละเอียด.
แหล่งข้อมูล
Zendesk Tickets API ฟิลด์ 'tags' ซึ่งเป็นอาร์เรย์ของสตริง.
ตัวอย่าง
สอบถามเรื่องการขายปัญหาการเรียกเก็บเงินคำขอฟีเจอร์ลูกค้า VIP
|
|||
|
ประเภทบริการ
ServiceType
|
หมวดหมู่หรือประเภทของคำขอบริการ เช่น เหตุขัดข้อง คำถาม ปัญหา หรืองาน. | ||
|
คำอธิบาย
ประเภทบริการใช้จัดหมวดหมู่ลักษณะของคำขอบริการ Zendesk ใช้ฟิลด์ 'type' เพื่อแยกประเภทการติดต่อขอรับการสนับสนุน การจัดประเภทตั้งแต่ต้นช่วยส่งทิกเก็ตไปยังทีมที่เหมาะสมและใช้กระบวนการที่ถูกต้อง. แอตทริบิวต์นี้จำเป็นต่อการกรองและเปรียบเทียบข้อมูล ช่วยให้นักวิเคราะห์ตรวจสอบลำดับกระบวนการของคำขอแต่ละประเภท ซึ่งมักมีขั้นตอนการแก้ไขและ SLA แตกต่างกัน และเป็นมิติหลักในแดชบอร์ดประสิทธิภาพเจ้าหน้าที่และทีม เพื่อดูว่าใครเหมาะกับการจัดการคำขอแต่ละประเภท.
เหตุผลที่สำคัญ
ใช้จัดหมวดหมู่คำขอเพื่อแยกวิเคราะห์กระบวนการแต่ละประเภท เช่น เหตุขัดข้องและคำถาม ซึ่งมีขั้นตอนการดำเนินงานต่างกัน.
แหล่งข้อมูล
Zendesk Tickets API ฟิลด์ 'type'.
ตัวอย่าง
คำถามเหตุขัดข้องปัญหางาน
|
|||
|
ระดับความสำคัญของคำขอ
RequestPriority
|
ระดับความสำคัญที่กำหนดให้คำขอบริการ เช่น ต่ำ ปกติ สูง หรือเร่งด่วน. | ||
|
คำอธิบาย
ระดับความสำคัญของคำขอใช้ระบุความเร่งด่วนของคำขอบริการ ระดับนี้มักกำหนดเป้าหมายเวลาแก้ไขและนโยบาย SLA ที่ใช้กับทิกเก็ต ระบบหรือผู้ใช้อาจกำหนดระดับความสำคัญตั้งแต่แรก และเจ้าหน้าที่อาจเปลี่ยนแปลงได้ระหว่างวงจรของทิกเก็ต. แอตทริบิวต์นี้สำคัญต่อการแบ่งกลุ่มและวิเคราะห์หาสาเหตุ ช่วยตรวจสอบว่าทิกเก็ตที่มีความสำคัญสูงได้รับการแก้ไขเร็วกว่าทิกเก็ตที่มีความสำคัญต่ำหรือไม่ และเป็นปัจจัยหลักในแดชบอร์ด 'แนวโน้มการยกระดับคำขอบริการ' และ 'การปฏิบัติตาม SLA'.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มคำขอตามความเร่งด่วน ซึ่งสำคัญต่อการวิเคราะห์การปฏิบัติตาม SLA และช่วยให้จัดการปัญหาสำคัญได้ทันท่วงที.
แหล่งข้อมูล
Zendesk Tickets API ฟิลด์ 'priority'.
ตัวอย่าง
ต่ำปกติสูงเร่งด่วน
|
|||
|
สถานะคำขอ
RequestStatus
|
สถานะของคำขอบริการในเวลาที่เกิดเหตุการณ์ เช่น ใหม่ เปิด หรือรอดำเนินการ. | ||
|
คำอธิบาย
สถานะคำขอแสดงสถานะของทิกเก็ต ณ เวลาหนึ่ง Zendesk มีสถานะมาตรฐานหลายแบบ เช่น ใหม่ เปิด รอดำเนินการ พักไว้ แก้ไขแล้ว และปิด ซึ่งแสดงความคืบหน้าของคำขอตลอดวงจร การเปลี่ยนฟิลด์นี้เป็นตัวกระตุ้นหลักในการสร้างกิจกรรมลงในบันทึกเหตุการณ์. การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะเป็นส่วนสำคัญของการวิเคราะห์คอขวด ช่วยระบุว่าทิกเก็ตติดค้างอยู่ตรงไหน เช่น ใช้เวลานานเกินไปในสถานะ 'รอดำเนินการ' หรือ 'พักไว้' การทำความเข้าใจการเปลี่ยนสถานะยังช่วยค้นหาวงจรการทำงานซ้ำด้วย.
เหตุผลที่สำคัญ
การติดตามสถานะเป็นพื้นฐานในการทำความเข้าใจความคืบหน้าของคำขอ และระยะเวลาที่อยู่ในสถานะรอหรือกำลังดำเนินการ.
แหล่งข้อมูล
Zendesk Tickets API ฟิลด์ 'status'.
ตัวอย่าง
ใหม่เปิดรอดำเนินการแก้ไขแล้วปิดแล้ว
|
|||
|
แก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรกหรือไม่
IsFirstContactResolution
|
ระบุว่าคำขอได้รับการแก้ไขโดยเจ้าหน้าที่คนแรกที่ได้รับมอบหมาย โดยไม่มีการเปลี่ยนผู้รับผิดชอบหรือการตอบกลับจากผู้ส่งคำขอหรือไม่. | ||
|
คำอธิบาย
การแก้ไขได้ตั้งแต่การติดต่อครั้งแรก (FCR) เป็นเมตริกสำคัญที่แสดงว่าปัญหาของลูกค้าได้รับการแก้ไขในการติดต่อครั้งเดียว แอตทริบิวต์ที่คำนวณนี้เป็นค่าสถานะแบบบูลีน โดยมีค่าเป็นจริงเมื่อเจ้าหน้าที่คนแรกที่ได้รับมอบหมายแก้ไขทิกเก็ตได้ โดยไม่มีการเปลี่ยนผู้รับผิดชอบและมีการตอบกลับจากเจ้าหน้าที่เพียงครั้งเดียว แอตทริบิวต์นี้สนับสนุน KPI 'อัตราการแก้ไขได้ตั้งแต่การติดต่อครั้งแรก' โดยตรง การวิเคราะห์ลักษณะของกรณีที่แก้ไขได้ตั้งแต่ครั้งแรกช่วยให้เห็นแนวทางปรับปรุงกระบวนการ ส่วนกรณีที่ไม่ผ่าน FCR อาจชี้ให้เห็นโอกาสในการฝึกอบรมเจ้าหน้าที่ ปรับปรุงบทความในฐานความรู้ หรือคัดแยกคำขอเบื้องต้นให้มีประสิทธิภาพยิ่งขึ้น.
เหตุผลที่สำคัญ
วัดความสามารถในการแก้ไขปัญหาให้จบในการติดต่อครั้งเดียว ซึ่งช่วยเพิ่มทั้งความพึงพอใจของลูกค้าและประสิทธิภาพการปฏิบัติการ.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณจากข้อมูลหลายส่วน โดยต้องวิเคราะห์บันทึกเหตุการณ์ของทิกเก็ตเพื่อตรวจสอบการเปลี่ยนผู้รับผิดชอบและจำนวนการตอบกลับสาธารณะจากเจ้าหน้าที่.
ตัวอย่าง
truefalse
|
|||
|
คะแนนความพึงพอใจ
SatisfactionRating
|
คะแนนความพึงพอใจที่ผู้ส่งคำขอให้หลังจากแก้ไขทิกเก็ตแล้ว. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกความคิดเห็นของลูกค้าต่อประสบการณ์การรับบริการสนับสนุน โดยทั่วไปจะเก็บผ่านแบบสำรวจหลังทำเครื่องหมายทิกเก็ตว่าแก้ไขแล้ว คะแนนที่พบบ่อย ได้แก่ 'ดี' หรือ 'ไม่ดี' และบางครั้งมีความคิดเห็นเพิ่มเติม. คะแนนความพึงพอใจเป็นตัวชี้วัดผลลัพธ์ที่สำคัญ เมื่อนำรูปแบบกระบวนการมาเทียบกับคะแนน จะเห็นได้ว่าพฤติกรรมใดในกระบวนการทำให้ลูกค้าพึงพอใจหรือไม่พอใจ ตัวอย่างเช่น การวิเคราะห์อาจพบว่าอัตราการมอบหมายงานใหม่ที่สูงหรือระยะเวลาแก้ไขที่นานสัมพันธ์กับคะแนนความพึงพอใจที่ต่ำ.
เหตุผลที่สำคัญ
เชื่อมโยงการดำเนินกระบวนการกับผลลัพธ์ของลูกค้าโดยตรง ช่วยระบุพฤติกรรมในกระบวนการที่ส่งผลต่อความพึงพอใจของลูกค้า.
แหล่งข้อมูล
Zendesk Tickets API ฟิลด์ 'satisfaction_rating.score' หรือ 'satisfaction_rating.reason'.
ตัวอย่าง
ดีไม่ดีเสนอแล้ว
|
|||
|
จำนวนครั้งที่มอบหมายงานให้ Agent ใหม่
AgentReassignmentCount
|
จำนวนครั้งทั้งหมดที่มีการเปลี่ยนผู้รับผิดชอบคำขอจากเจ้าหน้าที่คนหนึ่งไปยังอีกคนหนึ่ง. | ||
|
คำอธิบาย
แอตทริบิวต์นี้นับจำนวนครั้งที่ฟิลด์ 'assignee_id' ของทิกเก็ตเปลี่ยนแปลง หากทิกเก็ตหนึ่งมีการเปลี่ยนผู้รับผิดชอบหลายครั้ง อาจสะท้อนปัญหาในกระบวนการได้หลายอย่าง เช่น การส่งคำขอไปยังทีมผิดตั้งแต่แรก เจ้าหน้าที่มีความรู้ไม่เพียงพอ หรือคำขอซับซ้อนเกินกว่าที่เจ้าหน้าที่คนเดียวจะจัดการได้ เมตริกนี้ใช้วัดประสิทธิภาพของกระบวนการ และสนับสนุน KPI 'อัตราการเปลี่ยนผู้รับผิดชอบ' โดยตรง การวิเคราะห์กรณีที่มีการเปลี่ยนผู้รับผิดชอบบ่อยจะช่วยให้เห็นโอกาสในการปรับปรุงกฎการส่งต่องาน การฝึกอบรมเจ้าหน้าที่ หรือแหล่งข้อมูลความรู้ เพื่อให้คำขอไปถึงผู้รับผิดชอบที่เหมาะสมได้เร็วขึ้น.
เหตุผลที่สำคัญ
ช่วยวัดจำนวนครั้งที่มีการส่งต่องานภายในและชี้ให้เห็นจุดติดขัดในกระบวนการ เพราะการเปลี่ยนผู้รับผิดชอบบ่อยครั้งมักทำให้งานล่าช้าและไม่มีประสิทธิภาพ.
แหล่งข้อมูล
คำนวณจากจำนวนครั้งที่ค่า 'assignee_id' เปลี่ยนแปลงใน Zendesk Ticket Audits API ของแต่ละทิกเก็ต.
ตัวอย่าง
013
|
|||
|
ชื่อนโยบาย SLA
SlaPolicyName
|
ชื่อของนโยบายข้อตกลงระดับการให้บริการ (SLA) ที่ใช้กับคำขอ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุนโยบาย SLA ที่กำหนดเวลาเป้าหมายในการตอบกลับและแก้ไขคำขอบริการ โดยทั่วไปนโยบายจะพิจารณาจากปัจจัยต่างๆ เช่น ความสำคัญและประเภทของคำขอ หรือระดับการสมัครใช้บริการของลูกค้า การทราบนโยบาย SLA ที่ใช้กับคำขอเป็นสิ่งสำคัญสำหรับแดชบอร์ด 'การวิเคราะห์การปฏิบัติตาม SLA และการผิด SLA' เพราะช่วยให้มีบริบทที่จำเป็นต่อการประเมินผลการดำเนินงาน โดยแต่ละนโยบายอาจกำหนดเป้าหมายต่างกัน จึงประเมินได้อย่างเป็นธรรมและแม่นยำว่าทิกเก็ตบรรลุเป้าหมายระดับบริการที่กำหนดไว้หรือไม่.
เหตุผลที่สำคัญ
แสดงบริบทสำหรับการวิเคราะห์ SLA โดยระบุว่าคำขอถูกวัดผลเทียบกับเป้าหมายชุดใด เพื่อให้รายงานการปฏิบัติตามข้อกำหนดมีความถูกต้อง.
แหล่งข้อมูล
Zendesk Ticket Metrics API โดยข้อมูล SLA มักเชื่อมโยงกับเมตริกของทิกเก็ต.
ตัวอย่าง
เร่งด่วน: ตอบกลับภายใน 1 ชั่วโมงมาตรฐาน: แก้ไขภายใน 24 ชั่วโมงSLA สำหรับลูกค้าพรีเมียม
|
|||
|
ชื่อผู้ส่งคำขอ
RequestorName
|
ชื่อผู้ใช้ปลายทางหรือลูกค้าที่ส่งคำขอบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุบุคคลที่เริ่มส่งคำขอบริการ การเชื่อมโยงคำขอกับลูกค้าแต่ละรายช่วยให้เห็นกระบวนการสนับสนุนจากมุมมองของผู้ใช้. ในการวิเคราะห์กระบวนการ สามารถใช้ข้อมูลผู้ส่งคำขอเพื่อดูรูปแบบของลูกค้าหรือกลุ่มลูกค้าได้ เช่น ตรวจสอบว่าลูกค้าบางรายใช้เวลาแก้ไขปัญหานานกว่าปกติ หรือมีการทำงานซ้ำบ่อยกว่าหรือไม่ ซึ่งอาจบ่งชี้ถึงปัญหาเกี่ยวกับผลิตภัณฑ์หรือบริการที่ลูกค้าใช้อยู่.
เหตุผลที่สำคัญ
เชื่อมโยงกระบวนการกับลูกค้า ช่วยวิเคราะห์ปัญหาเฉพาะราย คำขอที่เกิดซ้ำ และระดับความพึงพอใจ.
แหล่งข้อมูล
Zendesk Users API โดยเชื่อมข้อมูลจาก 'requester_id' ในการตอบกลับของ Tickets API.
ตัวอย่าง
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
เป็นการทำงานซ้ำหรือไม่
IsRework
|
ระบุว่าคำขอบริการถูกเปิดอีกครั้งหลังจากแก้ไขแล้วหรือไม่. | ||
|
คำอธิบาย
ค่าสถานะแบบบูลีนนี้ใช้ระบุกรณีที่ต้องแก้ไขงานซ้ำ โดยทั่วไปถือว่าคำขอบริการเป็นงานแก้ไขซ้ำเมื่อสถานะเปลี่ยนจาก 'แก้ไขแล้ว' กลับไปเป็นสถานะเปิด แสดงว่าการแก้ไขครั้งแรกยังไม่เพียงพอและลูกค้าต้องติดต่อกลับเกี่ยวกับปัญหาเดิม แอตทริบิวต์นี้จำเป็นต่อการคำนวณ KPI 'อัตราการแก้ไขคำขอบริการซ้ำ' และใช้กับแดชบอร์ด 'การวิเคราะห์งานแก้ไขซ้ำและการเปิดคำขออีกครั้ง' เมื่อนักวิเคราะห์ระบุกรณีที่ต้องแก้ไขซ้ำได้ ก็จะแยกเส้นทางกระบวนการที่ไม่มีประสิทธิภาพออกมาวิเคราะห์ หาสาเหตุที่มีการเปิดคำขออีกครั้ง และปรับปรุงการแก้ไขปัญหาให้จบตั้งแต่การติดต่อครั้งแรกได้.
เหตุผลที่สำคัญ
ชี้ให้เห็นความล้มเหลวของกระบวนการที่แก้ไขปัญหาไม่จบในครั้งเดียว ซึ่งสะท้อนปัญหาด้านคุณภาพและประสิทธิภาพที่ส่งผลต่อความพึงพอใจของลูกค้าโดยตรง.
แหล่งข้อมูล
คำนวณจากการวิเคราะห์ลำดับสถานะของทิกเก็ตใน Zendesk Ticket Audits API การเปลี่ยนสถานะจาก 'แก้ไขแล้ว' เป็น 'เปิด' หมายถึงมีการแก้ไขงานซ้ำ.
ตัวอย่าง
truefalse
|
|||
|
ผิด SLA หรือไม่
IsSlaBreached
|
ระบุว่าคำขอบริการไม่เป็นไปตามเป้าหมาย SLA ข้อใดข้อหนึ่งหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เป็นค่าสถานะแบบบูลีนหรือแบบจัดหมวดหมู่ ซึ่งแสดงผล SLA ของทิกเก็ต เช่น 'บรรลุเป้าหมาย', 'ผิด SLA' หรือ 'กำลังดำเนินการ' โดยพิจารณาจากการเปรียบเทียบเวลาตอบกลับหรือเวลาแก้ไขจริงกับเป้าหมายที่ระบุไว้ในนโยบาย SLA ที่ใช้ แอตทริบิวต์นี้สำคัญต่อแดชบอร์ด 'การวิเคราะห์การปฏิบัติตาม SLA และการผิด SLA' เพราะช่วยให้นับและแสดงภาพทิกเก็ตที่เป็นไปตามหรือไม่เป็นไปตามข้อกำหนดได้ง่าย จากนั้นจึงวิเคราะห์ลักษณะของกระบวนการในทิกเก็ตที่ผิด SLA เพื่อหาสาเหตุ เช่น เวลารอนานหรือการเปลี่ยนผู้รับผิดชอบหลายครั้ง.
เหตุผลที่สำคัญ
วัดผลการดำเนินงานเทียบกับข้อตกลงระดับการให้บริการโดยตรง ซึ่งเป็นตัวชี้วัดสำคัญของคุณภาพบริการและความพึงพอใจของลูกค้า.
แหล่งข้อมูล
ได้จาก Zendesk Ticket Metrics API ซึ่งให้ข้อมูลสถานะ SLA ของแต่ละทิกเก็ต.
ตัวอย่าง
เป็นไปตามเป้าหมายผิด SLAกำลังดำเนินการ
|
|||
|
เวลาสิ้นสุด
EndTime
|
วันที่และเวลาที่แน่นอนซึ่งกิจกรรมเสร็จสิ้น. | ||
|
คำอธิบาย
เวลาสิ้นสุดระบุว่ากิจกรรมเสร็จเมื่อใด สำหรับเหตุการณ์ Zendesk หลายรายการ กิจกรรมเกิดขึ้นทันที ดังนั้นเวลาสิ้นสุดจึงตรงกับเวลาเริ่มต้น แต่สำหรับกิจกรรมที่อิงตามสถานะ เช่น 'พักคำขอไว้' เวลาสิ้นสุดคือเวลาที่นำทิกเก็ตออกจากสถานะพักไว้. แอตทริบิวต์นี้จำเป็นต่อการคำนวณระยะเวลาของกิจกรรมแต่ละรายการ ซึ่งเป็นข้อมูลสำคัญในการวิเคราะห์คอขวด เมื่อนำเวลาเริ่มต้นมาเทียบกับเวลาสิ้นสุด จะวัดเวลาที่ใช้ดำเนินการในแต่ละขั้นตอนได้โดยตรง และช่วยระบุว่าขั้นตอนใดใช้เวลามากที่สุด.
เหตุผลที่สำคัญ
ใช้คำนวณระยะเวลาของกิจกรรมแต่ละรายการ ซึ่งสำคัญต่อการระบุคอขวดในกระบวนการและวัดประสิทธิภาพในแต่ละขั้นตอน.
แหล่งข้อมูล
สำหรับเหตุการณ์ที่เกิดขึ้นเป็นครั้งๆ เวลานี้มักตรงกับ StartTime ส่วนระยะเวลาของสถานะจะใช้เวลาประทับของเหตุการณ์ถัดไปที่เปลี่ยนสถานะ.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:20:10Z
|
|||
|
องค์กรของผู้ส่งคำขอ
RequestorOrganization
|
องค์กรหรือบริษัทที่ผู้ส่งคำขอสังกัดอยู่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เชื่อมโยงคำขอบริการกับองค์กรลูกค้าแต่ละแห่ง มีความสำคัญเป็นพิเศษกับการสนับสนุนแบบ B2B ซึ่งข้อตกลงระดับการให้บริการและสัญญาสนับสนุนมักกำหนดในระดับองค์กร. การวิเคราะห์ข้อมูลตามองค์กรช่วยให้เห็นผลการดำเนินงานด้านการสนับสนุนในระดับบริษัท ช่วยระบุองค์กรที่ส่งทิกเก็ตจำนวนมาก พบปัญหาเดิมซ้ำๆ หรือมีคะแนนความพึงพอใจต่ำ ข้อมูลนี้มีประโยชน์ต่อการดูแลลูกค้าและติดตามแนวโน้มความสัมพันธ์กับลูกค้าโดยรวม.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์บริการ B2B โดยจัดกลุ่มคำขอตามบริษัท ซึ่งสำคัญต่อการดูแลความสัมพันธ์กับลูกค้าและ SLA ในระดับองค์กร.
แหล่งข้อมูล
Zendesk Organizations API โดยเชื่อมข้อมูลจาก 'organization_id' ในการตอบกลับของ Tickets API.
ตัวอย่าง
Acme CorporationGlobal Tech Inc.Innovate Solutions
|
|||
กิจกรรมในการจัดการคำขอบริการ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขคำขอบริการแล้ว
|
กิจกรรมนี้บันทึกจุดที่เจ้าหน้าที่ให้วิธีแก้ไขและเปลี่ยนสถานะทิกเก็ตเป็น 'solved' ในมุมมองของเจ้าหน้าที่ถือว่าคำขอเสร็จสมบูรณ์แล้ว แต่ผู้ส่งคำขอยังสามารถเปิดอีกครั้งได้. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายสำคัญที่แสดงว่างานของเจ้าหน้าที่สิ้นสุดลง เวลาที่ใช้จนถึงสถานะนี้เป็นตัวชี้วัดหลักของประสิทธิภาพในการแก้ไขปัญหา.
แหล่งข้อมูล
อนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'status' ของบันทึกการตรวจสอบทิกเก็ต เมื่อค่าใหม่เป็น 'solved'.
บันทึก
อนุมานจากเหตุการณ์ 'Change' ในบันทึกการตรวจสอบ เมื่อสถานะเปลี่ยนเป็น 'solved'.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิดคำขอบริการแล้ว
|
หมายถึงการปิดคำขอบริการอย่างถาวร ทิกเก็ตจะเปลี่ยนเป็นสถานะ 'closed' โดยอัตโนมัติหลังจากอยู่ในสถานะ 'solved' ตามระยะเวลาที่กำหนด และจะเปิดอีกครั้งไม่ได้. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดที่แน่นอนของกระบวนการคำขอบริการ และใช้เป็นจุดสิ้นสุดในการคำนวณระยะเวลาของเคสทั้งหมด.
แหล่งข้อมูล
อนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'status' ของบันทึกการตรวจสอบทิกเก็ต เมื่อค่าใหม่เป็น 'closed'.
บันทึก
อนุมานจากเหตุการณ์ 'Change' ในบันทึกการตรวจสอบ เมื่อสถานะเปลี่ยนเป็น 'closed'.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิดคำขอบริการอีกครั้ง
|
เกิดขึ้นเมื่อผู้ส่งคำขอตอบกลับคำขอที่มีสถานะ 'solved' ทำให้สถานะเปลี่ยนกลับเป็น 'open' โดยอัตโนมัติ แสดงว่าการแก้ไขที่เสนอไปยังไม่เพียงพอ. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นตัวชี้วัดหลักของการทำงานซ้ำ การวิเคราะห์ความถี่ช่วยวัดคุณภาพการแก้ไขปัญหาและระบุสาเหตุที่ลูกค้าไม่พึงพอใจ.
แหล่งข้อมูล
อนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'status' ของบันทึกการตรวจสอบทิกเก็ต เมื่อค่าเดิมเป็น 'solved' และค่าใหม่เป็น 'open'.
บันทึก
อนุมานจากการเปลี่ยนสถานะจาก 'solved' เป็น 'open'.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอให้เจ้าหน้าที่
|
กิจกรรมนี้เกิดขึ้นเมื่อมีการมอบหมายคำขอบริการให้เจ้าหน้าที่คนใดคนหนึ่งเป็นครั้งแรก โดยอนุมานจากเหตุการณ์ 'Change' ในบันทึกการตรวจสอบทิกเก็ต เมื่อฟิลด์ 'assignee_id' เปลี่ยนจากค่าว่างหรือรหัสกลุ่มเป็นรหัสผู้ใช้รายบุคคล. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นของการทำงานจริงโดยเจ้าหน้าที่ และสำคัญต่อการวัดเวลาตอบกลับครั้งแรก เวลารอก่อนการมอบหมายครั้งแรก และการกระจายภาระงานของเจ้าหน้าที่.
แหล่งข้อมูล
อนุมานจากเหตุการณ์ 'Change' ครั้งแรกของฟิลด์ 'assignee_id' ในบันทึกการตรวจสอบทิกเก็ต ซึ่งกำหนดรหัสผู้ใช้รายใดรายหนึ่ง.
บันทึก
อนุมานจากเหตุการณ์เปลี่ยนแปลงครั้งแรกที่กำหนดฟิลด์ 'assignee_id' ให้กับเจ้าหน้าที่.
ประเภทเหตุการณ์
inferred
|
|||
|
ไม่เป็นไปตามเป้าหมาย SLA
|
กิจกรรมนี้บันทึกเวลาที่คำขอบริการไม่เป็นไปตามเป้าหมาย SLA ที่กำหนด เช่น เวลาตอบกลับครั้งแรกหรือเวลาแก้ไขปัญหา Zendesk บันทึกเป็นเหตุการณ์โดยตรงเมื่อไม่เป็นไปตามเป้าหมาย. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้สำคัญต่อการติดตามการปฏิบัติตามข้อกำหนด และเป็นข้อมูลหลักสำหรับ KPI อัตราการปฏิบัติตาม SLA โดยระบุจุดที่ไม่สามารถทำตามคำมั่นด้านบริการได้.
แหล่งข้อมูล
ดึงข้อมูลจากเหตุการณ์ 'SLABreach' ในเหตุการณ์ทิกเก็ต Zendesk หรือบันทึกการตรวจสอบ โดยเหตุการณ์จะระบุว่าไม่เป็นไปตามตัวชี้วัด SLA ใด.
บันทึก
ระบุจากเหตุการณ์ 'SLABreach' ที่บันทึกไว้โดยตรงในข้อมูลทิกเก็ต.
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งคำตอบสาธารณะแล้ว
|
กิจกรรมนี้บันทึกการสื่อสารที่เจ้าหน้าที่ส่งถึงผู้ส่งคำขอ โดยบันทึกเป็นเหตุการณ์ 'Comment' ในข้อมูลทิกเก็ต Zendesk เมื่อแอตทริบิวต์ 'public' มีค่าเป็น true. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์เหล่านี้สำคัญต่อการวิเคราะห์ความถี่ในการสื่อสาร การวัดเวลาตอบกลับของเจ้าหน้าที่ และการระบุจำนวนครั้งที่ต้องติดต่อกันก่อนแก้ไขปัญหาได้.
แหล่งข้อมูล
นี่คือเหตุการณ์ 'Comment' ที่บันทึกไว้อย่างชัดเจนในข้อมูลทิกเก็ต รายละเอียดเหตุการณ์มีแอตทริบิวต์ 'public: true' เพื่อแยกจากบันทึกภายใน.
บันทึก
ดึงข้อมูลจากเหตุการณ์ 'Comment' ของทิกเก็ตที่ตั้งค่าแฟล็ก 'public' เป็น true.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้างคำขอบริการ
|
เป็นจุดเริ่มต้นของวงจรคำขอบริการ เมื่อผู้ส่งคำขอส่งทิกเก็ตใหม่ผ่านช่องทางใดช่องทางหนึ่ง ระบบบันทึกเหตุการณ์นี้เป็น 'Create' ในบันทึกการตรวจสอบทิกเก็ตของ Zendesk จึงใช้ระบุเวลาเริ่มต้นของกระบวนการได้อย่างชัดเจน. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นเหตุการณ์เริ่มต้นหลักของคำขอบริการทุกคำขอ จึงจำเป็นต่อการคำนวณรอบเวลาตั้งแต่ต้นจนจบและวิเคราะห์ปริมาณคำขอที่เข้ามา.
แหล่งข้อมูล
บันทึกเป็นประเภทเหตุการณ์ 'Create' ในบันทึกการตรวจสอบทิกเก็ตของ Zendesk เวลาของเหตุการณ์นี้คือเวลาที่สร้างทิกเก็ตคำขอบริการ.
บันทึก
บันทึกโดยตรงจากเหตุการณ์ 'Create' ในบันทึกการตรวจสอบทิกเก็ต.
ประเภทเหตุการณ์
explicit
|
|||
|
เปลี่ยนระดับความสำคัญ
|
ระบุว่ามีการปรับระดับความสำคัญของคำขอบริการ เช่น 'ต่ำ' 'ปกติ' 'สูง' หรือ 'เร่งด่วน' โดยบันทึกเป็นเหตุการณ์ 'Change' ของฟิลด์ 'priority' ในบันทึกการตรวจสอบทิกเก็ต. | ||
|
เหตุผลที่สำคัญ
การวิเคราะห์การเปลี่ยนระดับความสำคัญช่วยให้เห็นว่าคำขอใดมีความเร่งด่วนเพิ่มขึ้นตามเวลา และประเมินได้ว่ามีการจัดลำดับความสำคัญอย่างเหมาะสมหรือไม่.
แหล่งข้อมูล
บันทึกเป็นเหตุการณ์ 'Change' ในฟิลด์ 'priority' ภายในบันทึกการตรวจสอบของทิกเก็ต Zendesk โดยแสดงค่าก่อนหน้าและค่าใหม่.
บันทึก
อนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'priority' ของบันทึกการตรวจสอบ.
ประเภทเหตุการณ์
inferred
|
|||
|
พักคำขอไว้
|
กิจกรรมนี้เกิดขึ้นเมื่อเปลี่ยนสถานะคำขอบริการเป็น 'on-hold' โดยทั่วไปหมายถึงเจ้าหน้าที่กำลังรอข้อมูลจากผู้ส่งคำขอหรือบุคคลภายนอก อนุมานจากเหตุการณ์เปลี่ยนสถานะ. | ||
|
เหตุผลที่สำคัญ
ช่วยแยกและวัดเวลารอที่อยู่นอกเหนือการควบคุมโดยตรงของทีมสนับสนุน ทำให้เห็นเวลาที่เจ้าหน้าที่ใช้จัดการคำขอได้แม่นยำขึ้น.
แหล่งข้อมูล
อนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'status' ของบันทึกการตรวจสอบทิกเก็ต เมื่อค่าใหม่เป็น 'on-hold'.
บันทึก
อนุมานจากเหตุการณ์ 'Change' ในบันทึกการตรวจสอบ เมื่อสถานะเปลี่ยนเป็น 'on-hold'.
ประเภทเหตุการณ์
inferred
|
|||
|
เพิ่มบันทึกภายในแล้ว
|
เจ้าหน้าที่เพิ่มบันทึกหรือความคิดเห็นภายในในคำขอบริการ ซึ่งเจ้าหน้าที่คนอื่นเท่านั้นที่มองเห็น บันทึกเป็นเหตุการณ์ 'Comment' เมื่อแอตทริบิวต์ 'public' มีค่าเป็น false. | ||
|
เหตุผลที่สำคัญ
การติดตามบันทึกภายในช่วยให้เห็นการทำงานร่วมกันระหว่างเจ้าหน้าที่หรือทีม ซึ่งอาจทำให้เกิดความล่าช้า หรือช่วยให้แก้ปัญหาได้อย่างมีประสิทธิภาพ.
แหล่งข้อมูล
นี่คือเหตุการณ์ 'Comment' ที่บันทึกไว้อย่างชัดเจนในข้อมูลทิกเก็ต รายละเอียดเหตุการณ์มีแอตทริบิวต์ 'public: false' ซึ่งระบุว่าเป็นบันทึกภายใน.
บันทึก
ดึงข้อมูลจากเหตุการณ์ 'Comment' ของทิกเก็ตที่ตั้งค่าแฟล็ก 'public' เป็น false.
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมายเจ้าหน้าที่ใหม่
|
หมายถึงการโอนความรับผิดชอบของคำขอบริการจากเจ้าหน้าที่คนหนึ่งไปยังอีกคนหนึ่ง อนุมานจากเหตุการณ์ 'Change' ที่เกิดขึ้นภายหลังในฟิลด์ 'assignee_id' หลังจากการมอบหมายครั้งแรก. | ||
|
เหตุผลที่สำคัญ
การติดตามการมอบหมายใหม่เป็นสิ่งสำคัญในการคำนวณ KPI อัตราการมอบหมายเจ้าหน้าที่ใหม่ ซึ่งช่วยระบุจุดไม่มีประสิทธิภาพในกระบวนการ การส่งต่อผิดทีม หรือช่องว่างด้านความรู้.
แหล่งข้อมูล
อนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'assignee_id' ของบันทึกการตรวจสอบทิกเก็ต โดยไม่นับเหตุการณ์มอบหมายครั้งแรกของทิกเก็ต.
บันทึก
อนุมานจากเหตุการณ์ 'Change' ครั้งที่สองเป็นต้นไปในฟิลด์ 'assignee_id'.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกระดับคำขอแล้ว
|
หมายถึงการส่งต่อคำขอบริการอย่างเป็นทางการไปยังทีมสนับสนุนระดับสูงกว่า ทีมอื่น หรือผู้บริหาร โดยทั่วไปอนุมานจากการเปลี่ยนกลุ่มที่ได้รับมอบหมายในทิกเก็ต หรือการเปลี่ยนฟิลด์กำหนดเองที่ใช้ติดตามการยกระดับ. | ||
|
เหตุผลที่สำคัญ
การติดตามคำขอที่ถูกยกระดับช่วยให้ระบุคำขอที่ซับซ้อน ความจำเป็นในการฝึกอบรมเจ้าหน้าที่ด่านหน้า และปัญหาเชิงระบบที่ต้องให้ผู้มีอำนาจระดับสูงเข้ามาจัดการ.
แหล่งข้อมูล
นี่ไม่ใช่เหตุการณ์มาตรฐาน ต้องอนุมานจากเหตุการณ์ 'Change' ในฟิลด์ 'group_id' ที่เปลี่ยนเป็นกลุ่มสำหรับการยกระดับ หรือจากการเปลี่ยนฟิลด์ทิกเก็ตที่กำหนดเองเพื่อใช้ติดตามการยกระดับคำขอ.
บันทึก
อนุมานจากการเปลี่ยน 'group_id' หรือฟิลด์กำหนดเอง 'escalation'.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มใช้เป้าหมาย SLA
|
ระบุเวลาที่นำนโยบายข้อตกลงระดับการให้บริการ (SLA) มาใช้กับทิกเก็ตคำขอบริการ ระบบจะบันทึกเหตุการณ์นี้โดยตรงเมื่อคุณสมบัติของทิกเก็ตตรงกับเงื่อนไขของนโยบาย SLA ที่ใช้งานอยู่. | ||
|
เหตุผลที่สำคัญ
การติดตามเวลาที่เริ่มใช้ SLA มีความสำคัญต่อการตรวจสอบการปฏิบัติตามข้อกำหนด วิเคราะห์ความเสี่ยงที่จะผิด SLA และทำความเข้าใจกรอบเวลาการให้บริการที่คาดหวังสำหรับคำขอแต่ละประเภท.
แหล่งข้อมูล
บันทึกจากเหตุการณ์ 'SLAPolicyApplied' ในข้อมูลเหตุการณ์หรือบันทึกการตรวจสอบทิกเก็ตของ Zendesk โดยเหตุการณ์นี้ระบุนโยบายที่ตรงตามเงื่อนไข.
บันทึก
ระบุจากเหตุการณ์ 'SLAPolicyApplied' ที่บันทึกไว้อย่างชัดเจนในข้อมูลทิกเก็ต.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงกระบวนการจัดการคำขอบริการได้วันนี้ ใช้เทมเพลตข้อมูลนี้เพื่อค้นหาคอขวดและเพิ่มประสิทธิภาพใน Zendesk Support.
ปรับปรุงการจัดการคำขอบริการ ลดความล่าช้าได้ตั้งแต่วันนี้.
ลดความล่าช้าในการดำเนินงานและความไม่พอใจของผู้ใช้ พร้อมทำงานอัตโนมัติได้ 70%.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าได้รวดเร็ว.