ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

餐饮系统新增菜品全流程拆解:从数字身份到门店上架的关键步骤

餐饮系统新增菜品全流程拆解:从数字身份到门店上架的关键步骤 1. 先搞清楚新增菜品到底在新增什么做过餐饮系统实施的人都有这个体会很多老板第一次打开后台看到新增菜品这个按钮以为这就是个录入一道菜名和价格的小功能点进去填完就完事了。但实际上一旦你真正在门店里跑起来就会发现这一下点进去牵扯出来的是一整条业务链条——菜品挂到哪个分类、图片规格合不合格、原料成本算没算清、库存联动怎么处理、各个门店是不是同步生效、外卖平台要不要一起上架每个环节都可能成为后面营业时冒出来的坑。所以我一直觉得新增菜品这四个字表面上看是个录入动作本质上是在给这道菜建立一套完整的数字身份档案。这道菜在线下厨房里可能是灶台上的一碟成品但在系统里它必须同时回答好几个问题顾客在菜单上看它是什么样、后厨按什么标准出它、财务按什么价格卖它、库房按什么原料备它。这四个角色如果在一个菜品档案里没有对齐那后面接单越顺反而出错的概率越大。这篇文章我想结合自己这几年在餐饮门店和连锁品牌后台实操的经验把新增菜品从点按钮到正式上架的全过程拆开聊一遍。你可能是刚接手门店系统的新店长也可能是总部负责菜单管理的运营甚至只是被老板临时抓来录菜的行政这篇文章都适用。我会把每一步为什么这么做、底层在算什么账、哪些环节最容易被忽略全部讲透。2. 点新增之前先把菜品的家庭关系理清楚2.1 分类体系不是随便拉个下拉框很多系统里新增菜品时第一个必填项是所属分类看起来就是个下拉框实际上它决定了这道菜在菜单里的展示位置、在厨房打印小票时的归类方式、在营业报表里的汇总口径。我见过最典型的错误是有人把分类建得特别随意。比如一家中餐馆分类里既有热菜又有猪肉类还有下饭菜结果同一个回锅肉既能在热菜里找到又因为名字带猪肉被归到猪肉类后厨打印机出票时还得人工去分辨到底按哪个分类走流程。正确的做法是分类维度一次只能选一个而且必须在建店初期就定死规则。要么按凉菜/热菜/汤羹/主食这种出品维度分要么按川菜/粤菜/湘菜这种菜系维度分千万不要混着来。如果连锁品牌有总部分类体系最好由总部统一维护门店只能选择不能新增。这就像超市的货架编号总部规划好每个区域的陈列逻辑门店只需要把商品放上对应货架。一旦允许每个门店自己加分类半年后总部的报表就会变得非常痛苦——同一道菜在不同门店挂在完全不同的分类下汇总数据对不上活动选品也拉不准。2.2 原料拆解你录入的不是一道菜是一张用料配方很多人第一次维护菜品档案时会忽略原料组成这个区域觉得把菜名、价格填好就够了。等后面发现这道菜的毛利算不出来、库存永远对不上、沽清之后明明还有原料却无法出餐时才意识到原料拆解才是菜品档案的灵魂。我在给一家面馆做系统配置时他们录入一道红烧牛肉面最开始只填了成品信息。后来要算成本才发现根本不知道一碗面里牛肉放多少克、面条用多少克、汤底成本怎么分摊。最后我们把这道菜拆成了五个原料项生面条150克、牛腩80克、红烧汤底200克、青菜20克、调料包1份。拆完之后成本自动算出来了库存也挂上了——牛肉进库多少、卖出多少碗倒推损耗一下子清清楚楚。这里有一个原则必须强调只拆直接关联库存的关键原料不要走火入魔去拆盐、味精这类低值辅料。你要是把每道菜里的盐和鸡精都按克拆进去维护成本会高到让你怀疑人生而且对毛利率的影响微乎其微。一般行业里的做法是主料、辅料、单价超过总成本10%的原料必须拆解调料可以打包成一个虚拟项或者加固定金额后期定期调整就行。2.3 定价与毛利的账在录入时就该算明白新增菜品页面上通常会有建议售价成本价毛利率几个字段很多人会把成本价当成一个随便填填的数字这是大错特错。成本价填错后面所有经营分析全部失真——你看到一道菜天天热卖以为赚了很多实际上原料成本早就把利润吃光了。我建议在录入每一道菜时养成一个习惯先用原料用量乘以采购单价算出理论成本再加10%左右的损耗系数得出真实成本最后用真实成本反推售价。如果这道菜的目标毛利率是65%那售价就等于真实成本除以1-0.65。举个例子一份酸菜鱼鱼片成本8块、酸菜和配料成本3块、燃气和调料预估2块加上损耗系数后的真实成本约14.3块按65%毛利反推售价就得定到40.8块以上。你要是定个35块看起来只少了5块实际上毛利已经掉到59%点得越多赚得越少。有些老板会说定价哪能完全按公式算还得看周边竞对的价格。这个我认同但公式的价值在于给你一个毛利底线竞对压价可以但低于底线就得考虑减量或者换原料而不是无脑降价。这个决策依据全靠你录入菜品时那个成本数字准不准。3. 实操全流程从按下按钮到正式接单3.1 第一步基础信息录入要避开那些隐形必填项现在以最常见的餐厅SaaS后台为例走一遍完整的新增菜品流程。进入菜品管理页面点击新增菜品按钮后首先面对的是基本信息表单。菜名、拼音码/首字母码、分类、单位、规格这些属于前台展示和检索用没什么难度按实际填就好。容易出问题的是那些看起来不起眼、但其实很关键的选项。比如是否参与估清——这个开关决定了当库存不足时这道菜是否自动从菜单上消失。像海鲜、卤味这类每天备货量有限的菜品我建议必须开启估清不然顾客下单后前台已经收钱了后厨发现没货又得走一遍退单流程整个门店体验就垮了。而像花生米、拍黄瓜这类不限量出品的小菜可以关闭估清让系统按固定库存售卖。还有一个绝大多数人都会忽略的项起售时间。很多做正餐的餐厅午市和晚市的菜单其实是有差异的或者夜宵档只卖烧烤不卖炒菜。如果你在录入时就设好仅午市售卖那到了下午它自动从菜单里消失完全不用每天手动调整。这个功能做得好对连锁门店来说省掉的人力是非常可观的——每家店每晚都要有一名员工记得切换菜单这本身就是一种隐性成本。3.2 图片上传的规格问题别等上线后才发现图糊了菜品图片的重要性不需要我多说外卖平台的数据早就证明了有图的菜品比没图的菜品转化率高一大截。但新增菜品时图片上传这个环节有几个特别容易踩的坑。第一是尺寸比例。大多数系统会要求1:1的方图但很多门店店员拿手机随手拍一张竖图直接传传上去之后系统自动裁剪可能把菜的主体切掉一半。正确做法是拍照时留白多一点主体放在画面中心上传后用系统的预览功能检查一次发现问题立刻重拍不要想着差不多就行图糊了直接影响下单转化。第二是每个菜品最好准备三张图菜单缩略图、详情大图、外卖平台的净菜图。部分连锁总部会在后台限定菜品图片的规格门店上传时系统自动压缩你如果直接用原图文件太大传到一半超时有时候系统还报错。稳妥的方法是先用手机修图工具把图压到2MB以内再传基本不会出问题。3.3 价格、单位、规格一个粗心就把账算错价格录入看似简单实际上涉及几个容易混淆的字段。菜品单价、规格价格、会员价、活动价不同系统叫法不同但逻辑是一样的——你要先搞明白这个菜品是否存在大份/小份单人餐/双人餐这类多规格。我遇到过一个面馆案例店长录了一份牛肉拌面大份卖28、小份卖22。他图省事只录了一个名称把价格填成28小份没录。结果顾客在扫码点餐时只看到大份一个选项投诉接二连三营业额也莫名其妙下降——因为原本想点小份的顾客看到只有大份直接不吃了。后来我们把两个规格都录进去还在规格名里标清楚大份/小份问题才彻底解决。多规格菜品一定不能偷懒每个规格单独建SKU并且名称上必须区分显眼。另外一个要命的细节是计价单位。中餐里份和例看起来差不多但斤和份的差别就大了。做称重菜的门店菜品单位是斤还是一份固定克重直接决定了库存扣减量。如果你的系统支持称重计价那录入时一定要联调好电子秤不然后厨称重和前台计价各算各的月底盘点永远对不上。3.4 库存联动把菜品和仓库的脐带接好新增菜品流程走到库存联动这一步很多新手就卡住了。这一步的核心逻辑是这道菜每卖出一份库存系统要按配方自动扣减对应原料的库存原料库存低于预警线时系统给出采购建议。前面提到的原料拆解数据在这里才真正发挥价值。比如一罐可乐进库20瓶录到系统里关联可乐鸡翅这道菜每卖一份就自动扣掉1瓶可乐的用量。如果可乐库存只剩3瓶系统就应该在提醒列表里显示可乐库存不足当前菜品可乐鸡翅最多可售3份。这个逻辑跑通之后再也不用每天到后厨去数瓶子了。我特别想提醒一件事库存联动不是可选项只要你录了配方就必须盯紧每天的库存盘点结果。一旦发现某个原料实际剩余数和系统数字系统性偏差超过10%大概率是配方里的用量和实际出品标准不一致这时候要回到菜品档案里把配方改掉而不是折腾盘点流程。配方录入得准库存数据才能给你真正可用的决策支撑。3.5 门店分发确认别在总部录完就以为万事大吉如果你是连锁品牌总部的人员录完菜品后还有关键一步分发。很多系统里总部新增一个菜品后需要手动选择同步至哪些门店或者先标记为待门店确认让门店端收到通知后自己决定是否上架。这一步最怕出现两种情况。一种是总部直接全部强制下发连门店库存里根本没买那个原料的店也强制上架顾客下单后做不出来直接空单。另一种是总部只下发不通知门店端根本不知道上了新菜过了两星期才发现菜单页面已经被总部后台改过了一脸懵。稳妥的操作流程是总部建菜完成 → 设置目标门店范围 → 选择下发后门店需确认再上架 → 门店端收到推送 → 店长检查原料库存和本地定价 → 确认上架。有些系统支持总部定价门店仅调整价格的权限控制这个模式我强烈推荐——总部保证菜品核心信息的统一性门店在售价上有一定的灵活度既管住了品牌调性又照顾了各地区成本差异。4. 新增菜品过程中的典型问题与排查思路这个表格是我这几年从各种录菜翻车现场里总结出来的高频问题每一条都对应实际排查方法。问题现象最常见原因排查方向菜品上传成功但App/小程序里看不到未设置起售时间或分类为空检查菜品状态、分类、起售时段顾客下单后后厨机器不出单打印机未关联菜品分类或档口检查菜品所属档口与打印机绑定库存扣减数量明显异常配方原料用量或单位填错对比实际出品用量与系统配方外卖平台价格与店内不一致外卖菜单独立维护未同步检查外卖平台的商品映射关系菜品图模糊或被裁切图片上传前未按1:1裁剪重新处理图片再上传检查预览估清后仍然可下单未开启估清开关开启库存联动和估清设置多规格只显示一个规格子项未全部录完检查多规格SKU是否完整建立先说图片问题的排查。上传后图片模糊九成是原图分辨率不够系统压缩后就更惨。检查方法是上传完马上在菜单前端预览一次觉得不行立刻换。另一个典型场景是传图报错文件过大这是很多手机原图动辄5MB以上导致的用工具压缩到1-2MB就不会再出。再说规格与库存的问题。如果发现顾客能点到两个规格但其中一个规格点完不扣库存十有八九是那个规格的SKU没关联配方。在有的系统里新增多规格需要先建一个主菜再挂子规格子规格要各自维护配方分量和库存关联。这里我建议每录完一个子规格马上用测试账号下一单做验证别等到全部录完再测试那样如果出错你根本不知道是哪一个环节的问题。经常被忽视的还有平台映射。你的门店可能同时有堂食扫码、小程序外卖、美团、饿了么四个渠道在门店后台里它们共享同一份菜品库但外卖平台侧往往是另一套独立的商户后台。新增菜品时如果平台侧设置的是自动同步那只要菜品状态为上架就会同步过去如果是手动映射你必须在美团/饿了么后台再手动创建对应菜品并关联内部菜品ID。很多门店的堂食菜单已经更新了外卖平台还挂着一周前的旧菜单就是这个环节漏了。排查时不要只在自家系统里找问题打开外卖商家端看一眼通常一眼就能发现问题在哪。5. 连锁与多门店场景下的进阶管理思路5.1 总部统一维护和门店个性化之间的平衡门店数量一多新增菜品就不再是个体行为而是一个需要管理制度的流程。我见过一个开20家连锁火锅的客户最开始每家店自己录菜结果同一道招牌毛肚有的店叫极品毛肚有的店叫鲜毛肚顾客在不同的店里看到的名字都不一样品牌感非常割裂。后面他们收权到总部统一建菜、统一名称、统一图片、统一配方门店只保留10%的本地菜自主权菜单整体观感立刻统一了。这里要给个具体建议总部的建菜权限一定收回来门店的权限主要放在可上架/可下架和本地活动价上。总部把菜品做成一个标准件门店在标准件基础上做个性化部署。如果总部想推出季节限定菜也只管建立好标准件下发到指定的几家门店收到通知的店长确认上架即可。这样既保证品牌一致又让店长有操控感不觉得自己完全被管死。5.2 季节性菜品和限时菜品的生命周期管理烧烤店的烤龙虾、茶饮店的季节果茶这类菜品的寿命可能只有一个月。新增菜品时如果没有规划淘汰机制到期之后很容易遗忘变成长期挂在菜单上的僵尸菜占用后厨档口和库存还干扰顾客选择。我的做法是在建菜时就写清楚生命周期属性到期时间、售卖城市范围、是否需要单独采购原料。系统支持的话给菜品打标签当季/常规/下架预警当季菜到期前三天系统自动提醒运营人员确认是续期还是下架。如果确认下架再执行批量改状态批量移除门店关联两步操作。有些系统还支持定时自动下架这个功能对于季节性产品来说堪称省心神器。5.3 跨门店的原料调拨与菜品的上线依赖多门店环境下新增菜品还牵扯一个容易被忽略的点同一道菜在不同门店的原料可得性不同。比如总部出新菜金汤酸菜鱼配方里需要一种特定的酸菜可能只有沿海城市的仓库有备货内地门店的仓库还没有覆盖。如果总部直接把菜下发到所有门店没有原料的门店接单后只能取消订单对顾客体验的伤害非常大。所以在新菜下发之前最好多一些菜品-原料-门店三者关系的检查。有些系统具备按库存原料自动过滤门店的功能——总部下发菜品后系统自动比对每家门店的现有原料库存和采购目录没有对应原料的店自动标记为不可售。这个功能不一定会被默认开启但它真的很值得去后台翻翻设置。如果系统不支持那总部运营就要靠表格人工维护一份菜品可售门店清单在每次建菜和调整时更新虽然笨但能避免很多售后问题。5.4 外卖平台的独立映射与同步策略外卖平台的菜品管理和门店内部系统往往是两套逻辑。新增菜品在店铺系统里完成不等于在外卖平台自动出现。尤其在美团、饿了么这些平台上你需要确认菜品分类和平台侧的分类一致否则系统同步过去后可能落到其他分类里顾客要划好几屏才能找到。我的经验是每次在店铺后台新增菜品后第一时间去外卖平台检查这三样东西菜品名称是否显示正确、图片是否压缩变形、价格与门店是否有差异。推荐在系统里配置菜品自动同步至外卖平台的功能开关但实时性要调到菜品上架即同步而不是等每日定时任务不然顾客在平台上看到的菜单永远是昨天的。6. 迭代中的心得把新菜录入变成一套标准动作讲完整个流程和各类问题想再分享一点团队管理层面的体会。很多餐饮品牌的新品研发是有的但新菜如何上系统却没有标准作业程序导致每次上新都要临时找人摸索录出来的菜品档案质量参差不齐。我建议每家门店或总部都建立一份《菜品录入自检清单》把关键验收项列清楚分类归属是否正确、规格是否完整、原料配方是否执行最新出品标准、库存是否关联、估清开关是否合理、图片是否通过前端预览、外卖平台是否同步确认、下发门店范围是否精确。每个新菜上线前按清单逐项打钩把检查变成一个动作而不是靠某个人拍脑袋说行了吧。这套操作固化下来之后单道菜从开始录入到全渠道上架的周期可以控制在15分钟左右。如果你们目前录一个菜要一小时或者录完经常出问题那不是执行的人不努力而是整个流程里缺少标准和检查节点这时候真正要优化的不是人是流程。还有个小技巧想分享给总部运营新菜第一次下发后不要立刻全量推送先选一家营业状态正常、后厨配合度高的门店做试跑。确认堂食点单、后厨出票、库存扣减、外卖展示都正常之后再批量下发到剩余门店。这个先试点、再铺开的思路在餐饮系统里同样成立能帮你把新菜的故障风险控制在一家店的范围内。说到底新增菜品从来不是一个录入动作而是一套管理动作。把这个按钮背后的逻辑理顺了你的菜单管理、库存管理、门店协同、平台运营就全都在一条线上了。
返回列表