เทมเพลตข้อมูลบริการลูกค้าของคุณ

Microsoft Dynamics 365 Customer Service
เทมเพลตข้อมูลบริการลูกค้าของคุณ

เทมเพลตข้อมูลบริการลูกค้าของคุณ

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

แอตทริบิวต์บริการลูกค้า

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

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

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

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

แหล่งข้อมูล

นี่คือคีย์หลักของเอนทิตี Case (incident) ใน Microsoft Dynamics 365 Customer Service.

ตัวอย่าง
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
กิจกรรม
ActivityName
ชื่อของเหตุการณ์ทางธุรกิจที่เกิดขึ้น ณ เวลาใดเวลาหนึ่งสำหรับคำขอรับบริการ.
คำอธิบาย

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

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

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

แหล่งข้อมูล

โดยทั่วไปจะได้จากการจับคู่การเปลี่ยนสถานะ (statuscode) หรือเหตุการณ์เฉพาะจากเอนทิตีที่เกี่ยวข้อง เช่น Tasks, Emails หรือ Phone Calls กับชื่อกิจกรรมมาตรฐาน

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

แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูลเหตุการณ์ สำหรับกระบวนการนี้จะแสดง Microsoft Dynamics 365 Customer Service เป็นระบบต้นทางเสมอ หากมีหลายระบบ ฟิลด์นี้มีความสำคัญต่อการแยกแหล่งข้อมูลและตรวจสอบที่มาของข้อมูล.

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

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

แหล่งข้อมูล

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

ตัวอย่าง
Microsoft Dynamics 365 Customer Service
เวลาเริ่มต้น
EventTime
เวลาประทับที่ระบุว่ากิจกรรมเกิดขึ้นเมื่อใด.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ข้อมูลนี้สอดคล้องกับฟิลด์อย่าง 'createdon' หรือ 'modifiedon' ในเอนทิตี Case (incident) หรือเอนทิตีกิจกรรมที่เกี่ยวข้อง เช่น Email, Task หรือ Phone Call

ตัวอย่าง
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาประทับของการรีเฟรชหรือดึงข้อมูลจากระบบต้นทางครั้งล่าสุด.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ระบบสร้างและประทับค่านี้ลงในชุดข้อมูลขณะดึงข้อมูล.

ตัวอย่าง
2023-10-27T08:00:00Z
ช่องทาง
Channel
ช่องทางการติดต่อที่ใช้ส่งคำขอรับบริการ.
คำอธิบาย

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

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

ช่วยให้เห็นว่าช่องทางติดต่อลูกค้าแต่ละแบบส่งผลต่อประสิทธิภาพของกระบวนการ เวลาแก้ไข และความพึงพอใจของลูกค้าอย่างไร.

แหล่งข้อมูล

ตรงกับฟิลด์ 'Case Origin' (caseorigincode) ในเอนทิตี Case (incident).

ตัวอย่าง
โทรศัพท์อีเมลเว็บแชต
ชื่อเจ้าหน้าที่
AgentName
ชื่อเจ้าหน้าที่บริการลูกค้าหรือผู้ใช้ที่รับผิดชอบกิจกรรม.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ตรงกับฟิลด์ 'Owner' (ownerid) ในเอนทิตี Case (incident) ซึ่งเชื่อมโยงกับเอนทิตี System User (systemuser).

ตัวอย่าง
Alice SmithBob Johnsonระบบ
ชื่อลูกค้า
CustomerName
ชื่อลูกค้าหรือบัญชีที่เชื่อมโยงกับคำขอรับบริการ.
คำอธิบาย

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

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

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

แหล่งข้อมูล

นี่คือฟิลด์ค้นหา 'Customer' (customerid) ในเอนทิตี Case (incident) ซึ่งอ้างอิงได้ทั้งระเบียน Account หรือ Contact.

ตัวอย่าง
Global Tech Inc.Jane DoeInnovate Solutions
ประเภทคำขอรับบริการ
ServiceRequestType
หมวดหมู่หรือประเภทหลักของคำขอรับบริการ.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ข้อมูลนี้มักจัดเก็บไว้ในฟิลด์ 'Subject' (subjectid) หรือฟิลด์หมวดหมู่ที่กำหนดเองในเอนทิตี Case (incident).

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

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

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

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

แหล่งข้อมูล

ตรงกับฟิลด์ 'Priority' (prioritycode) ในเอนทิตี Case (incident).

ตัวอย่าง
ต่ำปกติสูง
เวลาเป้าหมายในการแก้ไขตาม SLA
SlaTargetResolutionTime
เวลาที่ตกลงกันไว้ในสัญญาสำหรับแก้ไขคำขอรับบริการ.
คำอธิบาย

แอตทริบิวต์นี้ระบุระยะเวลาเป้าหมายในการแก้ไขคำขอรับบริการตาม Service Level Agreement (SLA) ที่ใช้งานอยู่ ใช้เป็นเกณฑ์เปรียบเทียบกับผลการดำเนินงานจริง ค่านี้สำคัญต่อแดชบอร์ดติดตามการปฏิบัติตาม SLA และการคำนวณ KPI อัตราการปฏิบัติตาม SLA เพื่อชี้ให้เห็นว่ากระบวนการไม่เป็นไปตามข้อตกลงการให้บริการในจุดใด.

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

เป็นเกณฑ์หลักในการวัดผลการให้บริการเทียบกับข้อตกลง และช่วยวิเคราะห์การปฏิบัติตาม SLA รวมถึงกรณีที่ไม่เป็นไปตามเป้าหมายได้โดยตรง.

แหล่งข้อมูล

กำหนดค่านี้จากการตั้งค่า SLA ใน Dynamics 365 และเชื่อมโยงกับกรณีบริการผ่าน SLA KPI Instances.

ตัวอย่าง
2592008640014400
เหตุผลของสถานะ
StatusReason
ระบุเหตุผลโดยละเอียดของสถานะปัจจุบันของคำขอรับบริการ.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ตรงกับฟิลด์ 'Status Reason' (statuscode) ในเอนทิตี Case (incident).

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

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

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

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

แหล่งข้อมูล

คำนวณโดยเปรียบเทียบ 'ServiceRequestCycleTime' กับ 'SlaTargetResolutionTime'.

ตัวอย่าง
truefalse
แก้ไขได้ตั้งแต่การติดต่อครั้งแรกหรือไม่
IsFirstContactResolution
ระบุว่าคำขอได้รับการแก้ไขระหว่างการติดต่อครั้งแรกหรือไม่.
คำอธิบาย

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
truefalse
คะแนน CSAT
CustomerSatisfactionScore
คะแนนความพึงพอใจที่ลูกค้าให้หลังจากแก้ไขเคสแล้ว.
คำอธิบาย

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

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

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

แหล่งข้อมูล

โดยทั่วไปข้อมูลนี้มาจากเอนทิตีแบบสำรวจที่เกี่ยวข้อง เช่น Customer Voice และเชื่อมกลับไปยังเอนทิตี Case (incident).

ตัวอย่าง
5341
ทีมเจ้าของเคส
OwnerTeam
ทีมที่รับผิดชอบคำขอรับบริการอยู่ในขณะนี้.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ได้มาจากฟิลด์ 'Owner' (ownerid) ในเอนทิตี Case (incident) เมื่อเจ้าของเป็นระเบียน Team ไม่ใช่ System User.

ตัวอย่าง
ทีมสนับสนุนระดับ 1ฝ่ายการเงินทีมผู้เชี่ยวชาญด้านเทคนิค
ผลิตภัณฑ์ที่เกี่ยวข้อง
ProductInvolved
ผลิตภัณฑ์ที่เกี่ยวข้องกับคำขอรับบริการของลูกค้า.
คำอธิบาย

แอตทริบิวต์นี้ระบุผลิตภัณฑ์หรือบริการที่เกี่ยวข้องกับปัญหาของลูกค้า ช่วยแบ่งวิเคราะห์กระบวนการบริการตามผลิตภัณฑ์ เพื่อดูว่าผลิตภัณฑ์ใดทำให้เกิดคำขอรับบริการมากกว่า มีปัญหาซับซ้อนกว่า หรือต้องใช้ทักษะเฉพาะทางของเจ้าหน้าที่ การวิเคราะห์นี้ช่วยปรับปรุงผลิตภัณฑ์และวางแผนทรัพยากร.

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

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

แหล่งข้อมูล

ตรงกับฟิลด์ค้นหา 'Product' (productid) ในเอนทิตี Case (incident).

ตัวอย่าง
เครื่องพิมพ์ Alpha-100ซอฟต์แวร์ Zeta CRMแพ็กเกจข้อมูล Omega
มีการทำงานซ้ำหรือไม่
IsRework
ค่าที่คำนวณเพื่อระบุว่าเคสมีการทำงานซ้ำหรือไม่.
คำอธิบาย

ค่าบูลีนนี้ระบุเคสที่มีการวนกลับไปทำงานซ้ำหรือทำกิจกรรมเดิมหลายครั้ง เช่น มีเหตุการณ์ 'Information Requested From Customer' หลายครั้ง หรือมีเหตุการณ์ 'Case Reactivated' หลังจากแก้ไขแล้ว โดยคำนวณจากการวิเคราะห์ลำดับกิจกรรมเพื่อหารูปแบบที่บ่งชี้ถึงความไม่มีประสิทธิภาพหรือการแก้ปัญหาไม่สำเร็จตั้งแต่ครั้งแรก แอตทริบิวต์นี้สำคัญต่อแดชบอร์ดวิเคราะห์งานซ้ำและการติดต่อลูกค้าซ้ำ.

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

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

แหล่งข้อมูล

คำนวณโดยตรวจหารูปแบบลำดับกิจกรรมที่กำหนด เช่น Resolved -> Reactivated หรือกิจกรรมที่เกิดซ้ำภายในเคสด้วยการวิเคราะห์ process mining.

ตัวอย่าง
truefalse
มีการส่งต่อ
IsEscalated
ระบุว่ามีการส่งต่อคำขอรับบริการไปยังทีมระดับสูงขึ้นหรือไม่.
คำอธิบาย

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

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

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

แหล่งข้อมูล

ตรงกับฟิลด์ 'Is Escalated' (isescalated) ในเอนทิตี Case (incident).

ตัวอย่าง
truefalse
รหัสบทความฐานความรู้
KnowledgeArticleId
รหัสของบทความฐานความรู้ที่เชื่อมโยงกับคำขอรับบริการ.
คำอธิบาย

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

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

ติดตามการใช้ฐานความรู้ เพื่อให้เห็นว่าเจ้าหน้าที่ใช้ทรัพยากรที่มีอยู่ช่วยแก้ปัญหาได้รวดเร็วและสม่ำเสมอหรือไม่.

แหล่งข้อมูล

ข้อมูลนี้อยู่ในความสัมพันธ์ระหว่างเอนทิตี Case (incident) กับ Knowledge Article (knowledgearticle).

ตัวอย่าง
KA-01337KA-02048
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมบริการลูกค้า

ขั้นตอนและจุดสำคัญเหล่านี้ควรบันทึกไว้ในบันทึกเหตุการณ์ เพื่อค้นหาและปรับปรุงกระบวนการบริการลูกค้าได้อย่างแม่นยำ.
6 แนะนำ 7 ไม่บังคับ
กิจกรรม คำอธิบาย
แก้ไขกรณีบริการแล้ว
เหตุการณ์สำคัญนี้ระบุจุดที่เจ้าหน้าที่เห็นว่าปัญหาของลูกค้าได้รับการแก้ไขแล้ว เป็นการดำเนินการที่บันทึกไว้อย่างชัดเจนใน Dynamics 365 โดยสร้างระเบียนกิจกรรม 'Case Resolution' ที่เชื่อมโยงกับกรณีบริการ.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

เหตุการณ์นี้ตรงกับการสร้างระเบียนกิจกรรม 'Resolution' (Case Resolution) โดยเวลาประทับ 'actualend' ในระเบียนนี้เป็นเวลาแก้ไขปัญหา.

บันทึก

ใช้เวลาประทับ 'actualend' หรือ 'createdon' จากระเบียนกิจกรรม 'Resolution' ที่เกี่ยวข้อง.

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

เป็นจุดสิ้นสุดของวงจรกระบวนการในระบบอย่างแท้จริง ระยะเวลาระหว่าง 'Resolved' กับ 'Closed' อาจบ่งชี้ภาระงานธุรการหรือความล่าช้าในการปิดระเบียนให้เรียบร้อย.

แหล่งข้อมูล

ติดตามจากการเปลี่ยนฟิลด์ 'statecode' ในเอนทิตี 'Incident' เป็น 'Canceled' (2) หรือสถานะปิดที่กำหนดเอง โดยดูเวลาที่เปลี่ยนแปลงได้จากประวัติการตรวจสอบ.

บันทึก

ติดตามเวลาที่ 'statecode' เปลี่ยนเป็นสถานะสิ้นสุดสุดท้าย เช่น Canceled/Closed.

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

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

แหล่งข้อมูล

ติดตามการเปลี่ยนแปลงฟิลด์ 'ownerid' ในเอนทิตี 'Incident' โดยดูเวลาที่เปลี่ยนแปลงได้จากบันทึกประวัติการตรวจสอบ.

บันทึก

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

ประเภทเหตุการณ์ explicit
เริ่มจับเวลา SLA
ระบุว่าเริ่มจับเวลา Service Level Agreement (SLA) สำหรับกรณีบริการแล้ว โดยเริ่มนับเวลาตามตัวชี้วัดการให้บริการที่กำหนด เช่น 'First Response By' หรือ 'Resolve By' เหตุการณ์นี้จัดการโดยกลไก SLA ของ Dynamics 365 และมีการบันทึกไว้อย่างชัดเจน.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

บันทึกไว้ในเอนทิตี 'SLA KPI Instance' ซึ่งเชื่อมโยงกับเอนทิตี 'Incident' เวลาประทับ 'createdon' ของระเบียน SLA KPI Instance ที่เกี่ยวข้องเป็นเวลาเริ่มต้น.

บันทึก

ใช้เวลาที่สร้างระเบียน 'SLA KPI Instance' ซึ่งเชื่อมโยงกับกรณีบริการ.

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

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

แหล่งข้อมูล

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

บันทึก

ระบุเวลาที่ฟิลด์ 'ownerid' เปลี่ยนไปยังคิวส่งต่อที่ทราบอยู่.

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

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

แหล่งข้อมูล

ระบบบันทึกเหตุการณ์นี้จากเวลาประทับ 'createdon' ของเอนทิตี 'Incident' (Case) สำหรับระเบียนใหม่แต่ละรายการ.

บันทึก

ใช้เวลาประทับ 'createdon' ของระเบียน Incident.

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

ข้อมูลนี้สำคัญต่อการวัดความล่าช้าที่เกิดจากลูกค้าและทำความเข้าใจ KPI 'เวลารอข้อมูลจากลูกค้า' ช่วยแยกเวลาที่กระบวนการต้องรอข้อมูลจากภายนอกได้.

แหล่งข้อมูล

อนุมานได้จากการเปลี่ยนฟิลด์ 'statuscode' ในเอนทิตี 'Incident' เป็นค่าอย่าง 'On Hold' โดยมีเหตุผลเป็น 'Waiting for Customer' ใช้เวลาที่เปลี่ยนสถานะเป็นเวลาของเหตุการณ์.

บันทึก

ติดตามเวลาที่ statuscode เปลี่ยนเป็นสถานะที่กำหนดไว้ว่า 'รอข้อมูลจากลูกค้า'.

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

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

แหล่งข้อมูล

อนุมานจากการสร้างระเบียนในเอนทิตี 'IncidentKnowledgeBaseRecord' ซึ่งเชื่อมโยงบทความความรู้กับกรณีบริการ โดยใช้เวลาที่สร้างระเบียนนี้.

บันทึก

ใช้เวลาที่เชื่อมโยงบทความความรู้กับ Incident.

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

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

แหล่งข้อมูล

ติดตามเมื่อผู้ใช้อัปเดตฟิลด์ 'workedbyid' ในเอนทิตี 'QueueItem' ที่เชื่อมโยงกับกรณีบริการ หรือเมื่อเจ้าของกรณีบริการเปลี่ยนจากคิวเป็นผู้ใช้.

บันทึก

ระบุเวลาที่มีการกรอกข้อมูลในฟิลด์ 'workedbyid' ของ QueueItem.

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

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

แหล่งข้อมูล

ดึงข้อมูลจากประวัติการตรวจสอบของเอนทิตี 'Incident' โดยเฉพาะการเปลี่ยนแปลงฟิลด์ 'subjectid' หรือฟิลด์จัดหมวดหมู่ที่กำหนดเองอื่นๆ.

บันทึก

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

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

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

แหล่งข้อมูล

ติดตามจากการเปลี่ยนฟิลด์ 'statecode' ในเอนทิตี 'Incident' จาก 'Resolved' (1) กลับเป็น 'Active' (0) โดยบันทึกเวลาที่เปลี่ยนแปลงไว้ในประวัติการตรวจสอบ.

บันทึก

ติดตามเวลาที่ 'statecode' เปลี่ยนจาก Resolved เป็น Active ในบันทึกการตรวจสอบ.

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

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

แหล่งข้อมูล

อนุมานจากการสร้างกิจกรรม 'Email' ขาออกที่มีลิงก์แบบสำรวจ หรือระเบียนกิจกรรม 'Customer Voice survey invite' ที่เกี่ยวข้องกับกรณีบริการ.

บันทึก

ใช้เวลาที่สร้างระเบียนกิจกรรมที่เกี่ยวข้องกับแบบสำรวจ.

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

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

แหล่งข้อมูล

อนุมานได้จากเวลาประทับของกิจกรรม 'Email' ขาออกที่เกี่ยวข้องกับกรณีบริการ หรือการเปลี่ยน statuscode เป็นสถานะก่อนการแก้ไขเสร็จสิ้น.

บันทึก

ใช้เวลาประทับของกิจกรรมอีเมลขาออก หรือเวลาที่เปลี่ยนสถานะเป็น 'Solution Proposed'.

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

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

วิธีดึงข้อมูลจาก Microsoft Dynamics 365 Customer Service

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

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

ปรับปรุงบริการลูกค้า เพิ่มอัตราการแก้ไขปัญหาตั้งแต่การติดต่อครั้งแรก ลดต้นทุนได้ทันที

ระบุคอขวดและตั้งเป้าแก้ปัญหาได้ตั้งแต่การติดต่อครั้งแรก 80% เพื่อให้ลูกค้าพึงพอใจยิ่งขึ้น.

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

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