ระบบขายตั๋วหลายรอบเวลา: คู่มือออกแบบให้ขายได้มั่นใจ

ระบบขายตั๋วหลายรอบเวลาต้องแยก “กิจกรรม” ออกจาก “รอบที่เข้าร่วมได้” ให้ชัด ลูกค้าที่ซื้อรอบ 10:00 ไม่ควรใช้สิทธิ์ในรอบ 13:00 โดยไม่มีขั้นตอนเปลี่ยนรอบ และ Capacity ต้องสัมพันธ์กับรอบและประเภทตั๋ว ไม่ใช่ตรวจจำนวนรวมทั้งวันอย่างเดียว

ระบบขายตั๋วหลายรอบเวลาคืออะไร

เป็นระบบขายสิทธิ์เข้าร่วมกิจกรรมตามวันและรอบเวลา เช่น การแสดง พิพิธภัณฑ์ หรือกิจกรรมจำกัดจำนวน แยก Event, Session, Ticket Type, Order และ Ticket เป็นองค์ประกอบคนละหน้าที่

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

กลไกขายและสถานะทำงานอย่างไร

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

สถานะอย่าง Available, Held, Confirmed, Cancelled และ Checked-in มีผลต่างกัน ต้องกำหนด Transition ที่อนุญาต การโหลดหน้าชำระเงินสำเร็จใน Browser ไม่ควรเป็นหลักฐานจ่ายเงินเพียงอย่างเดียว

Architecture ของระบบขาย

Web/App → Session Catalog → Inventory Service/Database → Order/Payment → Ticket Service → Check-in เพิ่ม Queue สำหรับออกเอกสารหรือแจ้งลูกค้า โดยต้องมีหลักฐานธุรกรรมคงอยู่ก่อนตอบรับ

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

Workflow ตั้งแต่เลือกจนผ่านประตู

1. แสดงรอบที่เปิดขายและเวลาปิดรับ
2. ตรวจราคาและถือโควตาฝั่ง Server
3. สร้างรายการชำระเงินผูก Order และรอบ
4. รับผลที่ตรวจสอบได้และยืนยันแบบไม่ซ้ำ
5. ออก Ticket ID และ Token สำหรับตรวจเข้า
6. ตรวจวัน รอบ และสิทธิ์เมื่อสแกน
7. กระทบยอดยอดขาย คืนเงิน และสิทธิ์ที่ใช้

ประโยชน์ทางธุรกิจและเทคนิค

ธุรกิจควบคุมจำนวนคนแต่ละรอบและติดตามความต้องการได้ ทีมเทคนิคใช้แบบจำลองรอบและตั๋วที่ชัด ทำให้เพิ่มรอบหรือราคาได้โดยไม่สร้างระบบใหม่ทุกกิจกรรม

ต้นทุนต้องรวม Payment Fee, การส่งข้อความ อุปกรณ์สแกน และการดูแลช่วงเปิดขาย หากโหลดพุ่งเป็นช่วงสั้น อาจต้องจัดการ Admission Queue มากกว่าขยายเครื่องอย่างเดียว

กรณีใช้งาน: เปลี่ยนรอบหลังซื้อ

ตัวอย่างสมมติ: ลูกค้าขอย้ายจากรอบเช้าไปรอบบ่าย ต้องถือโควตารอบใหม่ก่อนปล่อยรอบเดิมหรือใช้ธุรกรรมที่รักษาความถูกต้องตามนโยบาย พร้อมบันทึกส่วนต่างราคา

หากย้ายแล้วออก QR ใหม่ ต้องเพิกถอน Token เดิมและป้องกันใช้ทั้งสองใบ การคืนเงินกับการคืน Capacity ต้องแยกเงื่อนไขให้ชัด เช่น ตั๋วที่ใช้แล้วไม่ควรคืนโควตาอัตโนมัติ

Security ของราคาและตั๋ว

คำนวณราคา ส่วนลด และค่าธรรมเนียมฝั่ง Server ผูก Payment กับยอด สกุลเงิน และ Order ที่ตรงกัน ไม่รับยอดจาก Client เป็นผลตัดสิน ตรวจสิทธิ์เจ้าหน้าที่เปลี่ยนรอบและคืนเงิน

QR ควรมีข้อมูลเท่าที่จำเป็น และ Token ที่เดาได้ยาก ไม่ฝังข้อมูลส่วนบุคคลเกินจำเป็นเพื่อให้เจ้าหน้าที่เห็นบนเครื่องสแกน

Scalability และ Integration

Cache รายละเอียดรอบได้ แต่การตัดโควตาต้องตัดสินจากแหล่งข้อมูลหลักที่ควบคุมธุรกรรมได้ กระจายโหลดตาม Session และจำกัดจำนวนตั๋วต่อคำขอตามนโยบาย

เชื่อม Payment, Email/SMS และบัญชีด้วยสถานะที่ Retry ได้โดยไม่ซ้ำ แสดงปัญหาให้เจ้าหน้าที่เห็นเมื่อชำระแล้วแต่ยังออกตั๋วไม่สำเร็จ พร้อมวิธีส่งตั๋วใหม่โดยไม่สร้างสิทธิ์ใหม่

ปัญหาที่พบบ่อยและ Best Practices

ปัญหาคือใช้ยอดรวมทั้งวันแทน Capacity ต่อรอบ ถือโควตาไม่หมดอายุ และยืนยันจาก Redirect ควรทำ State Machine, ทดสอบส่ง Webhook ซ้ำ และทดสอบคำขอสุดท้ายของรอบที่เหลือโควตาน้อย

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

แนวทางระยะถัดไป

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

สรุปการออกแบบระบบขายตั๋วหลายรอบเวลา

แยกกิจกรรม รอบ Capacity, Order และ Ticket พร้อมสถานะที่ตรวจสอบได้ ระบบขายตั๋วหลายรอบเวลาต้องทดสอบการถือสิทธิ์ ชำระซ้ำ ย้ายรอบ และตรวจเข้าประตูเป็นเส้นทางเดียวกัน

จุดตรวจสำคัญของ ระบบขายตั๋วหลายรอบเวลา

• Capacity แยกตามรอบและทรัพยากรร่วม
• ราคาและการถือสิทธิ์ตัดสินที่ Server
• Webhook ตรวจตัวตนและไม่สร้างผลซ้ำ
• เปลี่ยนรอบและคืนเงินมีประวัติ
• ตั๋วผูกวัน รอบ และสถานะการใช้

เตรียมข้อมูลเพื่อประเมินระบบกับ Zairosoft

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