คุจิออนไลน์ · เตรียมขอใบเสนอราคา
สร้างเว็บไซต์คุจิออนไลน์: 5 เรื่องที่ต้องตัดสินใจก่อนขอใบเสนอราคา
แม้จะเป็น ‘เว็บไซต์คุจิ’ เหมือนกัน แต่ขอบเขตการพัฒนาก็แตกต่างกันตามวิธีขายและวิธีรับรางวัล ก่อนนับจำนวนหน้าจอ ให้กำหนดก่อนว่าคำสั่งซื้อหนึ่งรายการจะดำเนินไปจากการชำระเงินสู่การจับรางวัลและการจัดส่งอย่างไร แล้วการเปรียบเทียบใบเสนอราคาจะง่ายขึ้นมาก
KUJI BUILDER · ตรวจสอบเนื้อหาล่าสุด
1. เริ่มจากกฎของกระดานคุจิหนึ่งกระดาน
การขายตั๋วจำนวนจำกัดจนหมดกับการจับตามความน่าจะเป็นคงที่ทุกครั้งต้องออกแบบสต็อกต่างกัน ตัวอย่างเช่น กระดาน 80 ใบที่มีรางวัล A 2 ใบ ข้อกำหนดควรระบุก่อนว่าทุกระดับรวมกันได้ 80 หรือไม่ และผู้ซื้อตั๋วใบสุดท้ายได้รับรางวัล Last One หรือไม่ พร้อมกำหนดรายการรางวัลและจำนวนที่ซื้อได้ไปด้วย
- ชื่อสินค้า รูปภาพ และจำนวนของแต่ละระดับ รวมถึงจำนวนตั๋วทั้งหมด
- รูปแบบที่ต้องการ: เลือกหมายเลข สุ่ม หรือแพ็ก
- ราคาต่อครั้ง จำนวนต่อการซื้อ และข้อจำกัดการซื้อ
- เงื่อนไข Last One และการจัดการเมื่อหยุดขายหรือขายหมด
2. ออกแบบรองรับการชำระเงินล้มเหลวและคำขอซ้ำ
การเปิดหน้าชำระเงินได้ไม่ได้หมายความว่าพร้อมขายแล้ว แม้ลูกค้าจะปิดหน้าต่างหลังอนุมัติหรือมีคำขอเดิมซ้ำ คำสั่งซื้อและการจับรางวัลต้องถูกดำเนินการเพียงครั้งเดียว วิธีชำระเงินจะยืนยันตามการพิจารณาและสัญญา PG และต้องทดสอบโหมดทดสอบกับการชำระเงินจริงแยกกัน
- ผู้ถือสัญญา PG และวิธีชำระเงินที่ต้องการ
- การกันสต็อกระหว่างรอชำระเงินและเกณฑ์การหมดอายุ
- ขั้นตอนกู้คืนคำสั่งซื้อหลังการอนุมัติ การยกเลิก และการหมดเวลา
- วิธีกระทบยอดการชำระเงิน ยอดคำสั่งซื้อ และการชำระบัญชี
3. กำหนดการเก็บ การจัดส่ง และการรับรางวัลหลังถูกรางวัล
หน้าคำสั่งซื้อและงานประจำวันจะต่างกัน ขึ้นอยู่กับว่าจะจัดส่งทันทีหลังจับแต่ละครั้ง หรือเก็บรางวัลไว้ในคลังรางวัลเพื่อจัดส่งรวม หากมีบริการรับที่ร้านด้วย ต้องกำหนดการหมดอายุของรหัสรับรางวัล การรับแทน และการป้องกันการใช้รหัสที่ใช้ไปแล้วซ้ำ
- ค่าจัดส่ง เกณฑ์การจัดส่งรวม และระยะเวลาเก็บรักษา
- กำหนดปิดการเปลี่ยนที่อยู่ การบันทึกเลขพัสดุ และการรับแจ้งสินค้าเสียหายหรือส่งผิด
- สถานที่ เวลา และขั้นตอนยืนยันการรับที่ร้าน
- เกณฑ์การยกเลิกและคืนสินค้าทั้งในขั้นตอนการซื้อและหลังการจับรางวัล
4. แยกสิ่งที่ผู้ดูแลทำได้และข้อมูลที่ดูได้
ผู้รับผิดชอบการลงสินค้า การจัดส่ง และการชำระบัญชีต้องการสิทธิ์ที่ต่างกัน และควรกำหนดด้วยว่าจะเปลี่ยนจำนวนรางวัลหรือราคาระหว่างการขายได้หรือไม่ รวมถึงจะบันทึกว่าใครเปลี่ยนอะไรเมื่อใดหรือไม่ สำหรับประวัติการถูกรางวัลที่เปิดเผยต่อสาธารณะ ควรตกลงขอบเขตที่ไม่เปิดเผยข้อมูลที่ระบุตัวลูกค้าโดยไม่จำเป็น
- สิทธิ์ลงสินค้าและกระดานคุจิ ตั้งเวลาขาย และหยุดขาย
- แยกสิทธิ์การดูคำสั่งซื้อ การจัดส่ง และการอนุมัติคืนเงิน
- บันทึกการจับรางวัล การเปลี่ยนสต็อก และการดำเนินการของผู้ดูแล
- สิทธิ์เข้าถึงข้อมูลส่วนบุคคล ระยะเวลาเก็บรักษา และขั้นตอนการลบ
5. เปรียบเทียบค่าพัฒนาและค่าดำเนินงานแยกกัน
ใบเสนอราคาควรระบุฟีเจอร์ที่รวมอยู่ การเชื่อมต่อภายนอก เกณฑ์การตรวจรับ จำนวนครั้งที่แก้ไขได้ และสิ่งที่ส่งมอบ ค่าเซิร์ฟเวอร์ โดเมน PG การยืนยันตัวตน และการส่งการแจ้งเตือนควรตรวจสอบแยกจากค่าพัฒนา ส่วนการจดทะเบียน การยื่นแจ้ง สิทธิในสินค้า และนโยบายที่ใช้กับโครงสร้างการขายของคุณ ผู้ดำเนินธุรกิจควรตรวจสอบกับหน่วยงานและผู้เชี่ยวชาญที่เกี่ยวข้อง แล้วนำไปกำหนดขอบเขตการเปิดตัว
- แยกฟีเจอร์ที่จำเป็นกับฟีเจอร์ที่จะเพิ่มภายหลัง
- แยกค่าพัฒนา ค่าใช้จ่ายคงที่รายเดือน และค่าใช้จ่ายต่อธุรกรรมหรือต่อการส่ง
- ผู้เป็นเจ้าของโดเมน ซอร์สโค้ด คลาวด์ และบัญชี PG
- ระยะเวลารับประกันแก้ไขข้อบกพร่อง อัตราค่าพัฒนาเพิ่มเติม และวิธีส่งมอบข้อมูล