หน้าสั่งอาหารตรงของร้าน ที่เก็บราคาเต็มของทุกจานไว้กับร้าน

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

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

• เว็บเมนูสองภาษาที่ทุกจานมี URL จริง จัดโครงสร้างให้เสิร์ชเอนจินและเอนจินคำตอบยกไปตอบได้
• ขั้นตอนสั่งพร้อม PromptPay QR ตอนจ่ายเงิน ออเดอร์จะเข้าครัวก็ต่อเมื่อเงินเข้าแล้วเท่านั้น
• กติการับเองและรัศมีจัดส่งที่เจ้าของตั้งเอง ร้านจะไม่รับปากในสิ่งที่ส่งไม่ไหว
• จอคิวครัว: ออเดอร์ใหม่เลื่อนเข้ามา แตะเดียวเปลี่ยนจากกำลังทำเป็นพร้อมรับ
• สถานะออเดอร์ส่งเข้า LINE ของลูกค้า: รับออเดอร์แล้ว กำลังทำ พร้อมรับ
• รายชื่อลูกค้าแบบขอความยินยอม เป็นของร้านเอง ไว้บรอดแคสต์เมนูให้คนสั่งซ้ำ

• ซอร์สโค้ดทั้งหมดในรีโพของร้านเอง
• โฮสติ้ง โดเมน LINE OA และการต่อ PromptPay ตั้งในชื่อร้านทั้งหมด
• คู่มือภาษาคน: แก้ราคา ปิดเมนูที่หมด หยุดส่งชั่วคราววันที่ซอยน้ำท่วม
• คอลส่งมอบที่อัดวิดีโอไว้ เจ้าของย้อนดูเองได้ไม่ต้องถามซ้ำ

1. Map

   สัปดาห์แรกสั้น ๆ

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

   สโคปหนึ่งหน้า: เส้นทางออเดอร์ กติกาการจ่ายเงิน และส่วนที่เราตั้งใจปล่อยให้เป็นหน้าที่ของแอปต่อไป

2. Shape

   ภายในสองสัปดาห์เดียวกัน

   ผมออกแบบเมนูกับหน้าจ่ายเงินเพื่อลูกค้าหิว ๆ ที่ถือมือถือ และออกแบบจอคิวเพื่อคนครัวที่มือเปียก

   หน้าจอที่กดได้จริง ให้เจ้าของอนุมัติก่อนลงมือทำหลังบ้าน

3. Make

   ช่วงสัปดาห์ที่ลงมือสร้าง

   ผมสร้างเมนู การจ่ายเงิน และคิวครัวเป็นเส้นทางเดียวที่ทดสอบแล้ว: ออเดอร์จ่ายแล้วเข้า ตั๋วครัวออก สถานะวิ่งไป LINE

   ออเดอร์จริงที่จ่ายผ่าน PromptPay จริง ขึ้นบนจอครัวจริง

4. Prove

   หนึ่งสัปดาห์ที่โฟกัส

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

   รายการแก้ไขสั้น ๆ จากรอบขายจริง ปิดครบก่อนเปิดใช้

5. Hand-off

   ช่วงวันสุดท้าย

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

   กุญแจทั้งหมด: โค้ด โฮสติ้ง บัญชี และคู่มือภาษาไทยกับอังกฤษแบบอ่านรู้เรื่อง

• เสนอราคาเป็นรายโปรเจกต์หลังคุยสโคปสั้น ๆ คุณเห็นตัวเลขเต็มก่อนเงินจะเริ่มเดิน
• จ่ายเป็นงวดตามงาน: มัดจำเพื่อเริ่ม งวดเมื่อออเดอร์จ่ายเงินได้จริง และส่วนที่เหลือตอนส่งมอบ
• สโคปคงที่ ราคาคงที่ และไม่มีหักเปอร์เซ็นต์จากออเดอร์ ไม่ว่าออเดอร์ไหน นั่นแหละคือประเด็น

• ร้านมีหรือพร้อมเปิดบัญชีที่รับ PromptPay และ LINE OA ในชื่อร้านเอง
• เมนูค่อนข้างนิ่ง มีเมนูพิเศษรายวันได้ แต่ไม่ใช่รื้อเมนูใหม่ทุกสัปดาห์
• มีเจ้าของหนึ่งคนเป็นผู้อนุมัติระหว่างการสร้าง

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

จอครัวคือตัวสินค้า ไม่ใช่ตัวเว็บ

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

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

ผลที่ได้

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

สิ่งที่มันพิสูจน์

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