พอร์ทัลลูกค้ามักเริ่มจากเมนูหลายรายการตามโครงสร้างฐานข้อมูล เช่น “แจ้งปัญหา” สำหรับสร้าง ticket และ “สถานะการแจ้ง” สำหรับดูคำตอบ แม้แยกในโค้ดได้ง่าย แต่ผู้ใช้มองว่าสองอย่างนี้เป็นงานเดียวกัน: บอกปัญหา แล้วกลับมาติดตามว่าถึงไหนแล้ว
ในการปรับ Client Portal ของ ParitLAB เรารวมทั้งสองส่วนเป็นโมดูล Support เดียว หน้าแรกของโมดูลแสดงรายการที่เคยส่ง สถานะ วันที่ ผลิตภัณฑ์ที่เกี่ยวข้อง และคำตอบจากผู้ดูแล ปุ่ม “แจ้งปัญหาใหม่” เปิดฟอร์มเป็น overlay จึงไม่พาผู้ใช้ออกจากบริบทของประวัติเดิม
ทำไม overlay จึงเหมาะกับงานนี้
การแจ้งปัญหาเป็นงานสั้นที่เริ่มจากรายการเดิม ผู้ใช้อาจต้องดูชื่อ ticket ก่อนหน้าเพื่อหลีกเลี่ยงการส่งซ้ำ หรือดูว่าปัญหานั้นเคยได้รับคำตอบแล้วหรือยัง overlay ทำให้ปิดฟอร์มแล้วกลับมาที่ตำแหน่งเดิมได้ทันที และลดเมนูที่ทำหน้าที่ซ้ำกัน
อย่างไรก็ตาม overlay ต้องเป็น dialog ที่ใช้งานด้วยคีย์บอร์ดได้ มีชื่อที่โปรแกรมอ่านหน้าจอเข้าใจ ปิดด้วยปุ่มชัดเจน และคืน focus ไปยังปุ่มเปิดเมื่อจบงาน บนจอเล็กเนื้อหาต้องเลื่อนได้โดยไม่ทำให้หน้าด้านหลังขยับตาม
ข้อมูลที่ขอเท่าที่จำเป็น
ฟอร์มของเราให้เลือกซอฟต์แวร์ ระบุหัวข้อ และอธิบายรายละเอียด บัญชีและอีเมลมาจาก session ที่ผ่านการเข้าสู่ระบบอยู่แล้ว จึงไม่ต้องถามซ้ำ คำแนะนำหน้าฟอร์มบอกให้ระบุเวอร์ชัน อุปกรณ์ และขั้นตอนที่ทำให้เกิดปัญหา พร้อมเตือนไม่ให้ส่งรหัสผ่านหรือคีย์ลับ
การขอข้อมูลน้อยช่วยทั้งประสบการณ์และความปลอดภัย ทีมสนับสนุนได้รับข้อมูลที่ใช้ทำซ้ำปัญหา ขณะที่ลูกค้าไม่ต้องวางข้อมูลส่วนตัวเกินความจำเป็นลงในข้อความอิสระ
สถานะต้องแปลเป็นภาษาของผู้ใช้
ฐานข้อมูลใช้สถานะสั้นและคงที่ ได้แก่ new, in_progress และ resolved ส่วนหน้าไทยแสดง “รับเรื่องแล้ว”, “กำลังดำเนินการ” และ “แก้ไขแล้ว” หน้าอังกฤษใช้คำที่สอดคล้องกัน การเก็บค่าระบบแยกจากข้อความหน้าจอช่วยให้เปลี่ยนถ้อยคำหรือเพิ่มภาษาได้โดยไม่แก้ข้อมูลเก่า
คำตอบจากผู้ดูแลแสดงใต้ ticket เดิมพร้อมป้าย PARIT LAB ผู้ใช้จึงรู้ว่าข้อความใดเป็นรายละเอียดที่ตนส่งและข้อความใดเป็นคำตอบจากระบบสนับสนุน โดยไม่ต้องค้นหาอีเมลอีกช่องทางหนึ่ง
สิทธิ์เข้าถึงและความถูกต้องของข้อมูล
ทุก query ฝั่งลูกค้าต้องผูกกับ user ID ใน session ห้ามเชื่อ user ID ที่ส่งมาจาก browser ผู้ดูแลจึงเห็นรายการรวม ส่วนลูกค้าเห็นเฉพาะ ticket ของบัญชีตนเอง การสร้างคำขอใช้ CSRF token และตรวจ project ID ว่าเป็นค่าที่อนุญาตก่อนบันทึก
เมื่อ deploy การออกแบบใหม่ เราแยกการเปลี่ยนหน้าตาออกจากข้อมูล ticket ไม่สร้างตารางทับหรือย้ายข้อมูลโดยไม่จำเป็น ก่อนและหลังติดตั้งจะเปรียบเทียบจำนวนบัญชี ไลเซนส์ คำสั่งซื้อ และรายการแจ้งปัญหา พร้อมสำรองไฟล์บนเซิร์ฟเวอร์ วิธีนี้ไม่ได้พิสูจน์ความถูกต้องทุกฟิลด์ แต่เป็น guardrail ที่จับความผิดพลาดรุนแรงได้เร็ว
สิ่งที่ควรวัดต่อ
- เวลาจากสร้าง ticket ถึงคำตอบแรก
- สัดส่วน ticket ที่ขาดเวอร์ชันหรือขั้นตอนทำซ้ำ
- จำนวน ticket ซ้ำในเรื่องเดียวกัน
- อัตราที่ลูกค้ากลับมาเปิด ticket หลังสถานะ resolved
- ข้อผิดพลาดด้านสิทธิ์หรือการเข้าถึงข้อมูลข้ามบัญชี ซึ่งควรเป็นศูนย์
บทเรียนสำคัญคือเมนูควรสะท้อนงานของผู้ใช้ ไม่ใช่ตารางในฐานข้อมูล เมื่อการส่งปัญหา ประวัติ สถานะ และคำตอบอยู่ในบริบทเดียวกัน ระบบเข้าใจง่ายขึ้น และยังรักษาโครงสร้างข้อมูลที่เรียบง่ายสำหรับผู้ดูแลได้