掃碼點餐越來越常見，你想過其中的功能邏輯嗎？

掃碼點餐，即幫助餐飲商家實現(xiàn)通過手機掃碼完成自助點菜，點菜結(jié)果傳到商家收銀系統(tǒng)及后廚。商家可根據(jù)小票打印出的顧客點菜信息備餐，提升顧客點餐和商家服務(wù)效率。

在當前餐飲服務(wù)體系中，堂食、外賣是兩個最為核心的業(yè)務(wù)，掃碼點餐解決的是商家提供堂食就餐服務(wù)時的線上點餐問題。

掃碼點餐業(yè)務(wù)商家后臺功能列表

根據(jù)商家實際經(jīng)營模式和場所的不同，主要可分為2種類型的商家：不提供固定桌位甚至不提供桌位，提供固定桌位。

這兩種模式可以對應(yīng)快餐和正餐，兩種點餐模式，一般不允許同時存在。一個商家，僅可選擇其中一種。

一、取單號點餐

取單號點餐業(yè)務(wù)流程圖

取單號點餐適用于諸如茶飲、快餐等商家的點餐服務(wù)方式，該方式以“取單號”作為出餐和備餐完成后的取餐憑證，“取單號”更可以結(jié)合叫號屏等外接硬件提供更加立體的服務(wù)。

針對這種模式，顧客可以到店時使用微信掃門店點餐碼、搜索進入小程序等方式進入小程序進行線上點餐，下單完成后根據(jù)取單號取餐。

根據(jù)顧客的線下實際就餐場景，例如剛出門預(yù)估大概1小時后到門店能夠用餐，這時候提供這種預(yù)約點餐的商家就可以開啟“預(yù)點單”功能，滿足類似顧客的點餐需求。顧客可使用搜索或者收藏的商家小程序，可以在出門前就下單支付，預(yù)約在1小時后到門店取單。

在這種點餐模式中，商家備餐內(nèi)容及備餐的先后順序也會將“取單號”數(shù)值和“預(yù)點單”時間作為重要參考依據(jù)，以提高備餐效率。

二、掃桌碼點餐

掃桌碼點餐業(yè)務(wù)流程圖

掃桌碼點餐是線下點餐場景中比較復(fù)雜的一種。

一般情況下，提供掃桌碼點餐的商家為顧客提供了較為固定的桌位，會配備服務(wù)員隨時服務(wù)，并且送餐上桌。

在掃桌碼點餐業(yè)務(wù)中，所有業(yè)務(wù)都基于桌碼。

在本文開始的“掃碼點餐業(yè)務(wù)商家后臺功能列表”腦圖中：

“桌位管理”即是對門店桌碼的管理模塊，其中“區(qū)域管理”用于設(shè)置門店中諸如大廳、包廂等桌位的所在區(qū)域；“桌位類型”用于設(shè)置大桌、中桌、小桌等桌位的大小及可就餐人數(shù)；“桌位管理”用于設(shè)置門店具體的桌位，每一個桌位都需要設(shè)置一個區(qū)域及桌位類型，且每一個桌位都需要設(shè)置一個當前門店不可重復(fù)的桌位名稱，例如A1、A2，每個桌位都有對應(yīng)的小程序碼可供下載，然后由門店制作線下物料張貼到桌位上。

1. 結(jié)賬模式

在掃桌碼點餐中，結(jié)賬模式?jīng)Q定了點餐流程中是否提供中途加菜服務(wù)。若結(jié)賬模式設(shè)置為“先吃后付”，則支持中途加菜，反之則不支持加菜。

1）先吃后付

先吃后付在實際場景中也是比較常見的，對于一些提供正餐服務(wù)的商家，他們樂意提供中途加菜的服務(wù)。

在先吃后付的點單流程中，用戶選擇完商品后，只要提交訂單而無需立即支付，即告知商家所點商品信息，開始備餐。在這個過程中，用戶提交的訂單均是未結(jié)賬狀態(tài)，后續(xù)可基于該訂單增加新的商品，并提交訂單后告知商家新加商品信息，繼續(xù)備餐。

需要說明的是，點菜及加菜環(huán)節(jié)，是不計算任何優(yōu)惠內(nèi)容的。該過程進入支付環(huán)節(jié)后，訂單即會鎖定，不再支持加菜。訂單結(jié)算支付時，會統(tǒng)一計算可享受的優(yōu)惠信息。

先吃后付的優(yōu)惠計算滯后是在做這個業(yè)務(wù)中比較值得考量的一件事情。在餐飲的商家管理系統(tǒng)中，存在諸如優(yōu)惠券、限時折扣、滿減、新客專享、滿贈等一系列營銷活動。這些活動本身會根據(jù)訂單實際總額發(fā)生一定的變化，例如滿減可設(shè)置滿10減5、滿20減8等多個梯度，而用戶在加菜環(huán)節(jié)中訂單的金額是在不斷增加的。

如果將優(yōu)惠計算置前（提交訂單時），一是沒必要，二是對訂單本身的計算存在一定的影響。因為加菜時，例如若訂單金額觸發(fā)了新的滿減，就勢必需要釋放原有滿減內(nèi)容，而需要使用新的滿減梯度進行訂單計算，類似的情況對于優(yōu)惠券這種優(yōu)惠來說，更需要考慮凍結(jié)及釋放的情況。

此外，這里還有細節(jié)需要注意。例如就餐人數(shù)、桌碼選擇后，就不能再更改；加菜的信息提交后，都需要推送最新訂單信息至外設(shè)打印機等；加菜環(huán)節(jié)進入商品列表時，需在購物車保留已選商品信息，但不可編輯；加菜的商品在提交訂單時注明是第幾次加菜的。

2）先付后吃

先付后吃和先吃后付的區(qū)別即是不允許加菜，選擇商品后需支付完成才會通知商家備餐。這種模式相比先吃后付模式就簡單了不少，因為整體的點餐流程只存在一次，因此在提交訂單時即可計算優(yōu)惠并確定訂單整體信息。

2. 點餐模式

對于點餐模式，這里不再詳細說明。

目前，我們設(shè)置了關(guān)閉多人點餐、開啟多人點餐、拼桌模式等3種點餐模式，3種模式商家只可選擇一種。

若關(guān)閉多人點餐，則用戶掃桌碼后，對應(yīng)的桌位狀態(tài)即變更為“已開臺”，其他人若再掃這個桌碼則會提示“桌位已被占用”。這種狀態(tài)的桌位需由商家手動清臺，或商家設(shè)置為支付完成后自動清臺才可重新釋放使用。

若開啟多人點餐，則用戶掃桌碼后，對應(yīng)的桌位狀態(tài)也會變更為“已開臺”，但是其他人掃這個桌碼時不會再提示“桌位已被占用”，而是可以與開臺者一起共同點餐（共同將商品加入購物車）。若開臺者已提交訂單，則其他人掃桌碼則會跳轉(zhuǎn)至訂單詳情，可選擇“繼續(xù)加菜”繼續(xù)點餐。

若開啟拼桌模式，則不同用戶都可掃同一個桌碼，且彼此的訂單是完全獨立的，互相看不到。這種模式下，用戶所掃的桌碼僅用于商家送餐。

3. 其他設(shè)置

在商家端，還可提供諸如清臺設(shè)置、就餐人數(shù)設(shè)置、餐具費設(shè)置等。

清臺設(shè)置可提供商家2種清臺方式：手動清臺、支付完成后自動清臺。若商家設(shè)置為手動清臺，則對于“已開臺”的桌位，即使該桌位的用戶已經(jīng)支付完成，桌臺狀態(tài)依舊為“已開臺”狀態(tài)，除非商家手動對桌位進行清臺處理；若商家設(shè)置為支付完成后自動清臺，則用戶支付完成后，該桌即會自動變更為空閑狀態(tài)，其他用戶可掃桌碼重新開臺。

就餐人數(shù)設(shè)置，可為商家設(shè)置能提供的最大就餐人數(shù)，例如一個門店最大的包廂也只能容納20人，則對該項設(shè)置為20是一個比較合理的值。這樣用戶在小程序點餐時，最多只可選擇就餐人數(shù)為20人。

餐具費是掃桌碼點餐中一個比較常見的費用，即按照就餐人數(shù)收取餐具費，商家可根據(jù)實際情況設(shè)置一個非負的數(shù)值。這樣用戶在點餐時，如果選擇了人數(shù)，則結(jié)算時，會自動根據(jù)設(shè)置的餐具費進行后費。

三、總結(jié)

盡管在掃碼點餐業(yè)務(wù)中，已經(jīng)根據(jù)實際業(yè)務(wù)做了比較多的細分，但是實際場景中還會有更多的合理情況需要考慮。例如，即使門店提供掃桌碼點餐，他還會提供堂食打包外帶服務(wù)，這種情況下就不能再強制用戶掃桌碼等等。

餐飲是一個比較辛苦且競爭激烈的行業(yè)，小程序掃碼點餐是一個提高門店經(jīng)營效率，并可以提供歷史數(shù)據(jù)沉淀和分析的好工具。

現(xiàn)在，也有越來越多的商家在慢慢接受這種信息化的變革，也有越來越多的服務(wù)商在提供類似的技術(shù)支持。

本文的分享僅是個人在做掃碼點餐業(yè)務(wù)時的實踐總結(jié)，如果有不對的地方和需要交流的，歡迎指導(dǎo)交流。

本文由 @堅果 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議