เทมเพลตข้อมูลบริการลูกค้าของคุณ
เทมเพลตข้อมูลบริการลูกค้าของคุณ
- แอตทริบิวต์ที่แนะนำให้เก็บ
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูลจาก Microsoft Dynamics 365 Customer Service
แอตทริบิวต์บริการลูกค้า
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
คำขอรับบริการ
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
|
|||
กิจกรรมบริการลูกค้า
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขกรณีบริการแล้ว
|
เหตุการณ์สำคัญนี้ระบุจุดที่เจ้าหน้าที่เห็นว่าปัญหาของลูกค้าได้รับการแก้ไขแล้ว เป็นการดำเนินการที่บันทึกไว้อย่างชัดเจนใน 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
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตข้อมูลนี้เพื่อเริ่มต้นทำ process mining และค้นหาโอกาสเพิ่มประสิทธิภาพในการปฏิบัติการบริการลูกค้า เริ่มปรับปรุงเวิร์กโฟลว์ได้วันนี้ เพื่อมอบประสบการณ์ที่ดีขึ้นให้ลูกค้า.
ปรับปรุงบริการลูกค้า เพิ่มอัตราการแก้ไขปัญหาตั้งแต่การติดต่อครั้งแรก ลดต้นทุนได้ทันที
ระบุคอขวดและตั้งเป้าแก้ปัญหาได้ตั้งแต่การติดต่อครั้งแรก 80% เพื่อให้ลูกค้าพึงพอใจยิ่งขึ้น.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าได้ภายในไม่กี่นาที.