กฎตรวจสอบข้อมูลสำหรับฟอร์มธุรกิจที่ช่วยลดงานแก้ไขซ้ำ

ทำไมฟอร์มธุรกิจถึงทำให้ต้องแก้งานซ้ำ

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

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

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

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

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

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

เริ่มจากข้อมูลที่ผู้ใช้ต้องการจริง

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

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

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

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

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

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

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

กำหนดฟิลด์ที่จำเป็นอย่างเหมาะสม

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

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

แสดงให้เห็นว่าฟิลด์ใดจำเป็นก่อนที่ผู้ใช้จะกดส่ง ใช้ป้ายกำกับที่ชัดเจน เช่น «อีเมล (จำเป็น)» และใช้รูปแบบเดียวกันตลอดฟอร์ม อย่าพึ่งสีเพียงอย่างเดียว

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

• «อีเมลที่ทำงาน (จำเป็น): [email protected]»
• «หมายเลขคำสั่งซื้อ (จำเป็น): ใช้หมายเลข 8 หลักจากใบเสร็จ»
• «วันที่สะดวกให้ติดต่อ (จำเป็น): เลือกวันที่ในอนาคต»

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

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

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

เพิ่มการตรวจสอบข้ามฟิลด์เพื่อจับข้อมูลขัดแย้ง

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

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

กฎการใช้จ่ายก็ต้องตรวจสอบแบบเดียวกัน หากพนักงานขอซื้อของมูลค่า $2,500 ขณะที่วงเงินปกติคือ $1,000 ฟอร์มอาจกำหนดให้ระบุเหตุผลทางธุรกิจและผู้ติดต่อเพื่ออนุมัติ แสดงฟิลด์เหล่านี้ทันทีเมื่อจำนวนเงินเกินวงเงิน แทนที่จะรอจนส่งฟอร์มแล้ว

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

กฎตรวจสอบข้ามฟิลด์ที่ใช้ได้จริง ได้แก่

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

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

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

หยุดข้อมูลซ้ำก่อนจะกระจายไปทั่วระบบ

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

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

ตรวจสอบรายการใหม่กับข้อมูลที่มีอยู่ก่อนบันทึก การจับคู่แบบตรงตัวเหมาะกับหมายเลขใบแจ้งหนี้ รหัสคำสั่งซื้อ และรหัสพนักงาน ส่วนชื่อและที่อยู่ควรใช้การเปรียบเทียบที่ยืดหยุ่นกว่า เพราะผู้ใช้อาจกรอกต่างรูปแบบ «Maya Chen» และ «Maya C. Chen» อาจเป็นคนเดียวกัน แต่ฟอร์มไม่ควรสรุปเองว่าต้องเป็นเช่นนั้น

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

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

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

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

เขียนข้อความแก้ไขที่ผู้ใช้ทำตามได้

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

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

ใช้ภาษาธรรมดาที่บอกการกระทำถัดไป รหัสภายในอย่าง «ERR-104» อาจมีประโยชน์ต่อนักพัฒนา แต่ไม่ช่วยเจ้าหน้าที่ฝ่ายขายที่กำลังกรอกคำขอลูกค้า

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

ข้อความที่ดีอธิบายปัญหาโดยไม่กล่าวโทษผู้ใช้ «เราไม่สามารถบันทึกคำขอของคุณได้ เพราะหมายเลขบัญชีต้องมี 8 หลัก» ชัดเจนกว่า «คุณกรอกหมายเลขบัญชีไม่ถูกต้อง»

เก็บข้อมูลที่กรอกถูกต้องไว้เมื่อพบข้อผิดพลาด ผู้ที่กรอกไปแล้ว 14 ฟิลด์ควรแก้เฉพาะฟิลด์ที่มีปัญหา การล้างทั้งหน้าหลังตรวจพบข้อผิดพลาดเปลี่ยนการแก้ไข 20 วินาทีให้กลายเป็นงานที่ต้องกรอกซ้ำ

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

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

สร้างกฎตรวจสอบทีละขั้นตอน

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

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

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

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

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

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

ข้อผิดพลาดที่ทำให้ผู้ใช้หงุดหงิด

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

บังคับให้ทุกฟิลด์ต้องกรอก

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

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

หยุดผู้ใช้โดยไม่บอกวิธีแก้

ข้อความอย่าง «ข้อมูลไม่ถูกต้อง» บอกเพียงว่ามีบางอย่างผิดพลาด แต่ไม่บอกว่าต้องทำอะไรต่อ วางข้อความไว้ข้างฟิลด์ ระบุปัญหาให้ชัด และอธิบายรูปแบบที่ยอมรับ

เขียนว่า «กรอกอีเมลที่ทำงาน เช่น [email protected]» แทน «อีเมลผิด» หากวันที่สิ้นสุดมาก่อนวันที่เริ่มต้น ให้เขียนว่า «เลือกวันที่สิ้นสุดให้เป็นวันเดียวกันหรือหลังวันที่เริ่มต้น» คำแนะนำเหล่านี้ช่วยลดการลองซ้ำและคำขอความช่วยเหลือ

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

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

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

ตรวจสอบให้พร้อมก่อนเผยแพร่

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

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

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

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

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

หากสร้างฟอร์มใน AppMaster ให้ทดสอบอินเทอร์เฟซเว็บหรือมือถือ กระบวนการธุรกิจที่รับการส่งข้อมูล และรายการในฐานข้อมูลที่สร้างขึ้นตอนท้าย กฎที่ทำงานได้บนหน้าจอเดียวจะไม่ป้องกันข้อมูลเสียจากการนำเข้าหรือจากหน้าจออื่นของแอป

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

ตัวอย่าง: ฟอร์มคำขอลูกค้า

เจ้าหน้าที่ประสานงานฝ่ายขายรับสายจาก Northline Foods บริษัทที่ต้องการใบเสนอราคาบริการ เธอเปิดฟอร์มคำขอลูกค้าแล้วกรอกชื่อบริษัท ชื่อผู้ติดต่อ บริการที่ต้องการ วันที่จัดส่ง และคำอธิบายสั้นๆ

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

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

ก่อนสร้างข้อมูลลูกค้า การตรวจจับข้อมูลซ้ำจะเปรียบเทียบชื่อบริษัท โดเมนอีเมล และเบอร์โทรกับข้อมูลเดิม พบ «Northline Food Ltd» ที่ใช้เบอร์โทรหลักเดียวกัน ฟอร์มแสดงข้อมูลลูกค้าเดิมและให้เจ้าหน้าที่เลือกเปิดรายการนั้นเพื่อเพิ่มคำขอ หรือยืนยันว่าเป็นลูกค้ารายใหม่ที่มีนิติบุคคลหรือเบอร์ติดต่อแตกต่างกัน

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

นำการตรวจสอบที่ดีขึ้นมาใช้กับฟอร์มถัดไป

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

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

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

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

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

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

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