เทมเพลตข้อมูลการบริการลูกค้าของคุณ
เทมเพลตข้อมูลการบริการลูกค้าของคุณ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ งานบริการลูกค้า หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- ฟิลด์ข้อมูลมาตรฐานเพื่อให้วิเคราะห์ได้สอดคล้องกัน
- กิจกรรมสำคัญสำหรับการทำแผนที่กระบวนการอย่างแม่นยำ
- โครงสร้างพื้นฐานที่ใช้ได้กับระบบหลากหลาย
แอตทริบิวต์การบริการลูกค้า
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| กิจกรรม Activity | ชื่อเหตุการณ์ทางธุรกิจ งาน หรือขั้นตอนที่เกิดขึ้นในกระบวนการบริการลูกค้าสำหรับคำขอรับบริการรายการหนึ่ง. | ||
| คำอธิบาย กิจกรรมหมายถึงขั้นตอนหรือเหตุการณ์หนึ่งในวงจรของคำขอรับบริการ ตัวอย่างเช่น 'สร้างคำขอรับบริการแล้ว' 'มอบหมายคำขอแล้ว' 'เสนอวิธีแก้ปัญหาแล้ว' และ 'ปิดคำขอแล้ว' แต่ละกิจกรรมเชื่อมโยงกับคำขอรับบริการรายการหนึ่ง และมีเวลาประทับระบุเวลาที่เกิดขึ้น. แอตทริบิวต์นี้จำเป็นต่อการสร้างแผนผังกระบวนการ ซึ่งแสดงภาพเวิร์กโฟลว์บริการลูกค้า การวิเคราะห์ลำดับและความถี่ของกิจกรรมช่วยให้เห็นเส้นทางจริงที่คำขอรับบริการดำเนินไป รวมถึงรูปแบบการทำงานที่พบบ่อย คอขวด จุดที่แตกต่างจากแนวทางปกติ และการทำงานซ้ำ ข้อมูลนี้เป็นพื้นฐานสำคัญของการวิเคราะห์ process mining. เหตุผลที่สำคัญ แอตทริบิวต์นี้กำหนดขั้นตอนต่างๆ ในแผนผังกระบวนการของคุณ จึงจำเป็นต่อการทำความเข้าใจว่างานใดเกิดขึ้นและดำเนินตามลำดับใด. แหล่งข้อมูล มักได้มาจากบันทึกเหตุการณ์ ตารางเปลี่ยนสถานะ หรือบันทึกประวัติการตรวจสอบในระบบบริการลูกค้า. ตัวอย่าง สร้างคำขอแล้วมอบหมายคำขอส่งคำตอบครั้งแรกแก้ไขคำขอเสร็จแล้ว | |||
| รหัสคำขอรับบริการ ServiceRequestId | รหัสเฉพาะของข้อสอบถามหรือปัญหาของลูกค้าแต่ละรายการ ใช้เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมดไว้ในเคสเดียวกัน. | ||
| คำอธิบาย รหัสคำขอรับบริการเป็นคีย์หลักที่ใช้ระบุเคสของลูกค้าแต่ละรายการโดยไม่ซ้ำกัน ตั้งแต่สร้างเคสจนถึงแก้ไขเสร็จ รหัสนี้ใช้ระบุเคสและรวบรวมเหตุการณ์ การสื่อสาร และการดำเนินการทั้งหมดที่เกี่ยวข้องกับปัญหาของลูกค้าไว้ในลำดับเวลาเดียวกัน. ใน process mining แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานสำหรับสร้างเส้นทางตั้งแต่ต้นจนจบของคำขอรับบริการแต่ละรายการ เมื่อนักวิเคราะห์เชื่อมโยงทุกกิจกรรมกับรหัสคำขอรับบริการที่ตรงกัน ก็จะเห็นลำดับกระบวนการ ระบุจุดที่แตกต่างจากแนวทางปกติ และวัดระยะเวลาของแต่ละเคสได้อย่างแม่นยำ มุมมองที่ยึดเคสเป็นหลักนี้ช่วยให้เข้าใจประสิทธิภาพและหาจุดที่ควรปรับปรุง. เหตุผลที่สำคัญ นี่คือรหัสสำคัญที่ใช้ระบุเคส หากไม่มีรหัสนี้ คุณจะติดตามเส้นทางของปัญหาลูกค้าแต่ละรายการตลอดกระบวนการไม่ได้. แหล่งข้อมูล โดยทั่วไปจะอยู่ในส่วนหัวหรือตารางหลักของเคส ทิกเก็ต หรือเหตุขัดข้องในระบบจัดการบริการลูกค้า. ตัวอย่าง SR-2023-00123CASE009876TKT-554321INC0123456 | |||
| เวลาเกิดเหตุการณ์ EventTime | เวลาประทับที่ระบุวันที่และเวลาที่กิจกรรมหรือเหตุการณ์หนึ่งเกิดขึ้นอย่างแม่นยำ. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์ หรือที่เรียกว่าเวลาเริ่มต้น ระบุเวลาที่กิจกรรมเกิดขึ้น เหตุการณ์ทุกอย่างในบันทึก ตั้งแต่สร้างคำขอรับบริการไปจนถึงปิดคำขอ จะมีเวลาประทับกำกับไว้ ข้อมูลด้านเวลานี้จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลา. เมื่อนำเวลาประทับของคำขอรับบริการแต่ละรายการมาเรียงตามลำดับ เครื่องมือ process mining จะสร้างลำดับกระบวนการตามที่เกิดขึ้นจริงได้ เวลาเกิดเหตุการณ์เป็นพื้นฐานของการวิเคราะห์ด้านเวลา ทั้งการคำนวณระยะห่างระหว่างกิจกรรม วัดเวลารวมในการแก้ไขเคส ระบุคอขวด และตรวจสอบการปฏิบัติตามข้อตกลงระดับการให้บริการ (SLA). เหตุผลที่สำคัญ เวลาประทับนี้ใช้เรียงลำดับเหตุการณ์และวิเคราะห์ระยะเวลา เช่น คำนวณเวลาแก้ไขปัญหาและระบุคอขวด. แหล่งข้อมูล พบได้ในบันทึกเหตุการณ์หรือตารางประวัติการตรวจสอบ โดยมักอยู่คู่กับชื่อกิจกรรม ชื่อฟิลด์อาจเป็น 'วันที่สร้าง' 'วันที่เกิดเหตุการณ์' หรือ 'เวลาประทับ'. ตัวอย่าง 2023-10-26T10:00:00Z2023-10-26T10:15:30Z2023-10-27T14:05:00Z | |||
| ระบบต้นทาง SourceSystem | ระบบบันทึกข้อมูลต้นทางที่ใช้ดึงข้อมูลออกมา ซึ่งช่วยติดตามที่มาของข้อมูลได้. | ||
| คำอธิบาย แอตทริบิวต์ระบบต้นทางระบุแอปพลิเคชันหรือแพลตฟอร์มที่เป็นแหล่งข้อมูลบริการลูกค้า เช่น ServiceNow, Salesforce, Zendesk หรือระบบที่องค์กรพัฒนาขึ้นเอง เมื่อรวมข้อมูลจากหลายระบบ ฟิลด์นี้มีความสำคัญต่อการกำกับดูแลและติดตามที่มาของข้อมูล. แม้จะไม่ได้ใช้โดยตรงในการวิเคราะห์ลำดับกระบวนการทั่วไปส่วนใหญ่ แต่ฟิลด์นี้ให้บริบทที่สำคัญ ช่วยให้เข้าใจความแตกต่างที่อาจเกิดขึ้นด้านคุณภาพข้อมูลหรือการดำเนินกระบวนการระหว่างระบบ และยังจำเป็นต่อการตรวจสอบความถูกต้องของข้อมูล แก้ปัญหาการดึงข้อมูล และจัดการไปป์ไลน์การผสานข้อมูล. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูล การแก้ปัญหา และการวิเคราะห์ในสภาพแวดล้อมที่ใช้หลายระบบ. แหล่งข้อมูล โดยทั่วไปจะเพิ่มแอตทริบิวต์นี้ระหว่างการดึงข้อมูล (ETL) และอาจไม่มีอยู่ในตารางของระบบต้นทางโดยตรง. ตัวอย่าง Salesforce Service CloudZendesk SupportServiceNow CSM | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาประทับที่ระบุเวลาล่าสุดที่มีการรีเฟรชข้อมูลจากระบบต้นทาง. | ||
| คำอธิบาย แอตทริบิวต์อัปเดตข้อมูลล่าสุดบันทึกวันที่และเวลาที่ดึงหรือรีเฟรชข้อมูลครั้งล่าสุด ข้อมูลกำกับนี้สำคัญต่อการประเมินว่าข้อมูลที่นำมาวิเคราะห์เป็นปัจจุบันเพียงใด และการจัดการไปป์ไลน์ข้อมูล. แอตทริบิวต์นี้ช่วยให้ผู้ใช้และนักวิเคราะห์ทราบว่าข้อมูลที่ใช้วิเคราะห์เป็นข้อมูลล่าสุดเมื่อใด อีกทั้งยังช่วยกำหนดเวลาการรีเฟรชข้อมูลและทำให้มั่นใจว่าการตัดสินใจอ้างอิงข้อมูลที่ใหม่พอตามความต้องการ เมื่อติดตามกระบวนการที่กำลังดำเนินอยู่ การทราบเวลาอัปเดตล่าสุดเป็นสิ่งสำคัญต่อการตีความสถานะปัจจุบันของเคสที่ยังเปิดอยู่ให้ถูกต้อง. เหตุผลที่สำคัญ ระบุความใหม่ของข้อมูล เพื่อให้การวิเคราะห์และการตัดสินใจทางธุรกิจอ้างอิงข้อมูลที่ทันเวลาและเกี่ยวข้อง. แหล่งข้อมูล โดยทั่วไปเวลาประทับนี้จะสร้างและเพิ่มระหว่างขั้นตอนการดึงข้อมูล (ETL). ตัวอย่าง 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| กลุ่มผู้รับผิดชอบ AssignedGroup | ทีม แผนก หรือคิวที่ได้รับมอบหมายให้ดูแลคำขอรับบริการ. | ||
| คำอธิบาย กลุ่มผู้รับผิดชอบระบุทีมงานหรือหน่วยงานที่รับผิดชอบคำขอรับบริการ ณ ช่วงเวลาหนึ่ง เช่น 'ฝ่ายสนับสนุนระดับ 1' 'แผนกเรียกเก็บเงิน' หรือ 'ทีมสนับสนุนด้านเทคนิค' ระหว่างดำเนินการ คำขอรับบริการมักถูกส่งต่อระหว่างกลุ่มต่างๆ. การวิเคราะห์กลุ่มผู้รับผิดชอบช่วยให้เข้าใจการทำงานร่วมกันและการส่งต่องานระหว่างทีม ระบุได้ว่าทีมใดมีงานล้นมือ เกิดคอขวดระหว่างกลุ่มตรงไหน และคำขอแต่ละประเภทผ่านหน่วยงานใดบ้าง ข้อมูลนี้มีประโยชน์ต่อการปรับโครงสร้างทีม การจัดสรรทรัพยากร และการกำหนดกฎการส่งต่องานให้เหมาะสม. เหตุผลที่สำคัญ ช่วยวิเคราะห์ประสิทธิภาพของทีม การกระจายปริมาณงาน และความล่าช้าจากการส่งต่องานระหว่างแผนก. แหล่งข้อมูล อยู่ในระเบียนเคสหรือทิกเก็ต โดยมักใช้ชื่อฟิลด์ เช่น 'กลุ่มผู้รับผิดชอบ' 'ทีม' หรือ 'คิว'. ตัวอย่าง ฝ่ายสนับสนุนระดับ 1ข้อสอบถามเรื่องการเรียกเก็บเงินปัญหาด้านเทคนิคที่ต้องยกระดับฝ่ายสนับสนุนฮาร์ดแวร์ | |||
| ความพึงพอใจของลูกค้า CustomerSatisfaction | คะแนนหรือระดับความพึงพอใจที่ลูกค้าให้หลังจากแก้ไขคำขอรับบริการแล้ว. | ||
| คำอธิบาย ความพึงพอใจของลูกค้าเป็นตัวชี้วัดผลลัพธ์สำคัญที่สะท้อนมุมมองของลูกค้าต่อบริการที่ได้รับ โดยทั่วไปจะเก็บข้อมูลผ่านแบบสำรวจหลังแก้ไขปัญหา ซึ่งอาจใช้คะแนนตัวเลข เช่น 1 ถึง 5 หรือระดับความพึงพอใจ เช่น 'ดี' 'ปานกลาง' หรือ 'ไม่ดี'. แอตทริบิวต์นี้จำเป็นต่อการเชื่อมโยงประสิทธิภาพของกระบวนการกับผลลัพธ์ทางธุรกิจ เมื่อนำคะแนนความพึงพอใจมาเทียบกับตัวชี้วัดของกระบวนการ นักวิเคราะห์จะเห็นได้ว่าการทำงานแบบใดทำให้ลูกค้าพึงพอใจหรือไม่พอใจ ตัวอย่างเช่น การวิเคราะห์อาจพบว่าเคสที่มีการมอบหมายใหม่หลายครั้งหรือใช้เวลาแก้ไขนานมักได้คะแนนความพึงพอใจต่ำ ข้อมูลนี้ช่วยจัดลำดับความสำคัญของการปรับปรุงกระบวนการที่ส่งผลต่อประสบการณ์ลูกค้ามากที่สุดได้อย่างชัดเจน โดยอ้างอิงจากข้อมูลจริง. เหตุผลที่สำคัญ วัดมุมมองของลูกค้าต่อคุณภาพบริการโดยตรง และเชื่อมโยงประสิทธิภาพของกระบวนการกับผลลัพธ์ทางธุรกิจ. แหล่งข้อมูล โดยทั่วไปจัดเก็บไว้ในตารางคำตอบแบบสำรวจแยกต่างหาก ซึ่งเชื่อมโยงกับระเบียนคำขอรับบริการได้. ตัวอย่าง 5413 | |||
| เจ้าหน้าที่ Agent | ชื่อหรือรหัสเฉพาะของเจ้าหน้าที่บริการลูกค้าหรือผู้ใช้ที่รับผิดชอบกิจกรรมหนึ่ง. | ||
| คำอธิบาย แอตทริบิวต์เจ้าหน้าที่ระบุพนักงานที่ดำเนินกิจกรรมหนึ่ง หรือผู้ที่ได้รับมอบหมายให้ดูแลคำขอรับบริการในขณะนั้น ข้อมูลนี้อาจเป็นรหัสเฉพาะ ที่อยู่อีเมล หรือชื่อเต็ม. แอตทริบิวต์นี้ช่วยวิเคราะห์ประสิทธิภาพและปริมาณงานของพนักงานแต่ละคน ผู้จัดการสามารถดูการกระจายงาน เปรียบเทียบประสิทธิภาพของเจ้าหน้าที่จากตัวชี้วัด เช่น เวลาแก้ไขปัญหาหรือความพึงพอใจของลูกค้า และระบุโอกาสในการฝึกอบรม นอกจากนี้ยังจำเป็นต่อการวิเคราะห์การส่งต่องานระหว่างเจ้าหน้าที่ ซึ่งอาจทำให้เกิดความล่าช้าและสร้างความไม่พอใจให้ลูกค้า. เหตุผลที่สำคัญ แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ปริมาณงานและประสิทธิภาพของเจ้าหน้าที่ รวมถึงผลกระทบจากการส่งต่องานระหว่างเจ้าหน้าที่. แหล่งข้อมูล มักพบในตารางประวัติการมอบหมายเคส บันทึกเหตุการณ์ หรือฟิลด์ในระเบียนเคสหรือทิกเก็ตหลัก. ตัวอย่าง John Smithagent.jane@example.comuser_1138Sarah Doe | |||
| ช่องทางการติดต่อ CommunicationChannel | ช่องทางที่ใช้ส่งคำขอรับบริการหรือติดต่อสื่อสาร เช่น 'อีเมล' 'โทรศัพท์' หรือ 'แชต'. | ||
| คำอธิบาย ช่องทางการติดต่อระบุวิธีที่ลูกค้าใช้ติดต่อฝ่ายบริการลูกค้า ช่องทางที่พบบ่อย ได้แก่ อีเมล โทรศัพท์ พอร์ทัลเว็บ แชต และโซเชียลมีเดีย ช่องทางที่ใช้มีผลต่อความคาดหวังของลูกค้าและความซับซ้อนในการแก้ไขปัญหา. การวิเคราะห์กระบวนการแยกตามช่องทางการติดต่ออาจเผยให้เห็นความแตกต่างด้านประสิทธิภาพอย่างชัดเจน ตัวอย่างเช่น คำขอทางโทรศัพท์อาจแก้ไขได้เร็วกว่า แต่ใช้เวลาของเจ้าหน้าที่มากกว่าคำขอที่ส่งผ่านพอร์ทัลเว็บ การวิเคราะห์นี้ช่วยให้องค์กรปรับกลยุทธ์ช่องทาง จัดสรรทรัพยากรได้เหมาะสม และปรับประสบการณ์การบริการให้เข้ากับวิธีติดต่อแต่ละแบบ. เหตุผลที่สำคัญ ช่วยให้เห็นว่าช่องทางการติดต่อแต่ละแบบส่งผลต่อเวลาแก้ไขปัญหา ภาระงานของเจ้าหน้าที่ และประสิทธิภาพโดยรวมของกระบวนการอย่างไร. แหล่งข้อมูล โดยทั่วไปมีเป็นฟิลด์มาตรฐานในระเบียนเคสหรือทิกเก็ต เพื่อระบุวิธีที่ลูกค้าส่งคำขอ. ตัวอย่าง อีเมลโทรศัพท์แชตพอร์ทัลเว็บโซเชียลมีเดีย | |||
| ประเภทคำขอ RequestType | การจัดประเภทคำขอรับบริการ เช่น 'คำถาม' 'เหตุขัดข้อง' 'ปัญหา' หรือ 'คำขอฟีเจอร์'. | ||
| คำอธิบาย ประเภทคำขอใช้จัดหมวดหมู่ปัญหาหรือข้อสอบถามของลูกค้าในระดับกว้าง การจัดประเภทนี้ช่วยแบ่งกลุ่มคำขอรับบริการ เพื่อให้เข้าใจความต้องการที่ฝ่ายสนับสนุนต้องรับมือ ประเภทที่พบบ่อย ได้แก่ ปัญหาด้านเทคนิค คำถามเรื่องการเรียกเก็บเงิน คำขอข้อมูล หรือข้อร้องเรียน. แอตทริบิวต์นี้มีประโยชน์ต่อการวิเคราะห์ เพราะช่วยกรองและเปรียบเทียบกระบวนการของคำขอแต่ละประเภทได้ ตัวอย่างเช่น กระบวนการแก้ไข 'คำถามเรื่องการเรียกเก็บเงิน' อาจง่ายและเร็วกว่าการจัดการ 'เหตุขัดข้องทางเทคนิค' มาก การเข้าใจความแตกต่างเหล่านี้ช่วยกำหนด SLA ออกแบบเวิร์กโฟลว์ให้มีประสิทธิภาพ และจัดสรรทรัพยากรได้เหมาะสม. เหตุผลที่สำคัญ การแบ่งคำขอตามประเภทจำเป็นต่อการทำความเข้าใจเส้นทางของกระบวนการที่แตกต่างกัน และปรับปรุงการทำงานให้เหมาะกับปัญหาแต่ละประเภท. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในแบบฟอร์มเคสหรือทิกเก็ตหลัก โดยมักใช้ชื่อ 'ประเภท' 'หมวดหมู่' หรือ 'การจัดประเภท'. ตัวอย่าง เหตุขัดข้องคำถามปัญหาคำขอฟีเจอร์ | |||
| มีการยกระดับหรือไม่ IsEscalated | แฟล็กที่ระบุว่ามีการส่งคำขอรับบริการไปยังฝ่ายสนับสนุนหรือผู้บริหารระดับสูงขึ้นหรือไม่. | ||
| คำอธิบาย แอตทริบิวต์มีการยกระดับหรือไม่เป็นแฟล็กแบบบูลีน (จริงหรือเท็จ) ที่ระบุว่ามีการส่งคำขอรับบริการเข้าสู่กระบวนการยกระดับอย่างเป็นทางการ โดยทั่วไปจะยกระดับเมื่อปัญหาซับซ้อนเกินกว่าที่ฝ่ายสนับสนุนระดับปัจจุบันจะจัดการได้ แก้ไขไม่ทันเวลาที่กำหนด หรือลูกค้าไม่พึงพอใจอย่างมาก. แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์การยกระดับ ช่วยให้องค์กรคำนวณอัตราการยกระดับ ซึ่งเป็นตัวชี้วัดประสิทธิภาพสำคัญได้ เมื่อวิเคราะห์ลำดับกระบวนการของเคสที่ถูกยกระดับ องค์กรจะระบุสาเหตุหลักได้ เช่น ช่องว่างด้านทักษะของฝ่ายสนับสนุนด่านหน้า กระบวนการไม่ชัดเจน หรือปัญหาของผลิตภัณฑ์ การลดการยกระดับมักเป็นเป้าหมายสำคัญ เพราะมีค่าใช้จ่ายสูงและอาจส่งผลเสียต่อความพึงพอใจของลูกค้า. เหตุผลที่สำคัญ ช่วยระบุความถี่และสาเหตุหลักของการยกระดับ พร้อมชี้จุดที่ควรปรับปรุงเพื่อแก้ปัญหาได้ตั้งแต่การติดต่อครั้งแรก. แหล่งข้อมูล มักเป็นช่องทำเครื่องหมายหรือฟิลด์แฟล็กในระเบียนเคสหรือทิกเก็ต และอาจระบุได้จากกิจกรรม 'ยกระดับ'. ตัวอย่าง truefalse | |||
| ระดับความสำคัญ Priority | ระดับความสำคัญที่กำหนดให้คำขอรับบริการ เช่น 'ต่ำ' 'ปานกลาง' 'สูง' หรือ 'เร่งด่วน'. | ||
| คำอธิบาย แอตทริบิวต์ระดับความสำคัญแสดงความเร่งด่วนของคำขอรับบริการ ซึ่งมักกำหนดว่าต้องจัดการคำขอเร็วเพียงใด โดยทั่วไปจะพิจารณาจากผลกระทบต่อธุรกิจและความรุนแรงของปัญหาที่ลูกค้าแจ้ง SLA มักกำหนดตามระดับความสำคัญ. ในการวิเคราะห์กระบวนการ ระดับความสำคัญเป็นมิติสำคัญสำหรับกรองและเปรียบเทียบ นักวิเคราะห์ตรวจสอบได้ว่าคำขอที่มีความสำคัญสูงได้รับการแก้ไขเร็วกว่าคำขอที่มีความสำคัญต่ำตามที่คาดไว้หรือไม่ นอกจากนี้ยังช่วยตรวจสอบว่ามีการทำตามกฎการจัดลำดับความสำคัญ และการจัดสรรทรัพยากรสอดคล้องกับลำดับความสำคัญทางธุรกิจหรือไม่ การเปรียบเทียบลำดับกระบวนการของคำขอแต่ละระดับอาจเผยให้เห็นจุดที่จัดการปัญหาเร่งด่วนได้ไม่มีประสิทธิภาพ. เหตุผลที่สำคัญ ช่วยวิเคราะห์ว่าคำขอเร่งด่วนได้รับการจัดการเร็วขึ้นหรือไม่ และตรวจสอบว่าการจัดสรรทรัพยากรสอดคล้องกับความต้องการทางธุรกิจ. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในแบบฟอร์มเคสหรือทิกเก็ตของระบบบริการลูกค้าส่วนใหญ่. ตัวอย่าง ต่ำปานกลางสูงเร่งด่วน | |||
| เวลาสิ้นสุด EndTime | เวลาประทับที่ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด ใช้คำนวณระยะเวลาของกิจกรรมแต่ละรายการ. | ||
| คำอธิบาย แอตทริบิวต์เวลาสิ้นสุดระบุเวลาที่กิจกรรมเสร็จสิ้น ส่วนเวลาเกิดเหตุการณ์ระบุเวลาเริ่มต้น เวลาสิ้นสุดจึงเป็นข้อมูลอีกจุดที่จำเป็นต่อการวัดว่างานหนึ่งใช้เวลานานเท่าใด เหตุการณ์บางรายการไม่มีเวลาสิ้นสุดที่ชัดเจน แต่ข้อมูลนี้มีประโยชน์สำหรับกิจกรรมที่มีเวลาเริ่มและสิ้นสุด เช่น 'เจ้าหน้าที่ตรวจสอบปัญหา' หรือการโทรหาลูกค้า. ในการวิเคราะห์ เวลาสิ้นสุดลบด้วยเวลาเกิดเหตุการณ์จะได้ระยะเวลาที่ใช้ดำเนินกิจกรรม ซึ่งเป็นข้อมูลพื้นฐานสำหรับวิเคราะห์คอขวด เพื่อหาว่าขั้นตอนใดใช้เวลามากที่สุด การเข้าใจระยะเวลาของกิจกรรมช่วยวางแผนทรัพยากร ประเมินประสิทธิภาพ และหาจุดที่ปรับปรุงการปฏิบัติการให้คล่องตัวขึ้นได้. เหตุผลที่สำคัญ แอตทริบิวต์นี้ใช้คำนวณระยะเวลาของกิจกรรมแต่ละรายการ ซึ่งจำเป็นต่อการระบุคอขวดและวัดประสิทธิภาพ. แหล่งข้อมูล โดยทั่วไปพบในบันทึกเหตุการณ์หรือตารางประวัติการตรวจสอบ โดยอยู่คู่กับเวลาเริ่มต้น หากไม่มีข้อมูลนี้ อาจต้องคำนวณจากเวลาเริ่มต้นของเหตุการณ์ถัดไป. ตัวอย่าง 2023-10-26T10:30:00Z2023-10-26T11:00:45Z2023-10-27T16:20:00Z | |||
| สถานะคำขอ RequestStatus | สถานะปัจจุบันหรือสถานะย้อนหลังของคำขอรับบริการ เช่น 'เปิด' 'รอดำเนินการ' 'แก้ไขแล้ว' หรือ 'ปิดแล้ว'. | ||
| คำอธิบาย สถานะคำขอแสดงสถานะของคำขอรับบริการ ณ ช่วงหนึ่งในวงจรการดำเนินงาน สถานะจะเปลี่ยนไปตามความคืบหน้าของคำขอ เช่น จาก 'ใหม่' เป็น 'กำลังดำเนินการ' จากนั้นเป็น 'รอลูกค้า' และสุดท้ายเป็น 'แก้ไขแล้ว' ลำดับการเปลี่ยนสถานะมักใช้กำหนดกิจกรรมในแบบจำลองกระบวนการ. การวิเคราะห์การเปลี่ยนสถานะเป็นวิธีหลักในการทำความเข้าใจลำดับกระบวนการ ช่วยระบุเวลาที่คำขอค้างอยู่ในสถานะต่างๆ เช่น 'รอดำเนินการ' ซึ่งอาจแสดงให้เห็นว่าต้องรอหน่วยงานภายนอก นอกจากนี้ยังใช้แยกเคสที่เปิดอยู่กับเคสที่ปิดแล้ว ซึ่งเป็นข้อมูลพื้นฐานสำหรับรายงานจำนวนเคสที่กำลังดำเนินการและอัตราการแก้ไขปัญหา. เหตุผลที่สำคัญ ติดตามขั้นตอนในวงจรของคำขอ ช่วยระบุเวลาที่ใช้รอและกำหนดกิจกรรมในกระบวนการ. แหล่งข้อมูล เป็นฟิลด์หลักในระเบียนเคสหรือทิกเก็ต โดยมักบันทึกการเปลี่ยนสถานะไว้ในตารางประวัติการตรวจสอบ. ตัวอย่าง ใหม่กำลังดำเนินการรอลูกค้าแก้ไขแล้วปิดแล้ว | |||
| ผลิตภัณฑ์ Product | ผลิตภัณฑ์หรือบริการที่เกี่ยวข้องกับคำขอของลูกค้า. | ||
| คำอธิบาย แอตทริบิวต์ผลิตภัณฑ์ระบุผลิตภัณฑ์ บริการ หรือฟีเจอร์ที่เกี่ยวข้องกับคำขอของลูกค้า ช่วยจัดหมวดหมู่คำขอรับบริการตามส่วนงานที่เกี่ยวข้อง. การวิเคราะห์คำขอรับบริการแยกตามผลิตภัณฑ์มีความสำคัญต่อการหาสาเหตุหลักและปรับปรุงผลิตภัณฑ์ หากมีทิกเก็ตจำนวนมากเกี่ยวกับผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง อาจเป็นสัญญาณว่ามีปัญหาด้านคุณภาพ ข้อบกพร่อง หรือการใช้งาน ข้อมูลนี้เป็นความคิดเห็นที่มีประโยชน์ต่อทีมพัฒนาผลิตภัณฑ์และทีมวิศวกรรม ช่วยจัดลำดับความสำคัญของการแก้ไขและปรับปรุง เพื่อลดภาระงานของฝ่ายสนับสนุนและยกระดับประสบการณ์ของลูกค้า. เหตุผลที่สำคัญ เชื่อมโยงคำขอรับบริการกับผลิตภัณฑ์แต่ละรายการ เพื่อให้ข้อมูลสำคัญสำหรับการปรับปรุงผลิตภัณฑ์และการหาสาเหตุหลัก. แหล่งข้อมูล มักเป็นฟิลด์ในแบบฟอร์มเคสหรือทิกเก็ตที่เชื่อมโยงกับแค็ตตาล็อกผลิตภัณฑ์ หรือให้กรอกข้อมูลเองได้. ตัวอย่าง เครื่องพิมพ์ Alpha-100Enterprise Suite v2.5แอปมือถือแพลตฟอร์มเรียกเก็บเงิน | |||
| ลูกค้า Customer | ชื่อหรือรหัสเฉพาะของลูกค้าหรือบริษัทที่ส่งคำขอรับบริการ. | ||
| คำอธิบาย แอตทริบิวต์ลูกค้าระบุลูกค้าภายนอก ไม่ว่าจะเป็นบุคคลหรือองค์กร ที่เกี่ยวข้องกับคำขอรับบริการ ช่วยจัดกลุ่มและวิเคราะห์การติดต่อเพื่อรับบริการทั้งหมดของลูกค้าแต่ละราย. การมองกระบวนการโดยยึดลูกค้าเป็นหลักช่วยให้เข้าใจประสบการณ์โดยรวมของลูกค้า เมื่อตรวจสอบข้อมูลโดยกรองตามลูกค้า ธุรกิจจะระบุลูกค้าที่ส่งคำขอจำนวนมากได้ ซึ่งอาจบ่งชี้ถึงปัญหาของผลิตภัณฑ์หรือความจำเป็นในการอบรมเพิ่มเติม นอกจากนี้ยังช่วยติดตามประวัติการรับบริการของลูกค้ารายสำคัญ เพื่อให้มั่นใจว่าได้รับการสนับสนุนตามระดับที่คาดหวัง. เหตุผลที่สำคัญ ช่วยให้มองกระบวนการโดยยึดลูกค้าเป็นหลัก ระบุปัญหาที่เกิดซ้ำกับลูกค้าแต่ละราย และดูแลลูกค้ารายสำคัญได้. แหล่งข้อมูล เป็นฟิลด์มาตรฐานในระเบียนเคสหรือทิกเก็ต ซึ่งเชื่อมโยงกับออบเจ็กต์ผู้ติดต่อหรือบัญชีใน CRM. ตัวอย่าง ABC CorporationGlobal Tech Inc.Jane DoeACCT-00123 | |||
| เวลาเป้าหมายของ SLA SlaTargetTime | วันที่และเวลาที่ตกลงกันไว้ในสัญญาหรือกำหนดเป็นเป้าหมายสำหรับการแก้ไขคำขอรับบริการ. | ||
| คำอธิบาย เวลาเป้าหมายของ SLA คือกำหนดเวลาที่คาดว่าจะต้องแก้ไขคำขอรับบริการให้เสร็จตามข้อตกลงระดับการให้บริการ (SLA) ที่เกี่ยวข้อง เป้าหมายนี้มักขึ้นอยู่กับระดับความสำคัญ ประเภทคำขอ หรือระดับสัญญาของลูกค้า โดยอาจจัดเก็บเป็นเวลาประทับที่ระบุชัดเจน หรือเป็นระยะเวลานับจากเวลาที่สร้างคำขอ. แอตทริบิวต์นี้เป็นพื้นฐานสำคัญสำหรับการวิเคราะห์การปฏิบัติตาม SLA เมื่อนำเวลาแก้ไขจริงมาเปรียบเทียบกับเวลาเป้าหมายของ SLA องค์กรจะคำนวณอัตราการปฏิบัติตาม SLA ได้ process mining ยังช่วยแจกแจงผลให้ละเอียดขึ้น โดยแสดงว่าคำขอประเภทใดหรือขั้นตอนใดมีส่วนทำให้ไม่เป็นไปตาม SLA มากที่สุด ข้อมูลนี้ช่วยให้ปรับปรุงได้ตรงจุดเพื่อให้เป็นไปตามข้อตกลงการให้บริการ. เหตุผลที่สำคัญ จำเป็นต่อการวัดการปฏิบัติตาม SLA ซึ่งเป็น KPI สำคัญขององค์กรที่ให้บริการลูกค้า. แหล่งข้อมูล โดยทั่วไปคำนวณและจัดเก็บไว้ในระเบียนเคสหรือทิกเก็ตตามนโยบาย SLA ที่กำหนดไว้ในระบบ. ตัวอย่าง 2023-10-28T10:00:00Z2023-11-01T17:00:00Z2023-10-26T14:00:00Z | |||
กิจกรรมการบริการลูกค้า
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| แก้ไขคำขอเสร็จแล้ว | เป็นหมุดหมายสำคัญที่เจ้าหน้าที่ทำงานเสร็จและเห็นว่าปัญหาของลูกค้าได้รับการแก้ไขแล้ว โดยเปลี่ยนคำขอเป็นสถานะ 'Resolved' หรือ 'Solved'. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์หลักสำหรับวัดเวลาแก้ไข แสดงว่าทีมสนับสนุนทำงานที่ต้องลงมือจริงเสร็จแล้ว และเป็นหมุดหมายสำคัญในวงจรการให้บริการ. แหล่งข้อมูล บันทึกจากการเปลี่ยนสถานะอย่างชัดเจนเป็น 'Resolved' หรือ 'Solved' โดยระบบส่วนใหญ่จะบันทึกเวลาแก้ไขไว้โดยเฉพาะ. บันทึก ใช้เวลาจากฟิลด์ 'Resolved At' หรือเวลาที่เปลี่ยนสถานะเป็น 'Resolved'. ประเภทเหตุการณ์ explicit | |||
| ปิดคำขอรับบริการ | กิจกรรมสุดท้ายนี้เป็นการปิดคำขอรับบริการอย่างเป็นทางการในระบบงานธุรการ เมื่อถึงขั้นตอนนี้ถือว่าคำขอเสร็จสมบูรณ์และไม่ต้องดำเนินการต่อ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดสิ้นสุดของวงจรคำขออย่างเป็นทางการ ระยะเวลาตั้งแต่แก้ไขปัญหาเสร็จจนถึงปิดคำขออาจช่วยให้เห็นนโยบายของกระบวนการ เช่น การปิดคำขออัตโนมัติหรือการตรวจสอบขั้นสุดท้าย. แหล่งข้อมูล บันทึกเมื่อมีการเปลี่ยนสถานะเป็น 'ปิดแล้ว' โดยตรง หลายระบบมีเวลาประทับ 'เวลาที่ปิด' โดยเฉพาะ. บันทึก ใช้เวลาประทับ 'เวลาที่ปิด' หรือเวลาที่เปลี่ยนสถานะเป็น 'ปิดแล้ว'. ประเภทเหตุการณ์ explicit | |||
| เปิดคำขออีกครั้ง | เกิดขึ้นเมื่อคำขอรับบริการที่แก้ไขแล้วกลับมาอยู่ในสถานะที่กำลังดำเนินการ โดยทั่วไปเกิดเมื่อลูกค้าแจ้งว่าปัญหายังไม่ได้รับการแก้ไขหรือเกิดขึ้นอีก. | ||
| เหตุผลที่สำคัญ คำขอที่เปิดอีกครั้งเป็นตัววัดงานแก้ซ้ำโดยตรง และบ่งชี้อย่างชัดเจนว่าแก้ปัญหาไม่ได้ตั้งแต่การติดต่อครั้งแรก การวิเคราะห์เหตุการณ์เหล่านี้สำคัญต่อการยกระดับคุณภาพการแก้ปัญหา. แหล่งข้อมูล โดยทั่วไปเป็นเหตุการณ์ที่ระบบเปลี่ยนสถานะจาก 'Resolved' กลับเป็น 'Open' โดยอัตโนมัติเมื่อได้รับข้อความตอบกลับใหม่จากลูกค้า. บันทึก ตรวจหาการเปลี่ยนสถานะจาก 'Resolved' หรือ 'Closed' กลับเป็น 'Open' หรือ 'In Progress'. ประเภทเหตุการณ์ explicit | |||
| มอบหมายคำขอ | หมายถึงการมอบหมายคำขอรับบริการให้เจ้าหน้าที่หรือทีมที่รับผิดชอบเป็นครั้งแรก ขั้นตอนสำคัญนี้นำคำขอออกจากคิวเข้าสู่การทำงานจริง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการติดตามปริมาณงานของเจ้าหน้าที่ วัดเวลาจนถึงการมอบหมายครั้งแรก และระบุคอขวดในขั้นตอนกระจายงาน. แหล่งข้อมูล บันทึกจากการเปลี่ยนฟิลด์ 'Owner' หรือ 'Assigned To' ในบันทึกการตรวจสอบหรือประวัติของระเบียนคำขอรับบริการ. บันทึก ระบุการกำหนดค่าหรือการเปลี่ยนแปลงครั้งแรกของฟิลด์เจ้าหน้าที่หรือกลุ่มที่รับผิดชอบ. ประเภทเหตุการณ์ explicit | |||
| มอบหมายคำขอใหม่ | หมายถึงการโอนความรับผิดชอบของคำขอรับบริการจากเจ้าหน้าที่หรือทีมหนึ่งไปยังอีกทีมหนึ่ง หลังจากมอบหมายครั้งแรก ถือเป็นการส่งต่องานในกระบวนการสนับสนุน. | ||
| เหตุผลที่สำคัญ การติดตามการมอบหมายใหม่สำคัญต่อการวิเคราะห์การทำงานที่ขาดความต่อเนื่องและค้นหาการส่งต่องานที่ไม่จำเป็น หากมีการมอบหมายใหม่บ่อยครั้ง อาจเกิดจากปัญหาในการกำหนดเส้นทางหรือช่องว่างด้านความรู้. แหล่งข้อมูล อนุมานจากการติดตามการเปลี่ยนฟิลด์ 'Owner', 'Assigned To' หรือ 'Assignment Group' หลังการมอบหมายครั้งแรก. บันทึก ระบุการเปลี่ยนแปลงทั้งหมดของฟิลด์ผู้รับผิดชอบหรือกลุ่มที่รับผิดชอบหลังการมอบหมายครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| ยกระดับคำขอ | หมายถึงการส่งคำขอรับบริการอย่างเป็นทางการไปยังทีมสนับสนุนระดับสูงกว่า แผนกอื่น หรือผู้บริหาร ซึ่งเกิดขึ้นเมื่อเจ้าหน้าที่คนแรกแก้ปัญหาไม่ได้. | ||
| เหตุผลที่สำคัญ การยกระดับคำขอเป็นตัวชี้วัดสำคัญของความซับซ้อนในกระบวนการ ความสามารถของเจ้าหน้าที่ และการแก้ปัญหาไม่ได้ตั้งแต่การติดต่อครั้งแรก การวิเคราะห์เส้นทางการยกระดับช่วยปรับโครงสร้างการสนับสนุนให้เหมาะสม. แหล่งข้อมูล อาจบันทึกเป็นเหตุการณ์โดยตรงจากระบบกฎการยกระดับ หรืออนุมานจากการมอบหมายใหม่ให้ทีมหรือผู้ใช้ที่กำหนดไว้สำหรับรับเรื่องยกระดับ. บันทึก ใช้แฟล็กหรือเวลาที่บันทึกไว้สำหรับการยกระดับโดยเฉพาะ หรือระบุการเปลี่ยนผู้รับผิดชอบไปยังทีมรับเรื่องยกระดับที่ทราบอยู่แล้ว. ประเภทเหตุการณ์ explicit | |||
| สร้างคำขอรับบริการ | เป็นจุดเริ่มต้นของกระบวนการบริการลูกค้า เมื่อบันทึกคำขอของลูกค้าอย่างเป็นทางการ ระบบต้นทางจะบันทึกเหตุการณ์นี้เมื่อสร้างเคส ทิกเก็ต หรือรายการการติดต่อใหม่. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ จำเป็นต่อการวัดระยะเวลาตลอดวงจรและวิเคราะห์ปริมาณคำขอที่เข้ามาในแต่ละช่วงเวลา. แหล่งข้อมูล โดยทั่วไปใช้เวลาที่สร้างระเบียนเคสหรือทิกเก็ตหลักในระบบจัดการบริการ. บันทึก ใช้เวลาที่สร้างเคส ทิกเก็ต หรือรายการเหตุขัดข้องหลัก. ประเภทเหตุการณ์ explicit | |||
| ขอข้อมูลจากลูกค้า | เกิดขึ้นเมื่อเจ้าหน้าที่ต้องการข้อมูลเพิ่มเติมจากลูกค้าเพื่อดำเนินงานต่อ และเปลี่ยนคำขอเป็นสถานะรอดำเนินการ ซึ่งจะหยุดตัวจับเวลาของกระบวนการภายในหรือ SLA. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยให้เข้าใจความล่าช้าที่เกิดจากลูกค้า การติดตามระยะเวลาที่อยู่ในสถานะนี้ช่วยแยกเวลาทำงานของเจ้าหน้าที่ออกจากเวลารอลูกค้า. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะเป็นค่า เช่น 'Pending', 'On Hold' หรือ 'Awaiting Customer Info'. บันทึก ระบุการเปลี่ยนสถานะเป็น 'pending' หรือสถานะที่รอข้อมูลจากลูกค้าในประวัติเคส. ประเภทเหตุการณ์ inferred | |||
| จัดหมวดหมู่คำขอ | หมายถึงการจัดประเภท หมวดหมู่ หรือระดับความสำคัญให้คำขอรับบริการ ขั้นตอนนี้มักดำเนินการโดยเจ้าหน้าที่หรือกฎอัตโนมัติ เพื่อกำหนดความเร่งด่วนและเส้นทางส่งต่อ. | ||
| เหตุผลที่สำคัญ การวิเคราะห์การเปลี่ยนหมวดหมู่ช่วยให้เห็นประสิทธิภาพการคัดแยก งานแก้ซ้ำ และคำขอที่ส่งผิดทีม อีกทั้งยังช่วยให้เข้าใจความซับซ้อนและลักษณะของคำขอรับบริการ. แหล่งข้อมูล โดยทั่วไปอนุมานจากบันทึกการตรวจสอบหรือประวัติการเปลี่ยนฟิลด์ เช่น 'Category', 'Type' หรือ 'Priority' ในระเบียนคำขอรับบริการ. บันทึก ตรวจหาการเปลี่ยนแปลงฟิลด์หมวดหมู่ ระดับความสำคัญ หรือประเภทในประวัติเคส. ประเภทเหตุการณ์ inferred | |||
| เจ้าหน้าที่เริ่มตรวจสอบ | หมายถึงเจ้าหน้าที่เริ่มลงมือทำงานกับคำขอรับบริการ ซึ่งต่างจากการมอบหมายงาน และเป็นจุดเริ่มต้นของการวินิจฉัยหรือแก้ไขปัญหา. | ||
| เหตุผลที่สำคัญ ช่วยแยกเวลารอออกจากเวลาที่ลงมือทำงานจริง การวิเคราะห์กิจกรรมนี้อาจเผยให้เห็นความล่าช้าระหว่างการมอบหมายกับการเริ่มทำงาน. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะของคำขอรับบริการ เช่น จาก 'New' หรือ 'Assigned' เป็น 'In Progress' หรือ 'Work in Progress'. บันทึก ระบุการเปลี่ยนสถานะครั้งแรกหลังมอบหมายงานไปเป็นสถานะที่กำลังดำเนินการ. ประเภทเหตุการณ์ inferred | |||
| ได้รับข้อมูลจากลูกค้า | หมายถึงช่วงเวลาที่ลูกค้าส่งข้อมูลที่ร้องขอ ทำให้เจ้าหน้าที่กลับมาทำงานต่อได้ โดยทั่วไปเหตุการณ์นี้จะเปลี่ยนคำขอจากสถานะรอดำเนินการกลับเป็นสถานะที่กำลังทำงาน. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้สิ้นสุดช่วงเวลาที่รอลูกค้า การวิเคราะห์เวลาระหว่างกิจกรรมนี้กับ 'Information Requested' ช่วยให้เห็นเวลาที่ลูกค้าใช้ตอบกลับ. แหล่งข้อมูล อนุมานจากข้อความขาเข้าจากลูกค้า หรือการเปลี่ยนสถานะอัตโนมัติจาก 'Pending' กลับเป็น 'Open' หรือ 'In Progress'. บันทึก ตรวจหาข้อความขาเข้าจากลูกค้า หรือการเปลี่ยนสถานะจากสถานะ 'pending' เป็นสถานะที่กำลังดำเนินการ. ประเภทเหตุการณ์ inferred | |||
| ได้รับผลประเมินความพึงพอใจจากลูกค้า | เหตุการณ์นี้เกิดขึ้นเมื่อลูกค้าส่งคำตอบแบบสำรวจความพึงพอใจ ระบบจะบันทึกความคิดเห็น เช่น คะแนนหรือข้อความ ไว้กับคำขอรับบริการ. | ||
| เหตุผลที่สำคัญ เชื่อมโยงการดำเนินกระบวนการกับคุณภาพบริการในมุมมองของลูกค้าโดยตรง การวิเคราะห์คะแนนความพึงพอใจควบคู่กับข้อมูลกระบวนการช่วยระบุขั้นตอนที่ทำให้ลูกค้าได้รับประสบการณ์ไม่ดี. แหล่งข้อมูล บันทึกจากโมดูลแบบสำรวจเมื่อลูกค้าส่งคำตอบและเชื่อมโยงกับคำขอรับบริการต้นทาง. บันทึก ใช้เวลาที่ลูกค้าส่งคำตอบแบบสำรวจความพึงพอใจ. ประเภทเหตุการณ์ explicit | |||
| ผิด SLA | หมายถึงช่วงเวลาที่คำขอรับบริการไม่เป็นไปตาม Service Level Agreement ที่กำหนด เช่น เวลาตอบกลับครั้งแรกหรือเวลาแก้ไขให้เสร็จ นี่คือเหตุการณ์สำคัญต่อธุรกิจ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ใช้วัดระดับการให้บริการและการปฏิบัติตามข้อกำหนดโดยตรง การวิเคราะห์ว่าเกิดการผิด SLA เมื่อใดและเพราะเหตุใดจำเป็นต่อการปรับปรุงกระบวนการและการจัดการความคาดหวังของลูกค้า. แหล่งข้อมูล เหตุการณ์นี้คำนวณขึ้นจากการเปรียบเทียบเวลาของกิจกรรมกับเป้าหมาย SLA ที่กำหนดไว้ในสัญญาบริการหรือระบบนโยบาย. บันทึก เปรียบเทียบช่วงเวลาระหว่างกิจกรรมเริ่มต้นและสิ้นสุดกับเป้าหมาย SLA ที่กำหนด หากระยะเวลาเกินเป้าหมาย ให้บันทึกเหตุการณ์ผิด SLA. ประเภทเหตุการณ์ calculated | |||
| เพิ่มความคิดเห็นภายใน | เจ้าหน้าที่เพิ่มบันทึกหรือความคิดเห็นส่วนตัวในคำขอรับบริการ เพื่อประสานงานกับเจ้าหน้าที่หรือทีมอื่นภายใน โดยลูกค้าจะไม่เห็นข้อมูลนี้. | ||
| เหตุผลที่สำคัญ เหตุการณ์เหล่านี้แสดงถึงการประสานงานภายใน การแบ่งปันความรู้ หรือการเตรียมยกระดับคำขอ หากมีบันทึกภายในบ่อยครั้ง อาจบ่งชี้ว่าเคสซับซ้อนหรือทีมขาดความรู้ที่จำเป็น. แหล่งข้อมูล บันทึกจากกระแสกิจกรรมหรือบันทึกการสื่อสารของคำขอรับบริการ โดยกรองเฉพาะความคิดเห็นที่ระบุว่าเป็น 'internal' หรือ 'private'. บันทึก กรองความคิดเห็นหรือบันทึกกิจกรรมของเคส เพื่อดูรายการที่กำหนดให้เห็นเฉพาะภายใน. ประเภทเหตุการณ์ explicit | |||
| ส่งคำตอบครั้งแรก | หมายถึงการสื่อสารโดยตรงครั้งแรกที่เจ้าหน้าที่ส่งถึงลูกค้าหลังสร้างคำขอ โดยไม่รวมข้อความอัตโนมัติ นี่คือหมุดหมายสำคัญในการเริ่มดูแลลูกค้า. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการวัดและติดตาม SLA ของ 'First Response Time' ซึ่งแสดงว่าทีมสนับสนุนเริ่มจัดการปัญหาของลูกค้าได้รวดเร็วเพียงใด. แหล่งข้อมูล มักเป็นเหตุการณ์ที่มีการบันทึกเวลาไว้อย่างชัดเจนในระบบ SLA หรืออาจอนุมานจากข้อความสาธารณะขาออกข้อความแรกที่เจ้าหน้าที่ส่งในไทม์ไลน์ของเคส. บันทึก ใช้เวลาของ 'First Response Time' โดยเฉพาะหากมี หรือใช้เวลาของข้อความขาออกข้อความแรกจากเจ้าหน้าที่. ประเภทเหตุการณ์ explicit | |||
| ส่งแบบสำรวจความพึงพอใจ | หมายถึงการส่งแบบสำรวจความพึงพอใจให้ลูกค้า ซึ่งโดยทั่วไปจะเริ่มจากกฎอัตโนมัติหลังแก้ไขคำขอรับบริการแล้ว และเป็นจุดเริ่มต้นของการรวบรวมความคิดเห็น. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยให้เข้าใจบริบทของตัวชี้วัดความคิดเห็นจากลูกค้า และใช้วิเคราะห์อัตราการตอบแบบสำรวจรวมถึงช่วงเวลาที่ส่งคำขอความคิดเห็นได้. แหล่งข้อมูล บันทึกจากบันทึกการทำงานอัตโนมัติ ระเบียนอีเมลขาออก หรือระเบียนแบบสำรวจโดยเฉพาะที่เชื่อมโยงกับคำขอรับบริการ. บันทึก ระบุการสร้างออบเจ็กต์แบบสำรวจหรือข้อความขาออกที่เกี่ยวข้องกับแบบสำรวจความพึงพอใจ. ประเภทเหตุการณ์ explicit | |||
| เสนอแนวทางแก้ไข | หมายถึงเจ้าหน้าที่คิดแนวทางแก้ไขและแจ้งให้ลูกค้าทราบ กิจกรรมนี้อาจเกิดก่อนการปิดคำขออย่างเป็นทางการ โดยเฉพาะเมื่อจำเป็นต้องรอการยืนยันจากลูกค้า. | ||
| เหตุผลที่สำคัญ ขั้นตอนนี้ช่วยแยกเวลาที่ใช้ค้นหาแนวทางแก้ไขออกจากเวลาที่รอลูกค้ายอมรับ ทำให้เห็นรายละเอียดของช่วงการแก้ปัญหาได้ชัดเจนขึ้น. แหล่งข้อมูล โดยทั่วไปอนุมานจากข้อความขาออกที่มีรายละเอียดการแก้ไข หรือการเปลี่ยนสถานะเป็น 'Awaiting Acceptance' หรือ 'Solution Provided'. บันทึก ระบุข้อความขาออกที่มีคำสำคัญ เช่น 'solution' หรือการเปลี่ยนสถานะที่แสดงว่ามีการเสนอแนวทางแก้ไขแล้ว. ประเภทเหตุการณ์ inferred | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงกระบวนการบริการลูกค้าของคุณได้โดยเลือกคู่มือการดึงข้อมูลสำหรับระบบที่ใช้ หรือใช้เทมเพลตทั่วไปนี้เป็นจุดเริ่มต้นในการเตรียมข้อมูล.
ยกระดับการบริการลูกค้าของคุณได้ตั้งแต่วันนี้
ค้นหาคอขวด เพิ่มประสิทธิภาพการทำงานของเจ้าหน้าที่ และสร้างความประทับใจให้ลูกค้า.
ไม่ต้องใช้บัตรเครดิต เริ่มต้นได้ภายในไม่กี่นาที.