การสั่งกลับบ้านเป็นธุรกิจที่แตกต่างจากการนั่งรับประทาน ลูกค้าไม่นั่งลง ไม่มีโต๊ะจอดพวกเขา พวกเขาต้องการรู้สองสิ่ง: อาหารพร้อมเมื่อไหร่ และจ่ายเงินอย่างไร อะไรก็ตามที่ขวางสองคำถามนั้นคือแรงเสียดทาน และแรงเสียดทานทำให้เสียออเดอร์ให้คู่แข่งที่มีกระบวนการที่ดีกว่า
ในช่วงไม่กี่ปีที่ผ่านมา วิธีการสำหรับสั่งกลับบ้านเปลี่ยนจากการโทรศัพท์และเคาน์เตอร์รับลูกค้าเดินเข้ามาสู่เวิร์กโฟลว์ QR-และ-คิวที่ขยายตัวได้ ลูกค้ารับหมายเลขคิว สร้างออเดอร์บนโทรศัพท์ของตัวเอง จ่ายโดยอัปโหลดสลิปโอนเงิน และรับเมื่อหมายเลขถูกเรียก ทั้งหมดทำงานในเบราว์เซอร์ ไม่มีแอป ไม่มีสถานีพนักงานต้อนรับ ไม่มีหูฟัง
บทความนี้อธิบายการตัดสินใจเชิงปฏิบัติที่ทำให้เวิร์กโฟลว์นี้ใช้งานได้ในร้านอาหารจริง
การตั้งราคาสั่งกลับบ้านแยกต่างหาก
การตัดสินใจแรกคือราคาสั่งกลับบ้านควรเหมือนกับการนั่งรับประทานหรือไม่ ในหลายประเทศคำตอบคือไม่ การนั่งรับประทานรวมจาน แก้ว การบริการโต๊ะ และประสบการณ์ การสั่งกลับบ้านรวมบรรจุภัณฑ์และสมมติฐานว่าลูกค้าจะทานที่อื่น โครงสร้างต้นทุนต่างกัน และความเต็มใจจ่ายก็ต่างกัน
รูปแบบทั่วไปคือการเพิ่มราคาเล็กน้อยสำหรับสั่งกลับบ้าน อาจสิบถึงสิบห้าเปอร์เซ็นต์ เพื่อครอบคลุมบรรจุภัณฑ์และแรงงานส่วนเพิ่มในการจัดและส่งมอบ ร้านอาหารบางแห่งกลับลำและเสนอส่วนลดสั่งกลับบ้านเล็กน้อยเพราะประหยัดค่าล้างจานและการหมุนเวียนโต๊ะ ไม่ว่าทางใด ระบบเมนูต้องรองรับช่องราคาแยกต่อรายการ ต่างจากราคานั่งรับประทาน ที่ปรากฏเฉพาะเมื่อลูกค้าสั่งสำหรับรับสินค้า
รายการยังต้องการแฟล็กความพร้อมแยกต่างหากสำหรับสั่งกลับบ้าน อาหารบางอย่างเดินทางได้ไม่ดี ซูเฟล่ คาร์ปักโชละเอียด ของหวานที่ประกอบหลายชั้น ไม่มีสิ่งเหล่านี้ที่ควรอยู่ในเมนูสั่งกลับบ้าน ควรคงอยู่ในเมนูนั่งรับประทานแต่ซ่อนจากรายการสั่งกลับบ้านด้วยการสลับเดียว ไม่ใช่โดยการดูแลเมนูคู่ขนานสองเมนู
การยืนยันออเดอร์สองขั้นตอน
ข้อผิดพลาดคลาสสิกคือการปฏิบัติต่อออเดอร์สั่งกลับบ้านเหมือนการชำระเงินบนเว็บไซต์ ที่ลูกค้ายืนยันทุกอย่างในตอนท้าย ในทางปฏิบัติสิ่งนี้ล้มเหลวเพราะขั้นตอนการชำระเงินช้าที่สุดและเกิดข้อผิดพลาดมากที่สุด การโอนเงินใช้เวลา ลูกค้าอาจพิมพ์จำนวนผิดพลาด สลิปอาจไม่ชัด หากออเดอร์ถูกล็อกก่อนยืนยันการชำระ ครัวเริ่มปรุงอาหารที่ร้านอาจไม่ได้รับเงิน
เวิร์กโฟลว์ที่ดีกว่าคือการส่งมอบสองขั้นตอน ขั้นตอนที่หนึ่ง: ลูกค้าวางออเดอร์ ระบบบันทึกรายการ คำนวณยอดรวม และแสดงยอดรวมที่ชัดเจนในสกุลเงินเดียวกับที่ชำระ ขั้นตอนที่สอง: ลูกค้าอัปโหลดสลิปการชำระ จนกว่าร้านจะยืนยันสลิปด้วยตนเองว่าถูกต้อง ออเดอร์อยู่ในสถานะ "รอการยืนยัน" ครัวไม่เริ่มทำ แบดจ์สถานะของลูกค้าบอกว่า "รอร้านยืนยันการชำระ" เพื่อให้พวกเขารู้ว่าลูกบอลอยู่ในมือคุณ ไม่ใช่มือพวกเขา
ฟังดูช้า ในทางปฏิบัติการยืนยันของพนักงานใช้เวลาสิบวินาที เปิดแดชบอร์ด ดูรูปสลิป แตะปุ่ม ครัวเห็นออเดอร์ในขณะที่การชำระได้รับการยืนยัน ไม่ใช่ก่อน ซึ่งเป็นช่วงเวลาที่ถูกต้องพอดี
การอัปโหลดสลิปการชำระที่ไม่ล้มเหลว
โหมดความล้มเหลวที่พบบ่อยที่สุดสำหรับการอัปโหลดสลิปคือการอนุญาต โทรศัพท์ลูกค้าใช้ที่อยู่ IP แบบสุ่ม ขนาดรูปภาพแตกต่างจาก 200 KB ถึง 10 MB ลูกค้าบางคนจับภาพหน้าจอแอปธนาคาร บางคนถ่ายใบเสร็จที่พิมพ์ออกมาด้วยกล้อง บางคนวางรูปที่ส่งต่อมาจากแชท ระบบอัปโหลดต้องรับได้ทุกอย่างนี้โดยไม่เกิดข้อผิดพลาด
กฎเชิงปฏิบัติสักไม่กี่ข้อ ประการแรก รับรูปภาพหลายรูปแบบ: JPEG, PNG และ WebP ครอบคลุมกล้องโทรศัพท์และเครื่องมือจับภาพหน้าจอแทบทุกตัว ประการที่สอง ใช้ URL อัปโหลดที่ลงนามล่วงหน้าซึ่งหมดอายุในไม่กี่นาที เพื่อให้การอัปโหลดเกิดขึ้นโดยตรงจากโทรศัพท์ลูกค้าไปยังที่จัดเก็บโดยไม่มีเซิร์ฟเวอร์ของคุณอยู่ตรงกลาง ประการที่สาม ตรวจสอบประเภทไฟล์ฝั่งเซิร์ฟเวอร์ก่อนออก URL ประการที่สี่ จัดเก็บสลิปภายใต้เส้นทางที่มีชื่อเนมสเปซชัดเจนเพื่อให้คุณตรวจสอบภายหลังหากมีข้อพิพาทการชำระ
UI ที่หันหน้าให้ลูกค้าควรเป็นปุ่มใหญ่หนึ่งปุ่มที่ระบุว่า "อัปโหลดสลิปการชำระ" ไม่ใช่แบบฟอร์มหลายขั้นตอน หลังจากอัปโหลด แสดงภาพย่อของสลิปกลับให้ลูกค้าพร้อมตัวเลือก "เปลี่ยน" ในกรณีที่อัปโหลดภาพหน้าจอผิด แบดจ์สถานะของพวกเขาควรเปลี่ยนทันทีเป็น "รอร้านยืนยัน" เพื่อให้รู้ว่าการอัปโหลดสำเร็จ
รหัสอ้างอิงสำหรับรับสินค้า
เมื่อลูกค้ามาเก็บสินค้า คุณต้องการวิธีรวดเร็วในการจับคู่โทรศัพท์กับออเดอร์บนหน้าจอของคุณ การตะโกนหมายเลขคิวใช้ได้ในร้านเงียบๆ แต่ล้มเหลวในร้านชานมไข่มุกที่มีเสียงดังกับหมายเลข 12 ห้าคนในคิว
รหัสสั้นๆ หกตัวอักษรจากชุดอักขระที่ป้องกันความสับสน แก้ปัญหานี้ได้ สร้างฝั่งเซิร์ฟเวอร์ในเวลาที่วางออเดอร์ แสดงบนโทรศัพท์ลูกค้าควบคู่กับหมายเลขคิว แสดงรหัสเดียวกันในแดชบอร์ดพนักงาน เมื่อลูกค้ามาถึง พวกเขาแสดงโทรศัพท์ คุณเปรียบเทียบรหัส และส่งมอบถุง การแลกเปลี่ยนทั้งหมดใช้เวลาสามวินาทีและไม่ต้องพึ่งการตะโกนชื่อ
รหัสอ้างอิงยังทำหน้าที่เป็นการป้องกันการโกง ลูกค้าไม่สามารถอ้างว่า "ฉันคือหมายเลข 42" โดยไม่แสดงรหัสที่ตรงกับหมายเลข 42 สองคนสุ่มไม่สามารถชนกันในรหัสเดียวกันในวันเดียวกันในสถานการณ์ที่น่าจะเป็นไปได้ใดๆ
การกระทบยอดสิ้นวัน
รายได้สั่งกลับบ้านต้องกระทบยอดกับการโอนเงินทุกวัน วิธีที่ง่ายที่สุดคือมุมมองประวัติในแดชบอร์ดคิวที่แสดงออเดอร์ทุกรายการที่ทำเครื่องหมายว่า "ให้บริการแล้ว" ในวันที่กำหนด พร้อมหมายเลขคิว รหัสอ้างอิง เวลา ยอดรวม และลิงก์ไปยังรูปสลิป เลือกวันที่ ดูรายการ เห็นยอดรวมรายวัน ตรวจสอบกับรายงานธนาคาร ห้านาทีต่อวัน ควรทำเป็นส่วนหนึ่งของกิจวัตรปิดร้าน
ประวัติต้องจัดการเขตเวลาอย่างถูกต้อง ร้านอาหารในกรุงเทพที่ปิดเที่ยงคืนเวลาท้องถิ่นควรเห็นออเดอร์ทั้งหมดสำหรับวันปฏิทินนั้นรวมกัน ไม่แยกตาม UTC เที่ยงคืนกลางมื้อค่ำ ระบบควรรู้ประเทศของร้านอาหารและใช้เขตเวลาท้องถิ่นสำหรับการจัดกลุ่ม
ทำอย่างไรเมื่อเกิดปัญหา
ในเวิร์กโฟลว์จริงใดๆ กรณีพิเศษเกิดขึ้น ลูกค้าจ่ายจำนวนผิด สลิปอ่านไม่ออก ลูกค้าไม่มารับ ครัวหมดรายการระหว่างออเดอร์และการยืนยัน
สำหรับแต่ละอย่าง ออกแบบเส้นทางที่ชัดเจน จำนวนผิด: พนักงานเปิดออเดอร์ เห็นปัญหา และยอมรับการชำระบางส่วนพร้อมหมายเหตุหรือขอให้ลูกค้าชำระใหม่ สลิปอ่านไม่ออก: พนักงานส่งข้อความลูกค้าหรือเพียงแค่ไม่ยืนยัน ลูกค้าสังเกตสถานะของพวกเขาค้างอยู่และอัปโหลดใหม่ ไม่มาเก็บ: รายการคิวอยู่ในสถานะ "กำลังเตรียม" จนกว่าจะทำเครื่องหมาย "ให้บริการ" หรือ "ยกเลิก" ด้วยตนเอง
หมดสต็อกระหว่างออเดอร์และการยืนยันเป็นกรณีที่เจ็บปวดที่สุด คำตอบที่สะอาดที่สุดคือการคืนเงินด่วนให้ลูกค้าในบัญชีธนาคารเดียวกัน พร้อมคำขอโทษและหมายเหตุ ระบบควรทำให้สิ่งนี้ง่าย: ปุ่มยกเลิกบนออเดอร์ที่คุณสามารถใช้หลังจากเห็นสลิป โดยลูกค้าเห็นการยกเลิกบนโทรศัพท์ทันที
อย่าเพิ่มประสิทธิภาพเส้นทางที่ดีมากเกินไป
การล่อใจเมื่อออกแบบกระบวนการสั่งกลับบ้านคือการสมมติว่าทุกออเดอร์ดำเนินไปอย่างสมบูรณ์ และออกแบบ UI ตามนั้น นี่คือกับดัก ออเดอร์ส่วนใหญ่ดำเนินไปอย่างสมบูรณ์ แต่ออเดอร์ที่แย่ใช้เวลาไม่สัดส่วนและสร้างงานบริการลูกค้ามากที่สุด สร้างเวิร์กโฟลว์รอบกรณีที่แย่ก่อน และกรณีที่ดีจะดูแลตัวเอง
แบดจ์สถานะที่ชัดเจนที่ลูกค้าอ่านได้ในสามวินาที แดชบอร์ดที่แสดงทุกสิ่งที่พนักงานต้องการในมุมมองเดียว รหัสอ้างอิงสำหรับการส่งมอบที่รวดเร็ว มุมมองประวัติสำหรับการกระทบยอดสิ้นวัน บวกความคาดหวังเริ่มต้นว่าออเดอร์บางรายการจะต้องการการแทรกแซงด้วยตนเอง และระบบทำให้การแทรกแซงนั้นง่ายแทนที่จะเป็นไปไม่ได้ ทำให้ถูกต้องและคุณมีการดำเนินงานสั่งกลับบ้านที่ขยายตัวได้
