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

เทมเพลต process mining สำหรับทุกกระบวนการ
เทมเพลตข้อมูลการบริการลูกค้าของคุณ

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

เทมเพลต process mining สำหรับทุกกระบวนการ

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

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

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

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

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

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

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

เตรียมข้อมูลสำหรับ process mining อย่างไร.

วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด

อ่านคู่มือ ETL ของเรา   หรือ   เลือกกระบวนการและระบบที่ต้องการ.

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

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

ยกระดับการบริการลูกค้าของคุณได้ตั้งแต่วันนี้

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

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

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