到店服务预约小程序
预约、核销、会员一体交付，把高峰期占线与排班混乱收进可管理的时段库存。
背景
顾客主要靠电话预约，高峰占线；前台用共享表格排班，改约经常漏通知。
会员卡、次卡、活动价规则散落在口头约定，核销对不上账。
老板希望先验证“线上预约能否拉高翻台与复购”，暂不做独立 App。
约束
- 首期预算锁定在小程序 + 门店后台，不做原生 App
- 技师排班规则因店而异，但不能做成每店一套定制代码
- 必须对接微信支付与订阅消息，提审时间要计入排期
真正的难点
业务规则看起来简单，实际卡在“时段库存、技师技能、会员权益”三者交叉：改约、爽约、跨店核销稍有含糊，上线后就会天天改需求。
关键取舍
用时段库存做核心模型，技师是资源属性
先售卖可预约时段，再绑定可服务技师。避免一上来做复杂人力资源排班引擎，首期就能让前台少接电话。
会员权益配置化，不做硬编码活动
次卡、折扣、生日礼用规则表配置。运营改活动不走发版，减少“活动上线要等两周开发”的摩擦。
门店端优先“今日看板”，而不是功能大全
店长每天只看：待到店、待核销、空档、改约。报表后置到二期，保证一线真的用起来。
怎么做的
顾客端小程序：选店、选项目、选时段、支付、改约与到店提醒。
门店后台：技师排班、时段库存、核销、会员积分与基础经营数据。
接入微信支付与订阅消息；爽约/改约规则在上线前与老板书面确认，写进验收用例。
可核对的结果
电话预约占比明显下降试点门店高峰占线投诉减少，前台转处理改约与投诉
空档时段利用率提升可视化空档后，运营可定向推午间场次
会员复购可追踪次卡剩余与到店频次进入同一数据视图
10 周内过审上线含 1 轮微信审核驳回后的材料补交
复盘
- 预约类项目要把“改约/爽约/迟到”规则当成核心功能，而不是上线后再补。
- 门店是否采用，取决于今日看板是否比微信群/表格更快，不取决于后台菜单多不多。
- 提审与支付进件并行推进，否则开发完还要干等。
技术栈
微信小程序Node.js APIMySQL微信支付