门店原来的样子
顾客约时间靠微信来回问,会员卡和余额记在本子上,员工这个月该拿多少提成月底拿计算器算,几万块流水靠翻记录对账。
一家店还能扛,开到两三家,账就对不上了。
做成了什么
顾客端(小程序):自己挑时间预约、查会员卡和余额、看充值记录、查订单、消费后评价。
门店端(后台):今天谁约了几点、这个月收了多少、哪个员工该拿多少提成,一屏看完。会员、排班、优惠券、对账也都在这里。
优惠券能设门槛——满多少能用、哪些服务能用、什么时候到期。
两条主线
- 人:顾客预约 → 门店排班 → 到店消费 → 记录留存
- 钱:充值 → 余额变动 → 消费扣减 → 提成核算 → 对账
多店是怎么处理的
店长只能看自己那家店的数据,总部能看全部。这是从第一天就按多店设计的,不是单店版本后来硬改的。
用什么做的:uni-app + uniCloud + uView Plus + ECharts。小程序和后台一套代码,数据都在云端。
我负责的:全栈。需求梳理、数据表设计、云端接口、前端页面、测试——从需求到实现一个人走完。
三个关键点:
1. 钱按整数"分"存 —— 不会出现"付了 100,余额显示 99.99"这种事。
2. 订单、余额这类数据,前端改不了,只能走云端接口 —— 防着有人绕过界面直接改钱。
3. 余额扣减和充值记录绑在一起处理 —— 不会出现"扣了钱没记账"或者"记了账没扣钱"。
规模:16 张数据表;33 项回归测试,每次改动后重跑,重点盯金额换算、文件处理、权限边界这几处最容易出错的地方。
可点击原型:https://meiye-prototype.app.workbuddy.host/