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

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

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

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

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

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

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

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

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

วิธีดึงข้อมูลจาก ServiceNow CSM

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

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

เพิ่มประสิทธิภาพบริการลูกค้าให้ได้เต็มที่ตั้งแต่วันนี้

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

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

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