วิธีสร้างระบบ Helpdesk ticketing: ticket สถานะ การมอบหมาย และอีเมล
ระบบ helpdesk ticketing เปลี่ยนคำขอที่กระจัดกระจาย (อีเมล ข้อความ “คำถามสั้นๆ” ตามทางเดิน) ให้เป็น ticket คือบันทึกหนึ่งรายการต่อปัญหาหนึ่งเรื่อง มีเจ้าของ สถานะ ความสำคัญ และการสนทนาทั้งหมด หากจะสร้างหนึ่งระบบ คุณต้องมีวิธีสร้าง ticket คิวร่วมที่มีตัวกรอง การมอบหมายงาน เธรดที่แยกการตอบกลับสาธารณะออกจากบันทึกภายใน และการแจ้งเตือนเพื่อไม่ให้ใครรอโดยไม่มีคำตอบ เอไอแอปบิลเดอร์สร้างเวอร์ชันแรกที่แข็งแรงสำหรับจุดรับคำขอของ IT ภายใน HR หรือฝ่ายอาคารสถานที่ได้ในหนึ่งบ่าย การซัพพอร์ตลูกค้าพร้อมการจัดเธรดอีเมล เป้าหมายเวลาตอบกลับ และการรายงานต้องใส่ใจมากกว่านั้น และนี่คือที่ที่ผลิตภัณฑ์ helpdesk ที่มีอยู่แล้วคุ้มค่าค่าบริการ
ระบบต้องมีอะไรบ้าง
ข้อมูล
| ตาราง | ฟิลด์หลัก |
|---|---|
| Tickets | หมายเลข, หัวข้อ, ผู้ร้องขอ, หมวดหมู่, ความสำคัญ, สถานะ, ผู้รับผิดชอบ, ทีม, เวลาที่สร้าง, เวลาตอบครั้งแรก, เวลาแก้ไขแล้ว |
| Messages | Ticket, ผู้เขียน, เนื้อหา, การตอบกลับสาธารณะหรือบันทึกภายใน, ไฟล์แนบ, เวลาที่ส่ง |
| Requesters | ชื่อ, อีเมล, องค์กรหรือแผนก |
| Agents | ชื่อ, อีเมล, ทีม, บทบาท (เจ้าหน้าที่ หัวหน้า ผู้ดูแลระบบ) |
| Categories | ชื่อ, ทีมเริ่มต้น, ความสำคัญเริ่มต้น |
| Canned replies | หัวข้อ, เนื้อหา, หมวดหมู่ |
| Activity log | Ticket, ใคร, เปลี่ยนอะไร, เมื่อไหร่ |
บันทึก การประทับเวลาของการตอบครั้งแรกและการแก้ไขแล้ว ตั้งแต่ต้น เพราะรายงานทุกชิ้นสร้างจากข้อมูลนี้ และคุณสร้างย้อนหลังในภายหลังไม่ได้
หน้าต่างๆ
- ผู้ร้องขอ: ฟอร์ม “ส่งคำขอ” พร้อมหมวดหมู่และไฟล์แนบ รายการ “คำขอของฉัน” และเธรดของแต่ละ ticket
- เจ้าหน้าที่: คิว (ticket ของฉัน ยังไม่มอบหมาย เปิดทั้งหมด) ตัวกรองและการค้นหา มุมมอง ticket พร้อมการควบคุมการตอบ บันทึก สถานะ ความสำคัญ และผู้รับผิดชอบ
- ผู้ดูแลระบบ: หมวดหมู่ ทีม เจ้าหน้าที่ ข้อความตอบสำเร็จรูป และรายงานแบบเรียบง่าย
สิทธิ์การเข้าถึง
ผู้ร้องขอเห็นเฉพาะ ticket ของตัวเองและการตอบกลับสาธารณะเท่านั้น เจ้าหน้าที่เห็น ticket ของทีมตัวเองและบันทึกภายใน หัวหน้าและผู้ดูแลระบบเห็นทั้งหมดและจัดการการตั้งค่า การที่บันทึกภายในรั่วไปถึงลูกค้าคือหายนะคลาสสิกของ helpdesk ดังนั้นบังคับใช้ที่เซิร์ฟเวอร์ ไม่ใช่แค่ซ่อนแท็บ ดูการควบคุมการเข้าถึงตามบทบาท
การตัดสินใจและข้อแลกเปลี่ยน
ฟอร์ม อีเมล หรือทั้งสองอย่าง
เว็บฟอร์ม ง่ายที่สุดและให้ข้อมูลที่สะอาด: หมวดหมู่ ความสำคัญ และฟิลด์ที่จำเป็น การรับทางอีเมล ที่คนเขียนถึง support@ แล้ว ticket ก็ปรากฏขึ้นคือสิ่งที่ลูกค้าคาดหวัง แต่ต้องใช้ผู้ให้บริการอีเมลที่รับข้อความและส่งเข้าแอปของคุณได้ รวมถึงการจัดเธรดเพื่อให้การตอบกลับเข้ากับ ticket ที่ถูกต้อง (มักเป็นหมายเลข ticket ในหัวข้อหรือที่อยู่ reply-to ที่ไม่ซ้ำกัน) เริ่มด้วยฟอร์ม และเพิ่มอีเมลเมื่อขั้นตอนการทำงานพิสูจน์แล้วว่าใช้ได้ การส่งอีเมลจากแอปของคุณ ครอบคลุมขาออก
การมอบหมาย
ตัวเลือก: เจ้าหน้าที่เลือกจากคิวที่ยังไม่มอบหมาย การหมุนเวียนแบบ round-robin ภายในทีม หรือมอบหมายตามหมวดหมู่ การเลือกจากคิวใช้ได้ดีกับทีมเล็ก การมอบหมายอัตโนมัติช่วยเมื่อ ticket เริ่มไม่มีเจ้าของ
ความสำคัญและเป้าหมายการตอบกลับ
กำหนดความสำคัญสองหรือสามระดับพร้อมเป้าหมายการตอบครั้งแรก (“ด่วน: 1 ชั่วโมง ปกติ: 1 วันทำการ”) การแสดงเวลาที่เหลือบนแต่ละ ticket มีประโยชน์มากกว่ารายงานรายเดือนที่ไม่มีใครอ่าน เวลาทำการทำให้การคำนวณยากขึ้น ตัดสินใจตั้งแต่ต้นว่าเป้าหมายนับรวมกลางคืนและวันหยุดสุดสัปดาห์หรือไม่
การรวมและ ticket ซ้ำ
ปัญหาเดียวกันที่ถูกรายงานสามครั้งเป็นเรื่องปกติ การกระทำ “รวมเข้ากับ ticket #” ช่วยให้เจ้าหน้าที่ไม่ต้องตอบเรื่องเดิมซ้ำๆ ควรสร้างตั้งแต่เนิ่นๆ
พรอมต์แรกที่ใช้ได้จริง
สร้างระบบ helpdesk ของ IT ภายในสำหรับบริษัทที่มีพนักงาน 60 คน พนักงานส่งคำขอด้วยฟอร์ม: หัวข้อ หมวดหมู่ (ฮาร์ดแวร์ ซอฟต์แวร์ การเข้าถึง เครือข่าย อื่นๆ) ความสำคัญ (ต่ำ ปกติ ด่วน) คำอธิบาย และไฟล์แนบ แต่ละ ticket ได้หมายเลขและสถานะ ใหม่ กำลังดำเนินการ รอผู้ร้องขอ แก้ไขแล้ว ปิดแล้ว เจ้าหน้าที่ IT เห็นคิวที่มีแท็บ ยังไม่มอบหมาย ของฉัน และเปิดทั้งหมด พร้อมตัวกรองตามหมวดหมู่ ความสำคัญ และสถานะ รวมถึงการค้นหา หน้า ticket แสดงเธรดพร้อมการตอบกลับสาธารณะและบันทึกภายในที่แยกออกจากกันอย่างชัดเจน พนักงานไม่เคยเห็นบันทึกภายใน เจ้าหน้าที่มอบหมาย เปลี่ยนสถานะและความสำคัญ ใช้ข้อความตอบสำเร็จรูป และรวม ticket ที่ซ้ำกันได้ ติดตามเวลาตอบครั้งแรกและเวลาแก้ไข และแสดงเวลานับจากการอัปเดตล่าสุดบนแต่ละ ticket พนักงานมีหน้า “คำขอของฉัน” บทบาท: พนักงาน เจ้าหน้าที่ ผู้ดูแลระบบ เก็บทุกอย่างในฐานข้อมูล อินเทอร์เฟซเรียบ กระชับ และรวดเร็ว เน้นความเร็วมากกว่าการตกแต่ง
ขั้นตอนการสร้าง
- โมเดล ticket และฟอร์ม ส่ง แสดงรายการ เปิด ticket และตอบกลับ
- คิวและตัวกรอง ยังไม่มอบหมาย ของฉัน เปิดทั้งหมด กรองและค้นหา เรียงตามความสำคัญและอายุ
- บทบาทและการเข้าสู่ระบบ ผู้ร้องขอ เจ้าหน้าที่ ผู้ดูแลระบบ พร้อมบันทึกที่ซ่อนจากผู้ร้องขอที่เซิร์ฟเวอร์
- การควบคุมการมอบหมาย สถานะ และความสำคัญ พร้อมบันทึกกิจกรรมของทุกการเปลี่ยนแปลง
- การแจ้งเตือน อีเมลถึงผู้ร้องขอเมื่อมีการตอบกลับสาธารณะ และถึงเจ้าหน้าที่เมื่อมีการมอบหมายใหม่ ผ่านผู้ให้บริการอีเมลของคุณเอง
- ข้อความตอบสำเร็จรูปและการรวม
- เป้าหมายการตอบกลับและรายงานพื้นฐาน: ticket ที่เปิดแยกตามอายุ เวลาตอบครั้งแรก และ ticket ต่อหมวดหมู่
- การรับอีเมล เมื่อส่วนอื่นทำงานแล้ว โดยทดสอบการจัดเธรดอย่างละเอียด
- นำร่องกับทีมเดียว เป็นเวลาสองสัปดาห์ก่อนย้ายทุกคนมา
ข้อผิดพลาดที่พบบ่อย
- บันทึกภายในที่ผู้ร้องขอมองเห็นได้ เพราะซ่อนไว้แค่ในอินเทอร์เฟซ
- สถานะและหมวดหมู่มากเกินไป เจ้าหน้าที่จะเลือกตัวแรกที่ดูใกล้เคียง เริ่มด้วยไม่เกินห้าอย่างของแต่ละประเภท
- ไม่มีการประทับเวลาสำหรับการตอบครั้งแรกและการแก้ไข คุณจะอยากได้ตัวเลขในวันที่มีคนถามว่า “เรากำลังเร็วขึ้นหรือเปล่า”
- การตอบอีเมลสร้าง ticket ใหม่ แทนที่จะจัดเธรด ทดสอบการตอบจากแอปอีเมลบนโทรศัพท์ เพราะมักเปลี่ยนหัวข้อ
- ทุกคนถูกมอบหมายแต่ไม่มีใครรับผิดชอบ ใช้ผู้รับผิดชอบหนึ่งคนต่อ ticket และใช้ผู้ติดตามสำหรับคนอื่น
- ไฟล์แนบที่มี URL สาธารณะ ภาพหน้าจอข้อความผิดพลาดมักมีข้อมูลส่วนตัว เก็บไฟล์เป็นส่วนตัวและให้บริการเฉพาะคนที่เห็น ticket นั้นได้
เมื่อผลิตภัณฑ์สำเร็จรูปเป็นทางเลือกที่ดีกว่า
สำหรับการซัพพอร์ตลูกค้าข้ามอีเมล แชต และช่องทางโซเชียล พร้อมการติดตามเป้าหมายการตอบกลับ แบบสำรวจความพึงพอใจ มาโคร การรายงาน และการเชื่อมต่อ ผลิตภัณฑ์ helpdesk เฉพาะทางมักเป็นการลงทุนที่ดีกว่าเกือบเสมอ ผลิตภัณฑ์เหล่านั้นใช้เวลาหลายปีกับการจัดเธรดอีเมล สแปม การจัดเส้นทาง และการรายงาน และนั่นไม่ใช่ส่วนของธุรกิจที่ทำให้คุณแตกต่าง คู่มือทางเลือกแทน Zendesk ของเราเปรียบเทียบตัวเลือกต่างๆ
การสร้างเองเหมาะกับจุดรับคำขอภายใน (คำขอ IT, HR, อาคารสถานที่, การเงิน) เวิร์กโฟลว์เฉพาะทางที่ ticket เป็นงานที่มีขั้นตอนเฉพาะ และทีมที่ต้องการผูกคำขอเข้ากับข้อมูลอื่นที่เก็บอยู่แล้ว นอกจากนี้ยังหลีกเลี่ยงการคิดราคาต่อเจ้าหน้าที่เมื่อคนจำนวนมากจัดการ ticket เป็นครั้งคราว คู่มือเครื่องมือภายใน ครอบคลุมหมวดนี้ในวงกว้างกว่า
การสร้างด้วย Mythex
บน Mythex คุณอธิบาย helpdesk ในแชต ตรวจในพรีวิวสด และเผยแพร่ให้ทีมของคุณ ticket อยู่ในฐานข้อมูล Postgres ที่เอเจนต์เพิ่มเมื่อข้อมูลต้องถูกบันทึก และไฟล์แนบอยู่ในที่เก็บไฟล์ ของโปรเจกต์ การเข้าสู่ระบบสำหรับผู้ร้องขอและเจ้าหน้าที่ และอีเมลทั้งขาเข้าและขาออก ใช้ผู้ให้บริการของคุณเอง เพราะ Mythex ไม่มีผลิตภัณฑ์การเข้าสู่ระบบหรืออีเมลสำหรับผู้ใช้ปลายทางในตัว สูตรส่งอีเมล แสดงแนวทาง เพื่อนร่วมทีมช่วยสร้างได้ผ่านพื้นที่ทำงานร่วมกัน โดยตัว Mythex เองไม่มีค่าธรรมเนียมต่อที่นั่ง
สำหรับพรอมต์เริ่มต้น ลองใช้เทมเพลตคิวคำขอภายใน หรือบั๊กแทรกเกอร์ และจับคู่ helpdesk กับฐานความรู้ เพื่อให้คำถามที่พบบ่อยตอบตัวเองได้
คำถาม
ระบบ ticketing มีฟีเจอร์หลักอะไรบ้าง
วิธีสร้าง ticket (ผ่านฟอร์มหรืออีเมล) คิวร่วมที่มีสถานะและความสำคัญ การมอบหมายให้เจ้าหน้าที่ เธรดการสนทนาที่มีการตอบกลับสาธารณะและบันทึกส่วนตัว และการค้นหา ทุกอย่างอื่น เช่น เป้าหมายเวลาตอบกลับ ข้อความตอบสำเร็จรูป และรายงาน ล้วนสร้างต่อยอดจากฟีเจอร์เหล่านั้น
helpdesk ที่สร้างเองรับ ticket ทางอีเมลได้ไหม
ได้ แต่ต้องใช้ผู้ให้บริการอีเมลที่รับจดหมายได้ และส่งแต่ละข้อความมายังแอปของคุณผ่าน webhook การตอบกลับต้องมีการอ้างอิงถึง ticket เพื่อให้เข้าเธรดของ ticket ที่ถูกต้อง แทนที่จะสร้าง ticket ใหม่
helpdesk ภายในสำหรับ IT หรือ HR ควรสร้างเองหรือซื้อ
จุดรับคำขอภายในเหมาะกับการสร้างเอง เพราะปริมาณงานคาดเดาได้ หมวดหมู่เฉพาะกับบริษัทของคุณ และคุณควบคุมได้ว่าใครเห็นอะไร การซัพพอร์ตลูกค้าที่มีปริมาณมากมักคุ้มค่ากับผลิตภัณฑ์เฉพาะทางมากกว่า
ticket ควรมีสถานะอะไรบ้าง
ให้สั้นไว้: ใหม่ กำลังดำเนินการ รอลูกค้า แก้ไขแล้ว และปิดแล้ว ก็ครอบคลุมทีมส่วนใหญ่ เพิ่ม “พักไว้” ก็ต่อเมื่อคุณต้องรอบุคคลที่สามบ่อยๆ สถานะทุกตัวที่เพิ่มเข้ามาคือสิ่งอีกอย่างที่เจ้าหน้าที่อาจตั้งผิด