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

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

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

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

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

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

กิจกรรมในงานบริการลูกค้า

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

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

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

เริ่มปรับปรุงงานบริการลูกค้าบน Freshdesk วันนี้

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

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

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