เทมเพลตข้อมูลสำหรับงานบริการลูกค้าของคุณ
เทมเพลตข้อมูลสำหรับงานบริการลูกค้าของคุณ
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางการดึงข้อมูล
แอตทริบิวต์งานบริการลูกค้า
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
Activity
|
ชื่อเหตุการณ์หรือขั้นตอนทางธุรกิจที่เกิดขึ้นในกระบวนการบริการลูกค้า. | ||
|
คำอธิบาย
แอตทริบิวต์กิจกรรมหมายถึงการดำเนินการหรือการเปลี่ยนสถานะแต่ละรายการในวงจรของคำขอรับบริการ โดยบันทึกเหตุการณ์ทางธุรกิจที่สำคัญ เช่น 'สร้างทิกเก็ต', 'มอบหมายทิกเก็ต', 'ส่งคำตอบครั้งแรก' และ 'แก้ไขทิกเก็ตแล้ว' กิจกรรมเหล่านี้เป็นโหนดในแผนผังกระบวนการ การวิเคราะห์ลำดับและความถี่ของกิจกรรมเป็นหัวใจของ process mining ซึ่งช่วยให้เห็นภาพการไหลของกระบวนการ ระบุเส้นทางที่เกิดขึ้นบ่อยและไม่บ่อย และตรวจจับความเบี่ยงเบนจากขั้นตอนการปฏิบัติงานมาตรฐาน การทำความเข้าใจกิจกรรมช่วยให้ระบุจุดที่ไม่มีประสิทธิภาพ การทำงานซ้ำเป็นวง เช่น 'เปิดทิกเก็ตอีกครั้ง' หรือปัญหาด้านการปฏิบัติตามข้อกำหนดได้
เหตุผลที่สำคัญ
คุณสมบัตินี้กำหนดขั้นตอนในแผนผังกระบวนการ เพื่อแสดงและวิเคราะห์ลำดับงานตั้งแต่ต้นจนจบ.
แหล่งข้อมูล
ได้จากประเภทเหตุการณ์ใน Freshdesk ซึ่งอาจรวมการเปลี่ยนสถานะจาก API endpoint 'Tickets' และเหตุการณ์เฉพาะ เช่น การเพิ่มบันทึกหรือการตอบกลับจาก endpoint 'Conversations'.
ตัวอย่าง
สร้าง Ticketส่งการตอบกลับครั้งแรกเปลี่ยนสถานะเป็น Pendingแก้ไข Ticket แล้วปิด Ticket
|
|||
|
คำขอรับบริการ
ServiceRequest
|
รหัสเฉพาะของคำถามหรือปัญหาจากลูกค้าแต่ละรายการ ซึ่งมักเรียกว่า Ticket หรือเคส. | ||
|
คำอธิบาย
คำขอรับบริการเป็นรหัสเคสหลักที่เชื่อมโยงกิจกรรมทั้งหมดของการติดต่อกับลูกค้าหนึ่งครั้ง คำถาม ปัญหา หรือคำขอใหม่จากลูกค้าแต่ละรายการจะมี ID คำขอรับบริการที่ไม่ซ้ำกัน ID นี้จะคงเดิมตลอดวงจรของ Ticket ตั้งแต่การสร้างและมอบหมาย ไปจนถึงการแก้ไขและปิดเคส. ใน process mining คุณสมบัตินี้เป็นพื้นฐานสำคัญสำหรับสร้างเส้นทางของเคสลูกค้าแต่ละรายการตั้งแต่ต้นจนจบ เมื่อนำเหตุการณ์ที่เกี่ยวข้องทั้งหมดมาจัดกลุ่มตาม ID คำขอรับบริการ นักวิเคราะห์จะเห็นขั้นตอนของกระบวนการ วัดระยะเวลาดำเนินการ และระบุความแตกต่างหรือคอขวดที่ส่งผลต่อแต่ละเคสได้.
เหตุผลที่สำคัญ
นี่คือ Case ID สำคัญที่เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการเดียว ทำให้เห็นเส้นทางการรับบริการของลูกค้าแต่ละรายได้ครบถ้วน.
แหล่งข้อมูล
นี่คือ ID หลักของ Ticket ใน Freshdesk โดยทั่วไปจะอยู่ในช่อง 'id' ของ API endpoint 'Tickets'.
ตัวอย่าง
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
|
|||
|
เวลาเกิดเหตุการณ์
EventTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เกิดขึ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาเกิดเหตุการณ์หรือ Timestamp บันทึกวันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ ข้อมูลนี้สำคัญต่อการเรียงเหตุการณ์ตามลำดับเวลาและคำนวณระยะเวลาระหว่างขั้นตอนต่างๆ ในกระบวนการ กิจกรรมที่บันทึกไว้ทุกรายการต้องมี Timestamp กำกับ. ในการวิเคราะห์ คุณสมบัตินี้ใช้สร้างลำดับเวลาของคำขอรับบริการแต่ละรายการ และเป็นพื้นฐานสำหรับคำนวณ KPI ที่เกี่ยวข้องกับเวลา เช่น เวลาแก้ไขปัญหา เวลาตอบกลับครั้งแรก และระยะเวลาที่ติดอยู่ในคอขวด Timestamp ที่ถูกต้องช่วยให้เข้าใจประสิทธิภาพของกระบวนการและระบุความล่าช้าได้.
เหตุผลที่สำคัญ
Timestamp นี้จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลาและคำนวณตัวชี้วัดด้านระยะเวลาทั้งหมด เช่น ระยะเวลาตั้งแต่ต้นจนจบและการปฏิบัติตาม SLA.
แหล่งข้อมูล
ตรงกับช่อง 'created_at' หรือ 'updated_at' ที่เกี่ยวข้องกับเหตุการณ์ การตอบกลับ หรือการเปลี่ยนสถานะของ Ticket ใน Freshdesk API.
ตัวอย่าง
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
|
|||
|
เจ้าหน้าที่ที่ได้รับมอบหมาย
AssignedAgent
|
ชื่อหรือ ID ของเจ้าหน้าที่บริการลูกค้าที่รับผิดชอบ Ticket ในเวลาที่เกิดเหตุการณ์. | ||
|
คำอธิบาย
คุณสมบัตินี้ระบุเจ้าหน้าที่ที่ได้รับมอบหมายให้ดูแลคำขอรับบริการโดยเฉพาะ เจ้าหน้าที่ผู้รับผิดชอบอาจเปลี่ยนระหว่างวงจรของ Ticket เมื่อมีการมอบหมายใหม่หรือยกระดับปัญหา. การวิเคราะห์ข้อมูลตามเจ้าหน้าที่ที่ได้รับมอบหมายมีความสำคัญต่อแดชบอร์ดติดตามผลงาน ช่วยวัด KPI รายบุคคล เช่น เวลาแก้ไขปัญหาโดยเฉลี่ย ปริมาณ Ticket และอัตราการเปิดซ้ำ ทำให้ระบุเจ้าหน้าที่ที่ทำผลงานได้ดี ความต้องการฝึกอบรม และผลกระทบของการโอนงานต่อเวลาแก้ไขปัญหาโดยรวมได้.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลงานของเจ้าหน้าที่แต่ละคน ระบุผู้ที่ทำผลงานได้ดี โอกาสในการฝึกอบรม และผลกระทบจากการมอบหมายงานใหม่.
แหล่งข้อมูล
ตรงกับช่อง 'responder_id' ในออบเจ็กต์ 'Tickets' ของ Freshdesk ซึ่งสามารถนำไปเชื่อมกับรายละเอียดของเจ้าหน้าที่ได้.
ตัวอย่าง
Alice JohnsonRobert SmithMaria Garcia
|
|||
|
ประเภทคำขอรับบริการ
ServiceRequestType
|
การจัดประเภทคำขอรับบริการ เช่น 'คำถาม' 'เหตุขัดข้อง' 'ปัญหา' หรือ 'คำขอฟีเจอร์'. | ||
|
คำอธิบาย
ประเภทคำขอรับบริการเป็นช่องจัดหมวดหมู่สำคัญที่ระบุลักษณะของคำถามจากลูกค้า โดยทั่วไปจะกำหนดประเภทเมื่อสร้าง Ticket หรือระหว่างคัดแยกเบื้องต้น เพื่อส่งคำขอไปยังทีม หรือเจ้าหน้าที่ที่เหมาะสม. ในการวิเคราะห์ คุณสมบัตินี้ช่วยแบ่งกระบวนการเพื่อดูว่ามีการจัดการคำขอแต่ละประเภทอย่างไร เช่น เหตุขัดข้องใช้เวลาแก้ไขนานกว่าคำถามหรือไม่ และคำขอประเภทใดถูกเปิดซ้ำบ่อยที่สุด การแบ่งกลุ่มเช่นนี้ช่วยระบุคอขวดเฉพาะประเภทและปรับเวิร์กโฟลว์ให้เหมาะสม.
เหตุผลที่สำคัญ
ช่วยแบ่งกระบวนการเพื่อเปรียบเทียบผลงานและเวิร์กโฟลว์ของปัญหาลูกค้าประเภทต่างๆ เช่น เหตุขัดข้องกับคำถาม.
แหล่งข้อมูล
น่าจะตรงกับช่อง 'type' ในออบเจ็กต์ 'Tickets' ของ Freshdesk.
ตัวอย่าง
คำถามเหตุขัดข้องปัญหาคำขอฟีเจอร์
|
|||
|
ระดับความสำคัญ
Priority
|
ระดับความสำคัญที่กำหนดให้กับคำขอรับบริการ เช่น 'ต่ำ', 'ปานกลาง', 'สูง' หรือ 'เร่งด่วน'. | ||
|
คำอธิบาย
แอตทริบิวต์ระดับความสำคัญแสดงความเร่งด่วนของคำขอรับบริการ และมักใช้กำหนดเวลาเป้าหมายในการตอบกลับและแก้ไขปัญหา ระบบอาจกำหนดระดับความสำคัญโดยอัตโนมัติตามกฎ หรือเจ้าหน้าที่อาจกำหนดเองระหว่างคัดแยกคำขอ แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์การปฏิบัติตาม SLA และการจัดสรรทรัพยากรอย่างเหมาะสม นักวิเคราะห์สามารถกรองแผนผังกระบวนการตามระดับความสำคัญ เพื่อดูว่าทิกเก็ตที่มีความสำคัญสูงได้รับการจัดการเร็วกว่าทิกเก็ตที่มีความสำคัญต่ำจริงหรือไม่ นอกจากนี้ยังช่วยตรวจสอบว่ามีการเปลี่ยนระดับความสำคัญ ซึ่งถือเป็นการทำงานซ้ำ บ่อยเพียงใด และส่งผลต่อกระบวนการอย่างไร.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์ SLA และตรวจสอบว่ามีการจัดสรรทรัพยากรอย่างเหมาะสมหรือไม่ เพื่อให้จัดการปัญหาที่มีความสำคัญสูงได้เร็วกว่าปัญหาที่มีความสำคัญต่ำ.
แหล่งข้อมูล
ตรงกับฟิลด์ 'priority' ในออบเจ็กต์ 'Tickets' ของ Freshdesk.
ตัวอย่าง
ต่ำปานกลางสูงเร่งด่วน
|
|||
|
สถานะ
Status
|
สถานะปัจจุบันหรือสถานะย้อนหลังของคำขอรับบริการ เช่น 'เปิด', 'รอดำเนินการ', 'แก้ไขแล้ว' หรือ 'ปิดแล้ว'. | ||
|
คำอธิบาย
แอตทริบิวต์สถานะระบุสถานะของคำขอรับบริการ ณ ช่วงเวลาหนึ่ง การเปลี่ยนสถานะมักบ่งบอกถึงขั้นตอนสำคัญในกระบวนการ เช่น เปลี่ยนจาก 'เปิด' เป็น 'รอดำเนินการ' ระหว่างรอข้อมูลจากลูกค้า หรือเปลี่ยนจาก 'รอดำเนินการ' เป็น 'เปิด' เมื่อลูกค้าตอบกลับ การติดตามการเปลี่ยนสถานะเป็นสิ่งสำคัญต่อการทำความเข้าใจวงจรการทำงานของทิกเก็ต และช่วยดูได้ว่าทิกเก็ตใช้เวลาอยู่ในแต่ละสถานะนานเท่าใด ซึ่งเป็นประโยชน์ต่อการระบุคอขวด ตัวอย่างเช่น หากทิกเก็ตอยู่ในสถานะ 'รอดำเนินการ' เป็นเวลานาน อาจหมายถึงความล่าช้าในการรับข้อมูลจากลูกค้า.
เหตุผลที่สำคัญ
การติดตามการเปลี่ยนสถานะช่วยให้เข้าใจวงจรการทำงานของทิกเก็ต และดูได้ว่าเคสใช้เวลาอยู่ในสถานะอย่าง 'รอดำเนินการ' หรือ 'พักไว้' นานเท่าใด.
แหล่งข้อมูล
ตรงกับฟิลด์ 'status' ในออบเจ็กต์ 'Tickets' ของ Freshdesk ส่วนสถานะในอดีตต้องอนุมานจากบันทึกกิจกรรม.
ตัวอย่าง
เปิดรอดำเนินการแก้ไขแล้วปิดแล้ว
|
|||
|
กลุ่มที่รับผิดชอบ
AssignedGroup
|
ทีมหรือแผนกที่ได้รับมอบหมายให้ดูแลคำขอรับบริการ. | ||
|
คำอธิบาย
กลุ่มที่รับผิดชอบหมายถึงทีมเจ้าหน้าที่ที่ดูแลคำขอรับบริการนั้นๆ โดยมักส่งทิกเก็ตไปยังกลุ่มเฉพาะตามประเภทหรือความซับซ้อน เช่น 'ฝ่ายสนับสนุนด้านเทคนิค' หรือ 'แผนกเรียกเก็บเงิน' แอตทริบิวต์นี้มีประโยชน์ต่อการวิเคราะห์การส่งต่องานระหว่างแผนกและผลการดำเนินงานของแต่ละทีม ช่วยระบุกลุ่มที่รับทิกเก็ตมากที่สุด กลุ่มที่ใช้เวลาแก้ไขนานที่สุด และความถี่ในการโอนทิกเก็ตระหว่างกลุ่ม ข้อมูลนี้ช่วยปรับโครงสร้างทีมและเวิร์กโฟลว์ให้เหมาะสม.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ผลการดำเนินงานในระดับทีมหรือแผนก โดยแสดงการส่งต่องานและช่วยระบุคอขวดของแต่ละกลุ่ม.
แหล่งข้อมูล
ตรงกับฟิลด์ 'group_id' ในออบเจ็กต์ 'Tickets' ของ Freshdesk.
ตัวอย่าง
ฝ่ายสนับสนุนระดับ 1ฝ่ายสนับสนุนด้านเทคนิคระดับ 2ฝ่ายเรียกเก็บเงินฝ่ายดูแลความสำเร็จของลูกค้า
|
|||
|
เกินกำหนด SLA หรือไม่
IsSlaBreached
|
ค่าบูลีนที่ระบุว่าเวลาแก้ไขคำขอรับบริการเกินเป้าหมาย SLA หรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ที่คำนวณนี้แสดงผลการปฏิบัติตาม SLA ของคำขอรับบริการแต่ละรายการอย่างชัดเจน โดยเปรียบเทียบ 'ResolutionTime' จริงกับ 'SlaTargetResolutionTime' หากเวลาจริงมากกว่าเวลาเป้าหมาย ค่าจะเป็น true แอตทริบิวต์นี้ช่วยให้วิเคราะห์และแสดงผลการปฏิบัติตาม SLA บนแดชบอร์ดได้ง่ายขึ้น คุณสามารถนับและกรองทิกเก็ตที่เกินกำหนดได้อย่างสะดวก ทำให้นักวิเคราะห์เห็นขนาดของปัญหาการไม่ปฏิบัติตาม SLA และเจาะลึกลงหนึ่งระดับเพื่อค้นหารูปแบบกระบวนการและสาเหตุของทิกเก็ตที่เกินกำหนด อีกทั้งยังใช้กับแดชบอร์ดและ KPI ภาพรวมการปฏิบัติตาม SLA ได้โดยตรง.
เหตุผลที่สำคัญ
ช่วยให้วิเคราะห์การปฏิบัติตาม SLA ได้ง่ายขึ้น ด้วยการระบุเคสที่ไม่เป็นไปตามเป้าหมายอย่างชัดเจน และช่วยวิเคราะห์หาสาเหตุที่ทำให้เกินกำหนด.
แหล่งข้อมูล
ฟิลด์ที่คำนวณจากการเปรียบเทียบเวลาที่แก้ไขจริงกับเวลาที่ระบุใน 'SlaTargetResolutionTime' หรือฟิลด์ 'due_by' จาก Freshdesk.
ตัวอย่าง
truefalse
|
|||
|
คะแนนความพึงพอใจ
SatisfactionRating
|
คะแนนความพึงพอใจที่ลูกค้าให้หลังจากแก้ไขทิกเก็ตแล้ว. | ||
|
คำอธิบาย
คะแนนความพึงพอใจเป็นตัวชี้วัดผลลัพธ์สำคัญ โดยทั่วไปเก็บผ่านแบบสำรวจที่ส่งหลังจากแก้ไขทิกเก็ตแล้ว คะแนนมักเป็นตัวเลขหรือระดับ เช่น 'พึงพอใจ', 'เฉยๆ' หรือ 'ไม่พึงพอใจ' แอตทริบิวต์นี้ช่วยเชื่อมโยงรูปแบบของกระบวนการกับผลลัพธ์ที่ลูกค้าได้รับ เมื่อวิเคราะห์รูปแบบกระบวนการที่ทำให้คะแนนความพึงพอใจต่ำ องค์กรจะระบุพฤติกรรมหรือความล่าช้าที่ส่งผลเสียต่อประสบการณ์ของลูกค้าได้ ทำให้เห็นความเชื่อมโยงโดยตรงระหว่างประสิทธิภาพของกระบวนการกับความพึงพอใจของลูกค้า.
เหตุผลที่สำคัญ
เชื่อมโยงการดำเนินกระบวนการกับผลลัพธ์ของลูกค้า ช่วยระบุว่าพฤติกรรมในกระบวนการแบบใดทำให้ลูกค้าพึงพอใจมากหรือน้อย.
แหล่งข้อมูล
ข้อมูลนี้เป็นส่วนหนึ่งของฟีเจอร์คะแนนความพึงพอใจใน Freshdesk และเรียกดูได้ผ่าน API endpoint 'Surveys' หรือ 'Satisfaction Ratings'.
ตัวอย่าง
5314
|
|||
|
จำนวนครั้งที่โอนงานระหว่างเจ้าหน้าที่
AgentTransferCount
|
จำนวนครั้งทั้งหมดที่มีการมอบหมายคำขอรับบริการจากเจ้าหน้าที่คนหนึ่งไปยังอีกคนหนึ่ง. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เป็นตัวชี้วัดระดับเคสที่นับจำนวนครั้งที่เจ้าหน้าที่ผู้รับผิดชอบทิกเก็ตเปลี่ยนไป โดยนับจำนวนกิจกรรม 'Ticket Reassigned' ของคำขอรับบริการแต่ละรายการ การโอนงานบ่อยครั้ง หรือที่เรียกว่าการส่งงานวนไปมา อาจทำให้เกิดความล่าช้าและสร้างประสบการณ์ที่ไม่ดีให้ลูกค้า เพราะข้อมูลบริบทอาจสูญหายทุกครั้งที่ส่งต่องาน การวิเคราะห์จำนวนครั้งที่โอนงานช่วยระบุปัญหาในการมอบหมายงานครั้งแรก ช่องว่างด้านทักษะของเจ้าหน้าที่ หรือความซับซ้อนของกระบวนการ โดยทั่วไปเป้าหมายคือการลดการโอนงานที่ไม่จำเป็น เพื่อเพิ่มประสิทธิภาพและความพึงพอใจของลูกค้า.
เหตุผลที่สำคัญ
ใช้วัดความถี่ในการส่งต่องานภายใน ซึ่งอาจเป็นสาเหตุสำคัญของความล่าช้าและความไม่พอใจของลูกค้า และช่วยปรับปรุงการแก้ไขปัญหาในระดับแรก.
แหล่งข้อมูล
ฟิลด์ที่คำนวณจากจำนวนกิจกรรม 'Ticket Reassigned' ของคำขอรับบริการแต่ละรายการ.
ตัวอย่าง
0132
|
|||
|
ช่องทางการติดต่อ
CommunicationChannel
|
ช่องทางที่ใช้ส่งคำขอรับบริการ เช่น 'อีเมล', 'โทรศัพท์', 'แชต' หรือ 'พอร์ทัลเว็บ'. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุที่มาหรือช่องทางที่ลูกค้าใช้ติดต่อ แต่ละช่องทางอาจมีกระบวนการและระยะเวลาแก้ไขปัญหาต่างกัน เช่น คำขอที่ส่งผ่านแชตอาจมีเวลาแก้ไขเป้าหมายสั้นกว่าคำขอที่ส่งทางอีเมล การวิเคราะห์กระบวนการแยกตามช่องทางช่วยปรับการจัดสรรทรัพยากรและทำความเข้าใจประสิทธิภาพของแต่ละช่องทาง อีกทั้งยังช่วยให้เห็นว่าช่องทางใดสัมพันธ์กับการแก้ไขปัญหาที่รวดเร็วหรือความพึงพอใจของลูกค้าที่สูงกว่า เพื่อนำข้อมูลไปประกอบการตัดสินใจว่าจะส่งเสริมหรือลงทุนในช่องทางใด.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประสิทธิภาพและผลการดำเนินงานของกระบวนการในช่องทางติดต่อลูกค้าต่างๆ เช่น อีเมล โทรศัพท์ หรือแชต.
แหล่งข้อมูล
ตรงกับฟิลด์ 'source' ในออบเจ็กต์ 'Tickets' ของ Freshdesk.
ตัวอย่าง
อีเมลโทรศัพท์พอร์ทัลเว็บแชต
|
|||
|
ชื่อลูกค้า
CustomerName
|
ชื่อหรือ ID ของลูกค้าที่ส่งคำขอรับบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุลูกค้าที่เกี่ยวข้องกับคำขอรับบริการ และช่วยให้วิเคราะห์กระบวนการจากมุมมองของลูกค้า โดยติดตามการติดต่อทั้งหมดของลูกค้ารายหนึ่งในช่วงเวลาต่างๆ การวิเคราะห์แยกตามลูกค้าช่วยให้เห็นรูปแบบต่างๆ เช่น ลูกค้ารายใดส่งทิกเก็ตมากที่สุด หรือลูกค้ารายใดมีปัญหาที่ต้องเปิดทิกเก็ตซ้ำบ่อยที่สุด ข้อมูลนี้ช่วยวางแผนการดูแลความสำเร็จของลูกค้า และระบุลูกค้าที่อาจเลิกใช้บริการเพราะได้รับประสบการณ์ที่ไม่ดี นอกจากนี้ยังจำเป็นต่อการทำความเข้าใจเส้นทางของลูกค้าตั้งแต่ต้นจนจบผ่านคำขอรับบริการหลายรายการ.
เหตุผลที่สำคัญ
ช่วยให้เห็นกระบวนการจากมุมมองของลูกค้า และระบุลูกค้าที่ส่งคำขอบ่อยหรือพบปัญหาเดิมซ้ำๆ.
แหล่งข้อมูล
ข้อมูลนี้เชื่อมโยงผ่าน 'requester_id' ในออบเจ็กต์ 'Tickets' ซึ่งเชื่อมกับออบเจ็กต์ 'Contacts' หรือ 'Users' ใน Freshdesk.
ตัวอย่าง
จอห์น โดเจน สมิธบริษัท โกลบอลเทค จำกัด.
|
|||
|
ถูกเปิดอีกครั้งหรือไม่
IsReopened
|
ค่าบูลีนที่ระบุว่ามีการเปิดคำขอรับบริการที่แก้ไขแล้วขึ้นมาอีกครั้งหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ระดับเคสนี้จะเป็น true หากมีเหตุการณ์ 'Ticket Reopened' เกิดขึ้นในช่วงใดช่วงหนึ่งของวงจรการทำงานของคำขอรับบริการ ช่วยให้ระบุและวิเคราะห์เคสที่ต้องกลับมาทำงานซ้ำได้ง่าย หากมีการเปิดทิกเก็ตซ้ำในอัตราสูง อาจแสดงว่าการแก้ไขครั้งแรกยังไม่ครบถ้วนหรือไม่ได้ผล ทำให้เกิดความล่าช้าและลูกค้าไม่พอใจ เมื่อนักวิเคราะห์กรองเฉพาะทิกเก็ตที่เปิดซ้ำ ก็จะตรวจสอบสาเหตุได้ เช่น เหตุผลที่เปิดซ้ำบ่อย เจ้าหน้าที่หรือทีมที่มีอัตราสูง และประเภททิกเก็ตที่มีแนวโน้มถูกเปิดซ้ำมากที่สุด.
เหตุผลที่สำคัญ
ช่วยระบุเคสที่ต้องกลับมาทำงานซ้ำ ซึ่งเป็นตัวชี้วัดสำคัญของคุณภาพการแก้ไขและประสิทธิภาพของกระบวนการ การวิเคราะห์เคสเหล่านี้ช่วยเพิ่มอัตราการแก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรก.
แหล่งข้อมูล
ฟิลด์ที่คำนวณขึ้น กำหนดค่าเป็น true สำหรับคำขอบริการ หากมีเหตุการณ์ที่ Activity = 'Ticket Reopened' ในเคสนั้น
ตัวอย่าง
truefalse
|
|||
|
ผลิตภัณฑ์
Product
|
ผลิตภัณฑ์หรือบริการที่เกี่ยวข้องกับคำขอของลูกค้า. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุสายผลิตภัณฑ์หรือบริการที่เกี่ยวข้องกับคำขอรับบริการ โดยทั่วไปจะเป็นฟิลด์ที่กำหนดเองใน Freshdesk เพื่อจัดหมวดหมู่ทิกเก็ตสำหรับการส่งต่อและการรายงาน เมื่อกรองกระบวนการตามผลิตภัณฑ์ องค์กรจะเห็นปัญหาที่เกิดขึ้นกับผลิตภัณฑ์แต่ละรายการได้ เช่น ผลิตภัณฑ์บางรายการทำให้เกิดทิกเก็ตขอรับการสนับสนุนมากผิดปกติ หรือการเปิดตัวผลิตภัณฑ์ใหม่ทำให้มีคำถามเพิ่มขึ้น ข้อมูลนี้ช่วยให้ทีมพัฒนาและบริหารผลิตภัณฑ์นำไปปรับปรุงได้.
เหตุผลที่สำคัญ
ช่วยกรองกระบวนการตามกลุ่มผลิตภัณฑ์ เพื่อดูว่าผลิตภัณฑ์ใดทำให้เกิดคำขอรับการสนับสนุนมากที่สุด หรือใช้เวลาแก้ไขนานที่สุด.
แหล่งข้อมูล
โดยทั่วไปจะเป็นฟิลด์ที่กำหนดเอง ตำแหน่งที่แน่นอนขึ้นอยู่กับการตั้งค่า Freshdesk และมักอยู่ในส่วน 'custom_fields' ของการตอบกลับจาก API 'Tickets'.
ตัวอย่าง
แพลตฟอร์มอัลฟาแอปมือถือเบตาบริการสมาชิกแกมมา
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ดึงข้อมูลมา ในกรณีนี้คือ 'Freshdesk'. | ||
|
คำอธิบาย
คุณสมบัตินี้ระบุแอปพลิเคชันต้นทางของข้อมูลกระบวนการ สำหรับการวิเคราะห์นี้ ค่าจะเป็นค่าคงที่ เช่น 'Freshdesk' ซึ่งแสดงว่าเหตุการณ์ทั้งหมดมาจากแพลตฟอร์มบริการลูกค้า Freshdesk. แม้จะดูเป็นข้อมูลพื้นฐาน แต่คุณสมบัตินี้สำคัญต่อการกำกับดูแลข้อมูลและการรวมข้อมูลจากหลายระบบต้นทาง ช่วยระบุที่มาและบริบทได้ชัดเจน ทำให้นักวิเคราะห์ทราบว่าข้อมูลที่กำลังตรวจสอบมาจากไหน ซึ่งจำเป็นต่อการรักษาความถูกต้องของข้อมูลและสร้างความเชื่อมั่นในการวิเคราะห์.
เหตุผลที่สำคัญ
ให้บริบทสำคัญเกี่ยวกับที่มาของข้อมูล ซึ่งจำเป็นต่อการกำกับดูแลข้อมูลและการรวมข้อมูลจากหลายระบบต้นทาง.
แหล่งข้อมูล
เป็นค่าคงที่ 'Freshdesk' ที่เพิ่มระหว่างการแปลงข้อมูลเพื่อระบุแหล่งที่มา.
ตัวอย่าง
Freshdesk
|
|||
|
เวลาตอบกลับครั้งแรก
FirstResponseTime
|
เวลาตั้งแต่สร้างทิกเก็ตจนถึงเจ้าหน้าที่ตอบกลับลูกค้าครั้งแรก. | ||
|
คำอธิบาย
เวลาตอบกลับครั้งแรกใช้วัดว่าลูกค้าได้รับคำตอบเบื้องต้นจากเจ้าหน้าที่บริการเร็วเพียงใด โดยคำนวณจากเวลาของกิจกรรม 'First Response Sent' ลบด้วยเวลาของกิจกรรม 'Ticket Created' KPI นี้เป็นตัวชี้วัดสำคัญของความรวดเร็วในการให้บริการ และส่งผลต่อความพึงพอใจของลูกค้าอย่างมาก การตอบกลับครั้งแรกที่รวดเร็วช่วยให้ลูกค้ามั่นใจว่ามีผู้รับทราบปัญหาและกำลังดำเนินการ การวิเคราะห์ตัวชี้วัดนี้ช่วยให้องค์กรตรวจสอบได้ว่าทำตาม SLA สำหรับการตอบกลับครั้งแรกและให้บริการลูกค้าได้ทันท่วงทีหรือไม่.
เหตุผลที่สำคัญ
ใช้วัดความรวดเร็วในการให้บริการ ซึ่งเป็นปัจจัยสำคัญต่อความพึงพอใจของลูกค้า และช่วยติดตามเป้าหมายการให้บริการเชิงรุกโดยตรง.
แหล่งข้อมูล
ฟิลด์ที่คำนวณจากระยะเวลาระหว่างเวลาของเหตุการณ์ 'Ticket Created' กับเหตุการณ์ 'First Response Sent'.
ตัวอย่าง
3000009000001800000
|
|||
|
เวลาเป้าหมายในการแก้ไขตาม SLA
SlaTargetResolutionTime
|
ระยะเวลาที่ตกลงไว้ในสัญญาหรือกำหนดเป็นเป้าหมายสำหรับการแก้ไขคำขอรับบริการ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้กำหนดระยะเวลาเป้าหมายที่ควรใช้แก้ไขคำขอรับบริการตามข้อตกลงระดับการให้บริการ (SLA) โดยเป้าหมายมักขึ้นอยู่กับระดับความสำคัญหรือประเภทของทิกเก็ต ข้อมูลนี้เป็นส่วนสำคัญในการคำนวณการปฏิบัติตาม SLA เมื่อนำเวลาแก้ไขจริงมาเปรียบเทียบกับเป้าหมาย จะระบุได้ว่าทำได้ตามกำหนดหรือเกินกำหนด การวิเคราะห์ผลการดำเนินงานตาม SLA แยกตามประเภทคำขอ ทีม หรือเจ้าหน้าที่ เป็นส่วนสำคัญของการบริหารงานบริการ.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์พื้นฐานในการวัดการปฏิบัติตาม SLA ซึ่งเป็นตัวชี้วัดผลการดำเนินงานสำคัญขององค์กรบริการลูกค้า.
แหล่งข้อมูล
ข้อมูลนี้อาจอยู่ในฟิลด์อย่าง 'fr_due_by' สำหรับการตอบกลับครั้งแรก หรือ 'due_by' สำหรับการแก้ไข ในออบเจ็กต์ 'Tickets' ของ Freshdesk หรืออาจต้องคำนวณจากกฎนโยบาย SLA.
ตัวอย่าง
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่ามีการรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
คุณสมบัตินี้บันทึกวันที่และเวลาที่ดึงหรืออัปเดตชุดข้อมูลจาก Freshdesk ครั้งล่าสุด ช่วยให้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด ซึ่งสำคัญต่อการตัดสินใจทางธุรกิจได้ทันเวลาและเหมาะสม. นักวิเคราะห์ใช้ข้อมูลนี้เพื่อดูว่าชุดข้อมูลครอบคลุมช่วงเวลาใด และยืนยันว่ากำลังใช้ข้อมูลล่าสุดที่มีอยู่ ข้อมูลกำกับนี้สำคัญสำหรับแดชบอร์ดหรือรายงาน process mining เพื่อให้ผู้เกี่ยวข้องทราบว่าข้อมูลเป็นปัจจุบันแค่ไหน.
เหตุผลที่สำคัญ
แสดงว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้การวิเคราะห์และการตัดสินใจอ้างอิงข้อมูลล่าสุด.
แหล่งข้อมูล
ช่องข้อมูลกำกับที่สร้างขึ้นระหว่างการดึงข้อมูล โดยบันทึกเวลาที่ดึงข้อมูล.
ตัวอย่าง
2023-12-01T08:00:00Z
|
|||
กิจกรรมในงานบริการลูกค้า
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไข Ticket แล้ว
|
หมายถึงจุดสำคัญที่เจ้าหน้าที่ให้วิธีแก้ปัญหาแล้วเปลี่ยนสถานะ Ticket เป็น 'Resolved' ระบบบันทึกการเปลี่ยนสถานะนี้ไว้อย่างชัดเจนในประวัติ Ticket. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของการทำงานกับ Ticket และใช้เป็นพื้นฐานในการวัดเวลาแก้ไขปัญหา จึงเป็นเหตุการณ์สำคัญสำหรับวิเคราะห์ผลงานของเจ้าหน้าที่และประสิทธิภาพโดยรวมของกระบวนการ.
แหล่งข้อมูล
ดึงข้อมูลจากบันทึก 'Ticket Activities' ซึ่งบันทึกการเปลี่ยนสถานะเป็น 'Resolved' โดยเฉพาะ พร้อมเวลาเกิดเหตุการณ์
บันทึก
บันทึกเหตุการณ์เมื่ออัปเดตช่อง 'Status' ของ Ticket เป็น 'Resolved'.
ประเภทเหตุการณ์
explicit
|
|||
|
ปิด Ticket
|
นี่คือกิจกรรมสุดท้าย ซึ่งหมายถึงการปิด Ticket อย่างถาวร โดยทั่วไประบบจะดำเนินการโดยอัตโนมัติเมื่อ Ticket อยู่ในสถานะ 'Resolved' ครบระยะเวลาที่กำหนดและไม่มีลูกค้าตอบกลับเพิ่มเติม. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของวงจรคำขอรับบริการอย่างสมบูรณ์ และใช้เป็นจุดสิ้นสุดสำหรับคำนวณเวลาตั้งแต่ต้นจนจบได้อย่างแม่นยำ.
แหล่งข้อมูล
ดึงข้อมูลจากบันทึก 'Ticket Activities' ซึ่งบันทึกการเปลี่ยนสถานะครั้งสุดท้ายเป็น 'Closed' โดยมักเกิดจากระบบอัตโนมัติ
บันทึก
บันทึกเหตุการณ์เมื่ออัปเดตช่อง 'Status' ของ Ticket เป็น 'Closed'.
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมาย Ticket
|
หมายถึงการมอบหมาย Ticket ให้เจ้าหน้าที่หรือกลุ่มที่รับผิดชอบ ระบบจะบันทึกเหตุการณ์นี้ไว้ในประวัติ Ticket เมื่อมีการกรอกหรือเปลี่ยนช่องเจ้าหน้าที่หรือกลุ่มที่ได้รับมอบหมาย. | ||
|
เหตุผลที่สำคัญ
การติดตามการมอบหมายงานช่วยวิเคราะห์ภาระงานของเจ้าหน้าที่ ระบุจุดที่การจัดเส้นทางงานไม่มีประสิทธิภาพ และวัด KPI ระยะเวลาตั้งแต่สร้าง Ticket จนถึงมอบหมาย ช่วยให้เข้าใจการกระจายงานและเห็นจุดที่เกิดความล่าช้าก่อนเริ่มดำเนินการ.
แหล่งข้อมูล
ดึงข้อมูลจากบันทึก 'Ticket Activities' ซึ่งบันทึกการเปลี่ยนแปลงฟิลด์ 'Agent' หรือ 'Group' พร้อมเวลาเกิดเหตุการณ์
บันทึก
บันทึกเหตุการณ์เมื่อมีการอัปเดตช่อง 'Assigned to' ของเจ้าหน้าที่หรือกลุ่ม.
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งการตอบกลับครั้งแรก
|
หมายถึงการตอบกลับสาธารณะครั้งแรกที่เจ้าหน้าที่ส่งให้ลูกค้าหลังสร้าง Ticket Freshdesk บันทึกเหตุการณ์นี้โดยตรงเพื่อวัด 'First Response Time' สำหรับติดตาม SLA. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์นี้เป็นจุดสำคัญในการวัดความรวดเร็วในการตอบสนองลูกค้าและการปฏิบัติตาม SLA การวิเคราะห์เวลาจนถึงกิจกรรมนี้ช่วยระบุความล่าช้าในการเริ่มติดต่อกับลูกค้า.
แหล่งข้อมูล
Freshdesk ติดตามเหตุการณ์นี้โดยเฉพาะเพื่อใช้กับ SLA โดยอ้างอิงเวลาที่เจ้าหน้าที่เพิ่มความคิดเห็นสาธารณะเป็นครั้งแรก.
บันทึก
ระบุจากการตอบกลับสาธารณะครั้งแรกของเจ้าหน้าที่ในประวัติการสนทนาของ Ticket.
ประเภทเหตุการณ์
explicit
|
|||
|
สร้าง Ticket
|
นี่คือเหตุการณ์แรกในวงจรบริการลูกค้า ซึ่งเกิดขึ้นเมื่อลูกค้าส่งคำขอและมีการบันทึกลงใน Freshdesk อย่างเป็นทางการ ระบบบันทึกกิจกรรมนี้โดยตรงเมื่อสร้าง Ticket ใหม่ ไม่ว่าจะมาจากอีเมล พอร์ทัล โทรศัพท์ หรือการเชื่อมต่อ API. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดเริ่มต้นของทุกเคส จึงจำเป็นต่อการคำนวณเวลาแก้ไขปัญหาโดยรวม และวิเคราะห์แนวโน้มปริมาณ Ticket ตามช่องทางหรือประเภท.
แหล่งข้อมูล
เหตุการณ์นี้เป็นเหตุการณ์ที่ระบุไว้อย่างชัดเจนในบันทึก 'Ticket Activities' ของ Freshdesk ระบบจะสร้างเหตุการณ์นี้โดยอัตโนมัติเมื่อมีการสร้างระเบียนทิกเก็ตใหม่
บันทึก
บันทึกลงในลำดับกิจกรรมของ Ticket โดยตรงเมื่อสร้างรายการ.
ประเภทเหตุการณ์
explicit
|
|||
|
เปลี่ยนระดับความสำคัญของ Ticket
|
เหตุการณ์นี้เกิดขึ้นเมื่อเจ้าหน้าที่หรือกฎอัตโนมัติเปลี่ยนระดับความสำคัญของ Ticket เช่น จาก 'Low' เป็น 'High' โดยระบบบันทึกการเปลี่ยนแปลงนี้ไว้ในบันทึกกิจกรรมของ Ticket. | ||
|
เหตุผลที่สำคัญ
การเปลี่ยนระดับความสำคัญอาจบ่งชี้ว่ามีการยกระดับปัญหาหรือประเมินความเร่งด่วนใหม่ การวิเคราะห์การเปลี่ยนแปลงเหล่านี้ช่วยให้เข้าใจสาเหตุของการยกระดับปัญหาและผลกระทบต่อเวลาแก้ไข.
แหล่งข้อมูล
ดึงข้อมูลจากบันทึก 'Ticket Activities' ซึ่งบันทึกการเปลี่ยนแปลงคุณสมบัติของทิกเก็ตทั้งหมด รวมถึงฟิลด์ 'Priority'
บันทึก
บันทึกเหตุการณ์เมื่อมีการอัปเดตค่าในช่อง 'Priority'.
ประเภทเหตุการณ์
explicit
|
|||
|
เปลี่ยนสถานะเป็น Pending
|
กิจกรรมนี้เกิดขึ้นเมื่อเจ้าหน้าที่รอข้อมูลจากลูกค้าและเปลี่ยนสถานะ Ticket เป็น 'Pending' ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจนว่าเป็นการเปลี่ยนสถานะในประวัติกิจกรรมของ Ticket. | ||
|
เหตุผลที่สำคัญ
แสดงช่วงเวลาที่กระบวนการหยุดรอข้อมูลจากภายนอก การวิเคราะห์เวลาที่อยู่ในสถานะนี้ช่วยวัดความล่าช้าฝั่งลูกค้าและวิเคราะห์การปฏิบัติตาม SLA เนื่องจากมักหยุดนับเวลา SLA ในสถานะนี้.
แหล่งข้อมูล
ดึงข้อมูลจากบันทึก 'Ticket Activities' ซึ่งบันทึกการเปลี่ยนแปลงสถานะทั้งหมด รวมถึงการเปลี่ยนเป็น 'Pending'
บันทึก
บันทึกเหตุการณ์เมื่ออัปเดตช่อง 'Status' ของ Ticket เป็น 'Pending'.
ประเภทเหตุการณ์
explicit
|
|||
|
เปิด Ticket อีกครั้ง
|
กิจกรรมนี้เกิดขึ้นเมื่อลูกค้าตอบกลับ Ticket ที่อยู่ในสถานะ 'Resolved' แล้ว ทำให้สถานะเปลี่ยนกลับเป็น 'Open' โดยอัตโนมัติ ระบบบันทึกเหตุการณ์นี้ไว้อย่างชัดเจน. | ||
|
เหตุผลที่สำคัญ
อัตราการเปิด Ticket ซ้ำที่สูงบ่งชี้ว่าวิธีแก้ปัญหาครั้งแรกไม่ได้ผล ทำให้ต้องทำงานซ้ำและลูกค้าไม่พอใจ การวิเคราะห์กิจกรรมนี้จำเป็นต่อ 'การวิเคราะห์ Ticket ที่เปิดซ้ำ' และการเพิ่มโอกาสแก้ปัญหาได้ตั้งแต่การติดต่อครั้งแรก.
แหล่งข้อมูล
ระบบบันทึกเหตุการณ์นี้เมื่อลูกค้าตอบกลับและทำให้สถานะเปลี่ยนจาก 'Resolved' กลับเป็น 'Open' โดยอัตโนมัติ การเปลี่ยนสถานะนี้จะปรากฏในบันทึก 'Ticket Activities'
บันทึก
เปลี่ยนสถานะจาก 'Resolved' เป็น 'Open' หลังจากลูกค้าติดต่อเข้ามา.
ประเภทเหตุการณ์
explicit
|
|||
|
ผิด SLA
|
เหตุการณ์ที่คำนวณขึ้นเมื่อเวลาที่ใช้ตอบกลับหรือแก้ไข Ticket เกินเป้าหมายตามนโยบาย SLA ที่กำหนด Freshdesk ติดตามสถานะ SLA และทำเครื่องหมาย Ticket ว่า 'violated' ซึ่งใช้ระบุกิจกรรมนี้ได้. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ช่วยวิเคราะห์การปฏิบัติตาม SLA โดยระบุได้อย่างชัดเจนว่าข้อผูกพันด้านระดับการให้บริการไม่เป็นไปตามเป้าหมายเมื่อใดและที่ใด จึงสำคัญต่อการค้นหาสาเหตุของความล่าช้าที่เกิดซ้ำในระบบ.
แหล่งข้อมูล
อนุมานหรือคำนวณเหตุการณ์นี้จากการตรวจสอบสถานะ 'SLA' ของ Ticket ระบบอาจสร้างกิจกรรมเมื่อสถานะ SLA ของ Ticket เปลี่ยนเป็น 'Violated' หรือเมื่อเปรียบเทียบเวลาตอบกลับและเวลาแก้ไขกับเป้าหมาย SLA.
บันทึก
คำนวณจากข้อมูล Ticket เมื่อ 'Time to Resolve' เกิน 'SLA Target Resolution Time'.
ประเภทเหตุการณ์
calculated
|
|||
|
เพิ่มบันทึกภายใน
|
เจ้าหน้าที่เพิ่มบันทึกส่วนตัวใน Ticket เพื่อสื่อสารและทำงานร่วมกับเจ้าหน้าที่คนอื่นภายในองค์กร ระบบบันทึกเหตุการณ์นี้ไว้ในลำดับกิจกรรมของ Ticket และแสดงให้เจ้าหน้าที่เห็นเท่านั้น. | ||
|
เหตุผลที่สำคัญ
การติดตามบันทึกภายในช่วยวิเคราะห์รูปแบบการทำงานร่วมกันและระบุปัญหาที่ต้องหารือภายในอย่างมาก หากมีบันทึกภายในจำนวนมากก่อนแก้ไขปัญหา อาจบ่งชี้ว่าปัญหาซับซ้อนหรือมีช่องว่างด้านความรู้.
แหล่งข้อมูล
บันทึกเป็น 'Private Note' ในประวัติการสนทนาของ Ticket ซึ่งแยกจากการตอบกลับที่ลูกค้ามองเห็น.
บันทึก
บันทึกเหตุการณ์เมื่อเจ้าหน้าที่เพิ่มบันทึกและกำหนดเป็น 'Private'.
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมาย Ticket ใหม่
|
เกิดขึ้นเมื่อโอน Ticket จากเจ้าหน้าที่หรือกลุ่มหนึ่งไปยังอีกกลุ่มหนึ่ง หลังจากมอบหมายครั้งแรก ระบบบันทึกเหตุการณ์นี้ไว้ในบันทึกกิจกรรมของ Ticket โดยระบุการเปลี่ยนผู้รับผิดชอบ. | ||
|
เหตุผลที่สำคัญ
การมอบหมายใหม่บ่อยครั้งหรือการโอนงานระหว่างเจ้าหน้าที่ในอัตราสูง มักบ่งชี้ว่าจัดเส้นทางงานครั้งแรกไม่ถูกต้องหรือความรู้ถูกแยกอยู่ตามทีม การวิเคราะห์นี้ช่วยระบุโอกาสในการเพิ่มการแก้ปัญหาได้ตั้งแต่การติดต่อครั้งแรก.
แหล่งข้อมูล
ติดตามจากการเปลี่ยนแปลงฟิลด์ 'Agent' หรือ 'Group' ในบันทึก 'Ticket Activities' หลังจากมอบหมายงานครั้งแรก
บันทึก
อัปเดตช่อง 'Assigned to' อีกครั้งหลังจากมอบหมายครั้งแรกแล้ว.
ประเภทเหตุการณ์
explicit
|
|||
|
ลูกค้าตอบกลับ
|
หมายถึงการตอบกลับหรือข้อความใหม่ที่ได้รับจากลูกค้า เหตุการณ์นี้ปรากฏชัดเจนในชุดข้อความสนทนาของ Ticket และโดยทั่วไปจะเปลี่ยนสถานะจาก 'Pending' กลับเป็น 'Open'. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ช่วยให้เข้าใจการโต้ตอบไปมาระหว่างลูกค้ากับเจ้าหน้าที่ และวัดเวลาที่ลูกค้าใช้ในการตอบกลับ นอกจากนี้ยังเริ่มนับเวลา SLA ที่หยุดไว้ใหม่ ซึ่งส่งผลต่อตัวชี้วัดการปฏิบัติตามข้อกำหนด.
แหล่งข้อมูล
บันทึกเป็นรายการใหม่ในชุดข้อความสนทนาของ Ticket และเชื่อมโยงเหตุการณ์กับข้อมูลผู้ติดต่อของลูกค้า.
บันทึก
ผู้ติดต่อของลูกค้าเพิ่มบันทึกสาธารณะใหม่ใน Ticket.
ประเภทเหตุการณ์
explicit
|
|||
|
ส่งแบบสำรวจความพึงพอใจ
|
หมายถึงการส่งแบบสำรวจความพึงพอใจให้ลูกค้า ซึ่งโดยทั่วไปจะเริ่มจากกฎอัตโนมัติหลังแก้ไข Ticket แล้ว อาจบันทึกเหตุการณ์นี้ได้หากมีการบันทึกการทำงานอัตโนมัติไว้ในประวัติ Ticket. | ||
|
เหตุผลที่สำคัญ
เป็นจุดเริ่มต้นของการรวบรวมความคิดเห็น เมื่อนำคำตอบแบบสำรวจมาเปรียบเทียบกับรูปแบบกระบวนการ จะช่วยให้เห็นชัดว่าประสิทธิภาพของกระบวนการส่งผลต่อความพึงพอใจของลูกค้าอย่างไร.
แหล่งข้อมูล
โดยทั่วไปเริ่มจาก 'Automation Rule' การแสดงเหตุการณ์นี้เป็นรายการแยกในบันทึกกิจกรรมของ Ticket ขึ้นอยู่กับการตั้งค่าบันทึกการทำงานอัตโนมัติของ Freshdesk.
บันทึก
บันทึกเหตุการณ์เมื่อกฎอัตโนมัติทำงานหลังแก้ไข Ticket แล้ว.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงการปฏิบัติการด้านบริการลูกค้าด้วยความเข้าใจที่ชัดเจนเกี่ยวกับกระบวนการของคุณ เทมเพลตนี้เป็นก้าวแรกสู่การปรับปรุงงานโดยใช้ข้อมูลประกอบการตัดสินใจ.
เริ่มปรับปรุงงานบริการลูกค้าบน Freshdesk วันนี้
แก้ไขปัญหาได้ตั้งแต่การติดต่อครั้งแรก 80% และสร้างความประทับใจให้ลูกค้า.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าได้ในไม่กี่นาที