开始之前
先把材料备齐,不用再多开标签页。
- 先定好怎么经营:在线订购、餐位预订、服务预约,还是几样一起来。
- 店里真实的菜单或服务清单、价格、营业时间、人员或餐位规则,以及付款政策。
- 工作空间所有者同意你使用这个项目交付档位或云端权限内的模块。
你将学会
- 看得懂 CORE、AUTO、档位、必要条件和建议项分别代表什么。
- 把客户看得到的组件背后那份数据配置好。
- 把客户的动作和它在后台生成的记录一起测。
- 避免在已经上线的项目上做出会毁数据的模块改动。
先想清楚经营流程,再去开模块
看起来很像的两家店,需要的系统可能完全不同。先定客户会产生什么、东西进来之后老板要管什么。
- 客户要挑商品然后提交订单,就用在线订购。
- 客人要按餐位空档挑用餐时间,就用餐位预订。
- 客户要选服务、指定人员、挑时段、报名课程或付定金,就用预约与课程。
- 希望订单和预约自动建立客户档案、以后还能拿来服务,就加上客户模块。
达到这一步就算做完: 你打算开的每个模块,都说得出客户要填什么、可用时段怎么算、钱怎么收,以及数据最后会进后台哪里。
打开模块,先看清楚状态再动手
这个面板会分清楚三种:始终开着的基础、被页面组件点名要用的模块,以及受交付档位限制的可选能力。
- 在左侧工具栏打开模块,确认这个项目显示的交付档位。
- CORE 是一定包含的;AUTO 表示当前页面上有组件正在用它。
- 档位标签是能不能用的边界,不是装饰。在浏览器版里,发布时仍以服务器端的权限为准。
- 只开店家真的答应要经营和维护的模块。
达到这一步就算做完: 每个开启的可选模块,都有指定的负责人、真实的来源数据,也在客户流程里有它的位置。
必要条件照做,建议项看情况
Naratake 会自动把硬性依赖补上,也会建议常一起使用的模块。必要条件不能省;建议项用不到就可以关掉。
- 在线订购一定要有商品目录和支付,通常还会建议加上客户。
- 预约与课程一定要有商品目录,可能还会建议支付和客户。
- 餐位预订可以单独运作,可能会建议加上客户。
- 开完模块后,提示会把必要模块和建议模块分开列出;必要的那一半会一直开着,只有建议的那一半可以关掉。
达到这一步就算做完: 开启的这组模块没有漏掉任何硬性条件,可选的建议也跟实际经营计划对得上。
把客户真的会用到的经营数据填进去
开关打开不等于功能就绪。价格、可用时段、政策和对外的组件,四边都要一致。
- 商品目录和在线订购:填分类、商品、价格、选项、税费处理、自取或配送规则,以及可下单的时段。
- 餐位预订:设置营业时间、餐位数量或容纳人数、可订时段,以及确认方式。
- 预约与课程:设置服务项目、时长、人员排班、时段规则、名额,以及定金政策。
- 用组件把对应的客户端板块放上页面,再用动作设置相关按钮。
- 回到上线指南,把商品目录是空的、营业时间没填之类的警告处理掉。
达到这一步就算做完: 客户看到的板块只会列出有效的商品或时段,提交前显示的金额也跟预期一致。
把店面和后台当成同一条流程来测
最关键的证据是:客户做完一个动作,老板那边就出现他预期要管的那条记录。
- 打开预览 → 店面,实际下一笔测试订单、订座或预约。
- 别只走顺利的那条路,校验报错和空数据状态也要测。
- 把预览切到后台,到订单、订座或预约里找出刚才那条测试记录。
- 把测试记录按状态流程走一遍,核对金额、客户身份和指定的时间。
- 最关键的那条路,再用 Mobile(手机版)宽度重测一遍。
达到这一步就算做完: 店面提交的数据出现在后台正确的区域、细节无误,而且能按经营状态往下推。
改动线上模块,要当成数据迁移,不是改设计
网站上线之后,订单、客户、订座和预约可能已经存在模块专属的数据表里。把模块关掉,下一次部署可能就会要求做出会删数据的结构变更。
- 关掉线上模块之前,先用工作空间支持的功能把受影响的记录导出或备份。
- 确认店家已经停掉这条流程,页面上相关的组件和按钮也去掉了。
- 把编辑器对线上网站的警告整段读完;数据保留计划还不清楚就先取消。
- 变更批准之后,发布前把店面和后台的完整测试再跑一遍。
达到这一步就算做完: 没有任何线上经营模块是在没有老板批准的保留计划、也没有验证过替代流程的情况下被去掉的。
最后检查
这几条全部成立,才算真做完。
- 每个模块都对应到真实的客户动作和负责的人。
- 必要条件、建议项、交付档位和服务器权限都检查过了。
- 商品目录、排期、名额、价格和政策数据都是真的。
- 在店面做一个动作,后台就出现预期的那条记录。
- 在向工作空间申请上线之前,手机版和出错状态的测试都已通过。