28 มิ.ย. 2569·อ่าน 2 นาที

ตัวติดตาม SLA: สร้างกำหนดเวลา การหยุดเวลา และรายงานทีม

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

ตัวติดตาม SLA: สร้างกำหนดเวลา การหยุดเวลา และรายงานทีม

ทำไมทีมฝ่ายปฏิบัติการลูกค้าจึงติดตามกำหนดเวลา SLA ไม่ทัน

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

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

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

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

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

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

กำหนดข้อมูลที่ระเบียน SLA แต่ละรายการต้องมี

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

จากนั้นเพิ่มฟิลด์ที่ควบคุมกำหนดเวลา:

  • นโยบาย SLA เช่น «การสนับสนุนมาตรฐาน» หรือ «การสนับสนุนเร่งด่วน»
  • เวลาเริ่มต้น
  • เวลาครบกำหนดของการตอบกลับครั้งแรกและการแก้ไข
  • เหตุผลที่หยุดเวลาและเวลาเริ่มหยุด
  • เวลาเริ่มต่อหรือตัวเลขระยะเวลาที่หยุดรวม

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

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

AppMaster ช่วยรวมตรรกะนี้ไว้ในที่เดียว Data Designer ใช้ออกแบบฟิลด์ทิกเก็ต ส่วน Business Process แบบภาพใช้คำนวณกำหนดเวลาและสถานะการผิด SLA ทุกครั้งที่เจ้าหน้าที่สร้างหรืออัปเดตทิกเก็ต

กำหนดกฎ SLA ก่อนสร้างตัวติดตาม

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

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

เขียนกฎแต่ละข้อด้วยภาษาที่เข้าใจง่าย «ปัญหาการเรียกเก็บเงินระดับสูงของลูกค้าพรีเมียมต้องได้รับการตอบกลับภายในสองชั่วโมงทำการ» บอกได้ทันทีว่าต้องเก็บข้อมูลอะไรบ้าง ได้แก่ ระดับความสำคัญ แผน ประเภทคำขอ เวลาที่สร้าง และเวลาตอบกลับครั้งแรก

กำหนดปฏิทินการทำงาน

ตัดสินใจว่าเป้าหมายจะเดินตลอด 24 ชั่วโมงหรือเฉพาะเวลาสนับสนุน หากทีมสนับสนุนทำงานวันจันทร์ถึงศุกร์ เวลา 9:00 ถึง 17:00 ทิกเก็ตที่ได้รับวันศุกร์เวลา 16:30 และมีเป้าหมายสองชั่วโมงควรครบกำหนดวันจันทร์เวลา 10:30 ไม่ใช่เย็นวันศุกร์

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

กำหนดจุดเริ่มต้นและผู้ดูแลนโยบาย

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

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

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

วางโครงสร้างข้อมูลเบื้องหลังตัวติดตาม

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

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

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

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

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

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

คำนวณกำหนดเวลาของทิกเก็ต

เริ่มจากเวิร์กโฟลว์เดียว
เปลี่ยนประเภททิกเก็ตและนโยบาย SLA แรกของคุณให้เป็นแอปแบบไม่ต้องเขียนโค้ดที่ใช้งานได้จริง
เริ่มจากเวิร์กโฟลว์เดียว

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

จากนั้นเลือกนโยบาย SLA ที่ตรงกับแผนลูกค้า ประเภททิกเก็ต ระดับความสำคัญ หรือภูมิภาค แล้วคำนวณกำหนดเวลา:

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

ชั่วโมงทำการทำให้เรื่องนี้ซับซ้อนกว่าที่ฟังดู หาก SLA สี่ชั่วโมงเริ่มเวลา 16:00 และทีมสนับสนุนทำงานถึง 17:00 ทิกเก็ตจะมีเวลาเหลือหนึ่งชั่วโมงในวันนั้น กำหนดเวลาจึงเป็นเที่ยงวันของวันทำการถัดไป ไม่ใช่ 20:00 น.

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

แสดงทั้งกำหนดเวลาที่แน่นอนและเวลาที่เหลือ ป้ายกำกับอย่าง «เหลือ 2 ชม. 15 นาที» «ครบกำหนดใน 1 วัน» และ «เกินกำหนด 35 นาที» ช่วยให้เจ้าหน้าที่กวาดดูคิวได้เร็วกว่าการดูเวลา ใช้สถานะกลางสำหรับทิกเก็ตที่ยังอยู่ในเกณฑ์ สถานะเตือนเมื่อใกล้ถึงกำหนด และสถานะผิด SLA ที่ชัดเจนเมื่อเลยกำหนด

หยุดตัวจับเวลาเมื่อรอลูกค้าตอบกลับ

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

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

ใช้สถานะสั้นๆ และชัดเจน:

  • รอข้อมูลจากลูกค้า
  • รอการอนุมัติจากลูกค้า
  • รอสิทธิ์เข้าถึงจากลูกค้า
  • รอไฟล์จากลูกค้า

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

เมื่อลูกค้าตอบกลับ ให้เริ่มตัวจับเวลาต่อจากเวลาที่ตอบกลับ บวกช่วงเวลาที่รอเข้าไปใน total paused time แล้วคำนวณเวลาที่เหลือใหม่ตามกฎชั่วโมงทำการ การรอลูกค้า 90 นาทีจะเลื่อนกำหนดเวลาออกไป 90 นาที โดยขึ้นอยู่กับช่วงปิดทำการ

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

จำกัดเหตุผลการหยุดเวลาให้เหลือเฉพาะที่นโยบาย SLA อนุญาต กำหนดให้มีเหตุการณ์การขอข้อมูลจากลูกค้าก่อนยอมรับการหยุดเวลา ใน AppMaster Business Process สามารถตรวจสอบสถานะใหม่ บันทึกเวลาเริ่มหยุด และปฏิเสธการเปลี่ยนแปลงที่ไม่ถูกต้องก่อนอัปเดตระเบียน SLA

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

ดูตัวอย่างการสนับสนุนลูกค้า

ลูกค้าส่งคำถามเรื่องใบแจ้งหนี้เวลา 10:00 น. วันอังคารว่า «ทำไมใบแจ้งหนี้ของฉันจึงแสดงรายการเรียกเก็บเงินสองรายการ» ตัวติดตามสร้างทิกเก็ต B-184 มอบหมายให้ Support และใช้นโยบาย SLA ด้านการเรียกเก็บเงิน ทีมมีเวลาสี่ชั่วโมงทำการสำหรับการตอบกลับที่เป็นประโยชน์ครั้งแรก และแปดชั่วโมงทำการสำหรับการแก้ไข

Support ทำงานเวลา 9:00 ถึง 17:00 วันจันทร์ถึงศุกร์ เวลา 10:35 น. เจ้าหน้าที่ยืนยันว่าทีมกำลังตรวจสอบบัญชี ตัวจับเวลาการตอบกลับครั้งแรกหยุดที่ 35 นาที เหลือเวลา 3 ชั่วโมง 25 นาที ทิกเก็ตจึงผ่านเป้าหมายการตอบกลับครั้งแรก

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

ลูกค้าตอบกลับเวลา 15:30 น. ตัวติดตามบวกเวลาที่หยุด 4 ชั่วโมง 30 นาทีคืนเข้ากับกำหนดเวลาเดิม กำหนดเวลาแก้ไขเดิมคือ 18:00 น. วันอังคาร กำหนดเวลาที่ปรับแล้วจึงเป็น 14:30 น. วันพุธ หลังจากนำเวลาที่เหลือไปต่อในวันทำการถัดไป

เจ้าหน้าที่แก้ไขปัญหาเวลา 15:10 น. วันพุธ ทิกเก็ตจึงล่าช้า 40 นาที นับเป็นการแก้ไขเกินกำหนดหนึ่งครั้งของ Support ขณะที่การตอบกลับครั้งแรกยังตรงเวลา

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

รายงานการผิด SLA แยกตามทีม

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

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

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

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

ใช้จำนวนควบคู่กับอัตรา:

  • ทิกเก็ตทั้งหมดที่มี SLA ทำงานอยู่
  • ทิกเก็ตที่แก้ไขได้ภายในเป้าหมาย
  • ทิกเก็ตที่ยังเปิดและเกินกำหนด
  • ทิกเก็ตที่แก้ไขหลังพ้นกำหนด
  • อัตราการผิด SLA คำนวณจากจำนวนทิกเก็ตที่ผิด SLA หารด้วยทิกเก็ตที่มี SLA

อัตราการผิด SLA 50% มีความหมายต่างกัน หากมาจากทิกเก็ตล่าช้าหนึ่งใบจากสองใบ เทียบกับทิกเก็ตล่าช้า 50 ใบจาก 100 ใบ ควรดูแนวโน้มควบคู่กับรายละเอียดทิกเก็ต การผิด SLA ของทิกเก็ตระดับสูงบ่อยๆ อาจชี้ไปที่กฎการยกระดับหรือการส่งต่องาน ไม่ใช่ปริมาณงานโดยรวม

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

สร้างมุมมองสำหรับเจ้าหน้าที่และผู้จัดการ

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

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

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

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

เก็บประวัติการตรวจสอบสำหรับการเปลี่ยนนโยบาย หากฝ่ายปฏิบัติการเปลี่ยนเป้าหมายจากแปดชั่วโมงเป็น 12 ชั่วโมง ให้บันทึกว่าใครเปลี่ยน เมื่อใด และทิกเก็ตใหม่ใดใช้กฎนี้ ผลลัพธ์ในอดีตควรคงกฎที่มีผลเมื่อทิกเก็ตแต่ละใบเริ่มต้น

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

ข้อผิดพลาดที่ทำให้ผลลัพธ์ SLA คลาดเคลื่อน

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

กราฟที่ดูสะอาดก็ยังเล่าเรื่องผิดได้ หากกฎเบื้องหลังไม่ถูกต้อง

อย่าตีความกฎเวลาแบบตรงตัวเกินไป

อย่าคำนวณด้วยชั่วโมงตามปฏิทินเมื่อข้อตกลงรับประกันชั่วโมงทำการ ทิกเก็ตที่เปิดเวลา 16:30 น. วันศุกร์และมีเป้าหมายตอบกลับแปดชั่วโมงทำการจะไม่ผิด SLA เวลา 00:30 น. วันเสาร์ ให้นับเฉพาะชั่วโมงทำการและวันหยุดที่กำหนดในนโยบาย

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

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

นับความเป็นเจ้าของเพียงครั้งเดียว

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

กำหนดให้มีเวลาที่แก้ไขก่อนปิดทิกเก็ต สถานะปิดไม่ได้พิสูจน์ว่างานเสร็จเมื่อใด ตัวอย่างเช่น หากทิกเก็ตย้ายจาก Support ไป Billing เวลา 14:00 น. และผิด SLA เวลา 15:00 น. Billing จะเป็นผู้รับผิดชอบการผิด SLA ตามกฎผู้รับผิดชอบเมื่อเกิดการผิด SLA รายงานยังแสดงการส่งต่องานก่อนหน้าจาก Support ได้ โดยไม่นับการผิด SLA เพิ่มอีกครั้ง

ตรวจสอบตัวติดตามก่อนเปิดใช้งาน

เห็นงาน SLA ได้ชัดเจน
สร้างแดชบอร์ดแยกสำหรับเจ้าหน้าที่สนับสนุนและผู้จัดการฝ่ายปฏิบัติการ
เริ่มใช้ฟรี

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

ทดสอบช่วงเวลาที่ซับซ้อน ไม่ใช่เฉพาะกรณีปกติ:

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

เปรียบเทียบยอดรวมบนแดชบอร์ดกับรายการทิกเก็ตที่อยู่เบื้องหลัง หากรายงานบอกว่า Team A มีการผิด SLA 12 ครั้ง ให้กรองระเบียนแล้วนับ ตรวจสอบนี้ช่วยจับทิกเก็ตซ้ำ การขาดทีมที่รับผิดชอบ และทิกเก็ตที่เปิดใหม่แล้วถูกนับสองครั้ง

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

เริ่มเล็กๆ แล้วปรับปรุงเวิร์กโฟลว์

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

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

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

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

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

ทำไมจึงควรติดตามการตอบกลับครั้งแรกและการแก้ไขแยกกัน

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

ตัวจับเวลา SLA ควรเริ่มเมื่อใด

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

จะคำนวณกำหนดเวลา SLA ในช่วงเวลาทำการอย่างไร

นับเฉพาะชั่วโมงสนับสนุนที่ระบุไว้ในนโยบาย ตัวอย่างเช่น หากทีมสนับสนุนปิดเวลา 17:00 และเป้าหมายสองชั่วโมงเริ่มตอน 16:30 อีก 90 นาทีที่เหลือจะเลื่อนไปยังวันทำการถัดไป

ทีมควรหยุดตัวจับเวลา SLA เมื่อใด

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

จะเกิดอะไรขึ้นเมื่อลูกค้าตอบกลับทิกเก็ตที่หยุดเวลา

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

ทีมใดเป็นผู้รับผิดชอบการผิด SLA หลังโอนทิกเก็ต

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

เจ้าหน้าที่ควรเห็นอะไรในตัวติดตาม SLA

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

ผู้จัดการควรรายงานตัวชี้วัด SLA ใดบ้าง

แยกทิกเก็ตที่ยังเปิดและเกินกำหนดออกจากทิกเก็ตที่ปิดล่าช้า รายงานจำนวนทิกเก็ตที่อยู่ภายใต้ SLA จำนวนที่แก้ไขทันเวลา ทิกเก็ตที่ยังเปิดและเกินกำหนด ทิกเก็ตที่แก้ไขล่าช้า และอัตราการผิด SLA จากนั้นให้ผู้จัดการเปิดดูระเบียนทิกเก็ตต้นทางได้

ควรทดสอบตัวติดตาม SLA ก่อนเปิดใช้งานอย่างไร

ทดสอบทิกเก็ตที่สร้างใกล้เวลาปิดทำการ ก่อนวันหยุดสุดสัปดาห์และวันหยุดนักขัตฤกษ์ หลังรอลูกค้า และระหว่างการโอนทิกเก็ต นอกจากนี้ให้ปิดทิกเก็ตหลังพ้นกำหนด แล้วตรวจสอบว่าระบบบันทึกการผิด SLA หนึ่งครั้งภายใต้นโยบายที่ถูกต้อง

สร้างตัวติดตาม SLA โดยไม่เขียนโค้ดได้หรือไม่

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

ง่ายต่อการเริ่มต้น
สร้างบางสิ่งที่ น่าทึ่ง

ทดลองกับ AppMaster ด้วยแผนฟรี
เมื่อคุณพร้อม คุณสามารถเลือกการสมัครที่เหมาะสมได้

เริ่ม