ปรับปรุงหน้าชำระเงิน: ออกแบบ checkout ให้คนซื้อจนจบ และลดการทิ้งตะกร้า

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

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

ปรับปรุง checkout: คำตอบสั้น ๆ

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

ทำไมผู้ซื้อทิ้งตะกร้า และข้อไหนที่คุณแก้ได้

แบบสำรวจระยะยาวของ Baymard Institute กับผู้ซื้อออนไลน์ในสหรัฐฯ เมื่อตัดคนที่ “แค่ดูเฉย ๆ” ออกไปแล้ว ยังพบเหตุผลเดิม ๆ ที่ร้านสร้างขึ้นเอง เปอร์เซ็นต์ขยับไปบ้าง แต่รายการแทบไม่เปลี่ยน สังเกตว่า การแก้ไขหลายข้อ อยู่ก่อนขั้นตอนชำระเงินจะเริ่มเสียอีก

หาจุดรั่วของคุณเองก่อน

รายการทั่วไป บอกว่าควรมองหาอะไร ข้อมูลของคุณบอกว่า ต้องมองตรงไหน event อีคอมเมิร์ซที่ GA4 แนะนำ มีทั้ง view_cart, begin_checkout, add_shipping_info, add_payment_info และ purchase และ funnel exploration ที่สร้างจาก event เหล่านี้ แยกตามอุปกรณ์ จะแสดงว่าคนหลุดออกไปตรงไหน ถ้าหลุดมากก่อนเข้าหน้าชำระเงิน แปลว่าปัญหาอยู่ที่ค่าใช้จ่าย หรือความไว้ใจ ถ้าหลุดระหว่างขั้นจัดส่ง กับขั้นชำระเงิน แปลว่าปัญหาอยู่ที่ตัวเลือกการจัดส่ง หรือการชำระเงิน บทความ อัตราคอนเวอร์ชันของร้านค้าออนไลน์ และ การติดตามคอนเวอร์ชันใน GA4 อธิบายเรื่องการวัดผลไว้ จากนั้นลองดูคนสองสามคน ซื้อของบนมือถือของตัวเอง พวกเขาจะเจอสิ่งที่ไม่มีรายงานไหนแสดง

แก้สิ่งที่เกิดก่อนถึงหน้าชำระเงิน

• แสดงยอดรวมตั้งแต่เนิ่น ๆ ใส่ค่าจัดส่ง (หรือช่วงค่าจัดส่ง) และยอดขั้นต่ำสำหรับส่งฟรีถ้ามี ไว้ข้างราคาสินค้า และบอกให้ชัดว่า รวมภาษีและอากรสำหรับผู้ซื้อต่างประเทศแล้วหรือยัง บทความ ออกแบบหน้าสินค้าอีคอมเมิร์ซ อธิบายการแสดงราคาแบบรวมทุกอย่างไว้
• ตอบเรื่องจัดส่งและการคืนสินค้า ในบรรทัดเดียว ไว้ข้างปุ่มชำระเงิน เช่น “ได้รับสินค้าภายในวันพฤหัสบดี คืนสินค้าฟรีภายใน 30 วัน” ถ้าเงื่อนไขของคุณเป็นแบบนั้น และลิงก์ไปยังนโยบายฉบับเต็ม
• ทำให้เห็นว่าร้านมีตัวตนจริง ที่อยู่ธุรกิจ เบอร์โทรหรือช่องทางแชต โลโก้วิธีชำระเงินที่คุ้นตา และนโยบายที่อ่านเข้าใจง่าย ให้ผู้ซื้อมีสิ่งที่จับต้องได้ไว้ตรวจสอบ ส่วนตรา “ปลอดภัย 100%” ที่คุณออกแบบเอง ไม่ได้พิสูจน์อะไร บทความ ความน่าเชื่อถือของเว็บไซต์ อธิบายว่าผู้เข้าชมตัดสินเรื่องนี้อย่างไร

ออกแบบแบบฟอร์มชำระเงิน

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

ให้ guest checkout เป็นค่าเริ่มต้น

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

สำหรับลูกค้าที่กลับมาซื้อซ้ำ อย่าบล็อกการวาง (paste) หรือโปรแกรมจัดการรหัสผ่าน ในช่องเข้าสู่ระบบ เกณฑ์ Accessible Authentication (ขั้นต่ำ) ของ WCAG 2.2 (3.3.8) กำหนดว่า การเข้าสู่ระบบต้องไม่พึ่งความจำ หรือการพิมพ์ซ้ำโดยไม่มีตัวช่วย ส่วน autocomplete="one-time-code" ทำให้มือถือหลายรุ่น เสนอรหัสที่ส่งมาทาง SMS ให้อัตโนมัติ

ขอเฉพาะสิ่งที่คำสั่งซื้อต้องใช้

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

• ชื่อ ช่องชื่อเต็มช่องเดียว รองรับชื่อจากทั่วโลกได้มากกว่า แยกเป็นหลายช่อง เฉพาะเมื่อบริษัทขนส่ง หรือผู้ให้บริการชำระเงินกำหนด
• เบอร์โทร บริษัทขนส่งมักต้องใช้ บอกเหตุผลด้วย เช่น “สำหรับบริษัทขนส่ง ใช้เฉพาะเมื่อมีปัญหาในการจัดส่ง”
• ชื่อบริษัท และที่อยู่บรรทัดที่สอง ซ่อนไว้หลังลิงก์ “เพิ่มชื่อบริษัท” และ “เพิ่มเลขห้องหรือยูนิต”
• ที่อยู่สำหรับออกใบเสร็จ ตั้งค่าเริ่มต้นให้เป็นที่อยู่จัดส่ง เกณฑ์ Redundant Entry ของ WCAG 2.2 (3.3.7) กำหนดว่า ข้อมูลที่ให้ไว้แล้ว ต้องถูกกรอกให้ หรือเลือกได้ ไม่ใช่ให้พิมพ์ซ้ำ
• ความยินยอมรับข่าวสารการตลาด ใช้ช่องที่ยังไม่ติ๊ก และเขียนให้ตรงไปตรงมา ภายใต้ GDPR ของสหภาพยุโรปและสหราชอาณาจักร ช่องที่ติ๊กไว้ให้ล่วงหน้า ไม่นับเป็นความยินยอม

ให้เบราว์เซอร์กรอกให้

ค่า autocomplete ที่ถูกต้อง ทำให้มือถือกรอกที่อยู่ทั้งหมดได้ในแตะเดียว และเป็นวิธีปกติที่ใช้ให้ผ่านเกณฑ์ Identify Input Purpose ของ WCAG (1.3.5) มาตรฐาน HTML ยอมให้ใส่คำนำหน้า shipping หรือ billing เพื่อให้เบราว์เซอร์เสนอที่อยู่ที่บันทึกไว้ได้ถูกชุด

• ถามประเทศก่อน ถ้าคุณขายไปต่างประเทศ ประเทศเป็นตัวกำหนดรูปแบบที่อยู่ และไม่ใช่ทุกประเทศที่ใช้รหัสไปรษณีย์ จึงไม่ควรบังคับกรอกทุกที่
• อย่าใช้ type="number" กับหมายเลขบัตร หรือรหัสไปรษณีย์ MDN แนะนำให้ใช้ช่องตัวเลข เฉพาะค่าที่กดเพิ่มลดได้ เช่น จำนวนสินค้า และระบุว่าทั้งสองอย่างนี้ไม่เหมาะ อีกทั้งรหัสไปรษณีย์หลายแห่ง ก็มีตัวอักษรปนอยู่
• ตรวจช่องข้อมูลบัตรของผู้ให้บริการชำระเงิน ว่ารองรับการกรอกอัตโนมัติ และแป้นตัวเลข เพราะคุณแก้เองไม่ได้
• เสนอการค้นหาที่อยู่ แต่อย่าบังคับ เก็บ “กรอกที่อยู่เอง” ไว้ สำหรับอาคารใหม่และรูปแบบที่ไม่ปกติ และตรวจให้แน่ใจว่า มันไม่ขัดกับการกรอกอัตโนมัติของเบราว์เซอร์

ข้อความแจ้งข้อผิดพลาดที่ช่วยแก้ปัญหา

• ตรวจช่องกรอก ตอนที่ผู้ซื้อออกจากช่องนั้น ไม่ใช่ทุกครั้งที่กดแป้น
• วางข้อความแจ้งข้อผิดพลาด ไว้ข้างช่องนั้น และอธิบายวิธีแก้ “กรอกอีเมลในรูปแบบ name@example.com” ดีกว่า “ข้อมูลไม่ถูกต้อง” เกณฑ์ Error Identification (3.3.1) และ Error Suggestion (3.3.3) ของ WCAG กำหนดให้ระบุช่องที่ผิด อธิบายข้อผิดพลาดเป็นข้อความ และแนะนำวิธีแก้ เท่าที่ทำได้
• รับเว้นวรรคและขีด ในหมายเลขบัตรและเบอร์โทร แล้วจัดรูปแบบในโค้ดทีหลัง
• อย่าล้างสิ่งที่คนพิมพ์ไปแล้ว รหัสความปลอดภัยของบัตร เป็นช่องเดียว ที่ผู้ให้บริการอาจขอกรอกใหม่ได้อย่างสมเหตุสมผล

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

Checkout หน้าเดียวหรือหลายขั้นตอน

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

ไม่ว่าแบบไหน ให้สรุปคำสั่งซื้อ (สินค้า ค่าจัดส่ง ภาษี และยอดรวม) อยู่ในสายตาตลอด บนมือถือ ให้พับเก็บไว้ใต้แถบที่แสดงยอดรวม สำหรับการซื้อ เกณฑ์ Error Prevention ของ WCAG (3.3.4) กำหนดว่า คำสั่งซื้อต้องยกเลิกได้ ตรวจสอบและแก้ไขได้ หรือทบทวนและยืนยันได้ ก่อนจะยืนยันเป็นขั้นสุดท้าย การแสดงคำสั่งซื้อทั้งหมด ก่อนชำระเงิน คือวิธีที่ง่ายที่สุด ตัดช่องกรอกก่อน แล้วค่อยทดสอบเลย์เอาต์กับร้านของคุณเอง

การชำระเงิน: วิธีที่คุ้นเคยและความปลอดภัยที่มองเห็นได้

เสนอวิธีที่ลูกค้าใช้อยู่แล้ว

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

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

อย่าให้ข้อมูลบัตรผ่านเซิร์ฟเวอร์ของคุณ

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

รับมือการยืนยันตัวตนและบัตรถูกปฏิเสธ

ในเขตเศรษฐกิจยุโรป (EEA) และสหราชอาณาจักร การชำระเงินด้วยบัตรออนไลน์จำนวนมาก ต้องผ่านการยืนยันตัวตนลูกค้าแบบเข้มงวด มักผ่าน 3-D Secure เช่น การอนุมัติในแอปธนาคารของผู้ซื้อ ทดสอบขั้นตอนไปแล้วกลับนี้บนมือถือ ซึ่งควรจบที่หน้ายืนยันคำสั่งซื้อของคุณ ไม่ใช่หน้าจอว่างเปล่า เมื่อการชำระเงินถูกปฏิเสธ ให้เก็บตะกร้าและทุกรายละเอียดไว้ บอกตรง ๆ ว่าเกิดอะไรขึ้น และเสนอวิธีชำระเงินอื่น

ออกแบบ checkout บนมือถือ

นอกจากประเภท input ที่เป็นมิตรกับคีย์บอร์ด ที่พูดถึงไปแล้ว ยังมีกฎบางข้อ ที่เฉพาะกับมือถือ

• ปุ่มที่นิ้วโป้งเอื้อมถึง ทำปุ่ม “ดำเนินการต่อ” และ “ชำระเงิน” ให้เต็มความกว้าง และอยู่ต่ำบนหน้าจอ WCAG 2.2 กำหนดขนาดพื้นที่แตะขั้นต่ำ 24 x 24 CSS pixel (2.5.8) แต่ควรตั้งเป้าใกล้ 44 x 44 ซึ่งเป็นระดับ AAA ที่เข้มงวดกว่า
• แถบติดหน้าจอที่ไม่บังโฟกัส แถบชำระเงินที่ติดอยู่กับที่ หรือแบนเนอร์คุกกี้ ต้องไม่บังช่องที่กำลังถูกโฟกัสด้วยคีย์บอร์ดจนมิด ซึ่งเป็นเกณฑ์ Focus Not Obscured (ขั้นต่ำ) ของ WCAG 2.2 (2.4.11) และดีที่สุดคือ ไม่บังเลยแม้แต่ส่วนเดียว
• ไม่มีป๊อปอัปหรือทางอ้อม ปิดหน้าต่างชวนสมัครรับข่าวสาร และข้อความชวนแชต และแสดงข้อมูลการจัดส่ง การคืนสินค้า และเงื่อนไข ในแผงที่กดขยายได้ แทนการพาไปหน้าอื่น
• ความเร็วบนเน็ตมือถือ หน้าชำระเงินเป็นหน้าเฉพาะของแต่ละคน จึงแคชแบบส่วนอื่นของร้านไม่ได้ ทดสอบบนมือถือระดับกลาง ความเร็วของหน้าเว็บส่งผลต่อคอนเวอร์ชัน ในทุกขั้นตอน

กู้คืนตะกร้าที่ยังถูกทิ้ง

การกู้คืน หมายถึงทำให้กลับมาได้ง่าย ไม่ใช่การกดดัน

• บันทึกตะกร้า ไว้กับบัญชีลูกค้า เพื่อให้ตามไปได้ทุกอุปกรณ์ และบันทึกไว้ในเบราว์เซอร์ สำหรับผู้ซื้อที่ไม่ได้สมัครสมาชิก
• ส่งอีเมลเตือนตะกร้าที่ถูกทิ้ง เฉพาะเมื่อมีฐานรองรับที่ถูกต้อง ตัวอย่างเช่น สหภาพยุโรปและสหราชอาณาจักร โดยทั่วไปกำหนดให้ต้องได้รับความยินยอม ก่อนส่งอีเมลการตลาดถึงบุคคล โดยมีข้อยกเว้นแคบ ๆ ที่เรียกว่า “soft opt-in” สำหรับลูกค้าเดิม การเก็บอีเมลที่คนพิมพ์ไว้ แต่ไม่เคยกดส่ง แล้วส่งอีเมลหาเขา เป็นวิธีที่หาเหตุผลมารองรับได้ยากที่สุด
• ทำให้การเตือนมีประโยชน์ เตือนครั้งเดียว หรือชุดสั้น ๆ พร้อมรายการสินค้า ลิงก์ที่คืนตะกร้าให้ครบเหมือนเดิม และคำตอบต่อข้อสงสัยที่น่าจะมี ส่วนลดอัตโนมัติ เสี่ยงจะสอนให้ลูกค้าประจำ รอโค้ดก่อนซื้อ

ตรวจ checkout ได้เองในสัปดาห์นี้

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

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

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

อัตราการทิ้งตะกร้าที่ถือว่าปกติคือเท่าไร?

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

อีเมลเตือนตะกร้าที่ถูกทิ้ง ต้องขอความยินยอมจากผู้ซื้อไหม?

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

ปรับปรุง checkout แล้ว ยอดขายจะเพิ่มเท่าไร?

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

ขั้นต่อไป

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

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