วิธีสร้างรายงาน Support Ticket: ทีละขั้นตอน

รายงาน support ticket ส่วนใหญ่แล้วเป็นปัญหาเรื่องการกำหนดนิยาม จำนวน ticket ที่สร้าง, ticket ที่แก้ไขได้, เวลาตอบกลับครั้งแรก และเวลาแก้ไขปัญหา ทั้งหมดนี้ฟังดูเข้าใจง่ายในตัวเอง แต่ทุกตัวล้วนมีความหมายอย่างเป็นทางการมากกว่าหนึ่งความหมายภายใน help desk เดียวกัน

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

คู่มือนี้จะครอบคลุมถึงสิ่งที่คุณควรใส่ไว้ในรายงาน จุดที่นิยามแยกออกเป็นสองทางใน 4 เรื่อง และวิธีสร้างรายงานนี้ขึ้นมาจากข้อมูล ticket ที่ส่งออก

สิ่งที่ควรมีอยู่ในรายงาน support ticket

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

องค์ประกอบ	เหตุผลที่ต้องมี
Ticket ที่ถูกสร้างขึ้นในรอบระยะเวลา	ฝั่งอุปสงค์ (Demand)
Ticket ที่ได้รับการแก้ไขในรอบระยะเวลา	ฝั่งอุปทาน (Supply) ตามกฎสถานะที่กำหนดไว้
งานค้างสะสม (Backlog) ณ วันสิ้นสุดรอบระยะเวลา	ทุกอย่างที่ยังไม่ได้รับการแก้ไขหรือปิดงาน
เวลาตอบกลับครั้งแรก	ตามเวลาทำการที่กำหนดและนิยามที่ระบุไว้
เวลาแก้ไขปัญหา	ระบุให้ชัดเจนว่าเป็นแบบครั้งแรก (First) หรือแบบสมบูรณ์ (Full)
Ticket ที่ถูกเปิดซ้ำ	สัญญาณบ่งชี้คุณภาพที่ตัวเลขอื่นๆ ซ่อนไว้
Ticket ที่ไม่มีการตอบกลับ	จุดที่กระบวนการทำงานล้มเหลวโดยสิ้นเชิง
เกณฑ์วันที่และขอบเขตที่กำหนดไว้	ช่องทาง แบรนด์ และคิวใดบ้างที่รวมอยู่ด้วย

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

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

เริ่มต้นด้วยตัวที่ง่ายที่สุด Solved tickets คือ "จำนวน ticket ที่ได้รับการแก้ไขหรือปิดงานแล้ว" ดังนั้นตัวชี้วัดนี้จึงครอบคลุมสองสถานะแทนที่จะเป็นสถานะเดียว

"เวลาตอบกลับครั้งแรก" มีนิยามอย่างเป็นทางการสองแบบ

นี่คือจุดแยกที่ทำให้เกิดความเห็นไม่ตรงกันมากที่สุด และผู้ให้บริการระบบก็แจ้งเตือนเรื่องนี้โดยตรง

เอกสาร เอกสารประกอบ SLA ของ Zendesk กล่าวไว้ในบรรทัดเดียวว่า: "อย่าสับสนระหว่างเวลาตอบกลับของ SLA กับตัวชี้วัดเวลาตอบกลับดั้งเดิมของ Zendesk"

ตัวชี้วัดดั้งเดิม (native metric) จะเข้มงวดมากว่าใครเป็นคนตอบกลับ Zendesk ระบุว่า "เวลาตอบกลับครั้งแรกจะคำนวณจากคำตอบของ agent เท่านั้น" การดำเนินการอัตโนมัติและกิจกรรมที่เกี่ยวข้องกับบอท "จะไม่ถูกนำมาพิจารณาเมื่อคำนวณเวลาตอบกลับครั้งแรก"

แต่ตัวชี้วัด SLA ไม่ได้เป็นเช่นนั้น ในส่วนนี้ เวลาตอบกลับครั้งแรกคือ "ระยะเวลาระหว่างการสร้าง ticket กับความคิดเห็นสาธารณะครั้งแรกจาก agent (หรือการตอบกลับอัตโนมัติ)" Zendesk เสริมว่า "ตัวชี้วัดเวลาตอบกลับจะถือว่าบรรลุเป้าหมาย หากคุณตั้งค่า trigger ให้ตอบกลับอัตโนมัติด้วยความคิดเห็นสาธารณะ"

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

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

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

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

"เวลาแก้ไขปัญหา" ก็มีสองแบบเช่นกัน

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

เวลาแก้ไขปัญหาครั้งแรก (First resolution time) คือ "ระยะเวลาระหว่างการสร้าง ticket จนถึงการแก้ไขปัญหาครั้งแรก" โดยจะสิ้นสุดเมื่อ "สถานะของ ticket ถูกตั้งค่าเป็นแก้ไขแล้ว (solved) เป็นครั้งแรก"

เวลาแก้ไขปัญหาสมบูรณ์ (Full resolution time) คือ "ระยะเวลาระหว่างการสร้าง ticket จนถึงการแก้ไขปัญหาครั้งล่าสุด" โดยจะสิ้นสุดเมื่อ "สถานะของ ticket ถูกตั้งค่าเป็นแก้ไขแล้ว (solved) เป็นครั้งสุดท้าย"

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

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

มีผลกระทบต่อเนื่องขั้นที่สองที่คนมักจะมองข้าม ค่าเฉลี่ยรายวันของ ticket ที่แก้ไขได้จะนับ "เฉพาะในกรณีที่ปัจจุบันมีสถานะเป็นแก้ไขแล้วหรือปิดงานแล้วเท่านั้น" ดังนั้น ticket ที่ถูกเปิดซ้ำในวันนี้ จะหายไปจากยอดนับจำนวนที่แก้ไขได้ของเดือนที่แล้วอย่างเงียบๆ

ดังนั้น รายงานที่คุณรันในเดือนมิถุนายนจะไม่ได้ผลลัพธ์เดิมเมื่อรันในเดือนสิงหาคม ไม่มีอะไรเสีย แต่เป็นเพราะสถานะเบื้องหลังได้เปลี่ยนไปแล้ว

ยังมีอีกสองตัวชี้วัดที่แยกเวลาการรอคอยออกจากการทำงาน เวลาที่ผู้ร้องขอรอ (Requester wait time) คือเวลารวมในสถานะใหม่ (new), เปิด (open) และระงับชั่วคราว (on-hold) ส่วนเวลาที่ agent รอ (agent wait time) คือเวลารวมในสถานะรอดำเนินการ (pending)

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

เวลาตามปฏิทิน หรือ เวลาทำการ

ตัวเลขการตอบกลับและการแก้ไขปัญหาทุกตัวจะอิงตามนาฬิกาสองแบบ และคุณจำเป็นต้องเลือกแบบใดแบบหนึ่ง

Zendesk จัดเก็บทั้งสองแบบ หลังจากมีการตอบกลับสาธารณะครั้งแรก "ระบบจะคำนวณเวลาตอบกลับครั้งแรกเป็นเวลาตามปฏิทินและเวลาทำการ" ตัวชี้วัดทั้งสองนี้ "จะถูกจัดเก็บไว้พร้อมกับข้อมูล ticket"

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

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

ช่องทางการสนทนาสด (Live conversation) ยังมีรายละเอียดเพิ่มเติมอีกเล็กน้อย ตัวชี้วัด First reply time (sec) สำหรับการส่งข้อความและแชท "จะละเลยการตั้งค่าเวลาทำการของการส่งข้อความและเวลาเปิดให้บริการของแชทสดของคุณ"

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

วิธีการทำด้วยตัวเอง (Manual)

ทางเลือกที่ 1: แยกหนึ่งแท็บต่อหนึ่งกลุ่มตัวชี้วัด

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

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

คำนวณค่ามัธยฐาน (Median) แทนค่าเฉลี่ย (Mean) สำหรับตัวชี้วัดด้านเวลา เพราะ ticket เพียงไม่กี่ใบที่ถูกเปิดทิ้งไว้ในช่วงวันหยุดจะดึงค่าเฉลี่ยให้สูงขึ้นไปยังจุดที่ไม่มี ticket ใบไหนใช้เวลาจริงขนาดนั้นเลย

ข้อจำกัดสูงสุดคือสเปรดชีตไม่สามารถดูประวัติสถานะย้อนหลังได้ คุณจะได้เพียงสถานะปัจจุบันของแต่ละ ticket ดังนั้นพฤติกรรมการเปิดซ้ำจึงต้องดูจากจำนวนการเปิดซ้ำ (reopened count) แทนที่จะเป็นการสร้างประวัติขึ้นมาใหม่

ทางเลือกที่ 2: เขียนแท็บนิยามก่อนเป็นอันดับแรก

บันทึกนิยามของเวลาตอบกลับ, นาฬิกาที่ใช้, ตัวชี้วัดการแก้ไขปัญหา, กฎสถานะสำหรับตั๋วที่แก้ไขแล้ว, ช่องทางที่อยู่ในขอบเขต และเกณฑ์วันที่

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

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

ทางเลือกที่ 3: แบ่งกลุ่มข้อมูลก่อนหาค่าเฉลี่ย

แยกข้อมูลตามช่องทางก่อนที่จะคำนวณตัวชี้วัดด้านเวลา ticket จากอีเมล แชท และโทรศัพท์ มีลักษณะการทำงานที่แตกต่างกัน และค่ามัธยฐานที่นำมารวมกันจะไม่สามารถอธิบายช่องทางใดได้เลยอย่างถูกต้อง

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

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

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

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

จุดที่วิธีการทำด้วยตัวเองเริ่มช้าลง

รายงาน support ticket ฉบับแรกอาจใช้เวลาทำเพียงแค่ช่วงบ่ายวันเดียว แต่ฉบับที่สี่จะใช้เวลานานกว่านั้น เพราะระบบ help desk เบื้องหลังได้เปลี่ยนไปแล้ว

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

จากนั้นก็เกิดผลกระทบจากการเปิดตั๋วซ้ำ (reopen effect) ตัวเลขของไตรมาสที่แล้วไม่สามารถทำซ้ำให้ตรงกันได้อีกต่อไป และการอธิบายเหตุผลว่าทำไมจึงเป็นเช่นนั้นใช้เวลานานกว่าการสร้างรายงานขึ้นมาใหม่เสียอีก

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

สำหรับมุมมองด้านความพึงพอใจในภาพเดียวกันนี้ สามารถดูคู่มือของเราเกี่ยวกับ การสร้างรายงาน NPS และหากปริมาณงานคือตัวปัญหา คำแนะนำทีละขั้นตอนของเราเกี่ยวกับ การสร้าง AI agent สำหรับการสนับสนุนลูกค้าก่อนการขาย จะครอบคลุมในส่วนของการลดปริมาณงาน (deflection)

วิธีสร้างรายงานด้วย Powerdrill Bloom

ขั้นตอนที่ 1: อัปโหลดข้อมูล ticket ที่ส่งออกของคุณ

อัปโหลดข้อมูล ticket ที่ส่งออก หรืออัปโหลดข้อมูล ticket และ SLA พร้อมกัน Powerdrill Bloom จะวิเคราะห์คอลัมน์ต่างๆ ทันทีที่ได้รับข้อมูล ดังนั้นข้อมูลเวลาที่ว่างเปล่า รูปแบบวันที่ที่ปะปนกัน และ ticket ที่ไม่มีการตอบกลับครั้งแรกจะปรากฏขึ้นมาให้เห็นก่อนที่จะมีการคำนวณค่ามัธยฐานใดๆ

ขั้นตอนที่ 2: อธิบายรายงานด้วยภาษาธรรมชาติ (Natural Language)

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

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

ขั้นตอนที่ 3: ส่งออกแผนภูมิ รายงาน หรือสไลด์นำเสนอ

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

ข้อผิดพลาดที่พบบ่อย

การอ้างอิงการบรรลุเป้าหมาย SLA เป็นเวลาตอบกลับครั้งแรก แบบแรกยอมรับการตอบกลับอัตโนมัติ แต่อีกแบบหนึ่งจะคัดการดำเนินการอัตโนมัติออกไปโดยสิ้นเชิง

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

การใช้ค่าเฉลี่ย (Mean) สำหรับเวลาตอบกลับและเวลาแก้ไขปัญหา ticket ที่ถูกละทิ้งเพียงไม่กี่ใบสามารถดึงค่าเฉลี่ยไปยังจุดที่ไม่มี ticket ที่เกิดขึ้นจริงใบใดใช้เวลานั้นเลย

การนำช่องทางต่างๆ มารวมกัน ค่ามัธยฐานของแชทและอีเมลนั้นแตกต่างกันโดยธรรมชาติของการออกแบบ และการนำมารวมกันจะบดบังข้อเท็จจริงของทั้งสองช่องทาง

การรายงานเวลาแก้ไขปัญหาโดยไม่ได้ระบุว่าเป็นแบบใด เวลาแก้ไขปัญหาครั้งแรก (First resolution time) และเวลาแก้ไขปัญหาสมบูรณ์ (Full resolution time) เป็นตัวชี้วัดที่จัดเก็บแยกกัน ไม่ใช่แค่ความแตกต่างจากการปัดเศษตัวเลข

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

การละเลย ticket ที่ไม่มีการตอบกลับ สิ่งนี้ถูกนิยามว่าเป็น ticket ที่มีการตอบกลับจาก agent น้อยกว่า 1 ครั้ง และเป็นความล้มเหลวที่ชัดเจนที่สุดที่รายงานสามารถแสดงให้เห็นได้

บทสรุป

ระบุนิยามการตอบกลับ, ระบุนาฬิกาที่ใช้, เลือกการแก้ไขปัญหาแบบครั้งแรกหรือแบบสมบูรณ์, กำหนดกฎสถานะ, แบ่งกลุ่มตามช่องทาง และแสดงข้อมูลการเปิดซ้ำและ ticket ที่ไม่มีการตอบกลับ สิ่งเหล่านี้จะช่วยสร้างรายงาน support ticket ที่สามารถนำไปใช้งานจริงได้

สิ่งที่รายงานนี้อาจทำไม่ได้คือการนำไปเปรียบเทียบกับตัวเลขของบริษัทอื่นได้อย่างชัดเจน เนื่องจากนิยามต่างๆ สามารถกำหนดค่าได้ ดังนั้นเกณฑ์มาตรฐาน (Benchmark) ที่คุณอ่านจากที่ไหนสักแห่งเกือบจะแน่นอนว่าถูกวัดด้วยกฎเกณฑ์ที่แตกต่างกัน

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

หากการสร้างรายงานนี้ใหม่ในทุกๆ เดือนทำให้คุณต้องเสียเวลาไปทั้งวัน ลองใช้งาน Powerdrill Bloom กับข้อมูล ticket ที่ส่งออกของคุณดูสิ นอกจากนี้คุณยังสามารถดูหน้า เครื่องมือสร้างรายงานด้วย AI และ เครื่องมือสรุปความคิดเห็นของลูกค้า (voice of customer) ได้อีกด้วย

คำถามที่พบบ่อย

ทำไมการบรรลุเป้าหมาย SLA ของฉันจึงไม่ตรงกับเวลาตอบกลับครั้งแรก?

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

ฉันควรรายงานเวลาแก้ไขปัญหาครั้งแรก (First resolution time) หรือเวลาแก้ไขปัญหาสมบูรณ์ (Full resolution time)?

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

ตัวชี้วัดการสนับสนุนวัดเป็นเวลาตามปฏิทินหรือเวลาทำการ?

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

ทำไมยอดนับจำนวนตั๋วที่แก้ไขได้ของไตรมาสที่แล้วจึงเปลี่ยนไป?

ยอดนับจำนวนที่แก้ไขได้จะรวมเฉพาะ ticket ที่ปัจจุบันมีสถานะเป็นแก้ไขแล้วหรือปิดงานแล้วเท่านั้น ticket ที่ถูกเปิดซ้ำหลังจากสิ้นสุดรอบระยะเวลาจะหลุดออกจากยอดนับของรอบระยะเวลานั้น

ฉันสามารถเปรียบเทียบเวลาแก้ไขปัญหาของฉันกับเกณฑ์มาตรฐานของอุตสาหกรรมได้หรือไม่?

ได้เพียงคร่าวๆ เท่านั้น เนื่องจากนิยาม นาฬิกาที่ใช้ และสัดส่วนของช่องทางต่างๆ ล้วนสามารถกำหนดค่าได้ ดังนั้นตัวเลขที่มีการเผยแพร่จึงน่าจะถูกวัดด้วยกฎเกณฑ์ที่แตกต่างจากของคุณ