เทมเพลตข้อมูลบริการลูกค้าของคุณ
เทมเพลตข้อมูลบริการลูกค้าของคุณ
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางการดึงข้อมูล
แอตทริบิวต์บริการลูกค้า
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
คำขอรับบริการ
ServiceRequest
|
รหัสเฉพาะของคำขอรับบริการ เคส หรือทิกเก็ตแต่ละรายการของลูกค้า. | ||
|
คำอธิบาย
คำขอรับบริการเป็นรหัสหลักของเคสที่เชื่อมโยงกิจกรรมและเหตุการณ์ทั้งหมดของปัญหาลูกค้าหนึ่งรายการ ตั้งแต่สร้างจนปิดเคส และใช้ติดตามเส้นทางการติดต่อกับลูกค้าตั้งแต่ต้นจนจบ. ใน process mining แอตทริบิวต์นี้เป็นพื้นฐานสำหรับสร้างลำดับกระบวนการขึ้นใหม่ ค่า Service Request ที่ไม่ซ้ำกันแต่ละค่าจะแทนกระบวนการหนึ่งรายการ จึงวิเคราะห์ระยะเวลาตั้งแต่เริ่มจนจบ เส้นทาง และความแตกต่างของแต่ละเคสได้ ทั้งยังช่วยให้มั่นใจว่าทุกขั้นตอน ตั้งแต่การติดต่อครั้งแรกจนถึงการแก้ไขและปิดเคส เชื่อมโยงกับคำขอของลูกค้ารายเดียวกันอย่างถูกต้อง.
เหตุผลที่สำคัญ
นี่คือ Case ID สำคัญที่เชื่อมโยงทุกขั้นตอนของกระบวนการ ทำให้วิเคราะห์วงจรชีวิตทั้งหมดของการติดต่อฝ่ายบริการลูกค้าแต่ละครั้งได้.
แหล่งข้อมูล
โดยทั่วไปคือฟิลด์ 'number' จากตาราง 'sn_customerservice_case' ใน ServiceNow CSM.
ตัวอย่าง
CS0010001CS0010045CS0010112
|
|||
|
เวลาเกิดเหตุการณ์
EventTime
|
เวลาที่ระบุอย่างแม่นยำว่าเกิดกิจกรรมหรือเหตุการณ์นั้นเมื่อใด. | ||
|
คำอธิบาย
เวลาเกิดเหตุการณ์บันทึกวันที่และเวลาที่ทำกิจกรรม ใช้เรียงเหตุการณ์ตามลำดับเวลาและคำนวณระยะเวลาระหว่างขั้นตอนต่างๆ ในกระบวนการ. ในการวิเคราะห์ process mining แอตทริบิวต์นี้ใช้คำนวณตัวชี้วัดด้านเวลาทั้งหมด รวมถึงระยะเวลาดำเนินการ ระยะเวลารอ และเวลาที่ใช้ประมวลผล นักวิเคราะห์ใช้ข้อมูลนี้ระบุคอขวดจากกิจกรรมที่มีช่วงรอนาน และวัดผลการดำเนินงานเทียบกับข้อตกลงระดับการให้บริการ (SLA) การวิเคราะห์ที่เชื่อถือได้ต้องอาศัยเวลาที่บันทึกอย่างถูกต้องและสม่ำเสมอ.
เหตุผลที่สำคัญ
เวลานี้สำคัญต่อการเรียงเหตุการณ์ให้ถูกต้องและคำนวณตัวชี้วัดประสิทธิภาพทั้งหมด เช่น ระยะเวลาดำเนินการและคอขวด.
แหล่งข้อมูล
โดยทั่วไปตรงกับฟิลด์ 'sys_created_on' ในตารางตรวจสอบและประวัติของ ServiceNow เช่น 'sys_audit'.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:05:11Z
|
|||
|
ชื่อกิจกรรม
ActivityName
|
ชื่อของเหตุการณ์หรืองานที่เกิดขึ้นในวงจรชีวิตของคำขอรับบริการ. | ||
|
คำอธิบาย
ชื่อกิจกรรมอธิบายขั้นตอนหนึ่งในกระบวนการบริการลูกค้า เช่น 'สร้างคำขอรับบริการ' 'มอบหมายคำขอให้เจ้าหน้าที่' หรือ 'เสนอแนวทางแก้ไข' โดยดึงกิจกรรมเหล่านี้จากบันทึกของระบบหรือการอัปเดตตาราง เพื่อเรียงเหตุการณ์ของคำขอรับบริการแต่ละรายการตามลำดับเวลา. แอตทริบิวต์นี้สำคัญต่อการแสดงแผนผังกระบวนการ การระบุคอขวด และการทำความเข้าใจลำดับงาน นักวิเคราะห์สามารถดูเส้นทางที่เกิดขึ้นบ่อย ความเบี่ยงเบน และจุดที่ต้องทำงานซ้ำหรือไม่มีประสิทธิภาพได้จากลำดับและความถี่ของกิจกรรม ระดับรายละเอียดของกิจกรรมที่กำหนดไว้ยังส่งผลโดยตรงต่อความลึกของข้อมูลเชิงลึกจากโมเดลกระบวนการ.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้เป็นแกนหลักของแผนผังกระบวนการ โดยระบุขั้นตอนและงานที่นำลำดับกับระยะเวลามาวิเคราะห์.
แหล่งข้อมูล
แอตทริบิวต์เชิงแนวคิดนี้ได้มาจากตารางตรวจสอบของระบบ เช่น 'sys_audit' หรือจากการติดตามการเปลี่ยนสถานะและการอัปเดตฟิลด์สำคัญในตาราง 'sn_customerservice_case'.
ตัวอย่าง
สร้างคำขอบริการมอบหมายคำขอให้เจ้าหน้าที่ขอข้อมูลเพิ่มเติมจากลูกค้าแก้ไขคำขอรับบริการแล้ว
|
|||
|
กลุ่มผู้รับผิดชอบ
AssignmentGroup
|
ทีมงานหรือแผนกที่รับผิดชอบคำขอรับบริการ. | ||
|
คำอธิบาย
กลุ่มผู้รับผิดชอบหมายถึงคิวหรือทีมที่ได้รับมอบหมายให้ดูแลคำขอรับบริการ โดยมักส่งคำขอไปยังกลุ่มต่างๆ ตามลักษณะของปัญหา เช่น ฝ่ายสนับสนุนระดับ 1 ทีมเทคนิคเฉพาะทาง หรือแผนกเรียกเก็บเงิน. แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์การส่งต่องานระหว่างแผนกและระบุคอขวดในระดับทีม ช่วยให้เห็นว่างานไหลผ่านหน่วยงานต่างๆ อย่างไร และระบุกลุ่มที่มีงานล้นมือหรือต้องการการฝึกอบรมเพิ่มเติมได้ ข้อมูลนี้สนับสนุนแดชบอร์ด 'การส่งต่องานและการมอบหมายเคสใหม่' และ 'การไหลของกระบวนการ' โดยตรง.
เหตุผลที่สำคัญ
ระบุทีมที่รับผิดชอบงาน ซึ่งสำคัญต่อการวิเคราะห์ประสิทธิภาพและปริมาณงานของทีม รวมถึงการส่งต่องานระหว่างแผนก.
แหล่งข้อมูล
ตรงกับฟิลด์ 'assignment_group' ในตาราง 'sn_customerservice_case'.
ตัวอย่าง
ฝ่ายบริการลูกค้าสอบถามเรื่องการเรียกเก็บเงินฝ่ายสนับสนุนด้านเทคนิคระดับ 2
|
|||
|
เกิน SLA หรือไม่
IsSlaBreached
|
แฟล็กแบบบูลีนที่ระบุว่าคำขอรับบริการใช้เวลาเกินเป้าหมายตามข้อตกลงระดับการให้บริการ (SLA) ที่กำหนดไว้หรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณนี้ระบุว่าคำขอรับบริการได้รับการแก้ไขภายในเวลาที่ตกลงกันไว้หรือไม่ โดยทั่วไปจะเป็น 'True' หากใช้เวลาแก้ไขเกินเป้าหมาย SLA และเป็น 'False' หากไม่เกิน จึงเห็นผลการดำเนินงานตาม SLA ของแต่ละเคสได้อย่างชัดเจน แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'แนวโน้มการปฏิบัติตามและการละเมิด SLA' และ KPI 'อัตราการปฏิบัติตาม SLA' ช่วยให้วิเคราะห์ได้ง่ายขึ้นด้วยการกรองและนับเคสที่ละเมิด SLA โดยตรง ทำให้ระบุได้ว่าคำขอประเภทใด ระดับความสำคัญใด หรือทีมใดเกี่ยวข้องกับการละเมิด SLA มากที่สุด.
เหตุผลที่สำคัญ
ระบุได้ชัดเจนว่าเคสทำได้ทันกำหนดหรือไม่ ซึ่งเป็นข้อมูลพื้นฐานสำหรับวัดผลและรายงานการปฏิบัติตามข้อกำหนด SLA.
แหล่งข้อมูล
คำนวณจากฟิลด์ 'made_sla' ในตาราง 'task_sla' หรือคำนวณโดยเปรียบเทียบเวลาแก้ไขจริงกับเวลาที่วางแผนไว้.
ตัวอย่าง
truefalse
|
|||
|
เจ้าหน้าที่ที่ได้รับมอบหมาย
AssignedAgent
|
เจ้าหน้าที่บริการที่ได้รับมอบหมายให้ดูแลคำขอรับบริการในขณะนั้น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้ใช้ที่รับผิดชอบคำขอรับบริการ ณ เวลาหนึ่ง โดยมักเปลี่ยนไปตลอดวงจรชีวิตของเคสเมื่อมีการส่งต่องานระหว่างเจ้าหน้าที่หรือผู้เชี่ยวชาญ. การวิเคราะห์เจ้าหน้าที่ที่ได้รับมอบหมายช่วยให้เข้าใจการกระจายภาระงานและประสิทธิภาพของเจ้าหน้าที่ รวมถึงการส่งต่องาน เช่น เจ้าหน้าที่คนใดดูแลเคสที่ซับซ้อนมากที่สุด มีการมอบหมายเคสใหม่บ่อยเพียงใด และเจ้าหน้าที่บางคนเกี่ยวข้องกับระยะเวลาแก้ไขที่นานขึ้นหรือความพึงพอใจของลูกค้าที่สูงขึ้นหรือไม่ ข้อมูลนี้สำคัญต่อแดชบอร์ด 'การส่งต่องานและการมอบหมายเคสใหม่'.
เหตุผลที่สำคัญ
ติดตามผู้รับผิดชอบเคส เพื่อวิเคราะห์ปริมาณงาน ประสิทธิภาพ และความถี่ในการมอบหมายใหม่ ซึ่งมักบ่งชี้ถึงอุปสรรคในกระบวนการ.
แหล่งข้อมูล
ตรงกับฟิลด์ 'assigned_to' ในตาราง 'sn_customerservice_case'.
ตัวอย่าง
Beth AnglinDavid LooAbel Tuter
|
|||
|
ระดับความสำคัญ
Priority
|
ระดับความสำคัญของคำขอรับบริการ ซึ่งมีผลต่อความเร่งด่วนในการดำเนินการ. | ||
|
คำอธิบาย
ระดับความสำคัญแสดงความสำคัญและความเร่งด่วนที่ต้องใช้ในการจัดการคำขอรับบริการ โดยมักพิจารณาจากผลกระทบของคำขอต่อลูกค้าและความเร่งด่วนร่วมกัน ค่าที่ใช้ทั่วไปมีตั้งแต่วิกฤตถึงต่ำ. ใน process mining คุณสามารถใช้ระดับความสำคัญเป็นมิติในการกรองและเปรียบเทียบข้อมูล นักวิเคราะห์ตรวจสอบได้ว่าคำขอที่มีความสำคัญสูงได้รับการดำเนินการเร็วกว่าคำขอที่มีความสำคัญต่ำจริงหรือไม่ และการผิด SLA เกิดบ่อยขึ้นในระดับความสำคัญใด ข้อมูลนี้เป็นพื้นฐานสำคัญของแดชบอร์ด 'ระยะเวลาตั้งแต่ต้นจนจบของคำขอรับบริการ'.
เหตุผลที่สำคัญ
ช่วยแบ่งคำขอรับบริการตามความเร่งด่วน เพื่อให้ตรวจสอบได้ว่าปัญหาวิกฤตได้รับการจัดการเร็วกว่าปัญหาที่ไม่เร่งด่วน.
แหล่งข้อมูล
ตรงกับฟิลด์ 'priority' ในตาราง 'sn_customerservice_case'.
ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
|
|||
|
สถานะ
State
|
สถานะปัจจุบันของคำขอรับบริการในวงจรชีวิตของคำขอ. | ||
|
คำอธิบาย
แอตทริบิวต์สถานะอธิบายสถานะการดำเนินงานของคำขอรับบริการ ณ เวลาใดเวลาหนึ่ง เช่น 'New' 'In Progress' 'Awaiting Info' 'Resolved' หรือ 'Closed' การเปลี่ยนแปลงในฟิลด์นี้มักใช้กำหนดกิจกรรมในโมเดลกระบวนการ. การวิเคราะห์สถานะช่วยให้เห็นภาพรวมว่าเคสอยู่ในขั้นตอนใดของกระบวนการ และใช้ตรวจสอบระยะเวลาที่เคสอยู่ในแต่ละสถานะ เช่น 'Awaiting Info' ซึ่งอาจเป็นสาเหตุสำคัญของความล่าช้า นอกจากนี้ยังช่วยกำหนดจุดเริ่มต้นและจุดสิ้นสุดของ KPI สำคัญ เช่น 'ระยะเวลาตั้งแต่แก้ไขจนปิดเคส'.
เหตุผลที่สำคัญ
ระบุสถานะของคำขอในแต่ละช่วงเวลา ช่วยให้เห็นเวลาที่ใช้ในสถานะที่ไม่ก่อให้เกิดความคืบหน้า เช่น 'On Hold' หรือ 'Awaiting Information'.
แหล่งข้อมูล
ตรงกับฟิลด์ 'state' ในตาราง 'sn_customerservice_case'.
ตัวอย่าง
ใหม่กำลังดำเนินการรอข้อมูลจากผู้ใช้แก้ไขแล้วปิดแล้ว
|
|||
|
หมวดหมู่
Category
|
การจัดประเภทหลักของคำขอรับบริการ เช่น 'การเรียกเก็บเงิน' หรือ 'ปัญหาทางเทคนิค'. | ||
|
คำอธิบาย
หมวดหมู่ใช้จัดกลุ่มคำขอรับบริการตามลักษณะคำถามหรือปัญหาของลูกค้า โดยทั่วไปจะจัดประเภทเมื่อสร้างคำขอ เพื่อช่วยส่งต่อไปยังกลุ่มผู้รับผิดชอบที่ถูกต้อง. แอตทริบิวต์นี้จำเป็นต่อการแบ่งข้อมูลเพื่อวิเคราะห์กระบวนการ นักวิเคราะห์สามารถกรองตามหมวดหมู่เพื่อเปรียบเทียบขั้นตอนการทำงานของคำขอแต่ละประเภทได้ เช่น กระบวนการแก้ไขปัญหา 'การเรียกเก็บเงิน' อาจแตกต่างจาก 'ปัญหาทางเทคนิค' มาก แอตทริบิวต์นี้จึงใช้แบ่งข้อมูลในแดชบอร์ดเกือบทุกประเภทได้.
เหตุผลที่สำคัญ
ช่วยแยกผลการวิเคราะห์ตามประเภทคำขอ เพื่อดูว่าหมวดหมู่ใดมีแนวโน้มเกิดความล่าช้า การยกระดับเคส หรือการผิด SLA มากกว่า.
แหล่งข้อมูล
ตรงกับฟิลด์ 'category' ในตาราง 'sn_customerservice_case'.
ตัวอย่าง
สอบถาม / ขอความช่วยเหลือคำสั่งซื้อปัญหาเกี่ยวกับผลิตภัณฑ์การเรียกเก็บเงิน
|
|||
|
แก้ไขได้ตั้งแต่การติดต่อครั้งแรกหรือไม่
IsFirstContactResolution
|
แฟล็กแบบบูลีนที่ระบุว่าตัวแทนคนแรกที่ได้รับมอบหมายแก้ไขคำขอได้หรือไม่ โดยไม่มีการโอนงานหรือยกระดับปัญหา. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณนี้ระบุคำขอรับบริการที่แก้ไขได้อย่างมีประสิทธิภาพตั้งแต่การติดต่อครั้งแรก หรือโดยเจ้าหน้าที่คนแรกที่ดูแลเคส โดยทั่วไปจะตรวจสอบเงื่อนไข เช่น ไม่มีการมอบหมายงานใหม่ ('ReassignmentCount' เป็น 0) ไม่มีกิจกรรม 'เริ่มยกระดับปัญหาภายใน' และไม่มีการขอข้อมูลเพิ่มเติมจากลูกค้า แอตทริบิวต์นี้ใช้วัดตัวชี้วัดสำคัญด้านบริการลูกค้าโดยตรง และรองรับแดชบอร์ดกับ KPI 'อัตราการแก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรก' ช่วยวัดผล FCR ได้ง่าย และวิเคราะห์ปัจจัยที่ส่งเสริมหรือขัดขวางการแก้ไขปัญหาตั้งแต่การติดต่อครั้งแรก เช่น ช่องทางหรือประเภทคำขอ.
เหตุผลที่สำคัญ
วัดประสิทธิภาพของการตอบกลับครั้งแรกโดยตรง อัตรา FCR ที่สูงสัมพันธ์อย่างมากกับทั้งประสิทธิภาพการปฏิบัติการและความพึงพอใจของลูกค้า.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณระหว่างการแปลงข้อมูลตามกฎ เช่น 'ReassignmentCount' ต้องเป็นศูนย์และต้องไม่มีกิจกรรมยกระดับปัญหา.
ตัวอย่าง
truefalse
|
|||
|
จำนวนครั้งที่เปิดเคสอีกครั้ง
ReopenCount
|
จำนวนครั้งที่ลูกค้าเปิดคำขอรับบริการที่แก้ไขแล้วขึ้นมาอีกครั้ง. | ||
|
คำอธิบาย
ตัวนับนี้บันทึกจำนวนครั้งที่เคสเปลี่ยนจากสถานะ 'Resolved' หรือ 'Closed' กลับไปเป็น 'In Progress' หรือ 'Open' เคสที่เปิดอีกครั้งอาจหมายถึงวิธีแก้ไขครั้งแรกไม่ได้ผลหรือยังไม่สมบูรณ์. แอตทริบิวต์นี้เป็นตัวชี้วัดสำคัญของการทำงานซ้ำและคุณภาพการแก้ไขตั้งแต่ครั้งแรก หากเปิดเคสอีกครั้งหลายครั้ง อาจมีปัญหาในกระบวนการแก้ไข เช่น เจ้าหน้าที่ปิดทิกเก็ตเร็วเกินไปหรือยังไม่ได้แก้ปัญหาที่แท้จริงของลูกค้าให้ครบถ้วน ตัวชี้วัดนี้ช่วยให้เข้าใจประสิทธิผลของแนวทางแก้ไขที่เสนอ.
เหตุผลที่สำคัญ
บ่งชี้ว่าการแก้ไขไม่สำเร็จและต้องทำงานซ้ำ หากเปิดเคสอีกครั้งหลายครั้ง แสดงว่าคุณภาพของกระบวนการแก้ไขอาจไม่ดี และทำให้ลูกค้าไม่พอใจ.
แหล่งข้อมูล
โดยทั่วไปจะบันทึกข้อมูลนี้ไว้ในฟิลด์ชื่อ 'reopen_count' ของตาราง 'sn_customerservice_case' หรือตารางที่เกี่ยวข้อง.
ตัวอย่าง
012
|
|||
|
จำนวนครั้งที่มอบหมายใหม่
ReassignmentCount
|
จำนวนครั้งทั้งหมดที่มีการมอบหมายคำขอรับบริการให้เจ้าหน้าที่หรือกลุ่มอื่น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เป็นตัวนับที่เพิ่มขึ้นทุกครั้งที่ฟิลด์ 'assigned_to' หรือ 'assignment_group' เปลี่ยนค่า ใช้วัดจำนวนครั้งที่มีการส่งต่อเคสภายในองค์กรได้โดยตรง. จำนวนครั้งที่มอบหมายใหม่เป็นตัวชี้วัดโดยตรงของอุปสรรคในกระบวนการ และเป็นข้อมูลสำคัญสำหรับแดชบอร์ด 'การส่งต่องานและการมอบหมายเคสใหม่' รวมถึง KPI 'จำนวนครั้งเฉลี่ยที่มีการส่งต่องานต่อคำขอ' หากมีการมอบหมายใหม่หลายครั้ง อาจแสดงว่าการส่งต่อคำขอในขั้นต้นไม่เหมาะสม เจ้าหน้าที่มีทักษะไม่ตรงกับงาน หรือจัดประเภทเคสได้ยาก ซึ่งล้วนทำให้ใช้เวลาแก้ไขนานขึ้น.
เหตุผลที่สำคัญ
วัดความไม่มีประสิทธิภาพของกระบวนการโดยนับจำนวนครั้งที่ส่งต่องานโดยตรง จำนวนครั้งที่สูงมักสัมพันธ์กับระยะเวลาแก้ไขที่นานขึ้นและความไม่พอใจของลูกค้า.
แหล่งข้อมูล
เป็นฟิลด์ตัวชี้วัดมาตรฐาน 'reassignment_count' ในตาราง 'task' ซึ่งเป็นตารางหลักที่ตาราง 'sn_customerservice_case' ขยายต่อ.
ตัวอย่าง
0135
|
|||
|
ช่องทาง
Channel
|
ช่องทางการติดต่อที่ใช้ส่งคำขอรับบริการ. | ||
|
คำอธิบาย
ช่องทางระบุวิธีที่ลูกค้าใช้ส่งคำขอ เช่น 'อีเมล' 'โทรศัพท์' 'เว็บพอร์ทัล' หรือ 'แชต' แต่ละช่องทางอาจมีลักษณะของกระบวนการและความคาดหวังของลูกค้าแตกต่างกันมาก. การวิเคราะห์กระบวนการตามช่องทางช่วยประเมินประสิทธิผลของวิธีติดต่อแต่ละแบบ เช่น ตรวจสอบได้ว่าคำขอที่ส่งทาง 'โทรศัพท์' มีอัตราการแก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรกสูงกว่าหรือไม่ หรือคำขอทาง 'อีเมล' ใช้เวลาดำเนินการนานกว่าหรือไม่ ข้อมูลนี้สนับสนุนแดชบอร์ด 'ประสิทธิผลของช่องทางการติดต่อ' โดยตรง.
เหตุผลที่สำคัญ
ช่วยประเมินประสิทธิภาพและผลลัพธ์ของช่องทางติดต่อลูกค้าแต่ละแบบ เช่น โทรศัพท์ อีเมล หรือเว็บพอร์ทัล.
แหล่งข้อมูล
โดยทั่วไปตรงกับฟิลด์ 'contact_type' ในตาราง 'sn_customerservice_case'.
ตัวอย่าง
โทรศัพท์อีเมลบริการตนเองแชต
|
|||
|
มีการทำงานซ้ำหรือไม่
IsRework
|
แฟล็กแบบบูลีนที่ระบุว่ามีการทำงานซ้ำอย่างมีนัยสำคัญหรือไม่ เช่น เคสถูกเปิดอีกครั้งหรือมีการตรวจสอบซ้ำ. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณนี้ใช้ทำเครื่องหมายเคสที่มีรูปแบบการทำงานไม่มีประสิทธิภาพหรือเกิดซ้ำ ระบบอาจตั้งค่าแฟล็กเมื่อพบเหตุการณ์อย่าง 'เปิดคำขอรับบริการอีกครั้ง' หรือเมื่อชุดกิจกรรมสำคัญ เช่น 'เจ้าหน้าที่เริ่มตรวจสอบ' ตามด้วย 'เสนอวิธีแก้ไข' เกิดขึ้นหลายครั้งในเคสเดียวกัน แฟล็กนี้ช่วยให้ระบุเคสที่มีปัญหาและวัดปริมาณงานซ้ำในกระบวนการได้อย่างรวดเร็ว รองรับแดชบอร์ด 'จุดที่เกิดงานซ้ำและการทำซ้ำ' และ KPI 'อัตราการทำงานซ้ำ' โดยตรง นักวิเคราะห์จึงมุ่งตรวจสอบสาเหตุของความไม่มีประสิทธิภาพได้ โดยไม่ต้องค้นหารูปแบบที่เกิดซ้ำด้วยตนเอง.
เหตุผลที่สำคัญ
ช่วยวัดความไม่มีประสิทธิภาพของกระบวนการ โดยทำเครื่องหมายเคสที่มีขั้นตอนวนซ้ำหรือถูกเปิดอีกครั้ง ทำให้วัดและจัดการงานซ้ำได้ง่าย.
แหล่งข้อมูล
แอตทริบิวต์นี้คำนวณระหว่างการแปลงข้อมูล โดยใช้ตรรกะทางธุรกิจเพื่อตรวจหารูปแบบการทำงานซ้ำ เช่น 'ReopenCount' มีค่ามากกว่าศูนย์ หรือมีกิจกรรมเดิมเกิดซ้ำ.
ตัวอย่าง
truefalse
|
|||
|
รหัสผลการแก้ไข
ResolutionCode
|
รหัสที่ระบุผลลัพธ์สุดท้ายหรือวิธีแก้ไขคำขอรับบริการ. | ||
|
คำอธิบาย
รหัสผลการแก้ไขเป็นค่าที่มีโครงสร้าง ซึ่งเจ้าหน้าที่เลือกเมื่อแก้ไขเคสแล้ว โดยระบุรายละเอียดของวิธีแก้ไข เช่น 'ผู้ใช้แก้ไขเอง' 'ข้อผิดพลาดที่ทราบแล้ว' 'รายการซ้ำ' หรือ 'ไม่ต้องดำเนินการ'. แอตทริบิวต์นี้มีประโยชน์ต่อการวิเคราะห์หาสาเหตุที่แท้จริง การวิเคราะห์ความถี่ของรหัสผลการแก้ไขแต่ละแบบช่วยให้องค์กรระบุปัญหาที่เกิดซ้ำ ช่องว่างด้านความรู้ หรือปัญหาของผลิตภัณฑ์ได้ จากนั้นนำข้อมูลไปปรับปรุงเพื่อลดคำขอรับบริการบางประเภท.
เหตุผลที่สำคัญ
ให้ข้อมูลเกี่ยวกับผลลัพธ์ของคำขอรับบริการ ซึ่งสำคัญต่อการวิเคราะห์หาสาเหตุที่แท้จริงและระบุปัญหาที่เกิดซ้ำ.
แหล่งข้อมูล
ตรงกับฟิลด์ 'close_code' หรือฟิลด์รหัสผลการแก้ไขที่กำหนดเองในตาราง 'sn_customerservice_case'.
ตัวอย่าง
แก้ไขแล้ว (ใช้วิธีแก้ปัญหาชั่วคราว)แก้ไขแล้ว (ถาวร)แก้ไขไม่สำเร็จ (ลูกค้าไม่ตอบกลับ)ผู้แจ้งปิดเคสหรือยืนยันว่าแก้ไขแล้ว
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ใช้ดึงข้อมูลออกมา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูล ซึ่งสำคัญเป็นพิเศษเมื่อรวบรวมข้อมูลจากหลายระบบ สำหรับมุมมองกระบวนการนี้ ค่าจะเป็น 'ServiceNow CSM' เสมอ. ข้อมูลนี้ช่วยในการกำกับดูแลข้อมูลและแก้ไขปัญหา หากมีหลายระบบต้นทาง คุณสามารถกรองกระบวนการเพื่อดูการทำงานในแต่ละระบบ หรือเปรียบเทียบความแตกต่างของกระบวนการระหว่างระบบได้.
เหตุผลที่สำคัญ
ให้บริบทสำคัญเกี่ยวกับแหล่งที่มาของข้อมูล ช่วยให้เข้าใจตรงกันเมื่อใช้หลายระบบ และสนับสนุนการกำกับดูแลข้อมูล.
แหล่งข้อมูล
เป็นค่าคงที่ที่เพิ่มระหว่างการแปลงข้อมูลเพื่อระบุแหล่งที่มาของชุดข้อมูล.
ตัวอย่าง
ServiceNow CSM
|
|||
|
ลูกค้า
Customer
|
ชื่อหรือรหัสของลูกค้าหรือบริษัทที่ส่งคำขอรับบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้มีส่วนเกี่ยวข้องภายนอก ไม่ว่าจะเป็นบุคคลหรือองค์กรที่ยื่นคำขอรับบริการ และให้บริบทเกี่ยวกับลูกค้าของแต่ละเคส. การวิเคราะห์แอตทริบิวต์ลูกค้าช่วยให้มองกระบวนการบริการจากมุมของลูกค้า ใช้ระบุได้ว่าลูกค้าบางรายพบปัญหาบ่อยกว่าหรือรอนานกว่าหรือไม่ และเชื่อมโยงกับข้อมูลลูกค้าอื่นๆ เช่น กลุ่มลูกค้าหรือมูลค่าทางธุรกิจ เพื่อจัดลำดับความสำคัญของการปรับปรุงกระบวนการได้ ตัวอย่างเช่น ตรวจสอบได้ว่าลูกค้ามูลค่าสูงได้รับบริการเร็วขึ้นหรือไม่.
เหตุผลที่สำคัญ
เชื่อมโยงกระบวนการกับลูกค้าแต่ละราย เพื่อวิเคราะห์ระดับการให้บริการและความถี่ของปัญหาสำหรับลูกค้ารายสำคัญหรือกลุ่มลูกค้า.
แหล่งข้อมูล
อาจเป็นฟิลด์ 'caller_id' 'opened_for' หรือ 'account' ในตาราง 'sn_customerservice_case' ซึ่งอ้างอิงไปยังตารางผู้ใช้หรือบริษัท.
ตัวอย่าง
John SmithACME CorporationGlobal Tech Inc.
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่าดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลล่าสุด ช่วยให้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลใหม่เพียงใด และผู้ใช้เห็นได้ว่าข้อมูลใกล้เคียงเวลาจริงหรือเป็นภาพข้อมูลในอดีต. ในการวิเคราะห์ ข้อมูลนี้เป็นเมทาดาทาสำคัญที่ช่วยระบุช่วงเวลาของชุดข้อมูล ผู้ใช้จึงตีความแดชบอร์ดและ KPI ได้ถูกต้อง เช่น ทราบว่าข้อมูลเป็นปัจจุบันถึงชั่วโมงที่แล้วหรือวันก่อนหน้า.
เหตุผลที่สำคัญ
ระบุความใหม่ของข้อมูล ซึ่งสำคัญต่อความเกี่ยวข้องและความทันเวลาของข้อมูลเชิงลึกจาก process mining.
แหล่งข้อมูล
เวลานี้สร้างและเพิ่มระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL).
ตัวอย่าง
2023-11-20T08:00:00Z
|
|||
กิจกรรมบริการลูกค้า
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขคำขอรับบริการแล้ว
|
หมุดหมายสำคัญนี้แสดงว่าเจ้าหน้าที่บริการทำงานเสร็จแล้วและถือว่าปัญหาได้รับการแก้ไข บันทึกเหตุการณ์นี้เมื่อสถานะเคสเปลี่ยนเป็น 'Resolved' และมีการระบุเวลาใน resolved_at. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของกระบวนการแก้ไขที่กำลังดำเนินอยู่ และจำเป็นต่อการคำนวณระยะเวลาตั้งแต่เริ่มจนแก้ไขเสร็จ รวมถึงการปฏิบัติตาม SLA อีกทั้งยังเป็นจุดสิ้นสุดหลักสำหรับ KPI ด้านประสิทธิภาพหลายรายการ.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบเมื่อฟิลด์สถานะในตาราง sn_customerservice_case ถูกตั้งเป็น 'Resolved' โดยทั่วไปฟิลด์ resolved_at จะถูกระบุในเวลาเดียวกัน.
บันทึก
ตรวจจับการเปลี่ยนค่าใน 'state' เป็น 'Resolved' และใช้เวลาที่เกี่ยวข้องกับเหตุการณ์นั้น.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิดคำขอรับบริการ
|
กิจกรรมสุดท้ายนี้ระบุการปิดระเบียนคำขอรับบริการอย่างเป็นทางการ ซึ่งมักเกิดขึ้นหลังช่วงเวลารอยืนยันภายหลังการแก้ไข บันทึกเหตุการณ์นี้เมื่อสถานะเคสเปลี่ยนเป็น 'Closed' และมีการระบุเวลาใน closed_at. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดที่ชัดเจนของกระบวนการ จึงจำเป็นต่อการคำนวณวงจรชีวิตทั้งหมดของเคส การวิเคราะห์เวลาระหว่าง 'Resolved' กับ 'Closed' ช่วยให้เห็นภาระงานด้านธุรการหรือความล่าช้า.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบเมื่อฟิลด์สถานะในตาราง sn_customerservice_case ถูกตั้งเป็น 'Closed' โดยฟิลด์ closed_at จะถูกระบุในเวลาเดียวกัน.
บันทึก
ตรวจจับการเปลี่ยนค่าใน 'state' เป็น 'Closed' และใช้เวลาที่เกี่ยวข้องกับเหตุการณ์นั้น.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอให้เจ้าหน้าที่
|
กิจกรรมนี้เกิดขึ้นเมื่อมอบหมายคำขอบริการให้เจ้าหน้าที่คนใดคนหนึ่งตรวจสอบและแก้ไข ระบบอนุมานกิจกรรมนี้จากการเปลี่ยนแปลงฟิลด์ assigned_to ในระเบียนเคส. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้เป็นจุดสำคัญในการวัดเวลาตอบกลับครั้งแรกและการกระจายภาระงานของเจ้าหน้าที่ การติดตามการเปลี่ยนแปลงฟิลด์นี้ช่วยให้เห็นความไม่มีประสิทธิภาพของกระบวนการและคอขวดที่อาจเกิดจากเจ้าหน้าที่ไม่พร้อมให้บริการ.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบ (sys_audit) ของตาราง sn_customerservice_case โดยติดตามเวลาที่มีการกรอกหรือเปลี่ยนฟิลด์ assigned_to.
บันทึก
ตรวจจับการเปลี่ยนแปลงค่าของฟิลด์ 'assigned_to' ในประวัติการตรวจสอบของเคส.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มยกระดับเคสภายใน
|
หมายถึงการส่งต่อคำขอรับบริการอย่างเป็นทางการไปยังทีมสนับสนุนหรือผู้บริหารระดับสูงขึ้นเพื่อแก้ไขปัญหา อนุมานได้จากการเปลี่ยนกลุ่มผู้รับผิดชอบเป็นทีมระดับสูงขึ้น หรือการตั้งค่าแฟล็กที่เกี่ยวข้อง. | ||
|
เหตุผลที่สำคัญ
การติดตามการยกระดับเคสช่วยให้เห็นจุดอ่อนของกระบวนการ ช่องว่างด้านความรู้ของทีมสนับสนุนด่านหน้า และประเภทเคสที่ซับซ้อน เหตุการณ์นี้เป็นตัวชี้วัดสำคัญของอุปสรรคในกระบวนการและความไม่พอใจของลูกค้า.
แหล่งข้อมูล
อนุมานได้จากบันทึกการตรวจสอบ โดยตรวจจับการเปลี่ยนค่าใน 'assignment_group' เป็นทีมยกระดับเคสที่กำหนดไว้ หรือการเปลี่ยนค่าในฟิลด์ 'escalation' ของระเบียนเคส.
บันทึก
ตรวจจับการเปลี่ยนค่าในฟิลด์ 'escalation' หรือการย้ายไปยัง 'assignment_group' ระดับสูงขึ้น.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างคำขอบริการ
|
กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการบริการลูกค้า เมื่อมีการบันทึกเคสใหม่อย่างเป็นทางการในระบบ ระบบจะบันทึกเหตุการณ์นี้เมื่อมีการเพิ่มระเบียนใหม่ในตาราง sn_customerservice_case. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นของทุกเคส จึงจำเป็นต่อการคำนวณเวลาตั้งแต่ต้นจนจบและวิเคราะห์ปริมาณคำขอที่รับเข้ามา อีกทั้งยังเป็นตัวเริ่มกระบวนการในขั้นตอนถัดไปและตัวจับเวลา SLA.
แหล่งข้อมูล
เหตุการณ์นี้ตรงกับการสร้างระเบียนในตาราง sn_customerservice_case โดยใช้เวลาจากฟิลด์ sys_created_on.
บันทึก
เวลาที่สร้างระเบียน (sys_created_on) ในตาราง sn_customerservice_case.
ประเภทเหตุการณ์
explicit
|
|||
|
ขอข้อมูลเพิ่มเติมจากลูกค้า
|
เกิดขึ้นเมื่อเจ้าหน้าที่ต้องการข้อมูลเพิ่มเติมจากลูกค้าเพื่อดำเนินการต่อ และเปลี่ยนเคสเป็นสถานะรอดำเนินการ อนุมานได้จากการเปลี่ยนสถานะเป็นค่าอย่าง 'Awaiting User Info' หรือ 'On Hold'. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้สำคัญต่อการวิเคราะห์ 'ระยะเวลารอข้อมูลจากลูกค้า' เพราะช่วยแยกความล่าช้าที่เกิดจากการรอปัจจัยภายนอกออกจากเวลาที่ใช้ดำเนินการภายใน.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบของตาราง sn_customerservice_case เมื่อฟิลด์สถานะเปลี่ยนเป็นค่าที่ระบุว่ากำลังรอข้อมูลจากลูกค้า เช่น 'Awaiting Info'.
บันทึก
ตรวจจับการเปลี่ยนค่าในฟิลด์ 'state' เป็นค่าที่กำหนดไว้สำหรับสถานะ 'รอข้อมูลจากลูกค้า'.
ประเภทเหตุการณ์
inferred
|
|||
|
จัดหมวดหมู่และกำหนดลำดับความสำคัญของคำขอ
|
แสดงขั้นตอนคัดกรองเบื้องต้น ซึ่งจำแนกคำขอบริการและกำหนดระดับความสำคัญเพื่อพิจารณาความเร่งด่วนและการจัดเส้นทาง ระบบอนุมานกิจกรรมนี้จากการเปลี่ยนแปลงฟิลด์ category, subcategory หรือ priority ในประวัติการตรวจสอบของระเบียนเคส. | ||
|
เหตุผลที่สำคัญ
การวิเคราะห์กิจกรรมนี้ช่วยระบุความล่าช้าในการคัดกรองเคส และตรวจสอบว่าคำขอถูกส่งไปยังจุดที่ถูกต้องและจัดการตามความเร่งด่วนหรือไม่ กิจกรรมนี้ส่งผลต่อเวลาจนถึงการมอบหมายงานครั้งแรกและประสิทธิภาพการแก้ไขโดยรวม.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบ (sys_audit) ของตาราง sn_customerservice_case โดยติดตามการกรอกหรืออัปเดตฟิลด์ category และ priority ในครั้งแรก.
บันทึก
ตรวจจับการกำหนดค่าเริ่มต้นหรือการเปลี่ยนแปลงค่าของฟิลด์ 'category' หรือ 'priority'.
ประเภทเหตุการณ์
inferred
|
|||
|
เจ้าหน้าที่เริ่มตรวจสอบ
|
กิจกรรมนี้แสดงว่าเจ้าหน้าที่เริ่มดำเนินการกับคำขอรับบริการแล้ว โดยทั่วไปอนุมานได้จากการเปลี่ยนสถานะเคสจาก 'New' หรือ 'Assigned' เป็น 'Work in Progress'. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้ช่วยแยกเวลาที่รออยู่ในคิวออกจากเวลาที่เจ้าหน้าที่ลงมือทำ การวิเคราะห์ระยะเวลาตั้งแต่ได้รับมอบหมายจนเริ่มตรวจสอบจะช่วยให้เห็นความล่าช้าในการรับเคสใหม่ไปดำเนินการ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนค่าในฟิลด์สถานะของเคสเป็นสถานะที่กำลังดำเนินการ เช่น 'Work in Progress' โดยควรตรวจสอบและกำหนดค่าที่ใช้จริงให้ตรงกับระบบ.
บันทึก
ตรวจจับการเปลี่ยนค่าในฟิลด์ 'state' จากสถานะรอดำเนินการเป็นสถานะที่กำลังดำเนินการ เช่น จาก 'New' เป็น 'Work in Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
ได้รับข้อมูลจากลูกค้า
|
กิจกรรมนี้ระบุจุดที่ลูกค้าส่งข้อมูลที่ร้องขอมา ทำให้เจ้าหน้าที่กลับมาดำเนินงานต่อได้ อนุมานได้เมื่อสถานะเคสเปลี่ยนจาก 'Awaiting User Info' กลับเป็นสถานะที่กำลังดำเนินการ. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้สิ้นสุดช่วงเวลาที่รอข้อมูลจากลูกค้า จึงช่วยวัดเวลาตอบกลับของลูกค้าได้อย่างแม่นยำ และช่วยระบุประเภทเคสหรือลูกค้าที่เกี่ยวข้องกับความล่าช้านานที่สุด.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบของตาราง sn_customerservice_case เมื่อฟิลด์สถานะเปลี่ยนจาก 'Awaiting Info' กลับเป็นสถานะที่กำลังดำเนินการ เช่น 'Work in Progress'.
บันทึก
ตรวจจับการเปลี่ยนค่าในฟิลด์ 'state' จากสถานะ 'รอข้อมูลจากลูกค้า' กลับเป็นสถานะที่กำลังดำเนินการ.
ประเภทเหตุการณ์
inferred
|
|||
|
เปลี่ยนกลุ่มผู้รับผิดชอบ
|
แสดงว่ามีการโอนความรับผิดชอบของเคสจากทีมหนึ่งไปยังอีกทีมหนึ่ง ระบบอนุมานเหตุการณ์นี้จากการติดตามการเปลี่ยนแปลงฟิลด์ assignment_group ในระเบียนเคส. | ||
|
เหตุผลที่สำคัญ
การติดตามการเปลี่ยนกลุ่มผู้รับผิดชอบมีความสำคัญต่อการวิเคราะห์การส่งต่องานระหว่างแผนกและระบุปัญหาเชิงระบบในการจัดเส้นทาง หากกิจกรรมนี้เกิดขึ้นบ่อย อาจแสดงว่าเจ้าของงานหรือคำจำกัดความของกระบวนการไม่ชัดเจน.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบ (sys_audit) ของตาราง sn_customerservice_case โดยติดตามการเปลี่ยนแปลงฟิลด์ assignment_group.
บันทึก
ตรวจจับการเปลี่ยนแปลงค่าของฟิลด์ 'assignment_group' ในประวัติการตรวจสอบของเคส.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิดคำขอรับบริการอีกครั้ง
|
เกิดขึ้นเมื่อคำขอรับบริการที่แก้ไขแล้วกลับมาอยู่ในสถานะที่กำลังดำเนินการ เนื่องจากปัญหาเกิดซ้ำหรือแนวทางแก้ไขไม่ได้ผล อนุมานได้จากการเปลี่ยนสถานะจาก 'Resolved' กลับเป็น 'Work in Progress'. | ||
|
เหตุผลที่สำคัญ
เคสที่เปิดอีกครั้งเป็นตัวชี้วัดโดยตรงของคุณภาพการแก้ไข และเป็นสาเหตุหลักของการทำงานซ้ำ การวิเคราะห์เหตุการณ์เหล่านี้สำคัญต่อการเพิ่มอัตราการแก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรกและความพึงพอใจของลูกค้า.
แหล่งข้อมูล
อนุมานจากประวัติการตรวจสอบของตาราง sn_customerservice_case โดยตรวจหาลำดับเหตุการณ์ที่ฟิลด์สถานะเปลี่ยนจาก 'Resolved' ไปเป็นสถานะที่กำลังดำเนินการ.
บันทึก
ตรวจจับการเปลี่ยนค่าใน 'state' จาก 'Resolved' เป็นสถานะที่กำลังดำเนินการ เช่น 'Work in Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
ผิด SLA
|
หมายถึงเวลาที่คำขอรับบริการไม่เป็นไปตามข้อตกลงระดับการให้บริการที่กำหนดไว้ เช่น ระยะเวลาในการแก้ไข เหตุการณ์นี้คำนวณจากการเปรียบเทียบเวลาแก้ไขจริงกับเวลาสิ้นสุดตามแผนของ SLA. | ||
|
เหตุผลที่สำคัญ
การระบุกรณีผิด SLA เป็นพื้นฐานสำคัญของการติดตามการปฏิบัติตามข้อกำหนดและการจัดการประสิทธิภาพ เหตุการณ์นี้ช่วยชี้ว่าขั้นตอนใดของกระบวนการหรือเคสประเภทใดมีส่วนทำให้ผิด SLA มากที่สุด.
แหล่งข้อมูล
คำนวณจากการวิเคราะห์ระเบียนในตาราง task_sla ที่เกี่ยวข้องกับเคส โดยถือว่าผิด SLA หากฟิลด์ has_breached เป็น true หรือ actual_elapsed_time มากกว่า planned_duration.
บันทึก
ตรวจสอบแฟล็ก 'has_breached' ในระเบียน task_sla ที่เชื่อมโยงกัน.
ประเภทเหตุการณ์
calculated
|
|||
|
ส่งแบบสำรวจให้ลูกค้า
|
หมายถึงการส่งแบบสำรวจความพึงพอใจให้ลูกค้าหลังจากแก้ไขเคสแล้ว โดยทั่วไปบันทึกเหตุการณ์นี้เมื่อมีการสร้างระเบียนแบบสำรวจและเชื่อมโยงกับเคส. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ช่วยเชื่อมโยงรูปแบบการดำเนินกระบวนการกับความคิดเห็นของลูกค้า การทราบว่ามีการส่งแบบสำรวจเมื่อใดและส่งหรือไม่ เป็นข้อมูลสำคัญในการวิเคราะห์ประสิทธิผลของการรับฟังความคิดเห็น.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกไว้อย่างชัดเจนในตารางเฉพาะสำหรับแบบสำรวจ เช่น asmt_assessment_instance ซึ่งมีข้อมูลอ้างอิงไปยังระเบียนเคสต้นทาง.
บันทึก
การสร้างระเบียนในตาราง 'asmt_assessment_instance' ที่เชื่อมโยงกับเคส.
ประเภทเหตุการณ์
explicit
|
|||
|
เสนอแนวทางแก้ไข
|
กิจกรรมนี้ระบุจุดที่เจ้าหน้าที่พบแนวทางแก้ไขและแจ้งให้ลูกค้าทราบเพื่อขอการยืนยัน โดยมักอนุมานได้จากการเปลี่ยนสถานะเป็นค่าอย่าง 'Awaiting Acceptance' หรือจากบันทึกการทำงานที่ระบุไว้โดยเฉพาะ. | ||
|
เหตุผลที่สำคัญ
หมุดหมายนี้แบ่งช่วงการตรวจสอบออกจากช่วงยืนยันและแก้ไขปัญหา การวิเคราะห์เวลาที่ใช้รอการยืนยันจากลูกค้าช่วยให้เห็นโอกาสในการปรับขั้นตอนท้ายของเคสให้คล่องตัวขึ้น.
แหล่งข้อมูล
อนุมานจากบันทึกการตรวจสอบของตาราง sn_customerservice_case เมื่อสถานะเปลี่ยนเป็นค่าที่ระบุว่ามีการเสนอแนวทางแก้ไข เช่น 'Proposed Solution' ทั้งนี้ค่าอาจแตกต่างกันไปตามการตั้งค่าระบบ.
บันทึก
ตรวจจับการเปลี่ยนค่าในฟิลด์ 'state' เป็นค่าอย่าง 'Proposed Solution' หรือ 'Awaiting Acceptance'.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เตรียมข้อมูลให้พร้อม เพื่อค้นพบข้อมูลเชิงลึกและปรับปรุงการปฏิบัติการด้านบริการลูกค้า เริ่มปรับกระบวนการให้มีประสิทธิภาพและยึดลูกค้าเป็นศูนย์กลางได้ตั้งแต่วันนี้.
เพิ่มประสิทธิภาพบริการลูกค้าให้ได้เต็มที่ตั้งแต่วันนี้
เพิ่มความพึงพอใจของลูกค้าและแก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรก 80%.
ไม่ต้องใช้บัตรเครดิต เริ่มต้นใช้งานได้ในไม่กี่นาที.