รวบรวมอาการก่อนสรุปสาเหตุ
เริ่ม Node แรกด้วยสิ่งที่ผู้ใช้เห็น เช่น เข้าสู่ระบบไม่ได้ หน้าโหลดค้าง หรือไม่พบรายการ หลีกเลี่ยงการตั้งชื่อว่า Database Error ถ้ายังไม่มีหลักฐาน เพราะจะทำให้คำถามถัดไปพยายามยืนยันข้อสรุปเดิม
บันทึกเวลา ขอบเขตผู้ได้รับผลกระทบ อุปกรณ์ เวอร์ชัน และเลขอ้างอิงที่ไม่เปิดเผยข้อมูลส่วนตัว ข้อมูลเหล่านี้ช่วยแยกเหตุการณ์รายคนออกจากปัญหาระบบ
จัดลำดับการตรวจจากปลอดภัยและต้นทุนต่ำ
ถามข้อมูลที่ผู้ใช้ตอบได้ก่อน เช่น กระทบหลายคนหรือไม่ แล้วตรวจสถานะบริการและการตั้งค่าที่ไม่เปลี่ยนข้อมูล ก่อนเสนอการล้างข้อมูลหรือการกระทำที่ย้อนกลับยาก
แต่ละ Step ต้องมีผลที่คาดและคำถามถัดไป ถ้าให้ลองออกแล้วเข้าใหม่ ต้องบอกว่าควรเห็นอะไร และเมื่อไม่เห็นให้ไปทางไหน ไม่ใช้คำว่า ลองอีกครั้ง ซ้ำโดยไม่มีข้อมูลใหม่
- ยืนยันอาการ
- ตรวจขอบเขต
- ตรวจสถานะและ Dependency
- ทดลองวิธีที่ย้อนกลับได้
- ยืนยันผลหรือ Escalate
กำหนดสัญญาการส่งต่อ
ปลายทาง Escalate ควรระบุทีมรับ เหตุผล ระดับผลกระทบ หลักฐาน และสิ่งที่ลองแล้ว Support ไม่ควรส่งรหัสผ่าน OTP เนื้อหาส่วนตัว หรือ Log ขนาดใหญ่โดยไม่มีการคัดกรอง
แจ้งลูกค้าด้วยเลขอ้างอิงและช่องทางอัปเดตจากระบบจริง หลีกเลี่ยงการสัญญาเวลาที่กระบวนการไม่ได้รองรับ
- อาการและเวลา
- ขอบเขตผลกระทบ
- เลขอ้างอิงที่ปลอดภัย
- ผลการตรวจแต่ละข้อ
- ทีมและเจ้าของถัดไป
ปรับ Tree จาก Ticket ที่ปิดแล้ว
ทบทวน Ticket ที่เดินผิดสาขา ขั้นที่ไม่มีใครใช้ และคำถามที่ผู้ใช้ตอบไม่ได้ แก้คำถามหรือแยก Flow เฉพาะทางแทนการเพิ่มทุกกรณีไว้ต้นไม้เดียว
วัดประโยชน์จากผลจริง เช่น จุดที่ต้อง Escalate และ Feedback ของเจ้าหน้าที่ ไม่สร้างตัวเลขความสำเร็จหากยังไม่มีระบบ Analytics และนิยามที่ตรวจสอบได้