เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ

Zendesk Support
เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ

เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ

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

แอตทริบิวต์สำหรับการจัดการคำขอบริการ

ฟิลด์ข้อมูลที่แนะนำให้ใส่ในบันทึกเหตุการณ์เพื่อวิเคราะห์การจัดการคำขอบริการใน Zendesk Support.
5 จำเป็น 7 แนะนำ 9 ไม่บังคับ
ชื่อ คำอธิบาย
กิจกรรม
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
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการจัดการคำขอบริการ

ขั้นตอนและจุดสำคัญของกระบวนการที่ควรบันทึกในบันทึกเหตุการณ์ เพื่อค้นหาเส้นทางการทำงานของคำขอบริการได้อย่างถูกต้อง.
7 แนะนำ 6 ไม่บังคับ
กิจกรรม คำอธิบาย
แก้ไขคำขอบริการแล้ว
กิจกรรมนี้บันทึกจุดที่เจ้าหน้าที่ให้วิธีแก้ไขและเปลี่ยนสถานะทิกเก็ตเป็น '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

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

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

ปรับปรุงการจัดการคำขอบริการ ลดความล่าช้าได้ตั้งแต่วันนี้.

ลดความล่าช้าในการดำเนินงานและความไม่พอใจของผู้ใช้ พร้อมทำงานอัตโนมัติได้ 70%.

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

ไม่ต้องใช้บัตรเครดิต ตั้งค่าได้รวดเร็ว.