Koratระบบสั่งอาหารหน้าโต๊ะมักพังอยู่สองจุด จุดแรกคือตอนที่คนแปลกหน้าสั่งเข้าโต๊ะที่ไม่ใช่โต๊ะตัวเองได้ จุดที่สองคือตอนที่ยอดบนจอลูกค้าไม่ตรงกับยอดบนเครื่องคิดเงิน โมดูลร้านอาหารของ Korat ออกแบบย้อนกลับมาจากสองจุดนี้ เซสชันของโต๊ะเปิดโดยพนักงานและพกโทเคนที่ใช้ได้ครั้งเดียว บิลคือชุดแถวเดียวกับที่เครื่องคิดเงินอ่าน และ place_dining_order คิดราคาทุกบรรทัดบนเซิร์ฟเวอร์ ตัวเลือกเสริม ตัวจับเวลาบุฟเฟต์ และหน้าหารบิล ล้วนสร้างทับหลักประกันสองข้อนี้
QR หน้าโต๊ะ ถ่ายรูปเก็บไปสั่งทีหลังไม่ได้
ที่นี่ตั้งใจไม่มีช่อง "พิมพ์เลขโต๊ะ" มันเป็นฟีเจอร์ที่ทำง่ายที่สุด และเป็นเหตุผลที่ระบบสั่งอาหารหน้าโต๊ะจำนวนมากถูกป่วนได้จากลานจอดรถ ถ้าสิ่งเดียวที่ใช้ยืนยันคือตัวเลขที่พิมพ์ติดโต๊ะ ใครก็ตามที่เคยมากินที่ร้านก็สั่งเข้าโต๊ะไหนก็ได้ไปตลอดชีวิต แทนที่จะเป็นแบบนั้น พนักงานเปิดโต๊ะจากคอนโซล และการเปิดนั้นสร้างโทเคนใหม่ที่ใช้ได้ครั้งเดียวฝังอยู่ใน QR ที่แสดงบนโต๊ะนั้น QR ที่ถ่ายรูปเก็บไว้ สกรีนช็อตที่ส่งต่อให้เพื่อน หรือใบที่ปรินต์ไว้ตั้งแต่วันอังคารที่แล้ว ล้วนพกโทเคนที่หมดอายุแล้วและใช้ไม่ได้
ลูกค้าที่เพิ่งเดินมาถึงโต๊ะ ไม่ได้เป็นทั้งพนักงานของร้านและไม่ได้เป็นเจ้าของเซสชันที่ยังไม่เกิดขึ้น ภายใต้ row-level security เขาจึงอ่านตาราง dining_sessions ไม่ได้เลย ไม่ว่าจะแถวของตัวเองหรือแถวไหนก็ตาม RLS ตัดสินได้แค่ว่า *ใคร* เป็นคนเรียก แต่ตัดสินไม่ได้ว่าคำขอนั้นพกโทเคนที่ถูกต้องมาด้วยหรือเปล่า การสแกนจึงวิ่งผ่าน join_session_by_token ซึ่งเป็นฟังก์ชัน SECURITY DEFINER ที่จับคู่โทเคนบนเซิร์ฟเวอร์เอง ตั้งคนแรกที่สแกนเป็นเจ้าของโต๊ะ และคืนค่าว่างเมื่อโทเคนไม่ตรง โดยไม่บอกเหตุผล ข้อความ error ที่แยก "โทเคนผิด" ออกจาก "โทเคนหมดอายุ" คือเครื่องมือให้คนนั่งเดาโทเคน
เมื่อเข้าโต๊ะได้แล้ว เจ้าของโต๊ะชวนคนที่เหลือเข้ามาได้ด้วยลิงก์หรือการ์ดในแชท เพื่อนที่มาสายจึงเข้าเซสชันเดียวกัน และอาหารของเขาก็ลงบิลใบเดียวกัน
QR หน้าโต๊ะเป็นลิงก์ https เปิดได้ทั้งในแอปและบนเว็บ
QR บนโต๊ะเป็น URL แบบ https ไม่ใช่สคีมเฉพาะของแอป เครื่องที่ติดตั้ง Korat ไว้จะเปิดในแอปผ่าน App Link ที่ยืนยันโดเมนแล้ว ส่วนเครื่องที่ไม่มีแอป รวมถึง iPhone ทุกเครื่อง จะเปิดหน้าสั่งอาหารบนเว็บแทน นี่คือการแก้จุดที่เคยตายสนิทที่สุดของทั้งผลิตภัณฑ์ คือลูกค้านั่งลงที่โต๊ะ ยกกล้องขึ้นสแกน แล้วไม่มีอะไรเกิดขึ้นเลย หน้าเว็บนั้นอ่านเมนู นาฬิกาบุฟเฟต์ และด่านแอลกอฮอล์ได้ครบตั้งแต่ยังไม่ล็อกอิน แล้วขอให้เข้าสู่ระบบเฉพาะตอนกดส่งออเดอร์ ซึ่งเป็นจังหวะเดียวที่เลี่ยงไม่ได้ ส่วน QR ที่ปรินต์ไว้ตั้งแต่รุ่นเก่าซึ่งพก korat://dine ก็ยังสแกนได้ตลอดไป
ระบบจัดการร้านอาหาร จดออร์เดอร์และตัวเลือกเสริม
เมนูจัดเป็นหมวด และทุกเมนูใส่กลุ่มตัวเลือกได้ เช่น ช็อตเพิ่ม ระดับความเผ็ด หรือชนิดเส้น พร้อมส่วนต่างราคา แฟล็กว่าบังคับเลือกไหม และจำนวนที่เลือกได้สูงสุด ส่วนต่างราคาผูกอยู่กับตัวเลือกไม่ใช่พิมพ์ลงในโน้ต นั่นคือเหตุผลที่ใบสั่งเข้าครัวกับบรรทัดในบิลพูดตรงกันว่าลูกค้าสั่งอะไร แต่ละรายการยังใส่โน้ตอิสระและจำนวนได้ และตะกร้าแก้ไขได้จนกว่าจะกดส่ง
เวลาทำการ ออเดอร์สุดท้าย และด่านแอลกอฮอล์
ร้านตั้งเวลาเปิดปิดพร้อมช่วงกันสำหรับออเดอร์สุดท้ายได้ เมื่อใกล้ถึงเวลานั้น เมนูจะเตือนว่าครัวใกล้ปิด และเมื่อเลยไปแล้วระบบจะบล็อกการสั่ง แทนที่จะรับไว้ก่อนแล้วค่อยไปเงียบ ๆ ยกเลิกทีหลัง เมนูที่ปิดขายหรือของหมดจะขึ้นบอกบนการ์ดตั้งแต่ก่อนกด ส่วนเครื่องดื่มแอลกอฮอล์มีแฟล็กของตัวเอง คือเช็กอายุจากวันเกิดของลูกค้า และพนักงานยืนยันอายุให้ทั้งโต๊ะรวดเดียวได้ เกณฑ์อายุของแอลกอฮอล์และของทุกอย่างที่คุมด้วยอายุอยู่ในเงื่อนไขการใช้งาน
ออเดอร์รอพนักงานกดรับ ก่อนขึ้นจอครัว
ออเดอร์ที่ส่งเข้ามาไม่ได้วิ่งตรงเข้าครัว มันไปรออยู่ในคิวรอยืนยันบนจอครัว และพนักงานกดยืนยันหรือปฏิเสธทีละใบก่อนที่มันจะกลายเป็นงาน ระบบที่ปล่อยให้มือถือยิงใบสั่งเข้าครัวได้ตรง ๆ เท่ากับยื่นสิทธิ์ให้คนแปลกหน้าทำร้านเสียของ และตัดจังหวะที่คนจะทันสังเกตว่าโต๊ะหกเผลอสั่งชุดเดียวกันมาสี่ชุด
จากจอครัว พนักงานเลื่อนสถานะออเดอร์ไปทีละขั้น และคอนโซลร้านค้าแสดงป้ายตัวเลขสดที่รีเฟรชทุกไม่กี่วินาที ทั้งออเดอร์ที่กำลังทำ โต๊ะที่กดเรียกพนักงาน การจองที่รอตอบ และเดลิเวอรีใหม่ พร้อมแถบสีแดงขึ้นทันทีที่มีโต๊ะกดเรียก ฝั่งลูกค้าได้อีกครึ่งหนึ่งของวงจรนี้ คือเรียกพนักงาน ขอเช็กบิล หรือออกจากโต๊ะ
ปิดบิล หารบิล และจ่ายด้วยพร้อมเพย์ QR
บิลสดแสดงแถวเดียวกับที่เครื่องคิดเงินอ่าน อัปเดตทุกครั้งที่มีอาหารถูกยืนยัน ไม่ต้องรอเปิดยอดตอนจบมื้อ ไม่ต้องนั่งไล่จากความทรงจำ เมื่อปิดโต๊ะ แอปจะสรุปมื้อนั้นให้ รวมถึงแนะนำให้เพิ่มเพื่อนกับคนที่ร่วมโต๊ะ และเตือนให้เขียนรีวิวในภายหลัง ใบเสร็จเก็บอยู่ในประวัติบิลส่วนตัว
หารบิล: ใครต้องจ่ายเท่าไหร่
หน้าหารบิลตอบคำถามที่คนเถียงกันจริง ๆ คือกูต้องจ่ายเท่าไหร่ แต่ละคนเห็นยอดอาหารตามสั่งของตัวเอง บวกส่วนแบ่งเท่า ๆ กันของแพ็กเกจบุฟเฟต์ที่โต๊ะสั่ง และสร้าง QR PromptPay ตามยอดนั้นได้ ในรูปแบบ Thai QR มาตรฐานพร้อม checksum CRC-16
หน้าหารบิลคือการแยกยอด ไม่ใช่การแยกจ่าย มันคำนวณว่าใครต้องจ่ายเท่าไหร่ แต่ไม่ได้ตัดบัตรสี่ใบสำหรับสี่ส่วน การเคลียร์เงินยังเป็นเรื่องระหว่างคนที่โต๊ะกับร้านเหมือนเดิม
และไม่มีทางลัด "พิมพ์เลขโต๊ะ" ให้ใช้ เป็นความตั้งใจ ถ้า QR ของลูกค้าสแกนไม่ขึ้น พนักงานเปิดโต๊ะใหม่จากคอนโซล การเพิ่มช่องพิมพ์เองคือการคืนช่องโหว่ที่โทเคนถูกสร้างขึ้นมาเพื่อปิดพอดี
ระบบร้านบุฟเฟ่ต์ หมูกระทะ ชาบู จับเวลาต่อรอบ
บุฟเฟต์มีโมเดลของตัวเอง ไม่ใช่การแกล้งทำเป็นเมนูรายการหนึ่งที่ตั้งราคาต่อหัว แพ็กเกจหนึ่งมีราคาต่อหัว มีตัวจับเวลานับถอยหลังที่พนักงานต่อเวลาให้ได้ และแยกจำนวนผู้ใหญ่กับเด็ก เมนูแต่ละรายการมีบทบาทในบุฟเฟต์ของตัวเอง คือรวมอยู่ในแพ็กเกจ สั่งแยกเท่านั้น หรือรวมแต่คิดเพิ่ม เมนูชุดเดียวจึงเสิร์ฟลูกค้าได้ทั้งสองแบบ ระบบรองรับการคิดค่าอาหารเหลือพร้อมหน่วยกำกับด้วย คือกฎที่บุฟเฟต์ไทยส่วนใหญ่ปรินต์ติดโต๊ะอยู่แล้ว แต่ซอฟต์แวร์ส่วนใหญ่ทำเป็นไม่เห็น รายละเอียดทั้งชุด ทั้งขั้นราคาเด็ก last order และค่าอาหารเหลือสามหน่วย ตั้งจากไทล์แพ็กบุฟเฟต์ของร้านในคอนโซลธุรกิจ ส่วนร้านกาแฟใช้กลุ่มตัวเลือกแทนแพ็กต่อหัว จึงไม่ต้องตั้งแพ็กเลย
ระบบจัดการร้านอาหาร รับเดลิเวอรี สั่งกลับบ้าน และจองโต๊ะ
เมนูชุดเดียวกันรองรับทั้งเดลิเวอรีและสั่งกลับบ้าน ออเดอร์หนึ่งพกค่าส่ง ผู้ให้บริการขนส่ง เวลานัดรับ และที่อยู่ แล้วเดินผ่านสถานะใหม่ กำลังทำ กำลังไปส่ง และเสร็จแล้ว โดยแจ้งเตือนทั้งสองฝั่งทุกครั้งที่เปลี่ยนสถานะ การจองโต๊ะรับวันที่ เวลา จำนวนคน และโน้ต แล้วรอร้านยืนยัน จำนวนที่รออยู่แสดงเป็นป้ายสดบนแดชบอร์ด วงจรออเดอร์แบบเดียวกันนี้ฝั่งค้าปลีกเดินห้าขั้นและพกเลขพัสดุกับผู้ให้บริการขนส่งไปด้วย
ร้านที่ไม่ได้ใช้โต๊ะแต่เรียกลูกค้าด้วยเลขคิว ตั้งรูปแบบการให้บริการเป็นคิวแล้วใช้บัตรคิวหน้าร้านแทนได้ ใบสั่งกับบัตรคิวเดินคู่กันในร้านเดียวกัน
ระบบจัดการร้านอาหาร คิดราคาทุกบรรทัดเอง ลูกค้าแก้ไม่ได้
กฎที่ทำให้ทุกอย่างข้างบนปลอดภัยคือ ฝั่งไคลเอนต์ไม่เคยเป็นคนกำหนดราคา place_dining_order และ place_shop_order อ่านราคาสินค้า ส่วนต่างของตัวเลือก และค่าส่ง ออกมาจากฐานข้อมูลเอง แล้วโยนทิ้งทุกอย่างที่มือถือส่งมา ฟิลด์จากไคลเอนต์ที่เชื่อได้ คือส่วนลดที่ลูกค้ากดให้ตัวเองได้ หลักการเดียวกันนี้คุมรีวิวด้วย มีแค่ลูกค้าที่ฐานข้อมูลพิสูจน์ได้ว่านั่งกินหรือสั่งเดลิเวอรีจริงเท่านั้นที่เขียนรีวิวได้ และคะแนนดาวถูกคำนวณใหม่ด้วยทริกเกอร์ ไม่ใช่พิมพ์ใส่