ฟอร์มติดต่อไม่จำเป็นต้องเก็บทุกอย่างที่ทีมอาจอยากรู้ เป้าหมายแรกคือให้ลูกค้าอธิบายเรื่องที่ต้องการและฝากช่องทางที่ติดต่อกลับได้ ส่วนรายละเอียดที่ต้องคุยร่วมกันสามารถเก็บในขั้นถัดไป
เริ่มจากถามทีมว่า เมื่อได้รับคำขอหนึ่งรายการ ต้องรู้อะไรจึงจะส่งต่อถูกคนและเริ่มตอบได้ หากข้อมูลบางช่องไม่มีใครใช้ตัดสินใจจริง ควรทบทวนก่อนบังคับให้ทุกคนกรอก
ออกแบบจากบทสนทนาแรก ไม่ใช่จากทุกช่องในฐานข้อมูล
ลองใช้สถานการณ์สมมติของธุรกิจที่รับทำระบบ ลูกค้ายังไม่รู้ชื่อเทคโนโลยี แต่รู้ว่าทีมต้องคัดลอกคำสั่งซื้อจากแชททุกวัน คำถามว่า “อยากปรับปรุงงานส่วนไหน” เปิดให้เล่าโจทย์ได้ดีกว่าการบังคับเลือกเทคโนโลยีที่ยังไม่เข้าใจ
ชุดข้อมูลเริ่มต้นอาจมีชื่อผู้ติดต่อ ช่องทางติดต่อกลับ และคำอธิบายงาน ส่วนชื่อธุรกิจ เว็บไซต์เดิม หรืองบประมาณจะบังคับหรือไม่ ขึ้นกับว่าทีมจำเป็นต้องใช้ตั้งแต่ขั้นนี้จริงหรือไม่ ไม่มีจำนวนช่องที่เหมาะกับทุกธุรกิจ
หากถามงบประมาณหรือช่วงเริ่มงาน ควรเปิดทางให้ตอบว่ายังไม่กำหนดเมื่อธุรกิจรับคุยโจทย์ลักษณะนั้นได้ การบังคับเลือกค่าที่ไม่ตรงอาจได้ข้อมูลครบช่อง แต่ทำให้ทีมเข้าใจความพร้อมผิด
เขียนคำอธิบายใกล้คำถามที่คนอาจสงสัย เช่น “เล่างานที่ทำอยู่และสิ่งที่อยากปรับ ไม่ต้องระบุชื่อระบบ” ช่วยลดความรู้สึกว่าต้องเตรียมข้อกำหนดครบก่อนติดต่อ
บอกให้ชัดว่าต้องกรอกอะไร และแก้อย่างไร
ชื่อช่องควรมองเห็นได้แม้เริ่มพิมพ์แล้ว ไม่ฝากความหมายไว้เฉพาะข้อความตัวอย่างที่หายไปในช่อง แนวทางคำแนะนำในฟอร์มของ W3C อธิบายการระบุช่องจำเป็น รูปแบบข้อมูล และข้อจำกัดของข้อความตัวอย่างที่หายเมื่อผู้ใช้กรอก
ข้อความแจ้งปัญหาต้องช่วยให้ทำต่อได้ ลองเปรียบเทียบ “ข้อมูลไม่ถูกต้อง” กับ “ตรวจอีเมลอีกครั้ง เช่น name@example.com” อย่างหลังระบุทั้งจุดและวิธีแก้โดยไม่กล่าวโทษผู้กรอก แต่ต้องใช้เมื่อปัญหาเป็นรูปแบบอีเมลจริง ไม่ใช่ระบบปลายทางขัดข้อง
หากมีหลายจุดผิด ให้เห็นรายการที่ต้องแก้และไปยังช่องนั้นได้ ไม่ใช้เพียงกรอบสีแดง แนวทางแจ้งผลของ W3C แนะนำให้ข้อผิดพลาดอ้างถึงช่องที่เกี่ยวข้องและอธิบายวิธีแก้ด้วยภาษาที่เข้าใจได้
อย่าล้างข้อความยาวที่กรอกไว้เมื่อส่งไม่ผ่าน แยกข้อมูลที่ต้องแก้ออกจากข้อมูลที่ถูกต้องแล้ว และให้ผู้ใช้ลองส่งใหม่ได้โดยไม่ต้องเริ่มต้นทั้งหมด
ตรวจบนมือถือด้วยงานจริงหนึ่งเรื่อง
ให้คนทดลองอ่านหน้าบริการ เปิดฟอร์ม กรอกข้อความ และส่งด้วยโทรศัพท์ สังเกตว่าคีย์บอร์ดบังคำอธิบายหรือปุ่มหรือไม่ ช่องที่ต้องกรอกใช้รูปแบบป้อนข้อมูลเหมาะสมหรือไม่ และเปลี่ยนช่องได้สะดวกเพียงใด
ทดสอบด้วยคีย์บอร์ดและเครื่องมือช่วยอ่านด้วย ไม่ควรมีขั้นตอนที่ทำได้เฉพาะการแตะตำแหน่งหนึ่งโดยไม่มีชื่อให้เข้าใจ การตรวจนี้ควรครอบคลุมข้อความแจ้งข้อผิดพลาด ไม่ใช่เฉพาะแบบฟอร์มที่ยังว่าง
ถ้าต้องแนบไฟล์ บอกประเภทและขนาดที่รับก่อนเลือกไฟล์ พร้อมแสดงชื่อไฟล์ที่แนบและวิธีนำออก หลีกเลี่ยงการขอเอกสารที่มีข้อมูลสำคัญเกินความจำเป็นในการเริ่มคุย และอธิบายวัตถุประสงค์การใช้ข้อมูลให้ตรงกับงานจริง
“กำลังส่ง” กับ “รับเรื่องแล้ว” ต้องเป็นคนละสถานะ
เมื่อกดปุ่ม ให้แสดงว่ากำลังส่งและป้องกันการส่งซ้ำโดยไม่ตั้งใจ แต่ไม่ควรแสดงว่ารับเรื่องแล้วเพียงเพราะปุ่มถูกกด คำยืนยันต้องสัมพันธ์กับผลที่ระบบตรวจได้
หากระบบรับเรื่องสำเร็จแต่การแจ้งเตือนทีมมีปัญหา คำขอนั้นควรยังค้นหาและติดตามได้ กำหนดผู้รับผิดชอบตรวจรายการค้าง แทนการถือว่าอีเมลแจ้งเตือนคือหลักฐานเดียวว่ามีผู้ติดต่อ
ข้อความหลังส่งควรบอกขั้นต่อไปตามที่ทีมทำได้จริง เช่น จะติดต่อผ่านช่องทางที่ให้ไว้ หากยังไม่มีเวลาตอบกลับที่ตกลงและดูแลได้ ไม่ควรใส่คำรับรองเวลาเพื่อให้หน้าดูสมบูรณ์
ตรวจรับด้วยคำขอหนึ่งรายการตั้งแต่ต้นจนจบ
ใช้ข้อมูลทดสอบที่ไม่ใช่ข้อมูลลูกค้าจริง ส่งจากแต่ละภาษา แล้วตรวจว่ารายละเอียดครบ ภาษาไม่เพี้ยน ผู้รับถูกคน และรู้ว่าลูกค้าต้องการอะไร ตรวจกรณีอีเมลผิด เครือข่ายขาด และกดส่งซ้ำด้วย
คนรับเรื่องควรรู้ว่าต้องตอบเองหรือส่งต่อใคร รวมถึงมีวิธีปิดรายการที่จัดการแล้ว ฟอร์มที่กรอกง่ายแต่ไม่มีคนรับผิดชอบต่อยังไม่แก้ปัญหาการติดต่อของธุรกิจ
ถ้ายังเลือกหน้าปลายทางอยู่ อ่านเรื่อง Landing Page กับเว็บไซต์บริษัท ส่วนงานหลังรับเรื่องสามารถต่อยอดจากการส่งต่องานขายให้ทีมปฏิบัติการ เพื่อให้ข้อมูลจากหน้าจอกลายเป็นงานที่ทีมทำต่อได้
ฟอร์มมีคนกรอก แต่ทีมยังต้องถามใหม่ทุกครั้ง?
Talvyn Labs ช่วยออกแบบคำถามและเส้นทางรับเรื่อง ตั้งแต่หน้าฟอร์มบนมือถือจนถึงข้อมูลที่ทีมใช้เริ่มงาน พร้อมทดสอบกรณีส่งไม่สำเร็จ
ปรับฟอร์มให้ลูกค้าและทีมใช้ง่าย