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

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

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

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

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

ฟิลด์ข้อมูลเหล่านี้เป็นรายการแนะนำสำหรับบันทึกเหตุการณ์ เพื่อให้วิเคราะห์บริการลูกค้าได้อย่างละเอียด.
5 จำเป็น 6 แนะนำ 7 ไม่บังคับ
ชื่อ คำอธิบาย
คำขอบริการ
ServiceRequest
รหัสเฉพาะของคำขอบริการลูกค้าแต่ละรายการ ซึ่งเรียกอีกอย่างว่า Ticket หรือเคส.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

นี่คือ Case ID สำคัญที่เชื่อมโยงทุกขั้นตอนของกระบวนการ ทำให้สร้างและวิเคราะห์เส้นทางการให้บริการลูกค้าแต่ละรายการได้.

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ id.

ตัวอย่าง
102451287415332
เวลาเริ่มต้น
StartTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด.
คำอธิบาย

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

เวลานี้เป็นข้อมูลพื้นฐานสำหรับ process mining เพราะใช้เรียงเหตุการณ์ตามลำดับเวลา และใช้คำนวณระยะเวลาระหว่างกิจกรรม วัดเวลาตั้งแต่เริ่มจนจบ วิเคราะห์ผลการดำเนินงานเทียบกับ SLA และทำความเข้าใจลำดับเวลาของกระบวนการบริการ.

เหตุผลที่สำคัญ

เวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลา และวิเคราะห์ลำดับเวลาของกระบวนการคำขอบริการ.

แหล่งข้อมูล

Zendesk Ticket Audits API, ฟิลด์ created_at ของแต่ละเหตุการณ์ในประวัติการตรวจสอบ.

ตัวอย่าง
2023-04-15T10:00:00Z2023-04-15T10:05:14Z2023-04-16T14:30:00Z
ชื่อกิจกรรม
ActivityName
ชื่อเหตุการณ์หรืองานที่เกิดขึ้นในวงจรคำขอบริการ.
คำอธิบาย

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

ข้อมูลนี้สำคัญต่อการแสดงแผนผังกระบวนการ ค้นหารูปแบบกระบวนการ และวิเคราะห์ความถี่กับลำดับของเหตุการณ์ ช่วยให้นักวิเคราะห์เข้าใจว่ามีการดำเนินการใดบ้าง รวมถึงระบุเส้นทางที่พบบ่อย คอขวด และจุดที่เบี่ยงเบนจากขั้นตอนมาตรฐาน.

เหตุผลที่สำคัญ

ข้อมูลนี้ระบุขั้นตอนในกระบวนการ ช่วยแสดงแผนผังกระบวนการและวิเคราะห์ขั้นตอนการทำงานกับรูปแบบที่แตกต่างกัน.

แหล่งข้อมูล

ได้จากบันทึกการตรวจสอบ Ticket หรือสตรีมเหตุการณ์ของ Zendesk ซึ่งบันทึกการเปลี่ยนแปลงและการดำเนินการต่าง ๆ.

ตัวอย่าง
สร้างคำขอบริการมอบหมายคำขอให้เจ้าหน้าที่เจ้าหน้าที่ส่งคำตอบสาธารณะครั้งแรกแก้ไขคำขอบริการแล้ว
ระบบต้นทาง
SourceSystem
ระบบบันทึกข้อมูลหลักที่ใช้ดึงข้อมูลออกมา.
คำอธิบาย

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

ในการวิเคราะห์ ข้อมูลนี้ช่วยระบุแหล่งที่มาของข้อมูลให้ถูกต้อง ซึ่งสำคัญต่อการรักษาความถูกต้องของข้อมูลและทำความเข้าใจบริบทของกระบวนการ โดยเฉพาะในสภาพแวดล้อมที่เชื่อมต่อหลายระบบ.

เหตุผลที่สำคัญ

ระบุแหล่งที่มาของข้อมูล ซึ่งสำคัญต่อการกำกับดูแลข้อมูลและการแยกข้อมูลกระบวนการในสภาพแวดล้อมที่เชื่อมต่อหลายระบบ.

แหล่งข้อมูล

เพิ่มค่าคงที่นี้ระหว่างการดึงข้อมูลเพื่อระบุแหล่งที่มาของข้อมูล.

ตัวอย่าง
Zendesk Support
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ฟิลด์ข้อมูลเมตานี้สร้างและจัดเก็บระหว่างการดึงข้อมูล โดยบันทึกเวลาที่งานดึงข้อมูลทำงาน.

ตัวอย่าง
2023-10-27T02:00:00Z
เกินกำหนด SLA หรือไม่
IsSlaBreached
ค่าสถานะจริงหรือเท็จที่ระบุว่าเวลาแก้ไขคำขอรับบริการเกินเป้าหมาย SLA หรือไม่.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

แสดงผลการปฏิบัติตาม SLA ของแต่ละเคสอย่างชัดเจนว่าเป็นไปตามเป้าหมายหรือไม่ ช่วยให้ติดตามและรายงานการปฏิบัติตามข้อกำหนดได้ง่ายขึ้น.

แหล่งข้อมูล

คำนวณระหว่างการแปลงข้อมูล โดยเปรียบเทียบเวลาแก้ไขทั้งหมดกับ SlaTargetResolutionTime.

ตัวอย่าง
truefalse
เจ้าหน้าที่ที่ได้รับมอบหมาย
AssignedAgent
ชื่อหรือรหัสของเจ้าหน้าที่บริการลูกค้าที่ได้รับมอบหมายให้ดูแลคำขอบริการ.
คำอธิบาย

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

การวิเคราะห์ตามเจ้าหน้าที่ผู้รับผิดชอบช่วยให้เข้าใจภาระงาน ประสิทธิภาพ และผลการทำงานของเจ้าหน้าที่ ข้อมูลนี้ใช้ในแดชบอร์ด 'ภาระงานและประสิทธิภาพของเจ้าหน้าที่' เพื่อเปรียบเทียบเวลาให้บริการและจำนวนเคสของเจ้าหน้าที่แต่ละคน ช่วยระบุโอกาสในการฝึกอบรมและจัดสมดุลภาระงาน.

เหตุผลที่สำคัญ

ติดตามว่าเจ้าหน้าที่คนใดดำเนินการ ช่วยวิเคราะห์ผลการทำงานรายบุคคล การกระจายภาระงาน และการจัดสรรทรัพยากร.

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ assignee_id ดูรายละเอียดผู้ใช้ได้จาก Users API.

ตัวอย่าง
John SmithJane DoeSupportBot
ช่องทางการติดต่อ
CommunicationChannel
ช่องทางที่ใช้ส่งคำขอรับบริการหรือติดต่อสื่อสาร.
คำอธิบาย

แอตทริบิวต์นี้ระบุช่องทางการติดต่อ เช่น อีเมล แบบฟอร์มบนเว็บไซต์ แชต หรือโทรศัพท์ และแสดงให้เห็นว่าลูกค้าติดต่อฝ่ายบริการผ่านช่องทางใด.

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

เหตุผลที่สำคัญ

แสดงช่องทางที่ลูกค้าและเจ้าหน้าที่ใช้ติดต่อกัน เพื่อวิเคราะห์ประสิทธิภาพของแต่ละช่องทาง รวมถึงผลต่อกระบวนการและประสบการณ์ของลูกค้า.

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ via.channel.

ตัวอย่าง
เว็บไซต์อีเมลAPIแชต
ประเภทคำขอบริการ
ServiceRequestType
ประเภทของคำขอบริการ เช่น 'คำถาม', 'เหตุขัดข้อง', 'ปัญหา' หรือ 'งาน'.
คำอธิบาย

ข้อมูลนี้จัดหมวดหมู่คำขอบริการตามลักษณะของคำขอ โดยทั่วไปจะกำหนดประเภทเมื่อสร้างหรือคัดกรองคำขอ เพื่อช่วยเลือกเวิร์กโฟลว์และลำดับความสำคัญที่เหมาะสม.

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

เหตุผลที่สำคัญ

จัดหมวดหมู่คำขอเพื่อเปรียบเทียบผลการดำเนินงานและวิเคราะห์ปัญหาแต่ละประเภท ซึ่งสำคัญต่อการปรับปรุงกระบวนการให้ตรงจุด.

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ type.

ตัวอย่าง
คำถามเหตุขัดข้องปัญหางาน
ลำดับความสำคัญ
Priority
ระดับความสำคัญของคำขอบริการ เช่น 'ต่ำ', 'ปกติ', 'สูง' หรือ 'เร่งด่วน'.
คำอธิบาย

ลำดับความสำคัญบ่งบอกความเร่งด่วนของคำขอบริการ และมักมีผลต่อลำดับในคิวกับเวลาเป้าหมายในการแก้ไข ช่วยให้เจ้าหน้าที่จัดการปัญหาสำคัญก่อน.

ข้อมูลนี้จำเป็นต่อการวิเคราะห์ผลการดำเนินงานและ SLA แดชบอร์ด 'วิเคราะห์เวลาแก้ไขคำขอบริการ' ใช้ลำดับความสำคัญแบ่งกลุ่มข้อมูล เพื่อดูว่าคำขอที่มีความสำคัญสูงได้รับการจัดการเร็วกว่าคำขอระดับต่ำหรือไม่ และมีการจัดสรรทรัพยากรตามความต้องการของธุรกิจอย่างเหมาะสมหรือไม่.

เหตุผลที่สำคัญ

ระบุระดับความเร่งด่วนของคำขอ ซึ่งเป็นข้อมูลสำคัญสำหรับวิเคราะห์การปฏิบัติตามข้อกำหนด SLA และช่วยให้จัดการปัญหาเร่งด่วนได้ทันท่วงที.

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ priority.

ตัวอย่าง
ต่ำปกติสูงเร่งด่วน
เวลาเป้าหมายในการแก้ไขตาม SLA
SlaTargetResolutionTime
ระยะเวลาที่คาดว่าจะใช้แก้ไขคำขอรับบริการให้เสร็จตามนโยบาย SLA.
คำอธิบาย

แอตทริบิวต์นี้กำหนดเป้าหมายการแก้ไข Ticket ตามข้อตกลงระดับการให้บริการ (SLA) โดยเป้าหมายมักเปลี่ยนแปลงตามปัจจัยต่างๆ เช่น ความสำคัญและประเภทของคำขอ หรือแผนบริการของลูกค้า.

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

เหตุผลที่สำคัญ

กำหนดเวลาที่ให้บริการตามที่ตกลงกับลูกค้า และใช้เป็นเกณฑ์วัดการให้บริการตรงเวลาและการปฏิบัติตามข้อกำหนด SLA.

แหล่งข้อมูล

ได้จากนโยบาย SLA ที่ใช้กับ Ticket โดยเรียกดูข้อมูลนี้ได้ผ่าน Zendesk Ticket Metrics API.

ตัวอย่าง
144002880086400
กลุ่มเจ้าหน้าที่
AgentGroup
กลุ่มหรือทีมสนับสนุนที่รับผิดชอบคำขอรับบริการ.
คำอธิบาย

แอตทริบิวต์นี้ระบุทีมเจ้าหน้าที่ที่รับผิดชอบคำขอรับบริการ โดยมักส่งคำขอไปยังกลุ่มที่เหมาะสมตามทักษะ ผลิตภัณฑ์ หรือภาษาที่ใช้.

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

เหตุผลที่สำคัญ

ติดตามความรับผิดชอบของแต่ละทีม เพื่อวิเคราะห์ประสิทธิภาพของกลุ่ม การส่งต่องานระหว่างทีม และการจัดสรรทรัพยากรในระดับการสนับสนุนหรือความเชี่ยวชาญต่างๆ.

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ group_id เรียกดูรายละเอียดกลุ่มได้จาก Groups API.

ตัวอย่าง
ฝ่ายสนับสนุนระดับ 1ฝ่ายสนับสนุนด้านเทคนิคการเรียกเก็บเงิน
คะแนนความพึงพอใจ
SatisfactionRating
คะแนนความพึงพอใจที่ลูกค้าให้หลังจากแก้ไขคำขอรับบริการแล้ว.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

Zendesk Tickets API, ฟิลด์ satisfaction_rating.score.

ตัวอย่าง
ดีไม่ดีส่งแบบสำรวจแล้ว
จำนวนครั้งที่ขอข้อมูล
InformationRequestCount
จำนวนครั้งทั้งหมดที่ขอข้อมูลจากลูกค้าสำหรับคำขอรับบริการหนึ่งรายการ.
คำอธิบาย

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

แอตทริบิวต์นี้ใช้ในแดชบอร์ด 'วิเคราะห์การขอข้อมูลซ้ำ' การติดตามจำนวนครั้งช่วยระบุจุดที่กระบวนการไม่มีประสิทธิภาพและหัวข้อที่ควรนำไปฝึกอบรมเจ้าหน้าที่ การลดจำนวนครั้งที่ต้องขอข้อมูลช่วยลดเวลาแก้ไขและปรับปรุงประสบการณ์ของลูกค้าได้อย่างมาก.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

คำนวณโดยนับจำนวนเหตุการณ์ที่ ActivityName เป็น 'Information Requested From Customer' สำหรับ Service Request แต่ละรายการ.

ตัวอย่าง
013
มีการเปิดคำขอซ้ำหรือไม่
IsReopened
ค่าสถานะจริงหรือเท็จที่ระบุว่ามีการเปิดคำขอรับบริการซ้ำหลังจากทำเครื่องหมายว่าแก้ไขแล้วหรือไม่.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

คำนวณระหว่างการแปลงข้อมูล โดยตรวจสอบว่า Ticket เปลี่ยนสถานะจาก 'แก้ไขแล้ว' หรือ 'ปิดแล้ว' กลับเป็น 'เปิด' หรือไม่.

ตัวอย่าง
truefalse
รหัสการแก้ไข
ResolutionCode
รหัสหรือหมวดหมู่ที่ระบุเหตุผลในการแก้ไขหรือปิดคำขอ.
คำอธิบาย

รหัสการแก้ไขปัญหาให้ข้อมูลที่เป็นระบบเกี่ยวกับผลลัพธ์ของคำขอรับบริการ เช่น 'เจ้าหน้าที่แก้ไขแล้ว', 'รายการซ้ำ', 'ไม่ต้องดำเนินการ' หรือ 'ปัญหาที่ทราบแล้ว' จึงให้รายละเอียดมากกว่าสถานะ 'ปิดแล้ว' เพียงอย่างเดียว.

แอตทริบิวต์นี้มีประโยชน์อย่างยิ่งต่อการวิเคราะห์หาสาเหตุที่แท้จริง สำหรับแดชบอร์ด 'แนวโน้มคำขอรับบริการที่เปิดซ้ำ' การวิเคราะห์อัตราการเปิดซ้ำตามรหัสการแก้ไขจะช่วยให้เห็นว่าวิธีแก้ไขบางประเภทได้ผลน้อยกว่าประเภทอื่นหรือไม่ จนทำให้ลูกค้าต้องติดต่อฝ่ายบริการอีกครั้ง.

เหตุผลที่สำคัญ

ช่วยให้เข้าใจผลลัพธ์ของคำขอรับบริการ ซึ่งสำคัญต่อการวิเคราะห์หาสาเหตุที่แท้จริงและทำความเข้าใจว่าทำไมจึงมีการเปิดคำขอซ้ำ.

แหล่งข้อมูล

โดยทั่วไป ฟิลด์นี้เป็นฟิลด์ Ticket ที่กำหนดเองใน Zendesk ชื่อฟิลด์ที่แน่นอนขึ้นอยู่กับการตั้งค่า Zendesk ของแต่ละองค์กร.

ตัวอย่าง
แก้ไขได้ตั้งแต่การติดต่อครั้งแรกส่งต่อไปยังระดับ 2รอข้อมูลจากลูกค้าข้อบกพร่องของผลิตภัณฑ์
เวลาสิ้นสุด
EndTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด.
คำอธิบาย

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

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

เหตุผลที่สำคัญ

ใช้คำนวณระยะเวลาของกิจกรรม ซึ่งสำคัญต่อการระบุคอขวดและวัดผลการดำเนินงาน.

แหล่งข้อมูล

โดยทั่วไปคำนวณจาก StartTime ของเหตุการณ์ถัดไปในลำดับของคำขอบริการเดียวกัน.

ตัวอย่าง
2023-04-15T10:05:14Z2023-04-15T11:20:30Z2023-04-16T15:00:00Z
หมวดหมู่ผลิตภัณฑ์หรือบริการ
ProductServiceCategory
ผลิตภัณฑ์ บริการ หรือฟีเจอร์ที่เกี่ยวข้องกับคำขอของลูกค้า.
คำอธิบาย

แอตทริบิวต์นี้ให้รายละเอียดเพิ่มเติม โดยจัดหมวดหมู่คำขอรับบริการตามผลิตภัณฑ์หรือบริการที่เกี่ยวข้อง เจ้าหน้าที่อาจกำหนดหมวดหมู่เอง หรือระบบอาจกำหนดโดยอัตโนมัติตามเนื้อหาของคำขอ.

การจัดหมวดหมู่นี้สำคัญต่อแดชบอร์ด 'ความแม่นยำในการจัดหมวดหมู่คำขอ' และ 'แจกแจงระยะเวลาการตรวจสอบ' ช่วยวิเคราะห์ได้ว่าผลิตภัณฑ์ใดมีคำขอรับบริการมากที่สุด รายการใดใช้เวลาแก้ไขนาน และหมวดหมู่ที่กำหนดไว้ตอนแรกตรงกับวิธีแก้ไขสุดท้ายหรือไม่ ข้อมูลนี้ช่วยปรับปรุงการส่งต่องานและการฝึกอบรมเจ้าหน้าที่.

เหตุผลที่สำคัญ

เชื่อมโยงคำขอกับหน่วยงาน ผลิตภัณฑ์ หรือบริการที่เกี่ยวข้อง เพื่อวิเคราะห์จุดที่มีปัญหาและผลกระทบต่อกระบวนการได้อย่างตรงจุด.

แหล่งข้อมูล

โดยทั่วไป ฟิลด์นี้เป็นฟิลด์ Ticket ที่กำหนดเองใน Zendesk ชื่อฟิลด์ที่แน่นอนขึ้นอยู่กับการตั้งค่า Zendesk ของแต่ละองค์กร.

ตัวอย่าง
แอปมือถือการจัดการการสมัครใช้บริการการเชื่อมต่อ APIฮาร์ดแวร์
จำเป็น แนะนำ ไม่บังคับ

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

ขั้นตอนและหมุดหมายสำคัญที่ควรบันทึกในบันทึกเหตุการณ์ เพื่อค้นพบกระบวนการบริการลูกค้าได้อย่างแม่นยำ.
6 แนะนำ 8 ไม่บังคับ
กิจกรรม คำอธิบาย
แก้ไขคำขอบริการแล้ว
เจ้าหน้าที่เปลี่ยนสถานะคำขอบริการเป็น 'solved' หลังให้คำตอบแก่ลูกค้า สถานะนี้ยังไม่ถาวร เพราะลูกค้าสามารถตอบกลับและเปิด Ticket อีกครั้งก่อนปิดถาวรได้.
เหตุผลที่สำคัญ

จุดนี้เป็นหลักสำคัญในการวัดเวลาแก้ไขปัญหาและประสิทธิภาพของเจ้าหน้าที่ หมายถึงเวลาที่เจ้าหน้าที่เห็นว่างานเสร็จแล้ว และใช้วิเคราะห์งานที่ต้องทำซ้ำหากมีการเปิด Ticket อีกครั้ง.

แหล่งข้อมูล

การเปลี่ยนสถานะนี้บันทึกไว้อย่างชัดเจนใน Zendesk Ticket Audits API เมื่อกำหนดฟิลด์ 'status' เป็น 'solved'.

บันทึก

ค้นหาเหตุการณ์ 'Change' ใน Ticket Audits ที่กำหนดสถานะ Ticket เป็น 'solved'.

ประเภทเหตุการณ์ explicit
ขอข้อมูลเพิ่มเติมจากลูกค้า
เกิดขึ้นเมื่อเจ้าหน้าที่ต้องการข้อมูลเพิ่มเติมจากลูกค้าเพื่อดำเนินการต่อ และเปลี่ยนสถานะ Ticket เป็น 'pending' การเปลี่ยนสถานะนี้ระบุชัดเจนว่าขณะนี้กระบวนการกำลังรอข้อมูลจากบุคคลภายนอก.
เหตุผลที่สำคัญ

กิจกรรมนี้แสดงให้เห็นว่ากระบวนการต้องรอข้อมูลจากลูกค้า และหยุดนับเวลา SLA ภายในไว้ชั่วคราว หากเกิดขึ้นบ่อยหรือซ้ำหลายครั้งใน Ticket เดียว อาจหมายถึงการเก็บข้อมูลเบื้องต้นไม่ครบถ้วนและทำให้ใช้เวลาแก้ไขนานขึ้น.

แหล่งข้อมูล

เหตุการณ์เปลี่ยนสถานะนี้บันทึกไว้อย่างชัดเจนใน Zendesk Ticket Audits API เมื่อฟิลด์ 'status' เปลี่ยนเป็น 'pending'.

บันทึก

ค้นหาเหตุการณ์ 'Change' ใน Ticket Audits ที่กำหนดสถานะ Ticket เป็น 'pending'.

ประเภทเหตุการณ์ explicit
ปิดคำขอบริการ
กิจกรรมนี้เป็นขั้นตอนสุดท้ายที่ระบุว่าปิดคำขอบริการอย่างถาวรแล้ว โดยทั่วไปจะเกิดขึ้นโดยอัตโนมัติเมื่อผ่านระยะเวลาที่กำหนดหลังเปลี่ยนสถานะ Ticket เป็น 'solved' และไม่มีลูกค้าตอบกลับเพิ่มเติม.
เหตุผลที่สำคัญ

เหตุการณ์นี้เป็นจุดสิ้นสุดที่สมบูรณ์ของวงจร Ticket ระยะเวลาตั้งแต่ 'solved' จนถึง 'closed' คือช่วงที่ลูกค้ายังอาจเปิดคำขออีกครั้ง ส่วนเหตุการณ์ 'closed' ยืนยันว่าการแก้ไขเสร็จสิ้นแล้ว.

แหล่งข้อมูล

การเปลี่ยนสถานะนี้บันทึกไว้อย่างชัดเจนใน Zendesk Ticket Audits API เมื่อกำหนดฟิลด์ 'status' เป็น 'closed'.

บันทึก

ค้นหาเหตุการณ์ 'Change' ใน Ticket Audits ที่กำหนดสถานะ Ticket เป็น 'closed'.

ประเภทเหตุการณ์ explicit
เปิดคำขอบริการอีกครั้ง
กิจกรรมนี้เกิดขึ้นเมื่อลูกค้าตอบกลับ Ticket ที่มีสถานะ 'solved' Zendesk จะเปลี่ยนสถานะกลับเป็น 'open' โดยอัตโนมัติ ซึ่งแสดงว่าปัญหาอาจยังไม่ได้รับการแก้ไขครบถ้วน.
เหตุผลที่สำคัญ

การเปิดคำขอซ้ำเป็นตัวชี้วัดสำคัญว่าการแก้ไขปัญหาตั้งแต่การติดต่อครั้งแรกไม่สำเร็จ หรือคุณภาพของคำตอบยังไม่ดีพอ การวิเคราะห์ความถี่และสาเหตุของการเปิด Ticket ซ้ำช่วยระบุจุดที่ควรปรับปรุงการฝึกอบรมเจ้าหน้าที่และขั้นตอนการแก้ไขปัญหา.

แหล่งข้อมูล

การเปลี่ยนสถานะนี้บันทึกไว้อย่างชัดเจนใน Ticket Audits API เมื่อ 'status' เปลี่ยนจาก 'solved' กลับเป็น 'open'.

บันทึก

ติดตามเหตุการณ์ 'Change' ที่เปลี่ยนสถานะจาก 'solved' เป็น 'open'.

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

การมอบหมายเป็นจุดสำคัญสำหรับการกำหนดผู้รับผิดชอบและจัดการภาระงาน การวิเคราะห์เวลาที่ใช้ก่อนมอบหมายและรูปแบบการมอบหมายใหม่ช่วยให้เห็นคอขวดในขั้นตอนคัดกรองและกระจายงาน.

แหล่งข้อมูล

เหตุการณ์นี้บันทึกไว้อย่างชัดเจนเป็น 'Change' event ใน Zendesk Ticket Audits API ทุกครั้งที่มีการกรอกหรือเปลี่ยนฟิลด์ 'assignee_id'.

บันทึก

ติดตามการเปลี่ยนแปลงของฟิลด์ 'assignee_id' ในบันทึก Ticket Audits.

ประเภทเหตุการณ์ explicit
สร้างคำขอบริการ
กิจกรรมนี้เป็นจุดเริ่มต้นของกระบวนการบริการลูกค้า เมื่อมีการสร้าง Ticket ใหม่ใน Zendesk ผ่านช่องทางต่าง ๆ เช่น อีเมล แบบฟอร์มบนเว็บไซต์ หรือแชต ระบบจะบันทึกเหตุการณ์นี้พร้อม Ticket ID และเวลาที่สร้าง.
เหตุผลที่สำคัญ

เหตุการณ์นี้เป็นจุดเริ่มต้นหลัก ใช้คำนวณระยะเวลารวมของแต่ละคำขอและวิเคราะห์ปริมาณคำขอที่เข้ามาตามช่วงเวลา อีกทั้งยังเป็นจุดอ้างอิงสำหรับวัด KPI สำคัญ เช่น เวลาตอบกลับครั้งแรกและเวลาแก้ไขปัญหาทั้งหมด.

แหล่งข้อมูล

เหตุการณ์นี้บันทึกไว้อย่างชัดเจนใน Zendesk Ticket Audits API โดยตรงกับเหตุการณ์ 'Create' ของ Ticket และระบุเวลาที่สร้างครั้งแรก.

บันทึก

ดึงข้อมูลจากเหตุการณ์สร้าง Ticket ในบันทึก Ticket Audits.

ประเภทเหตุการณ์ explicit
เกิดการผิด SLA
กิจกรรมนี้ระบุเวลาที่คำขอบริการไม่เป็นไปตามข้อตกลงระดับการให้บริการที่กำหนดไว้ เช่น เวลาตอบกลับครั้งแรกหรือเวลาแก้ไขปัญหา ระบบคำนวณเหตุการณ์นี้โดยเปรียบเทียบเวลาของกิจกรรมใน Ticket กับนโยบาย SLA.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

ดึงข้อมูลได้จาก Zendesk Ticket Metrics API ซึ่งจัดเก็บเวลาที่ผิด SLA ('breached_at') หรือคำนวณโดยเปรียบเทียบเวลาของเหตุการณ์ใน Ticket กับกฎ SLA ที่กำหนดไว้.

บันทึก

ใช้เวลาจากฟิลด์ 'breached_at' ใน Ticket Metrics API หรือคำนวณโดยเปรียบเทียบเวลาแก้ไขปัญหากับเวลาตามนโยบาย SLA.

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

การจัดหมวดหมู่และกำหนดลำดับความสำคัญอย่างเหมาะสมมีความสำคัญต่อการส่งต่อคำขอและจัดสรรทรัพยากรอย่างมีประสิทธิภาพ การวิเคราะห์กิจกรรมนี้ช่วยประเมินความแม่นยำของการคัดกรองเบื้องต้นและผลต่อเวลาแก้ไขปัญหา.

แหล่งข้อมูล

ดึงข้อมูลจาก Zendesk Ticket Audits API ในรูปแบบเหตุการณ์ 'Change' โดยค้นหาการอัปเดตครั้งแรกของฟิลด์ เช่น 'priority', 'type' หรือฟิลด์ที่กำหนดเองซึ่งเกี่ยวข้องกับการจัดหมวดหมู่.

บันทึก

กรองบันทึก Ticket Audit เพื่อหาเหตุการณ์ 'Change' ครั้งแรกของฟิลด์สำคัญที่ใช้จัดหมวดหมู่หลังสร้าง Ticket.

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

จุดนี้เป็นหลักสำคัญในการวัด SLA 'First Reply Time' ซึ่งบ่งชี้ความรวดเร็วในการให้บริการ และแยกการสื่อสารอัตโนมัติออกจากการเริ่มตรวจสอบและให้ความช่วยเหลือโดยเจ้าหน้าที่.

แหล่งข้อมูล

ค้นหาความคิดเห็นสาธารณะแรกในสตรีม Ticket Comments ที่ผู้เขียนเป็นเจ้าหน้าที่จริง ไม่ใช่ผู้ใช้ระบบอัตโนมัติ.

บันทึก

ตรวจสอบความคิดเห็นใน Ticket โดยกรองเฉพาะความคิดเห็นสาธารณะจากเจ้าหน้าที่ แล้วเลือกความคิดเห็นที่มีเวลาบันทึกเร็วที่สุด.

ประเภทเหตุการณ์ inferred
ได้รับคะแนนความพึงพอใจ
เหตุการณ์นี้เกิดขึ้นเมื่อลูกค้าส่งคำตอบแบบสำรวจความพึงพอใจ เช่น 'Good' หรือ 'Bad' ระบบจะบันทึกคะแนนและความคิดเห็นที่เกี่ยวข้องไว้กับ Ticket.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

บันทึกเป็นเหตุการณ์ 'Change' ใน Zendesk Ticket Audits API เมื่อกรอกคะแนนและความคิดเห็นของลูกค้าลงในฟิลด์ 'satisfaction_rating'.

บันทึก

กรองบันทึก Ticket Audit เพื่อค้นหาการเปลี่ยนแปลงของฟิลด์ 'satisfaction_rating'.

ประเภทเหตุการณ์ explicit
เริ่มส่งต่อเรื่องภายใน
หมายถึงการส่งคำขอบริการไปยังทีมภายในอื่นหรือทีมสนับสนุนระดับสูงขึ้น โดยทั่วไปอนุมานได้จากการเปลี่ยนกลุ่มที่ได้รับมอบหมายให้ดูแล Ticket.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากเหตุการณ์ 'Change' ใน Zendesk Ticket Audits API เมื่อมีการแก้ไขฟิลด์ 'group_id' การเปลี่ยนกลุ่มหมายถึงมีการส่งต่องานระหว่างทีม.

บันทึก

ติดตามการเปลี่ยนแปลงของฟิลด์ 'group_id' ในบันทึก Ticket Audits.

ประเภทเหตุการณ์ inferred
ลูกค้าตอบกลับ
เหตุการณ์นี้เกิดขึ้นเมื่อลูกค้าตอบกลับ Ticket ซึ่งโดยทั่วไปจะอยู่ในสถานะ 'pending' Zendesk จะเปลี่ยนสถานะ Ticket จาก 'pending' กลับเป็น 'open' โดยอัตโนมัติ เพื่อแจ้งให้เจ้าหน้าที่ดำเนินงานต่อได้.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

เหตุการณ์นี้ตรงกับความคิดเห็นสาธารณะใหม่จากผู้ใช้ปลายทาง ซึ่งทำให้สถานะเปลี่ยนจาก 'pending' เป็น 'open' อย่างชัดเจนใน Zendesk Ticket Audits API.

บันทึก

ติดตามเหตุการณ์ 'Change' ที่เปลี่ยนสถานะจาก 'pending' เป็น 'open' หรือค้นหาความคิดเห็นสาธารณะใหม่จากผู้ใช้ปลายทาง.

ประเภทเหตุการณ์ explicit
ส่งข้อความตอบรับเบื้องต้น
หมายถึงการตอบกลับอัตโนมัติครั้งแรกที่ส่งถึงลูกค้าเพื่อยืนยันว่าได้รับคำขอแล้ว โดยทั่วไป Zendesk trigger จะส่งอีเมลแจ้งเตือนตามเทมเพลตทันทีหลังสร้าง Ticket.
เหตุผลที่สำคัญ

การติดตามกิจกรรมนี้สำคัญต่อการวัดความรวดเร็วในการตอบสนองครั้งแรกและการจัดการความคาดหวังของลูกค้า เวลาตั้งแต่สร้างคำขอจนถึงส่งข้อความตอบรับเป็นตัวชี้วัดสำคัญด้านความพึงพอใจของลูกค้า.

แหล่งข้อมูล

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

บันทึก

ค้นหาความคิดเห็นสาธารณะแรกที่ระบบอัตโนมัติหรือ trigger สร้างขึ้นทันทีหลังสร้าง Ticket.

ประเภทเหตุการณ์ inferred
ส่งแบบสำรวจความพึงพอใจ
หมายถึงเวลาที่ระบบส่งแบบสำรวจความพึงพอใจของลูกค้า (CSAT) ให้ลูกค้าโดยอัตโนมัติ โดยทั่วไปจะส่งหลังจากเปลี่ยนสถานะ Ticket เป็น solved ไม่นาน.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานได้จากบันทึกระบบอัตโนมัติหรือแท็กที่เพิ่มลงใน Ticket โดยเฉพาะ นอกจากนี้ ส่วน 'satisfaction_rating' ใน Zendesk Ticket Audits API ยังบันทึกเวลาที่ส่งแบบสำรวจให้ลูกค้า.

บันทึก

ค้นหาแท็ก เช่น 'csat_sent' หรือใช้เวลาที่ส่งคำขอให้ลูกค้าประเมินความพึงพอใจ.

ประเภทเหตุการณ์ inferred
แนะนำ ไม่บังคับ

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

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

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

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

ขจัดคอขวดในการบริการลูกค้า เพิ่ม CSAT ได้ตั้งแต่วันนี้

ลดการติดต่อติดตามซ้ำ ตั้งเป้า FCR ที่ 80% และยกระดับความพึงพอใจของลูกค้า.

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

ไม่ต้องใช้บัตรเครดิต