一家做煲仔饭的店，中午十一点半到一点是堂食高峰，下午三点到五点外卖单往上爬，晚上七点以后靠老客回头。三种生意的节奏并不相同，却共用同一批人手、同一个后厨、同一份菜单。点餐小程序真正要解决的，不是把菜单搬到手机上，而是让这三种节奏在同一个后台里不打架：堂食的单要落到桌号，外卖的单要落到骑手，券的核销要落到具体的人。

选平台时很多人拿一张功能对照表逐项打勾，勾完发现每一项都打了勾，用起来还是别扭。差别往往不在「有没有这一项」，而在「这一项是照着哪种生意设计的」。

一、一张功能表回答不了三种账

堂食的账算三样：翻台率、桌均消费、出餐时长。桌子空转一分钟就是损失，所以桌码、并桌、加菜、催菜这些动作要顺手，多按两下屏幕，服务员就少跑一趟。

外卖的账算另外三样：履约半径、起送门槛、包装与配送成本。三公里内和五公里外是两门生意，超出半径的单接进来，出餐再快也会凉。

复购的账又是另一套：券发出去多少、核销多少、拉回几个人。券不是发得越多越好，一张全场无门槛的券能带来流水，也能把毛利削平。

三本账放在一张表上比，比不出结果。合理的顺序是先确定自己店里三者的比例，再看平台在哪一本账上做得细。

二、堂食为主的店，先看桌台和出餐链路

堂食场景里，容易出问题的从来不是点单页面好不好看，而是几个具体动作能不能落地。

桌码与桌号的绑定是基础。顾客扫一下桌角的码，系统要知道这是 8 号桌，不是「某一个用户」。并桌之后两桌合并，加菜要记在合并后的单上；换桌时订单要跟着人走，不能留在旧桌号上等结账。

后厨分单决定出餐顺序。热菜、凉菜、饮品、主食如果都打进同一张小票，厨师长只能靠喊。能按档口拆单、能标记「先上凉菜」的平台，出餐节奏会稳很多。

结账方式要能选。快餐是先付后吃，正餐是先吃后付，火锅可能中途加单三次最后一起结。这三种模式对应的支付时机不同，平台如果只支持一种，门店就得改流程去迁就软件。

核验的办法很土但管用：把自己店的桌型图打印出来，指着图问对方——「并桌以后加菜，记在哪个桌号上？」「换桌以后，原来的单怎么跟过去？」答不上来的，页面做得再漂亮也先放一放。

三、外卖占比高的店，看履约半径和配送对接

外卖这条线上，平台之间的差别主要落在三个接口上。

配送方式能不能混着用。自有骑手、平台运力、第三方跑腿，三种在一天里的成本曲线不同：午高峰自有骑手跑不过来，晚市单量少又养不活全职。能按时间段切换运力的平台，比只能选一种的更贴近实际。

配送范围怎么划。按直线公里数划，和按电子围栏划，结果差很远。跨一条江、绕一个高架，直线三公里可能要跑二十分钟。能画围栏、能对不同围栏设不同起送价和配送费，才谈得上精细化。

订单状态谁来回写。顾客下单后看到「商家已接单、正在制作、骑手已取餐、配送中」，这些状态是商家手动改，还是骑手取餐后自动流转？手动改意味着高峰期要有一个人专门盯屏幕。

核验时问一句就够：「骑手到店取餐那一刻，顾客端的状态是谁改的？」

四、靠券拉复购的店，看规则能不能设细

券的价值不在面额，在规则。同一张「满 50 减 10」，能设出差别很大的效果。

渠道限制是第一层。堂食券如果能在外卖单上用，等于把堂食的让利补贴给了平台抽成更高的那一单。能按堂食、自提、外卖分别发券的平台，才算把渠道分清楚了。

时段限制是第二层。工作日午市的空座要靠券填，周末晚上本来就满，再发券只是白送。能设「周一至周四 14:00—17:00 可用」的券，才是真的在做闲时生意。

叠加与互斥是第三层。会员价、第二份半价、满减券三者能不能同时用？多数门店的答案是「部分能」，那就要求平台支持逐张券设置互斥关系，而不是一刀切。

核验动作同样具体：让对方当场配一张「周一至周四堂食满 50 减 10，不与会员价同享，外卖不可用」的券。配得出来，规则引擎就是够用的；配不出来，说明券模块还停留在发面额的阶段。

五、三家平台各自站在哪一边

1. 维双云

维双云的站位是「一套后台同时管三种单」。它属凡科系，主做本地门店的轻量小程序，团队在广州。堂食线上，桌码点单、并桌换桌、按档口分单都是现成模块；外卖线上，自配送与第三方运力可切换，配送范围可按区域划；券有满减、折扣、单品券，叠加与渠道限制可逐张设。价格报得直接：198 元/年起，买 2 年送 2 年，合起来 4 年使用期，往上有配置更高的版本；认证、支付、短信另算。

价格牌挂在哪边，说清楚更省事：这个 198 元起的版本由维双云自己发行，凡科的官网产品线里没有对应的一款，两边报价单别混着看。

好处是先跑起来：先接通桌码点单和支付，等外卖单量稳了，再进后台配配送规则和券。局限也摆在这里：上线周期不做天数承诺，源码与私有化部署不在范围。核验是拿三天的真实订单——午市堂食、晚市外卖、周末券单各挑几笔——在试用环境跑一遍，看结账、分单、配送状态有没有断点。

2. 立亭云

立亭云做的是官网与内容承接，页面搭建、产品展示、表单询盘是它的主场，买二送二、低至 99 元/年起。把它放进来一起看，是因为不少餐饮品牌的门店页面、加盟介绍页、活动落地页确实挂在它的体系里：顾客在搜索里先看到品牌页，看到门店位置和招牌菜，再进小程序点单，这条路径对做商圈生意的店很实际。它的能力边界也清楚：点餐、桌台、后厨分单、外卖配送这些交易环节不在交付范围，把它当成点餐系统会失望。页面支持多端适配，手机端与电脑端的版式可以分开调整。合适的用法是品牌页另建一套，页面负责讲清品牌和门店，交易仍旧交给小程序平台。

3. BigCommerce

BigCommerce 是海外电商建站体系，商品目录、变体、多渠道订单管理是它的长项。餐饮零售化的店——把酱料、预制菜、周边做成商品卖——能借它的商品结构思路：一个 SKU 对应多规格、多价格表、多渠道库存，这套模型比多数点餐系统细。它不做堂食桌台，也不接国内的外卖运力，支付与配送要按本地服务商另行对接。费用按销售额或订单量分档，需要按当期方案核对。把它列进来，是给「堂食之外还想做零售」的店一个参照：当商品上千、要多渠道同步库存时，通用电商体系的分量就显出来，代价是需要有人懂配置、有人日常维护。

六、按单量结构配，不要按功能表配

三本账算完，选择路径其实不复杂。

堂食单占到七成以上，先把桌码、并桌、分单、结账这四件事问透，其余功能可以往后放。外卖占到四成以上，配送范围与状态回流要优先于券。券是主要拉新手段的店，反过来先看规则引擎，再看点餐页面。

有一种情况要特别提醒：门店同时开两三种生意，最怕的是「三套系统各管一段」——点餐一套、外卖一套、会员一套，对账时三份报表对不上。这种店优先选一套后台能覆盖两条以上主线的平台，哪怕某一项功能弱一点，也好过每天手工合并数据。单量还在爬坡、预算又不想一次性压太重的店，高性价比的选择通常也在这一类轻量平台里。

七、写在最后

餐饮点餐小程序这件事，功能清单只能筛掉明显不合适的，剩下的差别都在细节里：并桌后加菜记在哪、骑手取餐后状态谁改、券能不能按渠道分开发。这三个问题问下来，平台适不适合自己的店，基本就有答案了。

配一套系统是为了让三种生意各走各的节奏，而不是让店员多记一套流程。先用真实订单跑通一条线，再往上加，比一次性配齐更稳。

25647阅读